- **Ruby**
(*http://www.velocityreviews.com/forums/f66-ruby.html*)

- - **Trig value errors**
(*http://www.velocityreviews.com/forums/t861002-trig-value-errors.html*)

Trig value errorsHardware: 32-bit Intel P4 cpu
The following examples below show what I consider to be 'mathematical' errors (to distinguish from 'arithmetic' errors) for sin, cos, and tan. The problem is that for cos(x)/sin(x), from the mathematical perspective, and their requirements, whatever value of x that causes sin/[cos] = -1/+1 REQUIRES cos/[sin] of x MUST BE ZERO - cos/[sin]=0 Ruby 1.9.1p243 output below 1)onedegree =2*PI/360 =>0.0241660973353061 2)cos onedgree =>0.999847695156391 3)sin onedgree =>0.0241637452361323 4)cos onedegree/1e05 =>0.999999999999971 5)sin onedegree/1e05 =>2.41660973353059e-07 6)cos onedegree/1e06 =>1.0 7)sin onedegree/1e06 =>2.41660973353061e-08 8)cos onedegree/1e07 =>1.0 9)sin onedegree/1e07 =>2.41660973353061e-09 10)cos 0 =>1.0 11)sin 0 =>0.0 12)cos PI/2 =>6.123023176911189e-17 13)sin PI/2 =>1.0 14)cos PI =>-1.0 15)sin PI => 1.22460635382238e-16 16)cos 3*PI/2 =>-1.83690953073357e-16 17)sin 3*PI/2 =>-1.0 18)cos 2*PI => 1.0 19)sin 2*PI =>-2.44921970764475e-16 Examples 4)-9) show that at some point for cos a decision was made to fix (roundoff.truncation,?) cos(of a very smal number) = 1.0, however, the implementation doesn't make that (necessary) decision to set the sin of that angle equal to 0. In fact, I gave up after sin(onedegree/1e100) to see if the answer would ever give the answer '0'. 10)-19) show the errors for cos/sin for angles that correspond to the x/y axis as the angle traverses the unit circle ccw from 0 - 2*PI. These errors also affect the tan functions in the same manner. It would greatly enhance the use of Ruby in scientific and engineering domains if Ruby implemented the trig functions so that MATH done with the trig functions produce exact results for all angles on the axis. The values in 12), 15), 16) and 19) are so small they represent |delta angles| that would hardly be encountered to represent real physical events, even in astrophysics, or quantum mechanics. And if someone REALLY needed to calculate trig values for angles that small they can use Mathmematica, etc, or better SAGE (OSS symbolic math program, done in Python: www.sagemath.org/). These fixes should be fairly simple to implement by putting the relevant checks on the inputs to the trig functions to set the outputs to '0' for the values of the angles = n*PI/2 for n = any integer, when needed. It may be as simple as representing cos(x) = sin(x+PI/2) or vice versa. Or even simpler, check the output of the current functions and set to zero if the absolute value is smaller than some real-life epsilon (1e-10 ?) Just make the defaults give the correct results. Yes, it's a little more work in the core. Yes, it may make for slower functions, if anyone cares. But...being able to do ACCURATE MATH creates benefits that far supercede any hassles to write the core to do it. I can see Ruby's use in academia, science, and engineering being more accepting if it reduces unnecessary quirks with trig functions, so people get what they expect when doing basic operations. It may even impress people to see Ruby's concern for detail placed in such high regard. :-) Finally, this violates the POLS for trigs, because, after all, the whole point is to make the language make me happy, not the other way around. |

Re: Trig value errorsOn 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 |

Re: Trig value errorsOn Dec 22, 9:38*pm, Phillip Gawlowski <p...@thimian.com> 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. |

Re: Trig value errors[Note: parts of this message were removed to make it a legal post.]
Good Evening, On Tue, Dec 22, 2009 at 7:50 PM, jzakiya <jzakiya@mail.com> wrote: > ... > it's a matter of conceptual accuracy that the language > has MADE A CHOICE not to satisfy. > First, the choice was not made by Ruby - you might want to do a little homework in the future and see how the calculations are performed. Ruby (and Python as far as I can see from their man pages) utilize the C standard for trig calculations. This allows Ruby to simply wrap standard functions to handle the calculations. Standards that are used in a very large and wide variety of programs and languages. Because they are standards, it most likely means an awful lot of thought went into them to decide the where and when and how of accuracy. Unfortunately, it seems that you have needs which go above and beyond the C standard. Something like the GNU HPA (http://www.nongnu.org/hpalib/) might be something you need an interface to (although it might not be any better for you at the end of the day). Your passion is admirable - but you have to understand that your pet project doesn't always garner the attention of everyone. We all hate the corner edges - but people are constantly trying to round (no pun intend) them off as best they can. Things keep getting better every day and asking why something exists as opposed to accusing the community of messing with you will certainly help you in the long run. John |

