Re: Re: bug in IntegerPart ?
- To: mathgroup at smc.vnet.net
- Subject: [mg47938] Re: Re: bug in IntegerPart ?
- From: Daniel Lichtblau <danl at wolfram.com>
- Date: Sun, 2 May 2004 04:50:33 -0400 (EDT)
- Sender: owner-wri-mathgroup at wolfram.com
AC wrote: > Daniel Lichtblau <danl at wolfram.com> wrote in message news:<c6qamj$s6j$1 at smc.vnet.net>... > [...] >>The confusion is between arithmetic models. Mathematica uses a binary >>representation for approximate numbers. It does not do (1.65 - 1.3) in > > > We already agreed that 'decimal' != 'approximate' (at least in > mathematics). We have agreed to no such thing. By universal convention (okay, universal - 1), 1.65 is an approximate number. If you think about it you realize that the only alternative is to make it exact, that is, 165/100, which is certainly something a parser and evaluator could do. But this is not a direction we will pursue. By the way: What is 3 + 1.65? What is 1.3 + 1.3*10^(-100)? What is Pi + 1.65? What is 1.3*Pi? How do you propose these be represented? Any serious follow up will address these examples in detail. > [...] > You apparently have problems to distiguish number from its internal > Mathematica representation. It seem like you don't care what a user > may need. I rather doubt I have any such problem, but that's not the issue. As has been noted in this thread, Mathematica works with approximate numbers in binary representation, and if the input is approximate then that's the end of the story. This is true regardless of how you might choose to think of the numbers: exact, approximate, or living is some way-cool realm of Heisenberg uncertainty in regard to those possibilities. The working assumption in the program is that the user will provide either exact or approximate numbers according to need. If that assumption is violated, do not expect the software to fix it for you. And if you wanted the program to use an implementation of approximate decimal arithmetic, Mathematica is not the program for you. > I can replace 1.2343 by 12343/10000 to get an exact > representation. However, if the set of data is large that causes some > pain. Again, such reluctance on your part will not be compensated by transformations on the part of the software. If you want exact arithmetic you need to provide the documented (and quite standard) form of exact input. >>this is the case for machine numbers is an obvious consequence of the >>fact that machine arithmetic is implemented using floating point >>hardware, all of which nowadays works with binary representations. > > > This statement is misleading at best. Eventually everything is > represented by computers in binary form. 12343/10000 can be > represented with finite number of bits and so can 1.2343. To be > truthful you should say: "The numerical engine of Mathematica, as > currently implemented, leads to non terminating binary representations > of decimals." The number 1.2343, as an approximate (decimal), cannot be represented in nonterminating binary, a matter that is covered in numerical analysis texts. One can rationalize it to 12343/10000 but then one can no longer do approximate arithmetic on it, which means one loses access to valuable technology that has grown up around numeric computation. Or one can reinvent approximate representations in nonbinary systems (which are of course ultimately implemented in binary, e.g. via BCD, but jump through hoops to do arithmetic). Then one loses efficient support from hardware, existing libraries such as Lapack and GMP, and so forth. I cannot imagine that these possibilities hold much interest for anyone. Anyway we are not pursing such paths. > [...] > We would save time and bandwidth, if you would stop pretending that > you don't understand what I'm saying, step out of your box, and admit > that there better alternatives exist. Interesting phrase, "step out of your box", from someone posting anonymously. Apparently this also gives but little compulsion to come up with actual, factual, references. > [...] >>>Only in Mathematica 1.3 is not 13/10. >> >>That's an extremely incorrect remark. In any system that does > > > Oh boy, here we go again. In mathematics these two numbers ARE > IDENTICAL. You are confounding secondary school mathematics with what happens later (e.g. in both numeric and symbolic computation domains). They are quite different, and texts as well as standard practice in both areas make that clear. Actually what I wrote above is not quite right: significant digits is a concept taught in some secondary schools. In that setting, 1.3 has but two such digits, and hence is but an approximation to 13/10. > Fact that in your implementation they are not, should give > you hint that there might be something not as perfect as you seem to > believe. You should try to get as close to mathematics as possible. What we should do in Mathematica development will hardly be determined by the various vaporous "suggestions" that have appeared in this thread. I will only comment that I make no claim to perfection of Mathematica numerics or for that matter of IEEE notions as to how to do numerical computation. I only claim these are sensible approaches, and they work well in practice. People who prefer to do things differently are still welcome to do so. >>approximate computation using an underlying binary representation (and >>this is most computational math programs, I gather), 1.3 is not 13/10. >>Indeed in any system that distinguishes exact from approximate numbers, >>1.3 is not 13/10 (though they may be deemed numerically equal). I have >>no intention of giving a lecture on the distinction between exact and >>approximate arithmetic. If it is unclear to you then you can read up on >>it in pretty much any text that covers symbolic algebra (as well as many >>that don't). >> >> >>>The notion that when one uses >>>the decimal point, she/he doesn't really know the number and needs to >>>be corrected is idiotic at best, >> >>Nobody is being "corrected". Approximate numbers are stored in binary >>representation. Period. > > THAT NUMBER IS NOT APPROXIMATE. YOU MAKE IT APPRIOXIMATE BY CHOOSING A > PARTICULAR IMPLEMENTATION FOR YOUR NUMERICAL ENGINE. In Mathematica the conventions that distinguish between approximate and exact numbers are very clearly spelled out, and are not at all controversial. Indeed, they are very much in accord with the main of mathematical computation (although the details of approximate bignum arithmetic have been known to raise eyebrows. And hairlines.) Moreover, this issue of distinguishing has nothing to do with implementation of numerical engine. Indeed, once one involves ANY numerical engine, one is dealing with approximate arithmetic. After that the issues involve internal representation, and we use binary rather than decimal. I gather that you disapprove, but it's not going to change. >>I haven't the faintest notion as to how BaseForm chooses to truncate. > > > You could look int your source code. > [...] The BaseForm issue does not hold sufficient interest for me. If it is not useful to you, I can only recommend that you not use it. --------------------------------------------------------- As best I can tell, you've sent five or six posts to MathGroup berating the Mathematica handling of decimal input, and the recent ones are becoming shrill, as happened the last time. You have to date in this thread, and in the last go-round, betrayed little understanding of the practice of mathematical computation, exact or numeric (I won't even get into the hybrid approaches that nowadays pervade both realms). To what purpose? At the end of the day your actual concern, I should hope, would be to get your code to behave as you would like. I see two alternatives. (1) Give input to Mathematica that conforms to our documentation of "exact", if you want it treated as such. (2) Find another software package that will do with numbers whatever it is you have in mind. Tirades in regard to what are fairly standard approaches to recognition and manipulation of approximate numbers will not effect any useful result. You can continue to post them until the moderator pulls the plug, or until all respondents lose interest (I seem the be the only one remaining). But all it might gain you is a paragraph in the folklore Guide to Usenet Cranks. I have to question your motives in continuing to pursue this. You are unhappy with the way in which Mathematica works with decimal input. Your proposed alternative appears to involve software implementation of base 10 approximate arithmetic, which would still not address issues involving values whose representations do not terminate in that base, and in any case is something we will not pursue. Why continue the discussion? Daniel Lichtblau Wolfram Research