Re: bug in IntegerPart ?
- To: mathgroup at smc.vnet.net
- Subject: [mg48000] Re: bug in IntegerPart ?
- From: John Doty <jpd at whispertel.LoseTheH.net>
- Date: Wed, 5 May 2004 08:11:06 -0400 (EDT)
- References: <c6g015$4lk$1@smc.vnet.net> <200404260641.CAA06324@smc.vnet.net> <c6l7gv$imk$1@smc.vnet.net> <200404281056.GAA12294@smc.vnet.net> <c6qamj$s6j$1@smc.vnet.net> <c6unq6$as8$1@smc.vnet.net> <c72dh5$lb$1@smc.vnet.net> <c7792b$hi4$1@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
AC wrote:
> John Doty <jpd at whispertel.LoseTheH.net> wrote in message news:<c72dh5$lb$1 at smc.vnet.net>...
>
>>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
>>that?
>
>
> 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?
-jpd