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: <firstname.lastname@example.org> <200404260641.CAA06324@smc.vnet.net> <email@example.com> <200404281056.GAA12294@smc.vnet.net> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
- 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
- Re: Re: bug in IntegerPart ?
- From: "J. McKenzie Alexander" <email@example.com>
- Re: Re: bug in IntegerPart ?