• 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: (was Int Function) mod bug
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (was Int Function) mod bug


  • Subject: Re: (was Int Function) mod bug
  • From: Christopher Nebel <email@hidden>
  • Date: Sun, 18 Aug 2002 21:04:39 -0700

On Sunday, August 18, 2002, at 08:26 PM, Deivy Petrescu wrote:

At 7:36 PM -0700 8/18/02, Paul Berkowitz wrote:

Is [div] fragile in some way I don't know of?

Funny you should ask this Paul.
Since any number x can be writen as x=(x div 1) + (x mod 1) , then the fact that mod has a problem would imply that div have a problem.

I should have known you'd show up for this, Deivy. :) The problem, if you want to call it that -- you could argue it's a design feature -- is not with div and mod as such. (round ... rounding down will exhibit the same behavior.) It's that fixed-precision arithmetic has some fundamental restrictions on what it can represent, and operations that magnify infinitesimal differences will reveal the odd bits. At some point, div has to make a choice about which integer it's going to return. Somewhere there's a line it has to cross, and you can argue about where that line should be, but no matter where you put it, some results are going to come out "wrong."

For example, 2.32 * 100 displays a result of 232.0. This is a lie, and it's a lie in any application that uses IEEE 754 floating point, which just about everyone does these days. In fact, it's just a hair shy of 232.0, as you can see if you say 2.32 * 100 - 232.0. Given perfect precision, you'd get zero, but in fact you get -2.8421709430404E-14 -- a very small number, to be sure, but not zero.

Perl does the exact same thing, and I notice that the Perl handbook has a section on the vagaries of fixed-precision math. Their advice is, essentially, "deal with it." They give some further pointers on testing for being within epsilon rather than testing for equality, but ultimately, that's just how it is.

AppleScript actually attempts to fudge the results of div and mod a bit to produce "better" results. We've dinked with this a couple of times, which is why some versions of AppleScript have different troublesome numbers than other versions. Personally, I'm inclined to rip all of it out, because it obviously doesn't work right in all cases, I don't believe it's possible to make it work right in all cases, and we'd at least be consistent with everyone else.


--Chris Nebel
AppleScript Engineering
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • Re: (was Int Function) mod bug
      • From: "Dennis W. Manasco" <email@hidden>
References: 
 >(was Int Function) mod bug (From: Deivy Petrescu <email@hidden>)

  • Prev by Date: Rounding x to y decimal places (was Re: Int Function
  • Next by Date: Re: Rounding x to y decimal places (was Re: Int Function
  • Previous by thread: (was Int Function) mod bug
  • Next by thread: Re: (was Int Function) mod bug
  • Index(es):
    • Date
    • Thread