From: jzakiya Date: 2009-12-23T12:50:19+09:00 Subject: Re: Trig value errors On Dec 22, 9:38 pm, Phillip Gawlowski wrote: > On 23.12.2009 03:10, jzakiya wrote: > > > But...being able to do ACCURATE MATH creates benefits > > that far supercede any hassles to write the core to do it. > > Floats won't be properly accurate in a mathematical sense, anyway, since > they are approximations. Their accuracy is highly dependend on the WORD > length of a CPU / Mathematical Co-processor (i.e. 8bit, 16bit, 32bit, > 64bit, 128bit, etc). > > Further reading provides:http://en.wikipedia.org/wiki/IEEE_754-2008 > > Your apparently required level of accuracy is the realm of specialized > math libraries, if not specialized languages and/or hardware, since it > isn't needed in most (any?) circumstances by Average J. Programmer. Only > a select few of us get to write code for, say, CERN. ;) > > Then there's existing code to consider. AFAIK, IEEE 754 is the way Ruby > handles floating point numbers, and there *will* be code that relies, > for better or for worse, on this behavior (and rather rightly, since > IEEE 754 is the accepted standard to handle floats), and a higher level > of accuracy could cause quite a number of ripple effects, requiring a > carefully planned change (maybe an eventual Ruby 2.0 even). > > -- > Phillip Gawlowski The reason I made the distinction between 'mathematical' versus 'arithmetical' accuracy is because 'mathematical' accuracy, in the case of the trig values, REQUIRES the trig values on an axis to defined as +1, -1, or 0. There are no mathematical ambiguities at these points. The issue I am raising is not a floating point issue, or how you choose to compute the trig values (series expansion, or whatever). I'm saying the current trigs implementations has by design (a choice of priorities) decided to return mathematically erroneous results, even though they may be computed arithmetically accurate. I am requesting that the trig functions return the correct 'mathematically' results that are inherent for the specific cases for angles n*PI/2, which REQUIRES that sin/cos=1,0,-1. As I showed in my examples, this decision is being done in some cases, but not others. We know cos(PI/2)=0 not 6.123023176911189e-17, so round it, truncate, whatever, to 0. Make it mathematically correct by whatever arithmetic process you choose. It's not about how many decimal places of arithmetic accuracy being represented, it's a matter of conceptual accuracy that the language has MADE A CHOICE not to satisfy.