• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: a numeric bug.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: a numeric bug.


  • Subject: Re: a numeric bug.
  • From: deivy petrescu <email@hidden>
  • Date: Thu, 15 Sep 2005 17:55:47 -0400


On Sep 15, 2005, at 13:38, Christopher Nebel wrote:

On Sep 15, 2005, at 3:13 AM, Emmanuel wrote:


At 9:05 AM +0100 9/15/05, has wrote:


deivy petrescu wrote:


I don't get it. 10^23 is way below AS numeric limit (which I believe is over 10^300).


The precision limit is much lower, however - approx. ±9e15. Beyond that they're only approximations, and calculations involving the least significant digits are going to have inaccuracies.



I think that Deivy's point is that when it comes to take the "mod" a smart computer storing 1.000 as the mantissa and 24 as the exponent of 10 should be able to give the correct result.



Sure, but that's not how the internal representation of numbers in AppleScript works. It's using IEEE 754 double-precision numbers, which use mantissa * 2**exponent, which is notoriously inaccurate when representing powers of 10. (10 is an infinite repeating decimal in base 2.)


--Chris Nebel
AppleScript and Automator Engineering

First, I am a bit less stressed now than when I found the errors :)
Second, I see, now, yesterday I did not, that to use (mod ) AS needs to keep the whole number to give an accurate answer.
However, I would assume that, and most people would probably agree, that rounding or precision errors (except for propagation) should happen in a far, far away decimal place. I would even accept
pi= 3.15
or
pi=3.0
But,
pi=10
would blow me away.


Somehow I feel that if a program offers the tool and makes no point on the limits of the tool, something is really wrong. This goes for AppleScript, and as has pointed out, for Python as well.



If you want arbitrary precision or strict financial math, you're using the wrong language, and you should stop one or the other.


Chris, I am well aware that you know Smile.
Many people may not know it and know that is a full fledge Scientific software used in many scientific institutions.
Someone in one of these institutions might one day need to use something like 10^23 mod 29.
Boy, is he in for a surprise!
I have no problem with AS shortcomings, if you will, but I'd appreciate some documentation.
As many people, or one person over and over again, I can't remember... :), pointed out the great benefit of AppleScript is having it being used in a way that it was not originally thought for.


Please document it. At least now I can find 10^24 mod 29 in AS or Smile, because I am aware of the problem. Thus, I can stil use Smile, or AS, and avoid the traps.
Thanks


deivy


_______________________________________________ Do not post admin requests to the list. They will be ignored. Applescript-users mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
  • Follow-Ups:
    • Re: a numeric bug.
      • From: Helmut Fuchs <email@hidden>
References: 
 >Re: a numeric bug. (From: has <email@hidden>)
 >Re: a numeric bug. (From: Emmanuel <email@hidden>)
 >Re: a numeric bug. (From: Christopher Nebel <email@hidden>)

  • Prev by Date: convert AS syntax to CLI
  • Next by Date: Re: Get the "last" folder...
  • Previous by thread: Re: a numeric bug.
  • Next by thread: Re: a numeric bug.
  • Index(es):
    • Date
    • Thread