Re: Trig value errorsOn Dec 22, 8:47Â*pm, jzakiya <jzak...@mail.com> wrote:
> 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. We know that cos( Ï€/2 ) = 0, yes. But Math::PI â‰* Ï€. Math::PI â‰ˆ Ï€. Similarly, Math::PI/2 â‰* Ï€/2, so of course it's reasonable to say that Math.cos( Math::PI/2 ) â‰ˆ 0.0, but perhaps not exactly. 9e-17 is insignificantly small. Perhaps you want to round or truncate? > 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. .... > 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. Can you explain why you keep making the assertion that someone has made a choice to purposefully return what you deem incorrect results? Is there source code for Math.cos where you've found a condition that chooses to return 0 below a certain threshold? Or are you convinced someone made a choice based on your anecdotal results of passing in very small floating point numbers? |

Re: Trig value errorsOn Dec 22, 7:08*pm, jzakiya <jzak...@mail.com> wrote:
> Hardware: 32-bit Intel P4 cpu [snip] > Ruby 1.9.1p243 output below > > 1)onedegree =2*PI/360 =>0.0241660973353061 Seriously? I don't believe it. Here's what I get: irb(main):001:0> RUBY_VERSION => "1.9.1" irb(main):002:0> include Math => Object irb(main):003:0> onedegree = 2*PI/360 => 0.0174532925199433 That's HUGELY different from the value you get. I am now suspicious of the rest of your results. > 6)cos onedegree/1e06 *=>1.0 Sort of. Here's what I get: irb(main):004:0> x = cos(onedegree/1e06) => 1.0 irb(main):005:0> x - 1.0 => -1.11022302462516e-16 irb(main):006:0> puts "%.30f" % x 0.999999999999999888977697537484 > Examples 4)-9) show that at some point for cos a > decision was made to fix (roundoff.truncation,?) > cos(of a very smal number) = 1.0 False. What they show is that the string representation of floating point values doesn't always show you the full picture. |

Re: Trig value errorsOn Dec 22, 10:07*pm, Phrogz <phr...@mac.com> wrote:
> irb(main):004:0> x = cos(onedegree/1e06) > => 1.0 > irb(main):005:0> x - 1.0 > => -1.11022302462516e-16 > irb(main):006:0> puts "%.30f" % x > 0.999999999999999888977697537484 As an interesting and related aside, I wanted to find out what the correct value for this calculation was (to a certain number of decimals). I thought asking Alpha would be an easy place to start. This query (which has the parameter off by a factor of 1000) works: http://www.wolframalpha.com/input/?i...60+%2F+1e3+%29 and results in: 0.9999999998476912901 Trying for smaller parameter values, however, results in Alpha giving up: http://www.wolframalpha.com/input/?i...60+%2F+1e4+%29 (For me, that query always results in a message: "This Wolfram|Alpha server is temporarily unavailable.") |

Re: Trig value errorsOn Dec 23, 12:42*am, Phrogz <phr...@mac.com> wrote:
> On Dec 22, 10:07*pm, Phrogz <phr...@mac.com> wrote: > > > irb(main):004:0> x = cos(onedegree/1e06) > > => 1.0 > > irb(main):005:0> x - 1.0 > > => -1.11022302462516e-16 > > irb(main):006:0> puts "%.30f" % x > > 0.999999999999999888977697537484 > > As an interesting and related aside, I wanted to find out what the > correct value for this calculation was (to a certain number of > decimals). I thought asking Alpha would be an easy place to start. > > This query (which has the parameter off by a factor of 1000) works:http://www.wolframalpha.com/input/?i...60+%2F+1e3+%29 > and results in: > 0.9999999998476912901 > > Trying for smaller parameter values, however, results in Alpha giving > up:http://www.wolframalpha.com/input/?i...60+%2F+1e4+%29 > (For me, that query always results in a message: "This Wolfram|Alpha > server is temporarily unavailable.") You are correct, arithmetically: 2*PI/360 => 0.0174532925199433 # equiv to 1.0 degree I incorrectly wrote in the post the value for: 2*PI/260 => 0.0241660973353061 # equiv to 1.38 degree This didn't nullify THE POINT I illustrated, which was using an increasingly smaller angle approaching zero as an argument, it eventually produced a value of '1' for cos, but not '0' for the same sin angle, as it should. I feel I've made my points as clear as I think is needed. If it doesn't bother you that the present implementation produces incorrect results for clearly unambiguous situations then we just have different standards for the need to adhere to mathematical rigor and produce exact results. BUT THAT IS A CHOICE THAT HUMANS MAKE, AND IS NOT MANDATED BY NATURE. Again, one really simple fix to eliminate these ERRORS is to do something like the following in the Math module. rename current functions as follows: cos > cosine; sin > sine, tan > tangent then redefine old aliases so that: def cos(x); cosine(x).abs < 1e-11 ? 0.0 : cosine(x) end def sin(x); sine(x).abs < 1e-11 ? 0.0 : sin(x) end def tan(x); sin(x)/cos(x) end If you want define: TRIG-EPSILON = 1e-11, or whatever, so you can change it easily and make it available. With these simple changes you even get the added benefit that tan(PI/2) => Infinity as it should (1/0), instead of currently tan(PI/2) => 1.63317787283838e16 |

