Trig value errors
jzakiya
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.
Phillip Gawlowski
> 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
jzakiya
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
Good Evening,
On Tue, Dec 22, 2009 at 7:50 PM, jzakiya <jza...@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
Phrogz
> 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?
Phrogz
> 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.
Phrogz
> 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=cos%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=cos%28+2*pi+%2F+360+%2F+1e4+%29
(For me, that query always results in a message: "This Wolfram|Alpha
server is temporarily unavailable.")
jzakiya
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
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,
--
JJ Fleck
PCSI1 Lycée Kléber
Robert Klemme
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 = 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
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.
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
Phillip Gawlowski
> 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.
How many real world (as in, reality, out in the wild, where money and
lives matter) cases do you know where a) Ruby is used for these
calculations and b) these calculations matter?
> 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.
A core tenent of mathematical rigor is consistency. Ruby *is*
consistent. The results are, within the limitations already elaborated
on earlier, correct, too.
If you need higher accuracy, you need a different tool.
Now to something no mathematician worth his or her salt likes to hear:
Math is *not* observed in nature. Math is a support science for physics,
to help *describe* actual, observeable, phenomena, and express theories
and formulae in an unambiguous manner, as well as in an abstract manner
to allow the manipulation of said formulae.
--
Phillip Gawlowski
Paul Smith
> On 23.12.2009 08:15, jzakiya wrote:
>
>> 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.
No, it didn't.
irb(main):020:0> x = cos(onedegree/1e06)
=> 1.0
irb(main):021:0> x - 1.0
=> -1.11022302462516e-016
In the first line, I assign x the value of cos(small). The irb output
of that number is 1.0. In the second line however, I show that x
cannot be equal to 1.0, as there is a non-zero difference between
them. (This is why you never check for equality of floats like this)
So, cos(small) only looks like 1.0, it isn't actually equal to 1.0.
Therefore it's not really much surprise than sin(small) isn't 0.
--
Paul Smith
http://www.nomadicfun.co.uk
Colin Bartlett
> We know cos(PI/2)=0 not 6.123023176911189e-17,
> so round it, truncate, whatever, to 0.
But Ruby PI is not (exactly) the mathematical pi,
so it's going to be difficult to decide in cos(x),
with x very close to pi/2, whether x was "really" pi/2,
or something a bit different from pi/2 ?
Phrogz wrote:
> I thought asking Alpha would be an easy place to start.
> ...
> http://www.wolframalpha.com
I didn't know about WolframAlpha! Thanks!
sin(pi/2) #=> 1
tan(pi/2) #=> infinity; so far, so good
sin(pi*0.5) #=> 1
sin(pi*0.5) - 1 #=> 0 "number name zero", so it is zero!
tan(pi*0.5) #=> 1.63312 x 10^16
(Actually in some ways I find that last result
a little surprising, because floating point
holds 0.5 exactly. But also not surprising!)
Since Fleck Jean-Julien mentioned Octave:
> Well, what you are looking for is ... or Octave,
> some kind of symbolic mathematics software.
> ... 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.
A naive user (me) of Octave gets:
sin(pi/2) #=> 1
cos(pi/2) #=> 6.123....189e-017
(By naive, I mean that a more experienced user
might be able to do better than that.)
Colin Bartlett
> ... Not sure what the term "nature" means here.
> AFAIK mathematics are a human invention ...
Are you *sure* about that? I think there are differing views
even amongst mathematicians: some agree with you,
but I think the majority vote (for now) is for "Realism",
in one of its several flavours.
http://en.wikipedia.org/wiki/Philosophy_of_mathematics
Phillip Gawlowski wrote:
> Now to something no mathematician worth his or her salt
> likes to hear: Math is *not* observed in nature.
> Math is a support science for physics,
> to help *describe* actual, observeable, phenomena,
> and express theories and formulae in an unambiguous manner,
> as well as in an abstract manner to allow
> the manipulation of said formulae.
That's a bit limiting: it's also very useful in engineering,
chemistry, etc, etc! And for a "support science" it does
rather well, frequently discovering/inventing (depending
on your philosophy of maths) things several decades
before physicists realised they needed them!
But to be fair, there is a two-way traffic.
(A warning for readers: my degree is in maths,
but I am not a mathematician!)
Xavier Noria
Ordinary programming language use floats, with all their limitations
and virtues. If you want something closer to exact math please look
elsewhere like Mathematica.
Phillip Gawlowski
> Phillip Gawlowski wrote:
>> Now to something no mathematician worth his or her salt
>> likes to hear: Math is *not* observed in nature.
>> Math is a support science for physics,
>> to help *describe* actual, observeable, phenomena,
>> and express theories and formulae in an unambiguous manner,
>> as well as in an abstract manner to allow
>> the manipulation of said formulae.
>
> That's a bit limiting: it's also very useful in engineering,
> chemistry, etc, etc! And for a "support science" it does
> rather well, frequently discovering/inventing (depending
> on your philosophy of maths) things several decades
> before physicists realised they needed them!
> But to be fair, there is a two-way traffic.
Well, if me and my professors had a choice, we wouldn't bother with
maths (I'm in college to get an engineering degree), so I'm quiet
oviously jsut a little biased. :P
And while maths, unlike other support sciences *does* have decent, and
interesting research all of its own, if it weren't for sciences that
need maths, nobody would need it, and it would find itself in the same
thankless corner as philosophy: Undervalued as well as underappreciated.
For example, I like the beauty of maths in music, and the visualization
of Mandelbrot fractals, and feel that maths can stand on its own very,
very well. :)
Mind, I'm not putting down maths as a field of science, at all! It has
established itself firmly in the science community, otherwise there
wouldn't be dedicated math degrees. :)
And it is indeed true that maths makes life easier, for quite near everyone.
--
Phillip Gawlowski
jzakiya
I use a Linux calculator named Qaculate.
I do not know the people who designed and
coded it, but it makes me happy. Why?
When I put in sin(180) it outputs '0'
not 1.22460635382238e-16, and when I change
to radians for angles and do sin(PI) it
also gives '0' and not 1.22460635382238e-16.
This makes me happy.
In fact, this little Linux calculator produces
all the correct (exact) answers for angles on
an axis for both cos and sin, whether you input
the angles in degrees or radians. Astonishing!!
I don't now anything about how the people who
designed and implemented Qalculate decided to
use whatever language they chose to write it in,
or what libraries they decided to use. I don't
know (or care) about any of those under-the-hood
things.
What I do KNOW is that the people who designed and
implemented this calculator CARED that it produced
the mathematically exact results for those angles.
This makes me happy.
I use another add-on calculator for Firefox, called,
tada! Calculator. Again, I don't know the people who
designed and/or coded it, and I don't know what
language or libraries they used to do it in either.
But when I use this little calculator in Firefox I do
know I get sin(PI) = 0, not 1.22460635382238e-16.
So, for this calculator too, somebody(s) CARED enough
to make sure the answers came out correctly (exact)
for angles on an axis too. So when I use this calculator,
This makes me happy.
I think Ruby is a Great language, and a fun language.
And I agree with your philosophy that languages that
people use should serve them, not the other way around.
So I humbly tell you I am Surprised that Ruby produces
the math errors I've illustrated in this thread, and
This makes me unhappy.
So I am asking you to see that these errors be fixed.
If Qaculator and Calculator can produce the correct
results, then so can Ruby. All that is necessary is that
you CARE enough that it does it.
It would make me very happy if I could share my code, and
not have to include patches and redefinitions in it just
to assure other people get the same (exact) results I do.
I agree with your Principle of Least Surprises (POLS).
The language should work to please the user.
The language should be intuitive to the user.
The language should not cause unnecessary surprises.
So please, fix these errors.
This will make me happy.
Thanks
pharrington
> On 23.12.2009 17:32, Colin Bartlett wrote:
>
> > Phillip Gawlowski wrote:
> >> Now to something no mathematician worth his or her salt
> >> likes to hear: Math is *not* observed in nature.
> >> Math is a support science for physics,
> >> to help *describe* actual, observeable, phenomena,
> >> and express theories and formulae in an unambiguous manner,
> >> as well as in an abstract manner to allow
> >> the manipulation of said formulae.
>
> > That's a bit limiting: it's also very useful in engineering,
> > chemistry, etc, etc! And for a "support science" it does
> > rather well, frequently discovering/inventing (depending
> > on your philosophy of maths) things several decades
> > before physicists realised they needed them!
> > But to be fair, there is a two-way traffic.
>
> Well, if me and my professors had a choice, we wouldn't bother with
> maths (I'm in college to get an engineering degree), so I'm quiet
> oviously jsut a little biased. :P
>
> And while maths, unlike other support sciences *does* have decent, and
> interesting research all of its own, if it weren't for sciences that
Now that we're thoroughly off topic :)
This is like saying if people didn't need to eat, there'd be no need
for food. Just because a statement is true does not mean it is
relevant.
There isn't a single field of research that yields practical
application who's core isn't founded in some sort of math. I'm not a
mathematician (or even a math major) but my understanding has always
been that maths have been *discovered*, not necessarily *invented*.
pharrington
> Dear Matz,
>
> I use a Linux calculator named Qaculate.
> I do not know the people who designed and
> coded it, but it makes me happy. Why?
>
> When I put in sin(180) it outputs '0'
> not 1.22460635382238e-16, and when I change
> to radians for angles and do sin(PI) it
> also gives '0' and not 1.22460635382238e-16.
>
> This makes me happy.
>
> In fact, this little Linux calculator produces
> all the correct (exact) answers for angles on
> an axis for both cos and sin, whether you input
> the angles in degrees or radians. Astonishing!!
>
> I don't now anything about how the people who
> designed and implemented Qalculate decided to
> use whatever language they chose to write it in,
> or what libraries they decided to use. I don't
> know (or care) about any of those under-the-hood
> things.
>
> What I do KNOW is that the people who designed and
> implemented this calculator CARED that it produced
> the mathematically exact results for those angles.
>
> This makes me happy.
Perhaps you should look under the hood to see what its doing.
>
> I use another add-on calculator for Firefox, called,
> tada! Calculator. Again, I don't know the people who
> designed and/or coded it, and I don't know what
> language or libraries they used to do it in either.
> But when I use this little calculator in Firefox I do
> know I get sin(PI) = 0, not 1.22460635382238e-16.
>
> So, for this calculator too, somebody(s) CARED enough
> to make sure the answers came out correctly (exact)
> for angles on an axis too. So when I use this calculator,
>
> This makes me happy.
***PURE*** speculation, but this sounds like its just rounding off the
results for a pretty display for the end user. (Again, look at the
source)
>
> I think Ruby is a Great language, and a fun language.
> And I agree with your philosophy that languages that
> people use should serve them, not the other way around.
>
> So I humbly tell you I am Surprised that Ruby produces
> the math errors I've illustrated in this thread, and
>
> This makes me unhappy.
>
> So I am asking you to see that these errors be fixed.
>
> If Qaculator and Calculator can produce the correct
> results, then so can Ruby. All that is necessary is that
> you CARE enough that it does it.
>
> It would make me very happy if I could share my code, and
> not have to include patches and redefinitions in it just
> to assure other people get the same (exact) results I do.
>
> I agree with your Principle of Least Surprises (POLS).
>
> The language should work to please the user.
> The language should be intuitive to the user.
> The language should not cause unnecessary surprises.
>
> So please, fix these errors.
>
> This will make me happy.
>
> Thanks
This has already been explained. The ratio of a circle's circumference
to its diameter cannot be fully actualized in finite bytes (and
certainly not in floats). Calculations using Math::PI, therefor,
unless given a special representation, and the language/library has
been built from the ground up to handle calculations with that special
representation (and similarly with all other sorts of irrational
numbers) will never yield a 100% result. If you need more precision
than floating point arithmatic provides, use a specialized language.
If you want your values that, for you, are sufficiently close to zero
to be zero, then its easy enough to round them. However, that decision
****CANNOT**** be made for everybody using the language, as different
people have different expectations of precision, and as has been
mentioned before libraries will break.
pharrington
Also, as an example:
static VALUE
math_cos(VALUE obj, VALUE x)
{
Need_Float(x);
return DBL2NUM(cos(RFLOAT_VALUE(x)));
}
If you have a beef with anyone, its with the implementers of the C
standard library, but...
Seebs
> I use a Linux calculator named Qaculate.
> I do not know the people who designed and
> coded it, but it makes me happy. Why?
Because it's not using IEEE 754 floats.
> So I am asking you to see that these errors be fixed.
And we have been asking you to please LEARN TO READ.
All your ranting misses the point.
THE RESULTS YOU ARE GETTING ARE MANDATED BY AN INTERNATIONAL STANDARD,
AND EVERY PIECE OF MATHEMATICAL CODE WRITTEN IN ANY LANGUAGE FOR THE LAST
TWO DECADES WHICH DOES NOT PROVIDE ITS OWN ARITHMETIC LIBRARIES FOR
SPECIAL PURPOSES HAS ONLY BEEN TESTED WITH THESE RESULTS FROM THESE
INPUTS.
Changing this would break EVERYTHING.
Here's a suggestion: Write a class which provides the semantics you want,
and use it instead of floating point numbers. The semantics of floating
point values are very rigidly defined, and failure to generate the exact
same behaviors as other systems would be MUCH worse than generating answers
which have miniscule rounding errors.
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
John W Higgins
Respectifully........
On Wed, Dec 23, 2009 at 9:42 AM, jzakiya <jza...@mail.com> wrote:
> All that is necessary is that
> you CARE enough that it does it.
>
> It would make me very happy if I could share my code, and
> not have to include patches and redefinitions in it just
> to assure other people get the same (exact) results I do.
>
> I agree with your Principle of Least Surprises (POLS).
>
> The language should work to please the user.
> The language should be intuitive to the user.
> The language should not cause unnecessary surprises.
>
> So please, fix these errors.
>
> This will make me happy.
>
>
What would make pretty much everyone on this list happy is if you took 1/10
the amount of time you've spent calling the Ruby community idiots actually
investigating why your tool of choice works better than you are getting from
the C STANDARD (note that nasty 8 letter word again) library. I took a 1
minute look at the Qalculate website and discovered that it uses the CLN
library for its math functions. Apparently that library has a higher degree
of precision that the C STANDARD library used by Ruby.
Shockingly choices are made that have nothing to do with people caring or
not. Clearly since a number of folks have decided to attempt to assist you
in even with your ignorant rant against the community we must care about
even the ignorant amongst us.
You may feel absolutely free to build an extension to access the library.
Also, taking another 2 minutes to investigate just a bit further I came
across a post from matz himself discussing this exact library (along with
GMP - another alternative).
http://osdir.com/ml/ruby-talk/2009-03/msg01505.html The problem is that
LEGALLY they cannot link a pure GPL library into ruby because of licensing
issues. Again, sometimes decisions are made that affect 1% of the user base
that are unfortunate but unless you step up and help (and bitching isn't
helping) - you are never going to get what you want. BTW, there appears to
be at least some form of an extension to access GMP which may be of
assistance to you -
http://t-a-w.blogspot.com/2007/08/resurrection-of-libgmp-ruby.html
Please step up yourself and assist the community in gaining access to more
precise mathematical functionality rather than making unfounded and
exceptionally ignorant accusations. No one years ago got a big chuckle out
of placing barriers to someone's future attempt to use sin and cos - we're
just plugging along doing the best we can.
John
Phrogz
> > 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
> 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.
No, it didn't produce a value of 1. Look at the second part of my
post, which you quoted, at the top of this message.
Benoit Daloze
If you want more precision, you could use BigDecimal (and BigMath).
Then you would get something like:
irb(main):025:0> p=2000; cos(PI(p)/2, p).to_s
=> "0.64773210554205705...E-2016"
irb(main):026:0> p=2000; sin(PI(p)/2, p).to_s
=> "0.99999999999999999999999999999999999999...E0"
Well, I think it's safe to round the 2016th decimal, isn't it ?
Also rounding a ton of 9.
So, rounding to the precision(2000), you get what you want.
irb(main):036:0> p=20; cos(PI(p)/2, p).round(p).to_f
=> 0.0
irb(main):037:0> p=20; sin(PI(p)/2, p).round(p).to_f
=> 1.0
And well, you really don't need 2000 of precision, 20 is far enough in this
case.
2009/12/23 Phrogz <phr...@mac.com>
Phillip Gawlowski
[...]
> This makes me happy.
[...]
> This makes me happy.
[...]
> This makes me happy.
[...]
> This makes me unhappy.
[...]
> So please, fix these errors.
>
> This will make me happy.
[...]
Bluntly speaking, your happiness is your probem, and not relevant to me,
Matz, or indeed anyone.
If you don't like the result Ruby provides, *do something constructive*.
Bitching and yapping about minute details, the reasoning for which have
been put before you more often than to be expected (i.e. more than
once), will earn you increasing animosity, if not hostility.
If you don't like how Ruby does math, feel free to investigate
alternatives to Ruby, or write a math library that does its calculations
to the level of accuracy that makes you happy.
Nobody forces you to use Ruby (unless it is your employer, in which case
I'd suggest investigating alternative employment, nice as Ruby is).
You could use JRuby and a Java library with "better" maths; you could
use IronRuby and a .NET library with "better" maths.
Nobody forces you to use Ruby as *is*, either. It's open source. Change
Ruby's behavior, if you like.
--
Phillip Gawlowski
Phillip Gawlowski
> Now that we're thoroughly off topic :)
My pleasure. ;)
> There isn't a single field of research that yields practical
> application who's core isn't founded in some sort of math. I'm not a
> mathematician (or even a math major) but my understanding has always
> been that maths have been *discovered*, not necessarily *invented*.
I have to disagree. While physics, or chemistry, uses math to yield
results of some form (statistics, for example, to evaluate an
experiment), you could replace math with something, if you so desired.
Essentially, what happens in physics happens whether there is math or not.
Of course, since math is very, very useful, it rose to the level of
prominence it has achieved in all the siences. It is, however, not the
driving factor behind these discoveries.
But be that as it may, math *is* a science, and leads to mathematical
discoveries. However, these discoveries are true in the framework "we"
(i.e. the body of human work in the sciences, *including* maths) arrived at.
In any case, math has its beauty (even if a lot of it will forever be
closed to me, since I lack the knowledge and the will to investigate it
deeper than I have to), and thus can be valued in and of itself. :)
And thusly, I'll keep my mouth shut about the topic now, but if further
discussion is desired, I'm more than happy to continue it off-list. :)
--
Phillip Gawlowski
jzakiya
Try this (with correct syntax if wrong).
Do similar for sin.
static VALUE
math_cos(VALUE obj, VALUE x)
{
Need_Float(x);
cos_value = DBL2NUM(cos(RFLOAT_VALUE(x)));
if (abs(cos_value) < 1e-10) cos_value 0.0;
return cos_value;
}
jzakiya
> > Also, as an example:
>
> > static VALUE
> > math_cos(VALUE obj, VALUE x)
> > {
> > Need_Float(x);
> > return DBL2NUM(cos(RFLOAT_VALUE(x)));
>
> > }
>
> > If you have a beef with anyone, its with the implementers of the C
> > standard library, but...
>
> Try this (with correct syntax if wrong).
> Do similar for sin.
>
> static VALUE
> math_cos(VALUE obj, VALUE x)
> {
> Need_Float(x);
> cos_value = DBL2NUM(cos(RFLOAT_VALUE(x)));
> if (abs(cos_value) < 1e-10) cos_value 0.0;
> return cos_value;
> }
please Excuse the typo:
if (abs(cos_value) < 1e-10) cos_value = 0.0;
Seebs
> Try this (with correct syntax if wrong).
> Do similar for sin.
> static VALUE
> math_cos(VALUE obj, VALUE x)
> {
> Need_Float(x);
> cos_value = DBL2NUM(cos(RFLOAT_VALUE(x)));
> if (abs(cos_value) < 1e-10) cos_value 0.0;
> return cos_value;
> }
That'd be exceptionally stupid.
Here's the problem: There exists at least one value for which the correct
value of cos(x) is about 9e-11, which can be correctly represented (within
a much, much, smaller margin of error) in a floating point value, and which
you would then "fix" by changing it from not-zero to exactly-zero.
Which is to say, this would introduce a comparatively HUGE error, much larger
than the alleged error you're complaining about.
If you want approximate values, round them.
jzakiya
> On 2009-12-24, jzakiya <jzak...@mail.com> wrote:
>
> > Try this (with correct syntax if wrong).
> > Do similar for sin.
> > static VALUE
> > math_cos(VALUE obj, VALUE x)
> > {
> > Need_Float(x);
> > cos_value = DBL2NUM(cos(RFLOAT_VALUE(x)));
> > if (abs(cos_value) < 1e-10) cos_value 0.0;
> > return cos_value;
> > }
>
> That'd be exceptionally stupid.
>
> Here's the problem: There exists at least one value for which the correct
> value of cos(x) is about 9e-11, which can be correctly represented (within
> you would then "fix" by changing it from not-zero to exactly-zero.
>
> Which is to say, this would introduce a comparatively HUGE error, much larger
> than the alleged error you're complaining about.
>
> If you want approximate values, round them.
>
> -s
> --
> Here's the problem: There exists at least one value for which the correct
> value of cos(x) is about 9e-11, which can be correctly represented (within)
And what (extremely small) angle(s) would that be?
Provide examples please:
If so then do:
if (abs(cos_value) < 1e-14) cos_value = 0.0;
This provides the correct answers for the errors I illustrated.
This makes me happy. :-)
Seebs
>> Here's the problem: There exists at least one value for which the correct
>> value of cos(x) is about 9e-11, which can be correctly represented (within)
> And what (extremely small) angle(s) would that be?
Are you really this stupid?
> if (abs(cos_value) < 1e-14) cos_value = 0.0;
> This provides the correct answers for the errors I illustrated.
Again:
If you can measure, in a float, the amount of the error, then there exists
a value for which that number is closer than 0, and you're introducing
an error larger than you're correcting.
> This makes me happy. :-)
Have you considered masturbating in public? It would also make you happy,
and be easier for other people to ignore.
Again:
If you want rounded values, round them yourself. You've just demonstrated
that you know how to round (albeit poorly). Great. When you want rounded
values, you go ahead and round them, then.
-s
--
pharrington
> On 2009-12-24, jzakiya <jzak...@mail.com> wrote:
>
> >seebs wrote:
> >> Here's the problem: There exists at least one value for which the correct
> >> value of cos(x) is about 9e-11, which can be correctly represented (within)
> > And what (extremely small) angle(s) would that be?
>
> Are you really this stupid?
>
> > if (abs(cos_value) < 1e-14) cos_value = 0.0;
> > This provides the correct answers for the errors I illustrated.
>
> Again:
>
> If you can measure, in a float, the amount of the error, then there exists
> a value for which that number is closer than 0, and you're introducing
> an error larger than you're correcting.
>
> > This makes me happy. :-)
>
> Have you considered masturbating in public? It would also make you happy,
> and be easier for other people to ignore.
>
> Again:
>
> If you want rounded values, round them yourself. You've just demonstrated
> that you know how to round (albeit poorly). Great. When you want rounded
> values, you go ahead and round them, then.
>
> -s
> --
Let him break his Ruby install if he wants. Best to learn through
experience.
Seebs
> Let him break his Ruby install if he wants. Best to learn through
> experience.
Yeah, but he seems to want to know why we aren't all rushing to fix a
couple of special cases.
(Hint to the OP: You're fixing "180", but not "179.99999" or "180.0000001".)
-s
--
Colin Bartlett
"And your Mom, too." Ruby-talk best practices
http://blog.rubybestpractices.com/posts/jamesbritt/and_your_Mom_too.html
And now thoroughly OT:
On Wed, Dec 23, 2009 at 10:15 PM, Phillip Gawlowski <p...@thimian.com> wrote:
> On 23.12.2009 18:45, pharrington wrote:
>> Now that we're thoroughly off topic :)
Not necessarily a bad thing! :)
> My pleasure. ;)
>
> I have to disagree. While physics, or chemistry, uses math to yield results
> of some form (statistics, for example, to evaluate an experiment), you could
> replace math with something, if you so desired.
> Essentially, what happens in physics happens whether there is math or not.
A mathematician (I think Ian Stewart) has observed that the physicists
would have derived the parts of group theory that they needed if
it hadn't been previously derived by the mathematicians.
> And thusly, I'll keep my mouth shut about the topic now, but if further
> discussion is desired, I'm more than happy to continue it off-list. :)
Same here: I think my email address is visible?
I even have an (ancient) mathematical joke to illustrate the points,
which I hesitate to inflict on ruby-talk in general.
Colin Bartlett
Paul Smith
<coli...@googlemail.com> wrote:
> As a general comment: "MINASWAN", or to be precise "MINASWA mostly N"
> "And your Mom, too." Ruby-talk best practices
> http://blog.rubybestpractices.com/posts/jamesbritt/and_your_Mom_too.html
Nice post, but I think I found a typo where a 'not' is missing:
And being wrong on one thing does make make a person wrong on everything.
Brian Candler
could be provided given the constraints of floating-point
representation.
Why would you want to make them less accurate? Surely it would be a bug
if the values returned were less accurate than the representation
allows?
Floating-point can represent smaller increments the closer you get to
zero. So values of 0 +/- dX can be represented much more accurately than
1 +/- dX.
--
Posted via http://www.ruby-forum.com/.
Seebs
> Why would you want to make them less accurate? Surely it would be a bug
> if the values returned were less accurate than the representation
> allows?
Because our hero is obsessed with the unrounded results of
intrinsically-rounded cases, and hasn't thought about the question
of whether, say, sin(45) or sin(60) is returning "exactly" the
right value. Special-casing zeroes implies a deep failure to
understand trig.
Rick DeNatale
> Floating-point can represent smaller increments the closer you get to
> zero. So values of 0 +/- dX can be represented much more accurately than
> 1 +/- dX.
Strictly speaking they can be represented much more precisely.
Precision and accuracy are different things.
http://en.wikipedia.org/wiki/Accuracy_and_precision
--
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
Robert Klemme
> On Sat, Dec 26, 2009 at 4:56 AM, Brian Candler <b.ca...@pobox.com> wrote:
>
>> Floating-point can represent smaller increments the closer you get to
>> zero. So values of 0 +/- dX can be represented much more accurately than
>> 1 +/- dX.
>
> Strictly speaking they can be represented much more precisely.
Are you sure you meant "precisely" and not "accurately"? Given the
Wikipedia article you quote it seems _that_ is what you rather wanted to
say.
> Precision and accuracy are different things.
>
> http://en.wikipedia.org/wiki/Accuracy_and_precision
In light of the article the term "precision" (aka "repeatability") is
pretty meaningless in this case (you could also say "uninteresting")
because due to the deterministic nature of the implementation of
trigonometric functions the result is always identical for the same
input. It is the accuracy that the whole thread revolves around. IEEE
standards mandate a certain accuracy and people who need better accuracy
need to use specialized tools - either math libraries with higher
accuracy (or even selectable accuracy) or tools that do symbolic math.
Also, as elsewhere in this thread has been explained, the "correction"
approach suggested (if the abs is lower than a particular epsilon,
return 0 instead of the value) is a pretty bad one - much worse than
general rounding of values because it introduces distorted accuracy.
Rounding is better because it generally cuts off digits; which is ironic
because it *reduces* overall accuracy of the function...
Kind regards
robert
A program that nicely demonstrates the nonlinearity of the error
introduced by the suggested "fix":
module Math
def sin2(x, epsilon = 1e-10)
y = sin(x)
y.abs < epsilon ? 0.0 : y
end
end
include Math
# find interesting start value
div = 1.2
x = 1.0
x /= div while sin(x) == sin2(x)
x *= div ** 10
# do the test
100.times do |i|
y1 = sin(x)
y2 = sin2(x)
printf "%6d %20e %20e %20e error: %20e\n", i, x, y1, y2, ((y2-y1)/x).abs
x /= div
end
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
Rick DeNatale
<short...@googlemail.com> wrote:
> On 26.12.2009 15:43, Rick DeNatale wrote:
>>
>> On Sat, Dec 26, 2009 at 4:56 AM, Brian Candler <b.ca...@pobox.com>
>> wrote:
>>
>>> Floating-point can represent smaller increments the closer you get to
>>> zero. So values of 0 +/- dX can be represented much more accurately than
>>> 1 +/- dX.
>>
>> Strictly speaking they can be represented much more precisely.
>
> Are you sure you meant "precisely" and not "accurately"? Given the
> Wikipedia article you quote it seems _that_ is what you rather wanted to
> say.
Precision refers to the smallest increment between floating point
numbers, the smaller the exponent the smaller the value of the least
sign, so one might be able to represent both
0.000000001
and
0.000000002
but, say
10000000.000000001 would have to be represented as
10000000.00
because you only have so many digits
Now one might compute a value of Pi
as
3.14
which would be more accurate, although less precise than a
miscalculated value like
4.3259890880890
One of the mistaken notions of novice programmers is to expect that
large amounts of precision in floating point arithmethic are always
good. However, in doing calculations with physical measurements of
various precisions, one can't get any better precision than what you
start with. One can be fooled that the low order digits of
calculations represent precision that really isn't there, and if one
isn't careful about things like the order of floating point operations
when dealing with either very close or very distant values, accuracy
can easily be lost.
http://docs.sun.com/source/806-3568/ncg_goldberg.html
Brian Candler
0.0 as it is around 1.0, then try this:
module Math
def sin2(x)
1.0 - (1.0 - sin(x))
end
module_function :sin2
end
>> include Math
=> Object
>> od = 2*PI/360
=> 0.0174532925199433
>> sin(od/1e8)
=> 1.74532925199433e-10
>> sin2(od/1e8)
=> 1.74532943653105e-10
>> sin(od/1e16)
=> 1.74532925199433e-18
>> sin2(od/1e16)
=> 0.0
jzakiya
Here's the nature of the problem.
Ruby currently gives incorrect values for x|y axis angles
cos PI/2 => 6.12303176911189e-17
sin PI => 1.22460635382238e-16
cos 3*PI/2 => -1.83690953073357e-16
sin 2*PI => -2.44921970764475e-16
Thus, sin gives incorrect answers on the +|- x axis
and, cos gives incorrect answers on the +|- y axis
Here's the total solution.
In order to produce the mathematically correct answers
we must FORCE the answers to meet mathematical necessity.
i.e. (1) 1 = cos^2 + sin^2
thus, (2) cos|sin = [1-(sin|cos)^2]^(1/2)
also, (3) for angle x when sin|cos= -1|1 > cos|sin= 0.0
To 'fix totally' these errors in sin|cos near the x|y axis define sin1|
cos1 here using Ruby's native cos|sin.
def sin1(x)
y=(1-cos(x)**2)**0.5 # calculate (2)
return 0.0 if y==0
return sin(x) < 0 ? -y : y # for correct quadrant sign
end
def cos1(x)
y=(1-sin(x)**2)**0.5 # calculate (2)
return 0.0 if y==0
return cos(x) < 0 ? -y : y # for correct quadrant sign
end
Now sin|cos == sin1|cos1 for all angles -1|1 degree from
each axis.
For |x| < 1 degree from 0, 90, 180, 270, 360, and their
multiples, sin1|cos1 will produce the mathematically
correct complimentary answers to satisfy (1) and (3).
In testing, I found only one instance on each side of
each +|- axis where the floating point approximations
gave answers which violated (3).
Here's an example at 0 degrees|radians
first let:
>degrees = PI/180
x|y axis check
>sin1(0*degrees) => 0.0
>cos1(0*degrees) => 1.0
>sin1(90*degrees) => 1.0
>cos1(90*degrees) => 0.0
>sin1(180*degrees) => 0.0
>cos1(180*degrees) => -1.0
>sin1(270*degrees) => -1.0
>cos1(270*degrees) => 0.0
>sin1(360*degrees) => 0.0
>cos1(360*degrees) => 1.0
1st Quadrant
>sin1((0+1e-5)*degrees) => 1.74413620095247e-07
>cos1((0+1e-5)*degrees) => 0.999999999999985
>sin1((0+1e-6)*degrees) => 1.49011611938477e-08
>cos1((0+1e-6)*degrees) => 1.0 # this pair violates (3)
>sin1((0+1e-7)*degrees) => 0.0 # correct now for
>cos1((0+1e-7)*degrees) => 1.0 # both as angle gets
>sin1((0+1e-8)*degrees) => 0.0 # closer and closer
>cos1((0+1e-8)*degrees) => 1.0 # to x-axis
4th Quandrant
>sin1((0-1e-5)*degrees) => -1.74413620095247e-07
>cos1((0-1e-5)*degrees) => 0.999999999999985
>sin1((0-1e-6)*degrees) => -1.49011611938477e-08
>cos1((0-1e-6)*degrees) => 1.0 # this pair violates (3)
>sin1((0-1e-7)*degrees) => 0.0 # correct now for
>cos1((0-1e-7)*degrees) => 1.0 # both as angle gets
>sin1((0-1e-8)*degrees) => 0.0 # closer and closer
>cos1((0-1e-8)*degrees) => 1.0 # to x-axis
Also for 4th Quadrant
>sin1((360-1e-5)*degrees)=> -1.74413620095247e-07
>cos1((360-1e-5)*degrees)=> 0.999999999999985
>sin1((360-1e-6)*degrees)=> -1.49011611938477e-08
>cos1((360-1e-6)*degrees)=> 1.0 # this pair violates (3)
>sin1((360-1e-7)*degrees)=> 0.0 # correct now for
>cos1((360-1e-7)*degrees)=> 1.0 # both as angle gets
>sin1((360-1e-8)*degrees)=> 0.0 # closer and closer
>cos1((360-1e-8)*degrees)=> 1.0 # to x-axis
This shows that the precision, or the smallest unit value
of an angle you can resolve, is on the order of |1e-5| at x|y-axis.
Any thing smaller provides no precision toward the answer, no matter
how many decimal places past this point you choose to calculate. These
are the most non-linear regions in the series expansion for cos|sin.
The same effect occurs as you increase the angle size,
but you can get greater precision (angle resolution),
with the greatest resolution occurring at |45| degrees.
Here, you get about |1e-14| degrees of angular precsion.
ie, as you go from 45-1e-14 > 45-1e-15 cos|sin stay the
same for smaller and smaller delta angles.
Now, sin1|cos1 (and tan1=sin1/cos1) meet the mathematical
requirements of (1),(2),(3) and are as inherently precise
as the underlying trig lib, and can become more precise as the trig
lib functions get better and/or the cpu size grows
They can NEVER BE WORSE than the native trig lib functions, and will
ALWAYS be mathematically MORE accurate, because they are DESIGNED to
meet mathematical trig requirements.
I would PROPOSE that Ruby adopt the structure presented
here and implement them in the C source to make them as
fast and efficient to compute as possible.
I would ENCOURAGE people to actually run|test the code
against the present trig functions to see for themselves
that they work for ALL angles.
This was done with Ruby 1.9.1p243 on Intel P4 cpu system.
John W Higgins
On Sun, Dec 27, 2009 at 6:00 PM, jzakiya <jza...@mail.com> wrote:
> i.e. (1) 1 = cos^2 + sin^2
>
This also means that 0 = 1 - cos^2 - sin^2
>
> To 'fix totally' these errors in sin|cos near the x|y axis define sin1|
> cos1 here using Ruby's native cos|sin.
>
> def sin1(x)
> y=(1-cos(x)**2)**0.5 # calculate (2)
> return 0.0 if y==0
> return sin(x) < 0 ? -y : y # for correct quadrant sign
> end
>
> def cos1(x)
> y=(1-sin(x)**2)**0.5 # calculate (2)
> return 0.0 if y==0
> return cos(x) < 0 ? -y : y # for correct quadrant sign
> end
>
>
You are simply unable to apparently grasp how mathematics works with
floating point numbers. So lets make a very simple example which shows that
your method fails as badly as does the standard methods.
First, to show that the standard methods show no greater precision lets test
87 degrees shall we.
1.0 - (sin(PI/180*87) ** 2 + cos(PI/180*87) ** 2)
=> 1.11022302462516e-16
So we fail with the standard and yours works
1.0 - (sin1(PI/2/90*87) ** 2 + cos1(PI/2/90*87) ** 2)
=> 0.0
But wait shall we - lets look at 67 degrees ok?
1.0 - (sin(PI/180*67) ** 2 + cos(PI/180*67) ** 2)
=> 0.0
1.0 - (sin1(PI/180*67) ** 2 + cos1(PI/180*67) ** 2)
=> 2.22044604925031e-16
Oh no - we have a problem - your calculation fails when the standard works.
There is no way to accurate get these values to ever work with floating
point mathematics. There will always be something that fails because all you
are doing is trying to cover up one inaccurate calculation with yet another
inaccurate calculation.
If you hide yourself in a box that is only 1 or 0 shockingly you can make
x^2 + y^2 = 1 because you are gaming the values. But you fail to appreciate
that the numbers will always have an element of imprecision that you have no
control over and you cannot make work to exact numbers when dealing with
floating points.
Yet again, the standard is the standard because a lot of VERY smart people
took the time to analyze the entire spectrum of results instead of limiting
themselves myopically to one particular area.
John
jzakiya
> [Note: parts of this message were removed to make it a legal post.]
>
All I can say is....
Against stupidity the Gods themselves contend in vain. :(
Seebs
> All I can say is....
>
> Against stupidity the Gods themselves contend in vain. :(
This adequately summarizes the difficulty people have had getting you to
understand why it is ridiculous to try to "fix" sin(180) but not to try to
"fix" sin(45).
jzakiya
> On 2009-12-28, jzakiya <jzak...@mail.com> wrote:
>
> > All I can say is....
>
> > Against stupidity the Gods themselves contend in vain. :(
>
> This adequately summarizes the difficulty people have had getting you to
> understand why it is ridiculous to try to "fix" sin(180) but not to try to
> "fix" sin(45).
>
> -s
> --
No, YOU still don't seem to know the difference between
precision an accuracy.
If you can READ I said my method is no more precise, i.e
it CANNOT resolve angular differences past the inherent
precision of the native trig functions.
But what you, and your cohorts, don't want to deal with, is my method
IS MORE ACCURATE for sin|cos on the x|y axis angles, whereas the
native functions are INACCURATE.
So, I DON'T CARE how precise any of the other angles
are, because they all are ACCURATE to the precision that
the native functions have. I said this many times, and
others have tried to explain the difference too.
One thing is VERY CLEAR though.
YOU, can't SHOW that my method is inaccurate for any
angle value. Can YOU?
Ah... A Brain is such a terrible thing to waste. :(
Walton Hoops
On 12/27/2009 8:56 PM, John W Higgins wrote:
> First, to show that the standard methods show no greater precision lets test
> 87 degrees shall we.
>
> 1.0 - (sin(PI/180*87) ** 2 + cos(PI/180*87) ** 2)
> => 1.11022302462516e-16
>
> So we fail with the standard and yours works
>
> 1.0 - (sin1(PI/2/90*87) ** 2 + cos1(PI/2/90*87) ** 2)
> => 0.0
>
> But wait shall we - lets look at 67 degrees ok?
>
> 1.0 - (sin(PI/180*67) ** 2 + cos(PI/180*67) ** 2)
> => 0.0
>
> 1.0 - (sin1(PI/180*67) ** 2 + cos1(PI/180*67) ** 2)
> => 2.22044604925031e-16
>
> Oh no - we have a problem - your calculation fails when the standard works.
Thus, your method is inaccurate for the angle value of 67.
Phillip Gawlowski
> Thus, your method is inaccurate for the angle value of 67.
On the plus side: My killfile-email rules work now. :)
--
Phillip Gawlowski
jzakiya
My methods
>sin1(67*degrees) => 0.92050485345244
>cos1(67*degrees) => 0.39073112848927
Ruby methods
>sin(67*degrees) => 0.92050485345244
>cos(67*degrees) => 0.39073112848927
Same answers.
It's clear you jokers just like to argue and spew nonsense. You make
stupid statements and provide no
data to establish your claims. But I guess well thought
out and consistent reproducible claims are just too
much for you guys to produce.
Are you guys Republicans and/or Global Climate Change deniers too?
John W Higgins
On Sun, Dec 27, 2009 at 9:35 PM, jzakiya <jza...@mail.com> wrote:
>
> One thing is VERY CLEAR though.
>
> YOU, can't SHOW that my method is inaccurate for any
> angle value. Can YOU?
>
This is getting funnier by the moment. Gotta love someone that just doesn't
grasp utter failure. So we've got 67 degrees on the high side and how about
we pull out nice low number now to completly end the conversation. Lets try
4.269e-07 degrees shall we?
z = 4.269e-07
1.0 - (sin(PI/180*z) ** 2 + cos(PI/180*z) ** 2)
=> 0.0
Standard functions pass - anyone wanna guess what we're going to find when
we try the new concept? Anyone? Bueller?
1.0 - (sin1(PI/180*z) ** 2 + cos1(PI/180*z) ** 2)
=> 2.22044604925031e-16
Have you had enough?
John
John W Higgins
On Sun, Dec 27, 2009 at 10:04 PM, jzakiya <jza...@gmail.com> wrote:
>
> My methods
>
> >sin1(67*degrees) => 0.92050485345244
> >cos1(67*degrees) => 0.39073112848927
>
>
You just will never ever get it will you?
cos1(67*degrees) - 0.39
0.000731128489273647
cos(67*degrees) - 0.39
0.000731128489273702
Got a problem don't we? Displayed value DOES NOT equal actual value. The
system displays x digits on the screen but stores y.
John
Walton Hoops
> My methods
>
>> sin1(67*degrees) => 0.92050485345244
>> cos1(67*degrees) => 0.39073112848927
>>
> Ruby methods
>
>
>> sin(67*degrees) => 0.92050485345244
>> cos(67*degrees) => 0.39073112848927
>>
> Same answers.
>
>
irb(main):017:0> def sin1(x)
irb(main):018:1> y=(1-cos(x)**2)**0.5 # calculate (2)
irb(main):019:1> return 0.0 if y==0
irb(main):020:1> return sin(x) < 0 ? -y : y # for correct quadrant sign
irb(main):021:1> end
=> nil
irb(main):022:0> def cos1(x)
irb(main):023:1> y=(1-sin(x)**2)**0.5 # calculate (2)
irb(main):024:1> return 0.0 if y==0
irb(main):025:1> return cos(x) < 0 ? -y : y # for correct quadrant sign
irb(main):026:1> end
=> nil
irb(main):027:0> degrees=PI/180
=> 0.0174532925199433
irb(main):028:0> s0=sin1(67*degrees)
=> 0.92050485345244
irb(main):029:0> c0=cos1(67*degrees)
=> 0.390731128489274
irb(main):030:0> s1=sin(67*degrees)
=> 0.92050485345244
irb(main):031:0> c1=cos(67*degrees)
=> 0.390731128489274
irb(main):032:0> s0==s1
=> false
irb(main):033:0> c0==c1
=> false
irb(main):034:0> s0-s1
=> -1.11022302462516e-16
irb(main):035:0> c0-c1
=> -5.55111512312578e-17
irb(main):036:0>
whoops.. guess they aren't equal after all.
Similarly, from one of your earlier examples:
irb(main):036:0> s=sin((360-1e-6)*degrees)
=> -1.74532923897938e-08
irb(main):037:0> c=cos((360-1e-6)*degrees)
=> 1.0
irb(main):038:0> c==1
=> false
irb(main):039:0> 1-c
=> 1.11022302462516e-16
That 1 isn't really a 1. This has been pointed out before, you just
chose to ignore it.
Seebs
> precision an accuracy.
I certainly do.
> If you can READ I said my method is no more precise, i.e
> it CANNOT resolve angular differences past the inherent
> precision of the native trig functions.
Right.
> But what you, and your cohorts, don't want to deal with, is my method
> IS MORE ACCURATE for sin|cos on the x|y axis angles, whereas the
> native functions are INACCURATE.
For any point you special case, there is a range of possible inputs
which yield something close enough that you automatically round it.
For all but one of those inputs, your method is LESS ACCURATE.
There is no reason to treat those particular points as specially
deserving of extra accuracy, to such an extent that you should
make other nearby input values less accurate.
> YOU, can't SHOW that my method is inaccurate for any
> angle value. Can YOU?
We already went through this. Your method is inaccurate for any
value for which the resulting value is within the range you picked
of values which are "really close to zero". In the long run, there
are many, many, more such values than there are values for which your
method is "more accurate".
Again, the problem here is simply that you don't understand what
rounding is, and when it should be done. If you want round numbers,
round them. Don't add a large computational expense (keep in mind
that on some machines, sin(x) may be in hardware, so you're replacing
a single instruction with a large hunk of interpreted code) to every
single trig function, introducing errors for a large number of them,
just to avoid having to round values if you want them rounded.
Let's see. You originally set your boundary to 1e-11, then improved
it to 1e-14, yes? Okay, let's see. Here's a range of values
(in doubles, since you were complaining about an e-16) near 180 which
produce values ranging from 1e-14 to -1e-14. You will notice
that, for all of these values except the one right in the middle,
yours produces an inaccuracy GREATER in magnitude than the
inaccuracy reported for 180.0. Which is to say... It's wrong
more often than it's right, and by a larger margin.
sin(179.99999999999940314410) = 1.0336512461933677897718553e-14
sin(179.99999999999943156581) = 9.8924232520836152815491005e-15
sin(179.99999999999945998752) = 9.4483340422335526653796478e-15
sin(179.99999999999948840923) = 9.0042448323834900492101951e-15
sin(179.99999999999951683094) = 8.5601556225334274330407425e-15
sin(179.99999999999954525265) = 8.1160664126833648168712898e-15
sin(179.99999999999957367436) = 7.6719772028333022007018371e-15
sin(179.99999999999960209607) = 7.2278879929832395845323845e-15
sin(179.99999999999963051778) = 6.7837987831331769683629318e-15
sin(179.99999999999965893949) = 5.8956203634330517360240265e-15
sin(179.99999999999968736120) = 5.4515311535829891198545738e-15
sin(179.99999999999971578291) = 5.0074419437329265036851211e-15
sin(179.99999999999974420462) = 4.5633527338828638875156685e-15
sin(179.99999999999977262632) = 4.1192635240328012713462158e-15
sin(179.99999999999980104803) = 3.6751743141827386551767631e-15
sin(179.99999999999982946974) = 3.2310851043326760390073105e-15
sin(179.99999999999985789145) = 2.7869958944826134228378578e-15
sin(179.99999999999988631316) = 1.8988174747824881904989525e-15
sin(179.99999999999991473487) = 1.4547282649324255743294998e-15
sin(179.99999999999994315658) = 1.0106390550823629581600471e-15
sin(179.99999999999997157829) = 5.6654984523230034199059446e-16
sin(180.00000000000000000000) = 1.2246063538223772582114179e-16
sin(180.00000000000002842171) = -3.2162857446782489034831087e-16
sin(180.00000000000005684342) = -7.6571778431788750651776354e-16
sin(180.00000000000008526513) = -1.2098069941679501226872162e-15
sin(180.00000000000011368684) = -1.6538962040180127388566689e-15
sin(180.00000000000014210855) = -2.5420746237181379711955742e-15
sin(180.00000000000017053026) = -2.9861638335682005873650269e-15
sin(180.00000000000019895197) = -3.4302530434182632035344795e-15
sin(180.00000000000022737368) = -3.8743422532683258197039322e-15
sin(180.00000000000025579538) = -4.3184314631183884358733849e-15
sin(180.00000000000028421709) = -4.7625206729684510520428375e-15
sin(180.00000000000031263880) = -5.2066098828185136682122902e-15
sin(180.00000000000034106051) = -5.6506990926685762843817429e-15
sin(180.00000000000036948222) = -6.5388775123687015167206482e-15
sin(180.00000000000039790393) = -6.9829667222187641328901009e-15
sin(180.00000000000042632564) = -7.4270559320688267490595535e-15
sin(180.00000000000045474735) = -7.8711451419188893652290062e-15
sin(180.00000000000048316906) = -8.3152343517689519813984589e-15
sin(180.00000000000051159077) = -8.7593235616190145975679116e-15
sin(180.00000000000054001248) = -9.2034127714690772137373642e-15
sin(180.00000000000056843419) = -9.6475019813191398299068169e-15
sin(180.00000000000059685590) = -1.0091591191169202446076270e-14
-s
--
pharrington
believe what you're posting, but I can't sleep right now so :\
But eh,
ruby-1.9.1-p376 > degrees = PI/180
=> 0.0174532925199433
ruby-1.9.1-p376 > sin(67*degrees)
=> 0.92050485345244
ruby-1.9.1-p376 > sin1(67*degrees)
=> 0.92050485345244
ruby-1.9.1-p376 > cos(67*degrees)
=> 0.390731128489274
ruby-1.9.1-p376 > cos1(67*degrees)
=> 0.390731128489274
ruby-1.9.1-p376 > cos(67*degrees) == cos1(67*degrees)
=> false
ruby-1.9.1-p376 > sin(67*degrees) == sin1(67*degrees)
=> false
Are you saying that Ruby is lying about Math.sin and your sin1
functions returning different values? Also, as has been pointed out
previously, what's displayed when a float is converted to a string is
not necessarily indicative of its actual, internal value.
Also, as has been pointed out, Math::PI is *not* the ratio of a
circle's circumference to its diameter, so even disregarding inherent
floating point imprecision, ranting about the miniscule inaccuracy of
trigonomic functions using this value is pointless because *we're not
even using 100% accurate data to begin with*.
> Are you guys Republicans and/or Global Climate Change deniers too?
If you're not a troll, you should really calm down, lay off the
mailing lists for awhile, and learn how to rationally think things
through and except advice/criticism
Marnen Laibow-Koser
>>
>> 1.0 - (sin(PI/180*67) ** 2 + cos(PI/180*67) ** 2)
>>
>> John
>
> All I can say is....
>
> Against stupidity the Gods themselves contend in vain. :(
Yup. And you're not on the gods' side here. :)
Best,
--
Marnen Laibow-Koser
http://www.marnen.org
mar...@marnen.org
Ryan Davis
On Dec 27, 2009, at 22:35 , pharrington wrote:
> Not sure at this point if you're just a brilliant troll, or actually
> believe what you're posting, but I can't sleep right now so :\
DING DING DING DING DING DING DING WE HAVE A WINNER!
Guys, stop feeding.
Don't make me bring Ilias back to make you all realize how good we currently have it.
--
I know that you believe you understand what you think I said but,
I'm not sure you realize that what you heard is not what I meant.
Phillip Gawlowski
>
> On Dec 27, 2009, at 22:35 , pharrington wrote:
>
>> Not sure at this point if you're just a brilliant troll, or actually
>> believe what you're posting, but I can't sleep right now so :\
>
> DING DING DING DING DING DING DING WE HAVE A WINNER!
>
> Guys, stop feeding.
An, admittedly not indepth, search for jza-somethingorother's email
address turns up that the guy isn't so much a troll, as of a rather
peculiar nature (The most math heavy subject was a sieve for prime
numbers, FWIW).
It's probably a case of SmallNameBigEgo:
http://tvtropes.org/pmwiki/pmwiki.php/Main/SmallNameBigEgo
--
Phillip Gawlowski
Rajinder Yadav
LoL I freaking missed the entire pissing contest!
> --
> Phillip Gawlowski
--
Kind Regards,
Rajinder Yadav | http://DevMentor.org | Do Good! - Share Freely