On Sunday, March 30, 2014 12:19:00 AM UTC-7, Joachim Durchholz wrote:
>
> 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 are numbers and there are operations. The addition of IEEE754 binary
numbers
does not always correspond to the mathematical sum. Except for overflow,
the addition
should result in the IEEE754 representable number that is closest to the
true value.
(I'm leaving out some edge cases like adding NaNs etc.)
I'm saying that every IEEE754 valid number is exactly some rational number.
>
> > 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.
>
I guess you don't. I said that you use arbitrary precision integers for
the "fraction".
the exponent could be a fixnum for most practical purposes.
>
> > 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.
>
Wrong. I said the numbers were closed under addition and multiplication.
They are not closed under division, and you need division to create 1/3.
You cannot create 1/3 from addition or multiplication of floats or binary
rationals.
> >> 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.
>
The point I was making is that people seem to want to use floats. In the
Macsyma / Maxima rational function package, floats are converted to
rational numbers. Sometimes this is just fine, and sometimes it really only
makes sense to leave the floats alone.
>
> 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).
>
That's because it would have to read the user's mind. There has to be
some other mechanism. For example, in Maxima there is a flag you
can set, keepfloat: true.
> What can be made to work is x^"0.5" - SymPy gets to see the
> representation and can convert to rational directly.
>
This looks like garbage. If SymPy controlled the parser, it could get
some kind of structure like
power(x, float_like_object( exact_integer(0), exact_integer(5)))
and some later stage could decide whether that is a
single/double/exact_ratio.... etc number.
for example, Maxima allows 1.2345d0 for a double float. 1.2345b0 for
a bigfloat.
and presumably with a tweek of the system could allow for decimal floats,
or conversion
of float_like_objects directly to ratios of integers.
I don't know if sympy has any access to such things. But it could, if all
input to sympy were
enclosed at the beginning and the end with
" ................."
That is, all sympy programs are python character strings, and sympy has a
hacked-up python parser
inside it.
Does python allow you to just write very long integers, e.g.
x: := 213456789123456789123456789 ?
If you have to do some song-and-dance and/or use quotes, you lose some of
the audience.
{Apologies -- I really don't know how big integers are integrated into
python or sympy}
--
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/50817642-efa1-4be4-9255-144551248149%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
