Velocity Reviews > Ruby > Trig value errors

# Trig value errors

jzakiya
Guest
Posts: n/a

 12-23-2009
Hardware: 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

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

1cos 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

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.

Phillip Gawlowski
Guest
Posts: n/a

 12-23-2009
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).

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

jzakiya
Guest
Posts: n/a

 12-23-2009
On Dec 22, 9:38*pm, Phillip Gawlowski <(E-Mail Removed)> 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).
>
>
> 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.

John W Higgins
Guest
Posts: n/a

 12-23-2009
[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 <(E-Mail Removed)> 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).

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

John

Phrogz
Guest
Posts: n/a

 12-23-2009
On Dec 22, 8:47Â*pm, jzakiya <(E-Mail Removed)> 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:I â‰* Ï€. Math:I â‰ˆ Ï€.
Similarly, Math:I/2 â‰* Ï€/2, so of course it's reasonable to say that
Math.cos( Math:I/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?

Phrogz
Guest
Posts: n/a

 12-23-2009
On Dec 22, 7:08*pm, jzakiya <(E-Mail Removed)> 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

> 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.

Phrogz
Guest
Posts: n/a

 12-23-2009
On Dec 22, 10:07*pm, Phrogz <(E-Mail Removed)> 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.")

jzakiya
Guest
Posts: n/a

 12-23-2009
On Dec 23, 12:42*am, Phrogz <(E-Mail Removed)> wrote:
> On Dec 22, 10:07*pm, Phrogz <(E-Mail Removed)> 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

Fleck Jean-Julien
Guest
Posts: n/a

 12-23-2009
> 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

Robert Klemme
Guest
Posts: n/a

 12-23-2009
2009/12/23 jzakiya <(E-Mail Removed)>:
> On Dec 23, 12:42=A0am, Phrogz <(E-Mail Removed)> wrote:
>> On Dec 22, 10:07=A0pm, Phrogz <(E-Mail Removed)> 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:I / 2) returned something negative.

Kind regards

robert

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/