Trig value errors

Discussion in 'Ruby' started by jzakiya, Dec 23, 2009.

  1. jzakiya

    jzakiya Guest

    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

    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.
    jzakiya, Dec 23, 2009
    #1
    1. Advertising

  2. 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
    Phillip Gawlowski, Dec 23, 2009
    #2
    1. Advertising

  3. jzakiya

    jzakiya Guest

    On Dec 22, 9:38 pm, Phillip Gawlowski <> wrote:
    > On 23.12.2009 03:10, jzakiya wrote:
    >
    > > But...being able to do ACCURATE MATH creates benefits
    > > that far supercede any hassles to write the core to do it.

    >
    > Floats won't be properly accurate in a mathematical sense, anyway, since
    > they are approximations. Their accuracy is highly dependend on the WORD
    > length of a CPU / Mathematical Co-processor (i.e. 8bit, 16bit, 32bit,
    > 64bit, 128bit, etc).
    >
    > Further reading provides:http://en.wikipedia.org/wiki/IEEE_754-2008
    >
    > Your apparently required level of accuracy is the realm of specialized
    > math libraries, if not specialized languages and/or hardware, since it
    > isn't needed in most (any?) circumstances by Average J. Programmer. Only
    > a select few of us get to write code for, say, CERN. ;)
    >
    > Then there's existing code to consider. AFAIK, IEEE 754 is the way Ruby
    > handles floating point numbers, and there *will* be code that relies,
    > for better or for worse, on this behavior (and rather rightly, since
    > IEEE 754 is the accepted standard to handle floats), and a higher level
    > of accuracy could cause quite a number of ripple effects, requiring a
    > carefully planned change (maybe an eventual Ruby 2.0 even).
    >
    > --
    > Phillip Gawlowski


    The reason I made the distinction between 'mathematical' versus
    'arithmetical' accuracy is because 'mathematical' accuracy, in the
    case of the trig values, REQUIRES the
    trig values on an axis to defined as +1, -1, or 0.

    There are no mathematical ambiguities at these points.

    The issue I am raising is not a floating point issue, or how you
    choose to compute the trig values (series expansion, or whatever). I'm
    saying the current trigs implementations has by design (a choice of
    priorities) decided to return mathematically erroneous results, even
    though they may be computed arithmetically accurate.

    I am requesting that the trig functions return the correct
    'mathematically' results that are inherent for the specific cases for
    angles n*PI/2, which REQUIRES that sin/cos=1,0,-1. As I showed in my
    examples, this decision is being done in some cases, but not others.

    We know cos(PI/2)=0 not 6.123023176911189e-17, so round
    it, truncate, whatever, to 0. Make it mathematically correct by
    whatever arithmetic process you choose.

    It's not about how many decimal places of arithmetic accuracy being
    represented, it's a matter of conceptual accuracy that the language
    has MADE A CHOICE not to satisfy.
    jzakiya, Dec 23, 2009
    #3
  4. [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 <> 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
    John W Higgins, Dec 23, 2009
    #4
  5. jzakiya

    Phrogz Guest

    On Dec 22, 8:47 pm, jzakiya <> 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?
    Phrogz, Dec 23, 2009
    #5
  6. jzakiya

    Phrogz Guest

    On Dec 22, 7:08 pm, jzakiya <> 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.
    Phrogz, Dec 23, 2009
    #6
  7. jzakiya

    Phrogz Guest

    On Dec 22, 10:07 pm, Phrogz <> 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=cos( 2*pi / 360 / 1e3 )
    and results in:
    0.9999999998476912901

    Trying for smaller parameter values, however, results in Alpha giving
    up:
    http://www.wolframalpha.com/input/?i=cos( 2*pi / 360 / 1e4 )
    (For me, that query always results in a message: "This Wolfram|Alpha
    server is temporarily unavailable.")
    Phrogz, Dec 23, 2009
    #7
  8. jzakiya

    jzakiya Guest

    On Dec 23, 12:42 am, Phrogz <> wrote:
    > On Dec 22, 10:07 pm, Phrogz <> 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=cos( 2*pi / 360 / 1e3 )
    > and results in:
    > 0.9999999998476912901
    >
    > Trying for smaller parameter values, however, results in Alpha giving
    > up:http://www.wolframalpha.com/input/?i=cos( 2*pi / 360 / 1e4 )
    > (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
    jzakiya, Dec 23, 2009
    #8
  9. > 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
    Fleck Jean-Julien, Dec 23, 2009
    #9
  10. 2009/12/23 jzakiya <>:
    > On Dec 23, 12:42=A0am, Phrogz <> wrote:
    >> On Dec 22, 10:07=A0pm, Phrogz <> 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=3Dcos( 2*pi / 360 / 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/
    Robert Klemme, Dec 23, 2009
    #10
  11. 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.


    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
    Phillip Gawlowski, Dec 23, 2009
    #11
  12. jzakiya

    Paul Smith Guest

    On Wed, Dec 23, 2009 at 2:03 PM, Phillip Gawlowski <> wrote:
    > 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

    Paul Smith, Dec 23, 2009
    #12
  13. jzakiya wrote
    > 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, Dec 23, 2009
    #13
  14. Robert Klemme wrote:
    > ... 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!)
    Colin Bartlett, Dec 23, 2009
    #14
  15. jzakiya

    Xavier Noria Guest

    Please could we stop this thread?

    Ordinary programming language use floats, with all their limitations
    and virtues. If you want something closer to exact math please look
    elsewhere like Mathematica.
    Xavier Noria, Dec 23, 2009
    #15
  16. 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
    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
    Phillip Gawlowski, Dec 23, 2009
    #16
  17. jzakiya

    jzakiya Guest

    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.

    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
    jzakiya, Dec 23, 2009
    #17
  18. jzakiya

    pharrington Guest

    On Dec 23, 12:14 pm, Phillip Gawlowski <> wrote:
    > 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
    > need maths, nobody would need it.


    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, Dec 23, 2009
    #18
  19. jzakiya

    pharrington Guest

    On Dec 23, 12:35 pm, jzakiya <> wrote:
    > 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, Dec 23, 2009
    #19
  20. jzakiya

    pharrington Guest

    On Dec 23, 12:35 pm, jzakiya <> wrote:
    > 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.
    >
    > 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


    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...
    pharrington, Dec 23, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?UGF1bA==?=

    SortExpression makes SortCommand event not to trig

    =?Utf-8?B?UGF1bA==?=, Sep 22, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    460
    =?Utf-8?B?UGF1bA==?=
    Sep 22, 2005
  2. Cary West

    Python trig precision problem

    Cary West, May 18, 2006, in forum: Python
    Replies:
    4
    Views:
    828
    Robert Kern
    May 19, 2006
  3. John Smith

    C's trig functions

    John Smith, Apr 26, 2005, in forum: C Programming
    Replies:
    7
    Views:
    439
    John Smith
    Apr 26, 2005
  4. Mark Healey
    Replies:
    7
    Views:
    1,458
    Tim Prince
    May 22, 2006
  5. kwikius
    Replies:
    1
    Views:
    378
    Default User
    May 22, 2008
Loading...

Share This Page