Simplify not maintaining precision?

[Eviatar]

Is this a known bug?

sage: a = RealField(200)(8.987551787368175506591796875e9)
sage: a
8.9875517873681755065917968750000000000000000000000000000000e9
sage: var('y')
y
sage: b = (a * x).mul(y, hold=True)
sage: b
(8.9875517873681755065917968750000000000000000000000000000000e9*x)*y
sage: c = (b / (x * y)).simplify()
sage: c
8987551787.37
sage: RealField(200)(c)
8.9875517873681697845458984375000000000000000000000000000000e9

[kcrisman]

On Aug 1, 3:17 pm, Eviatar <eviatarb...@gmail.com> wrote:
> Is this a known bug?

Perhaps it is better to say that it is a confusing feature.

sage: x.simplify?
<snip>
Note: Currently, this just sends the expression to Maxima and
converts
it back to Sage.
<snip>

In particular, the precision will not be carried over.

On the other hand, as a workaround for what you are doing, you could
just use a symbolic a and then substitute it in
(expression.subs(a=RealField...)) at the very end.

I am not sure if this is a good answer for you, but I don't think we
can do anything else about this at the current time.

- kcrisman

[Eviatar]

Oh, I just assumed the interface with Maxima would maintain precision.

[Nils Bruin]

On Aug 1, 1:42 pm, Eviatar <eviatarb...@gmail.com> wrote:
> Oh, I just assumed the interface with Maxima would maintain precision.

It could. Maxima does have a notion of multiprecision floats. They are
base 2, so interfacing with MPFR should be a cinch. Especially with
lib_maxima, translating MPFR to maxima multiprec and vv. should be a
matter of a couple of lines.

I don't know how many routines in Maxima work in a sensible way with
multiprec floats.

[Eviatar]

This is now #11643, http://trac.sagemath.org/sage_trac/ticket/11643.

[Nils Bruin]

On Aug 1, 6:52 pm, Eviatar <eviatarb...@gmail.com> wrote:
> This is now #11643,http://trac.sagemath.org/sage_trac/ticket/11643.

A little experimenting (see ticket) shows that Maxima itself does not
keep track of precision in its bigfloats. Any computation (including
just adding two numbers!) will just produce a bigfloat with precision
as set by "fpprec". This even happens when adding two bigfloats with
lower precision. In short, while maxima's bigfloats carry precision
information with them, this is not taken into account in computations.

If we want maxima's floats to act nicely with sage's precision model,
we'd have to scan the expression for mpfr objects, figure out from
that a reasonable precision, set fpprec to that and do the maxima
computation.
In your original example, you'd have to set "fpprec" to 200*ln(2)/
ln(10).