Re: Re: bug in IntegerPart ?
- To: mathgroup at smc.vnet.net
- Subject: [mg47938] Re: [mg47917] Re: bug in IntegerPart ?
- From: Daniel Lichtblau <danl at wolfram.com>
- Date: Fri, 30 Apr 2004 23:32:56 -0400 (EDT)
- Sender: owner-wri-mathgroup at wolfram.com
> 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
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
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
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
>>>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
> 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
(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?
Prev by Date:
Re: strange problems with Random
Next by Date:
Re: understanding Complement
Previous by thread:
Re: strange problems with Random
Next by thread:
Re: bug in IntegerPart ?