Re: bug in IntegerPart ?
- To: mathgroup at smc.vnet.net
- Subject: [mg47970] Re: bug in IntegerPart ?
- From: ancow65 at yahoo.com (AC)
- Date: Tue, 4 May 2004 01:08:50 -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>
- Sender: owner-wri-mathgroup at wolfram.com
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. 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.
(2) the elimination of problems on the boundary between machine and
big number arithmetic
(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.
I hope you agree that Mathematica should produce the same output no
matter what hardware. Type 0.100... . 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. 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.
> 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.:-)
> number's got a "." in it, it's approximate. Period :-)
Period? :-) You sound like Mr. Lichtblau. :-)
>
> If you want an exact rational number, use 165/100. What's so hard about
> that?
It is nuissance and it's ugly.
> 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.
>
> > Both developers and users will have
> > precision or speed as needed without compromising mathematical clarity
> > and precision.
>
> We already have this.
We don't. :-)
> The notation just doesn't match your prejudices.
???
>
> -jpd
- Follow-Ups:
- Re: Re: bug in IntegerPart ?
- From: "J. McKenzie Alexander" <jalex@lse.ac.uk>
- Re: Re: bug in IntegerPart ?