RE: Re: bug in IntegerPart ?
- To: mathgroup at smc.vnet.net
- Subject: [mg47946] RE: [mg47908] Re: bug in IntegerPart ?
- From: "DrBob" <drbob at bigfoot.com>
- Date: Sun, 2 May 2004 04:50:41 -0400 (EDT)
- Sender: owner-wri-mathgroup at wolfram.com
Peter, Mathematica already supports exact mathematics, as we all know. As Peltio pointed out in another thread, the expression 34.123*89 can be entered as N[Rationalize[34.123]*89,30] 3036.94700000000000000000000000 I'd probably use N[(34123/1000)*89, 30] 3036.947`30. or, better yet, (34123/1000)*89 3036947/1000 It appears you recognize that machine arithmetic is needed for speed, at least some of the time. We have both arithmetic models available, so what's the problem? Your quibble seems to be that exact arithmetic should be the default. Well, maybe so, but it isn't. I can live with that because it's doubtful, when I type in 34.123, that I actually know the number to infinitely many places (or even five). If I do, it's because I derived it by dividing two integers. In that case, there's no particular reason -- other than the space taken up onscreen -- to prefer writing 34.123 rather than 34123/1000. Mathematically, they're the same. If I don't know the number to more places than those I've entered, it's misleading (and amateurish) to do arithmetic or present results as if I did. It's also SLOW. Almost all algebraic (and all transcendental) numbers are not representable as terminating decimals, so it seems natural (to me) to think of decimals as approximate. Rational fractions and radicals of integers "look" exact. Decimals don't. I think, in a few years, the need for speed will be less pressing, and changing the default may be attractive. Like it or not, it will be up to developers to decide if, and when, that time has come. Meanwhile, if another system does it better, why not use it? The members of this group can't rewrite Mathematica to your specifications, even if we wanted to. DrBob www.eclecticdreams.net -----Original Message----- From: AC [mailto:ancow65 at yahoo.com] To: mathgroup at smc.vnet.net Subject: [mg47946] [mg47908] Re: bug in IntegerPart ? I have feeling speaking to deaf ears. Let me try again. On one hand, there is mathematics with all these wonderful and precise ideas. On other hand are computer programs that model (sic!) these ideas on computer. I have impression that some of us got some much involved with programs that forgot that they are just projections of mathematical ideas. In mathematics 1.3 is an exact number. Decimals can be represented on computer in number of ways. IEEE representation is only one of many. Contrary to the belief of posters, there are known ways to represent decimal numbers on computer EXACTLY. Just as there are big integers, there are also big floats available in number of languages or programs. Sorry, the charter of this group does not allow me to list their names. There is no apparent reason, why Mathematica could not do the same. Additionally, there are indeed numbers that are known only approximately and there are methods to perform computations with such. Interval arithmetic is notably one of such methods. As long as Mathematica's numerical model mixes these two classes, there will side effects and confusion. I am trying to say that the system can be improved relatively easily, the methods are known, and the only missing factor will. 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. Both developers and users will have precision or speed as needed without compromising mathematical clarity and precision. AC