MathGroup Archive 2004

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: bug in IntegerPart ?

  • To: mathgroup at
  • Subject: [mg48000] Re: bug in IntegerPart ?
  • From: John Doty <jpd at>
  • Date: Wed, 5 May 2004 08:11:06 -0400 (EDT)
  • References: <c6g015$4lk$> <> <c6l7gv$imk$> <> <c6qamj$s6j$> <c6unq6$as8$> <c72dh5$lb$> <c7792b$hi4$>
  • Sender: owner-wri-mathgroup at

AC wrote:
> John Doty <jpd at> wrote in message news:<c72dh5$lb$1 at>...
>>AC wrote:
>>>I have feeling speaking to deaf ears. Let me try again.
>>We feel the same way. Please listen.
>>> I made a constructive
>>>suggestion. (1) Treat all decimals as exact numbers. In this way
>>>number of problems arising on the border between Machine Precision and
>>>Big Number Arithmetic would disappear. The mapping between decimals in
>>>mathematics and Mathematica would become bijection. (2) Introduce a
>>>new notation or alternatively a programming switch for inexact numbers
>>>that would follow IEEE rules.
>>As a Mathematica user, I don't find this constructive. It would break 
>>practically everything I've done in Mathematica in the last 15 years.
> Your apocalyptic vision is completely groundless. In reality it would
> break nothing or almost nothing. Mathematica already has switches for
> machine and arbitrary precision. Decimals would go by default to
> arbitrary precision branch. Assuming that ?..' extension would be
> chosen numbers like 1.3.. would go through current machine precision
> branch.  Two function would be added to move between types
>      1.3..->  1.3 and 1.3 -> 1.3..
> The only significant change from users' point of view would be slower
> execution of legacy code that uses decimals.

Yeah, right. Try Sum[Cos[1.65 x],{x,0,1000000}]. Simple, huh? Now try 
Sum[Cos[165/100 x, {x,0,1000000}].

> Benefits would include
> (1) intuitive and much cleaner approach to various types of numerical
> computation; no more postings on math group on why 34.123*89 is not
> 3036.947 or why IntegerPart[(1.65 - 1.3)/0.007] is not 50.

Baloney. You can't eliminate approximate numbers without drastically 
weakening the language, so people who haven't studied numerical analysis 
will still be confused, while people who understand numerical analysis 
will be annoyed that you've abandoned conventional notation that has 
served us well for decades.

> (2) the elimination of problems on the boundary between machine and
> big number arithmetic

The "problems" are inherent in the use of approximate numbers.

> (3) the elimination of hardware dependence (the boundary mentioned in
> (2) is different on 32 and 64 bit machines, I believe).
> Again, the changes would require a small modification of the parser,
> mowing around some numerical computation switches, and adding two
> functions, all that with minimal impact on users.
> Actually, I am very curious what are you doing with the decimals that
> when treated as exact numbers it breaks your code drastically.

Any complicated numerical procedure involving irrational functions. 
Exactitude blocks evaluation of such functions. Sometimes you want this, 
sometimes you don't. Once you understand the rules (which are not 
difficult), it is easy to control this. You want different rules, which 
means a different language. Nothing wrong with that in principle, but it 
wouldn't be Mathematica. And for my purposes, your new language seems 
much less useful.

> I hope you agree that Mathematica should produce the same output no
> matter what hardware. Type 0.100... .

Of course I don't agree. This restriction would drastically reduce the 
efficiency of approximate calculations.

> On 32 bit processor if the
> number of zeros is 16 or less, Precision will return the same result
> (MachinePrecision). If number of zeros is greater then 16, the
> precision will gradually increase with the number of zeros added.
> Precision[0.50000000000000000]
> => MachinePrecision
> Precision[0.500000000000000000]
> =>17.
> If you have 64 bit processor, your MachinePrecision is greater and the
> expected result for the second input is
> Precision[0.500000000000000000]
> => MachinePrecision
> Remember, however, now MachinePrecision is different then before.

And much less practical.

> In
> all these cases the binary representation is finite ( 0.1) and. If you
> want to be precise, when typing decimal numbers, you need to keep
> track how many trailing zeros add and additionally what hardware the
> program is going to run on. You might indifferent to that, but it
> matters to me.

Mathematica gives you this kind of control, but the notation doesn't 
match your prejudices. If you want something different, write your own 
language (*that* would be constructive).

>>The notation 1.65 in Mathematica means, *by definition*, "an approximate 
>>number within machine precision of 1.65". You may not like this 
>>definition, but it's fundamental to the Mathematica language, and most 
>>of us who *actually use* Mathematica find it perfectly natural. If the 
> Let me assure you, I do use Mathematica.:-) 

Apparently not. It seems you just fight with it.

>>number's got a "." in it, it's approximate. Period :-)
> Period? :-) You sound like Mr. Lichtblau. :-)

Thank you. He's a very smart guy.

>>If you want an exact rational number, use 165/100. What's so hard about 
> It is nuissance and it's ugly. 

It's easy and clear. It matches long tradition (no sensible physicist 
would represent the electron's spin as 0.5).

>>The subset of rationals that can be expressed in decimal isn't 
>>especially useful for exact calculation anyway.
> Would you be more specific, please? It sounds like a first class
> nonsense but I don't want to jump the gun.

What prime factors do your denominators generally have? Anything other 
than 2 and 5?


  • Prev by Date: Re: Intra functional relations
  • Next by Date: Mandelbrot Set & Mathematica
  • Previous by thread: RE: Re: bug in IntegerPart ?
  • Next by thread: Re: understanding Complement