On 06Mar2014 19:53, Mark H. Harris email@example.com wrote:
On Thursday, March 6, 2014 8:53:35 PM UTC-6, Andrew Barnert wrote: [... lots of stuff, snipped along with Mark's replies ...]
You proposed some complicated AI-based solution to solve the problem of using separate number classes in a single expression, even though Python (almost exactly like C++, in this case) has already solved that problem with operator overloading.
No, I did not. I suggested that unifying numbers in an (AI) way
could solve this problem (conceptually) by regarding all numbers as PythonNumbers. Decimals should not only be default, they should be integrated, not tacked on with duck tape.
This sounds to me like keeping the original numeric text around and only turning it into some efficient-for-a-machine representation when it comes time to work on it.
One issue with that is that when the work occurs, it can be far from where the number was defined, and the correct internal representation might be poorly chosen.
(And note that Python is flexible enough that third-party libraries can easily insert new types like quaternions, matrices, symbolic expressions, etc. into the hierarchy in a way that's transparent to end users. I can multiply a NumPy matrix of float64 values by the builtin in 2 just by writing "m * 2", and it works exactly the way you'd want it to. It's hard to imagine that would be even feasible with an AI-based solution, but with the current design, that's the easiest part of NumPy.)
That's nice for you. Because sqrt(.23709) does not behave as I
expect, sadly, I have to train my users to enter sqrt('0.23709').
That's partly because .23709, in current python, becomes an IEEE float with some loss of precision because binary fractions and base-10 fractions do not round trip.
But also partly because sqrt() (in the pure mathematical sense) often produces transcendental numbers, which are not representation by any fixed precision intergal base notation - effectively IEEE floats and Decimal floats are fractions/rationals.
So sqrt() will, for almost all numbers, involve loss of precision no matter what base your backing storage is: base 2 as in IEEE float or base 10 as in a Decimal. Steven (or Stephen) has already pointed this out to you; perhaps it has been missed.
And going back (eg sqrt(2.01)*sqrt(2.01) ==> not-quite-2.01) just extends this loss of precision.
This is an inherent problem unless sqrt() doesn't convert to a "concrete" type, and instead just lurks as some symbolic representation, so that any expression involving it becomes a progressively more elaboration representation of an algebraic expression. Which may be correct, but only until you try to evaluate it to get a concrete number again.
There are some ideas in your posts that are worth responding to,
Thank you. If a user goes to the time and trouble to present an
idea clearly, I would expect the responders to respect the effort and respond to the points that make sense.
Many people have. You should see the short shrift some ideas receive.
I think part of the problem is not your wish for a "number" but that lack of a concrete proposal to implement it.
Cameron Simpson firstname.lastname@example.org
The Usenet is not the real world. The Usenet usually does not even resemble the real world. - email@example.com