Am 29.03.2014 21:28, schrieb Richard Fateman:
On Saturday, March 29, 2014 5:24:13 AM UTC-7, Sergey Kirpichev wrote:
On Saturday, March 29, 2014 8:34:36 AM UTC+4, Richard Fateman wrote:
Your problem is that the notions of + and - in your computer programming
language
are apparently inadequate.
In which one? Python, CLisp?
Common Lisp uses floating-point arithmetic for floats, exact arithmetic for
the data type used for
rationals. If you stick with integers and ratios of integers, Common Lisp
does mathematically
valid arithmetic.
There is nothing wrong with these statements.
I'm taking offense with this:
> So is every double-precision IEEE float (except inf and NaN)
> convertible to the exact rational number which it represents in the
> form integer/integer.
>
> It seems to me the meanings of words in sympy should correspond to
> their meanings in mathematics not some hack mockery of the word that
> appears in one or even several programming languages.
This sounds as if IEEE numbers were somehow a mathematical valid
implementation of arithmetic, which they simply aren't.
> There is a way of being considerably faster than ratio
of integers, while
correctly representing WITHOUT ERROR OR ROUNDOFF all results from addition
and multiplication of
numbers that originate as floats. This is "binary rational" and was used
so far as I know in only
one system designed by George E. Collins. It works like this:
a binary rational is an arbitrary-precision integer X 2^(power). Power is
an integer +-, and one could
also make it an arbitrary precision number, though 32 or even 16 bits is
probably enough for most
practical and impractical purposes.
I do not understand - if you use 32 or 16 bits, you're back at the data
model of IEEE arithmetic.
Advantage 1: No need for greatest common divisor calculations. If the
numerator in binary has k trailing zeros, strike them off and add k to the
power.
Advantage 2: No overflow or underflow or rounding from add and multiply.
Exact results.
Advantage 3: strictly a superset of floats.
Disadvantage 1. Division is not exact.
Disadvantage 2: Strictly a subset of "ratio of integers".
They still come with the same problems as IEEE arithmetic, most
importantly precision loss, manifest e.g. at the inability to exactly
represent 1/3.
But I admit, we shouldn't allow
using of Float's (or builtin float type) in symbolic mathematics.
I disagree, from experience. People want to introduce floats. For
example, some people
write squareroot(x) as x^0.5
Saves typing, and they believe it is the same thing.
Actually in this case it is, since 0.5 can be represented exactly.
What's hard is to make SymPy detect whether the float is an exact
representation of what the user wanted (it could silently convert to
rational) and when it isn't (it should warn the user).
What can be made to work is x^"0.5" - SymPy gets to see the
representation and can convert to rational directly.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/5337C564.80008%40durchholz.org.
For more options, visit https://groups.google.com/d/optout.