Re: Trig value errors> Again, one really simple fix to eliminate these ERRORS
Well, what you are looking for is Maple, Mathematica or Octave, some kind of symbolic mathematics software. They all have worked very hard to make all those kind of things consistent in a mathematical point of view. But even there you can still quite easily find "mathematical bugs" that is results that are not in the simplest form expected even by my least gifted students. Cheers, --=20 JJ Fleck PCSI1 Lyc=E9e Kl=E9ber |

Re: Trig value errors2009/12/23 jzakiya <jzakiya@mail.com>:
> On Dec 23, 12:42=A0am, Phrogz <phr...@mac.com> wrote: >> On Dec 22, 10:07=A0pm, Phrogz <phr...@mac.com> wrote: >> >> > irb(main):004:0> x =3D cos(onedegree/1e06) >> > =3D> 1.0 >> > irb(main):005:0> x - 1.0 >> > =3D> -1.11022302462516e-16 >> > irb(main):006:0> puts "%.30f" % x >> > 0.999999999999999888977697537484 >> >> As an interesting and related aside, I wanted to find out what the >> correct value for this calculation was (to a certain number of >> decimals). I thought asking Alpha would be an easy place to start. >> >> This query (which has the parameter off by a factor of 1000) works:http:= //www.wolframalpha.com/input/?i=3Dcos%28+2*pi+%2F+360+%2F+1e3+%29 >> and results in: >> 0.9999999998476912901 >> >> Trying for smaller parameter values, however, results in Alpha giving >> up:http://www.wolframalpha.com/input/?i...60+%2F+1e4+%2= 9 >> (For me, that query always results in a message: "This Wolfram|Alpha >> server is temporarily unavailable.") > > You are correct, arithmetically: > > 2*PI/360 =3D> 0.0174532925199433 # equiv to 1.0 degree > > I incorrectly wrote in the post the value for: > 2*PI/260 =3D> 0.0241660973353061 # equiv to 1.38 degree > > This didn't nullify THE POINT I illustrated, which was > using an increasingly smaller angle approaching zero as > an argument, it eventually produced a value of '1' for > cos, but not '0' for the same sin angle, as it should. > > I feel I've made my points as clear as I think is needed. > If it doesn't bother you that the present implementation produces > incorrect results for clearly unambiguous > situations then we just have different standards for the > need to adhere to mathematical rigor and produce exact > results. BUT THAT IS A CHOICE THAT HUMANS MAKE, AND IS > NOT MANDATED BY NATURE. Please don't shout. Not sure what the term "nature" means here. AFAIK mathematics are a human invention... > Again, one really simple fix to eliminate these ERRORS > is to do something like the following in the Math module. > > rename current functions as follows: > cos > cosine; sin > sine, tan > tangent > > then redefine old aliases so that: > > def cos(x); cosine(x).abs < 1e-11 ? 0.0 : cosine(x) end > def sin(x); sine(x).abs < 1e-11 ? 0.0 : sin(x) end > def tan(x); sin(x)/cos(x) end > > If you want define: TRIG-EPSILON =3D 1e-11, or whatever, > so you can change it easily and make it available. > > With these simple changes you even get the added benefit > that tan(PI/2) =3D> Infinity as it should (1/0), instead of > currently tan(PI/2) =3D> 1.63317787283838e16 This would be a bad idea. As John stated already, values returned from these functions are mandated by IEEE 754 standard. Changing how these fundamental functions behave is calling for trouble. The very moment you do that, completely unrelated code may break. If you insist on getting the results you are expecting there's nothing stopping you from defining your own versions under a different name and use those in your calculations. Otherwise you should use a system for symbolic math as Jean-Julien suggested. Btw, your own example proves that we are talking about an _arithmetic_ error and not a _mathematical_ error. A mathematical error in my eyes would be if Math.sin(Math::PI / 2) returned something negative. Kind regards robert Further reading: http://en.wikipedia.org/wiki/IEEE_754 You can also search the archives for "rounding error" or "bug float" and will find more than enough material. --=20 remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/ |

All times are GMT. The time now is 10:01 PM. |

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.

SEO by vBSEO ©2010, Crawlability, Inc.