Re: [sage-devel] RealField isn't doing it right

[William Stein]

On Mon, Apr 17, 2023 at 9:11 PM Nils Bruin  wrote:

>
> It's certainly reasonable to not call a floating point field "RealField".
> C and python don't even do that: they call such elements floats. I'm less
> sure whether such a RealFloats field should be any less prominent than it
> is now. Plus the whole renaming transition would be super painful.
>

 I called it "RealField" in Sage for compatibility with Magma:

https://magma.maths.usyd.edu.au/magma/handbook/text/253

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CACLE5GCjQuvqsr5r7ky6ubja%2B98GinUPcpR9PyrX900qy4VDrQ%40mail.gmail.com.

Re: [sage-devel] RealField isn't doing it right

[Nils Bruin]

On Monday, 17 April 2023 at 20:44:36 UTC-7 David Roe wrote:


So I think a concrete version of Dima's suggestion would be
1. Implement a new field that stores elements internally as rationals, 
printing as decimals to some precision (you could get a higher precision by 
casting explicitly to RealField(prec), or by using .n(prec)).
2. Real literals would land in this field, which would have coercion maps 
from Z and Q so arithmetic would be exact under the hood.
3. Coercion would go to the symbolic ring, so e^1.1 would live in the 
symbolic ring (rather than RealField(53) where it lives now).  For lack of 
annoyance it should probably still print as a 53-bit decimal, but you could 
cast it to RealField(200) and it would give the correct result.  I guess 
other transcendental functions (log, trig) would also land in the symbolics.
4. Live with the performance implications.  As Dima says, you can use RDF 
if you want fast floating point arithmetic.  But it's already the case that 
the symbolic ring is a performance trap for unwary users, and I'm not sure 
it's a good idea encouraging more use of it implicitly.


We don't need to implement something new for this. AlgebraicField() does 
this for algebraic (and hence rational) numbers and RealLazyField tries to 
do this for a reasonable class of computable real numbers. 
AlgebraicRealField is not a reasonable field to use for a default "real 
field" because it misses common transcendental elements. But RealLazyField 
might be. I'm not so sure floating point literals should land in it, 
though, because to me writing a number as a decimal fraction implies it is 
meant as an imprecise quantity (and the number of digits written is an 
indication of how many significant digits it has). I'm pretty sure I'm not 
alone in that expectation, so there is going to be a subset of users who 
would be upset that their floats end up not being floats any more. I don't 
think there are interesting elements in RealLazyField that could be easily 
constructed from a decimal fraction that can't easily be constructed in a 
different way and a lot of basic elements (like 1/3) cannot be constructed 
via decimal fractions, so I don't think using decimal fraction literals for 
RealLazyField elements makes sense. You'd teach people antipatterns that 
will paint them in a corner fairly soon. 

It's certainly reasonable to not call a floating point field "RealField". C 
and python don't even do that: they call such elements floats. I'm less 
sure whether such a RealFloats field should be any less prominent than it 
is now. Plus the whole renaming transition would be super painful.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/416a3fc5-5875-4c4a-84a2-4d622be9e4d0n%40googlegroups.com.

Re: [sage-devel] RealField isn't doing it right

[David Roe]

On Mon, Apr 17, 2023 at 7:39 PM aw  wrote:

> On Monday, April 17, 2023 at 4:05:56 PM UTC-6 Nils Bruin wrote:
>
>  But you WON'T be computing with exact quantities in RealField(200) unless
> your number can be expressed as +- an unsigned 200-bit integer times a
> power of two, so you're very fundamentally using the wrong tool if you're
> interested in exact computation.
>
>
> If properly implemented, it can emulate exact computation followed by a
> truncation to finite precision.
>
> When I say a very high precision environment is for doing exact
> computation, I don't mean that it should handling infinite digit strings. I
> mean that the input-output function for such an environment should be
> identical to the input-output function of a hypothetical environment that
> *does* do the full exact computation and then truncates the answer to the
> requested precision.
>
> In other words, a very high precision environment should emulate an
> environment that does the full exact computation and truncates the result
> to finite precision before giving it to the user. And, this emulation
> should be perfect.
>
> That is the behavior that a very high precision environment is required to
> have.
>
> For input expressions that don't have float literals in them, it looks
> like RealField does have the required behavior!
>
> Example:
>
> RealField(200)(sqrt(2))
> 1.4142135623730950488016887242096980785696718753769480731767
>
> actual digits, from https://apod.nasa.gov/htmltest/gifcity/sqrt2.1mil:
> 1.41421356237309504880168872420969807856967187537694807317667...
>
> RealField here gives the exact value of sqrt(2) rounded to 59 digits,
> which is 196 bits.
>
> 196 bits is slightly under the requested 200, but let's no get sidetracked
> by that here.
>
> By the way, when I say "truncated", I mean any acceptable truncation
> method. Rounding is one such method.
>
> The main point is that based on this and other similar examples involving
> algebraic irrationals or transcendentals like e and pi, RealField looks
> like it is trying hard to be a good high precision environment.
>
> But for some input expressions, it fails to have the required behavior. It
> gives an output that is not any kind of truncation of the exact value.
>
> Here's a question: if in pre-processing we interpret all float literals as
> rationals, as Dima Pasechnik suggested could be an option in an earlier
> post, do these failures all disappear? Does RealField then fully meet the
> behavior requirements for a very high precision environment?
>
> If that one tiny change would make it a good environment, whose answers
> are always the exact answers truncated to the requested precision, then why
> the heck would you not make that change?
>
> It would give you something more useful than you have now, at no cost.
>

It's certainly not no cost.  Here are several problems with this proposal:
* If you simply interpret float literals as rationals, they will print as
rationals.  I would find this extremely surprising and annoying; it makes
Sage more difficult to use as a basic calculator (I use Sage for my taxes
for example).
* Something that Nils has alluded to a bit is performance.  The above issue
could be resolved with some work by making a new kind of real field parent
that stored elements internally as rational numbers (at least until you
applied a transcendental function) but printed as decimals.  But it would
then be susceptible to coefficient blowup, which can make some computations
with rationals (especially in linear algebra) drastically slower than
computations with floating point values.  Hiding the fact that real
literals are implemented as rationals means that even people who are aware
of such issues wouldn't be expecting.  And you still face similar problems
as soon as you apply a transcendental function, unless you go fully over to
the symbolic ring.

So I think a concrete version of Dima's suggestion would be
1. Implement a new field that stores elements internally as rationals,
printing as decimals to some precision (you could get a higher precision by
casting explicitly to RealField(prec), or by using .n(prec)).
2. Real literals would land in this field, which would have coercion maps
from Z and Q so arithmetic would be exact under the hood.
3. Coercion would go to the symbolic ring, so e^1.1 would live in the
symbolic ring (rather than RealField(53) where it lives now).  For lack of
annoyance it should probably still print as a 53-bit decimal, but you could
cast it to RealField(200) and it would give the correct result.  I guess
other transcendental functions (log, trig) would also land in the symbolics.
4. Live with the performance implications.  As Dima says, you can use RDF
if you want fast floating point arithmetic.  But it's already the case that
the symbolic ring is a performance trap for unwary users, and I'm not sure
it's a good idea encouraging more use of it implicitly.

This is a nontrivial project, though not unreasonable.  I'm 

Re: [sage-devel] RealField isn't doing it right

[Nils Bruin]

On Monday, 17 April 2023 at 16:39:01 UTC-7 aw wrote:

If properly implemented, it can emulate exact computation followed by a 
truncation to finite precision.

When I say a very high precision environment is for doing exact 
computation, I don't mean that it should handling infinite digit strings. I 
mean that the input-output function for such an environment should be 
identical to the input-output function of a hypothetical environment that 
*does* do the full exact computation and then truncates the answer to the 
requested precision.

In other words, a very high precision environment should emulate an 
environment that does the full exact computation and truncates the result 
to finite precision before giving it to the user. And, this emulation 
should be perfect.


Unfortunately, not for a fixed precision. If you're working with 200 bits 
precision, then you cannot express the roots of
x^2-3 and x^2-(3+2^-200) as different floating point numbers. They are too 
close for that. If you know that two numbers are roots of polynomials with 
integer coefficients, you can compute a lower bound (in terms of the 
coefficients) on their difference if they are distinct at all. With such a 
bound you can indeed conclude the numbers are equal if their approximations 
to the required accuracy agree. This has been implemented in 
AlgebraicField. So if you're interested in exact arithmetic with algebraic 
numbers you should use that. To some extent these techniques can be 
extended to certain transcendental number as well. This is more 
experimental, but an implementation is available in RealLazyField.

Fixed precision floating point is fundamentally unable to do this: the 
number of real numbers it can represent in the interval [1,2] is bounded 
(by the set precision), whereas that interval contains infinitely many 
rational, algebraic, and transcendental real numbers. So there are pairs of 
numbers in there it won't be able to represent with distinct 
representations.

(of course computers have only finite memory so they can only represent 
finitely many numbers as well, so things like AlgebraicField() will run out 
of memory for some computations. But the bounds floating point sets are 
much more rigid).

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/6c707636-0c83-4162-a887-8f61f5b36e81n%40googlegroups.com.

Re: [sage-devel] RealField isn't doing it right

[aw]

On Monday, April 17, 2023 at 4:05:56 PM UTC-6 Nils Bruin wrote: 

 But you WON'T be computing with exact quantities in RealField(200) unless 
your number can be expressed as +- an unsigned 200-bit integer times a 
power of two, so you're very fundamentally using the wrong tool if you're 
interested in exact computation.


If properly implemented, it can emulate exact computation followed by a 
truncation to finite precision.

When I say a very high precision environment is for doing exact 
computation, I don't mean that it should handling infinite digit strings. I 
mean that the input-output function for such an environment should be 
identical to the input-output function of a hypothetical environment that 
*does* do the full exact computation and then truncates the answer to the 
requested precision.

In other words, a very high precision environment should emulate an 
environment that does the full exact computation and truncates the result 
to finite precision before giving it to the user. And, this emulation 
should be perfect.

That is the behavior that a very high precision environment is required to 
have.

For input expressions that don't have float literals in them, it looks like 
RealField does have the required behavior!

Example:

RealField(200)(sqrt(2))
1.4142135623730950488016887242096980785696718753769480731767

actual digits, from https://apod.nasa.gov/htmltest/gifcity/sqrt2.1mil:
1.41421356237309504880168872420969807856967187537694807317667...

RealField here gives the exact value of sqrt(2) rounded to 59 digits, which 
is 196 bits.

196 bits is slightly under the requested 200, but let's no get sidetracked 
by that here.

By the way, when I say "truncated", I mean any acceptable truncation 
method. Rounding is one such method.

The main point is that based on this and other similar examples involving 
algebraic irrationals or transcendentals like e and pi, RealField looks 
like it is trying hard to be a good high precision environment. 

But for some input expressions, it fails to have the required behavior. It 
gives an output that is not any kind of truncation of the exact value.

Here's a question: if in pre-processing we interpret all float literals as 
rationals, as Dima Pasechnik suggested could be an option in an earlier 
post, do these failures all disappear? Does RealField then fully meet the 
behavior requirements for a very high precision environment?

If that one tiny change would make it a good environment, whose answers are 
always the exact answers truncated to the requested precision, then why the 
heck would you not make that change?

It would give you something more useful than you have now, at no cost. 

-aw

 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/a2e8c4ba-5a73-44a4-992b-449e6d24b479n%40googlegroups.com.

Re: [sage-devel] RealField isn't doing it right

[aw]

On Monday, April 17, 2023 at 4:05:56 PM UTC-6 Nils Bruin wrote:

sage: pi200=RealField(200).pi()
sage: cos(pi200/13).algdep(8)
64*x^6 - 32*x^5 - 80*x^4 + 32*x^3 + 24*x^2 - 6*x - 1

This shows that cos(pi200/13) is remarkably close to satisfying a sextic 
equation with remarkably small coefficients

 
Very cool fact, thanks!

-aw  

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/93da1cd5-5184-4f01-b9d3-ec5021928c70n%40googlegroups.com.

Re: [sage-devel] RealField isn't doing it right

[Nils Bruin]

On Monday, 17 April 2023 at 14:58:49 UTC-7 aw wrote:

fixing a typo: it should be "exact irrationals like sqrt(2)"


Ah, NOW I see what the problem likely is: I think you're misled by the 
field being called "RealField". So ... yeah ... it's not. It should 
probably be called RealFloats or something like that. This has come up 
before, but would be a painful change to make : 
https://groups.google.com/g/sage-devel/c/ba9u_As3T4s/m/oXNgGozmAQAJ

With modern developments like RealLazyField, eventually sage *may* actually 
have something that actually models computations in the real numbers. If 
you're interested in algebraic numbers you can already have them with 
AlgebraicField() and AlgebraicRealField() -- those actually work pretty 
well. Do be aware that testing equality in such fields may be unexpectedly 
expensive (but since in floats testing for equality is generally 
nonsensical, that's probably still a win).

These things are still rather experimental, though, so probably not quite 
ready to be defaults in SageMath.

Note that "real literals" like "1.1" are not suitable vehicles to enter any 
interesting exact real number anyway: you can';t specify sqrt(2) exactly in 
that way. So you end up writing things like AA(2).sqrt(). Or AA(sqrt(2)) 
(the latter making intermediate use of SR). So I'm not so sure that decimal 
literals would coerce to exact decimal fractions even in a system where a 
"true" real field is available: quick and dirty floating point is 
historically just something that a lot of people expect to be available and 
people might start complaining if arithmetic with 1.1 starts blowing up in 
memory use.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/f6ff35d5-f87a-4991-894b-78c3b4f76d17n%40googlegroups.com.

Re: [sage-devel] RealField isn't doing it right

[Nils Bruin]

On Monday, 17 April 2023 at 14:12:43 UTC-7 aw wrote:

(A), exact vs inexact:

The purpose of a very high precision environment like RealField(200) is to 
compute with exact quantities - some combination of ints, rationals, exact 
rationals like sqrt(2), or exact transcendentals like pi.

 But you WON'T be computing with exact quantities in RealField(200) unless 
your number can be expressed as +- an unsigned 200-bit integer times a 
power of two, so you're very fundamentally using the wrong tool if you're 
interested in exact computation.

If you're interested in exact arithmetic then do so! Go for symbolic in SR 
or go for RealLazyField. The ideas behind RealLazyField come a lot closer 
to what you seem to want: it uses (fast) floating point approximations when 
that allows it to decide what is asked and keeps symbolic relations at hand 
to use when those are required. Of course, bear in mind that not all 
questions are decidable symbolically; much less so by a specific 
implementation.

The main place where I know high-precision computation really finds an 
application is in transcendental computations where, for some reason, you 
know the number comes out algebraic. With very high precision computation 
you can then recognize the algebraic number. See for instance 
https://github.com/nbruin/RiemannTheta.

A baby example:

sage: pi200=RealField(200).pi()
sage: cos(pi200/13).algdep(8)
64*x^6 - 32*x^5 - 80*x^4 + 32*x^3 + 24*x^2 - 6*x - 1

This shows that cos(pi200/13) is remarkably close to satisfying a sextic 
equation with remarkably small coefficients (and the routine found a sextic 
equation even though it was asked to find one of degree at most 8). Doing 
this example with 53 bits of precision does not yield enough bits to 
recover the sextic relation given here.

---
Concerning your literal example: Just write 2*RealField(200)(1.1) and 
you're good to go. You're still not representing 11/5 exactly because 
RealField(200) does not admit an exact representative,  but at least you'll 
have all the bits you can.

By writing RealField(200)(2*1.1) you're forcing python's hand to choose a 
precision, because 2*1.1 is NOT going to be a literal anymore. If you're 
not interested in getting floating point approximations then don't involve 
RealField(200). 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/f367a91f-539a-4ab3-8990-0861a470bd5dn%40googlegroups.com.

Re: [sage-devel] RealField isn't doing it right

[aw]

fixing a typo: it should be "exact irrationals like sqrt(2)"

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/cc814713-79a8-4ead-bfd7-e4602a7c89b3n%40googlegroups.com.

Re: [sage-devel] RealField isn't doing it right

[aw]

To the folks defending RealField's behavior: the reasons you cite for why 
it's acceptable would also apply to low-precision environments like single 
or double precision.

But very high precision environments have a different purpose than those 
low-precision environments. So you shouldn't be thinking about them in the 
same way as low-precision environments.

In this post I'm going to highlight two critical things that are specific 
to very high precision environments, which I think are getting overlooked. 
I'll label them A and B.

(A), exact vs inexact:

The purpose of a very high precision environment like RealField(200) is to 
compute with exact quantities - some combination of ints, rationals, exact 
rationals like sqrt(2), or exact transcendentals like pi.

It would be nuts to pass RealField(200) an inexact quantity x that is 
knowable only to a much smaller number of bits, for example 23 bits, 
because you can never get more than 23 good bits from any expression 
involving x. There's no point in asking for anything more than 23, so it 
would be crazy and wrong to ask for 200.

In other words, when used correctly, very high precision environments like 
RealField(200) are for computing exact quantities, not approximate floating 
point quantities.

They are for exact computation, not inexact computation.

The answer they give is the exact answer truncated to a finite precision 
that we specify.

This is completely different from an inexact computation limited to a 
finite precision by the inexactness of its inputs.

I think you guys may have failed to appreciate this fundamental 
distinction, and that's what led you to mishandle float literals in 
RealField's input.

You guys were thinking, RealField is for inexact floating point, so we 
should treat the float literal as an inexact floating point quantity. What 
you should have been thinking is, RealField is for exact values that we 
will truncate at the end, so we should treat the float literal as an exact 
rational.

By the way, if you want some corroboration for my claim that very high 
precision environments are for exact computation, just look at how they are 
implemented.

The implementation of a very high precision environment will use integers 
*only*, so that the calculation can be exact. This says the environment is 
intended for doing exact computation with exact quantities.

Contrast that with the implementation of a lower precision environment like 
single or double precision: this will use machine floats, because the 
calculation doesn't need to be exact. These environments are intended for 
doing inexact compution with inexact quantities.


(B), required behavior:

I'm gonna get math-y for this one.

Let X be a high precision environment.
We can see X as a function which takes an input expression S along with a 
parameter P specifying the desired precision for the output. It produces an 
output value V, with that precision.

I claim that for X to be working correctly, the input-output pairs (S,V) 
must satisfy the following condition:
 
V = exact value of S truncated to precision P 

An easy corollary of this is the following:

V is independent of the internal representation used by X

Another way to put that is, the internal representation used by X should 
never be visible in X's output.

This is required behavior. Implementations are not allowed to deviate from 
this. Any deviation is a mistake.


Ok, that was two critical things, (A) and (B), about very high precision 
environments.

Now let's re-visit the 2*1.1 example:

RealField(200)(2*1.1)
2.20017763568394002504646778106689453125

There are two separate problems with this, corresponding to (A) and (B):

(1) the literal 1.1 is not treated as the exact rational 11/10
(2) the values of the junk digits in the middle of the output depend on the 
internal representation

This says there are at least two separate problems in RealField, as a very 
high precision environment:

(1') RealField can mishandle float literals passed to it 
(2') RealField can wrongly allow its implementation details to get into its 
output 

RealField's behavior doesn't meet the requirements for a very high 
precision environment. 

I'm scratching my head trying to understand why you guys are defending 
RealField's behavior, instead of wanting to fix it.

Here's a question that might help: what kind of user would look at the 
output  of RealField(200)(2*1.1) and say, "Yeah, that's awesome, that's 
exactly what I was looking for! Thanks, Sage!"

Describe the kind of user who would say that.

And then ask yourself, what percentage of Sage users are like that?

How about this: what percentage of beginner or student Sage users are like 
that?

-aw

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion 

Re: [sage-devel] modular form basis

[William Stein]

On Mon, Apr 17, 2023 at 9:13 AM Ralf Hemmecke  wrote:
>
> Hello,
>
> is there any particular reason why the term 12/5*q is not subtracted
> away by the first basis element?

The answer is that M_2(Gamma0(11)) is represented internally as the
direct sum of the cuspidal and eisenstein subspaces. In particular,
notice that

M.eisenstein_submodule().basis()

is

[ 1 + 12/5*q + 36/5*q^2 + 48/5*q^3 + 84/5*q^4 + 72/5*q^5 + 144/5*q^6 +
96/5*q^7 + 36*q^8 + 156/5*q^9 + 216/5*q^10 + 12/5*q^11 + 336/5*q^12 +
168/5*q^13 + 288/5*q^14 + 288/5*q^15 + 372/5*q^16 + 216/5*q^17 +
468/5*q^18 + 48*q^19 + O(q^20) ]

If by default "ModularForms(Gamma0(11), 2, prec=20).basis()" were
required to be in reduced row echelon form,
then a lot of things would be much more difficult...

In addition to  M.echelon_basis() which John pointed out, there's also
M.integral_basis(), which is a HNF basis:

M.integral_basis()

[ 1 + 12*q^2 + 12*q^3 + 12*q^4 + 12*q^5 + 24*q^6 + 24*q^7 + 36*q^8 +
36*q^9 + 48*q^10 + 72*q^12 + 24*q^13 + 48*q^14 + 60*q^15 + 84*q^16 +
48*q^17 + 84*q^18 + 48*q^19 + O(q^20), q - 2*q^2 - q^3 + 2*q^4 + q^5 +
2*q^6 - 2*q^7 - 2*q^9 - 2*q^10 + q^11 - 2*q^12 + 4*q^13 + 4*q^14 -
q^15 - 4*q^16 - 2*q^17 + 4*q^18 + O(q^20) ]



>
> Ralf
>
> ┌┐
> │ SageMath version 9.6, Release Date: 2022-05-15 │
> │ Using Python 3.10.6. Type "help()" for help.   │
> └┘
> sage: ModularForms(Gamma0(11), 2, prec=20).basis()
> [
> q - 2*q^2 - q^3 + 2*q^4 + q^5 + 2*q^6 - 2*q^7 - 2*q^9 - 2*q^10 + q^11 -
> 2*q^12 + 4*q^13 + 4*q^14 - q^15 - 4*q^16 - 2*q^17 + 4*q^18 + O(q^20),
> 1 + 12/5*q + 36/5*q^2 + 48/5*q^3 + 84/5*q^4 + 72/5*q^5 + 144/5*q^6 +
> 96/5*q^7 + 36*q^8 + 156/5*q^9 + 216/5*q^10 + 12/5*q^11 + 336/5*q^12 +
> 168/5*q^13 + 288/5*q^14 + 288/5*q^15 + 372/5*q^16 + 216/5*q^17 +
> 468/5*q^18 + 48*q^19 + O(q^20)
> ]
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/64337a19-6c75-a78d-2579-1c06c771754b%40hemmecke.org.



-- 
William (http://wstein.org)

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CACLE5GCZ40E%3D85YT%3Dnpqko%3DF_AGW4G1b_nNWw9q6gM2cqMaetQ%40mail.gmail.com.

Re: [sage-devel] modular form basis

[John Cremona]

There is also M.echelon_basis() which does that.  I don't know why we need
two, does anyone?

John

On Mon, 17 Apr 2023 at 17:13, Ralf Hemmecke  wrote:

> Hello,
>
> is there any particular reason why the term 12/5*q is not subtracted
> away by the first basis element?
>
> Ralf
>
> ┌┐
> │ SageMath version 9.6, Release Date: 2022-05-15 │
> │ Using Python 3.10.6. Type "help()" for help.   │
> └┘
> sage: ModularForms(Gamma0(11), 2, prec=20).basis()
> [
> q - 2*q^2 - q^3 + 2*q^4 + q^5 + 2*q^6 - 2*q^7 - 2*q^9 - 2*q^10 + q^11 -
> 2*q^12 + 4*q^13 + 4*q^14 - q^15 - 4*q^16 - 2*q^17 + 4*q^18 + O(q^20),
> 1 + 12/5*q + 36/5*q^2 + 48/5*q^3 + 84/5*q^4 + 72/5*q^5 + 144/5*q^6 +
> 96/5*q^7 + 36*q^8 + 156/5*q^9 + 216/5*q^10 + 12/5*q^11 + 336/5*q^12 +
> 168/5*q^13 + 288/5*q^14 + 288/5*q^15 + 372/5*q^16 + 216/5*q^17 +
> 468/5*q^18 + 48*q^19 + O(q^20)
> ]
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/64337a19-6c75-a78d-2579-1c06c771754b%40hemmecke.org
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAD0p0K4OCfpw-5miY-2Kw_ntvv7J4CqxSEs%3D%3DbCDtZjnhtO66Q%40mail.gmail.com.

Re: [sage-devel] RealField isn't doing it right

[Dima Pasechnik]

I am beginning to think that more ball/interval arithmetic should be
involved here, in particular as dealing with RealField  is not much faster
than RealBallField with the same precision, yet allows a degree of control
over the error propagation.
(and perhaps the default 53 bits out to be bumped up to something more
appropriate for the hardware in  2023).

If one wants fast floats, then RDFs may be used.

Dima


On Mon, 17 Apr 2023, 17:05 Nils Bruin,  wrote:

> On Monday, 17 April 2023 at 05:04:00 UTC-7 Emmanuel Briand wrote:
>
> Real literals are created in preparsing and provide a way to allow casting
> into higher precision rings.
>
> Shouldn't RR(11/10) have the same fate?
>
> No, because RR(11/10) is not a literal. In principle 11/10 could be a
> "rational literal" but we don't have that in sage: rational numbers have no
> benefit. By the time you apply a conversion to it (and in this case the
> conversion needs to do something!) it's definitely not a literal any more.
>
> If you want a "real number" 11/10 that has these kinds of exact
> properties, RealLazyField()(11/10) is probably the way to go, but that
> field will have quite a different performance profile than RR does.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/d9bbb936-36ad-4466-9852-712236ec46dfn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq2zvkjHvqB2ioEphf-tmfJDoazdFHsQ_Qi-psgwxngbQw%40mail.gmail.com.

[sage-devel] modular form basis

[Ralf Hemmecke]

Hello,

is there any particular reason why the term 12/5*q is not subtracted 
away by the first basis element?


Ralf

┌┐
│ SageMath version 9.6, Release Date: 2022-05-15 │
│ Using Python 3.10.6. Type "help()" for help.   │
└┘
sage: ModularForms(Gamma0(11), 2, prec=20).basis()
[
q - 2*q^2 - q^3 + 2*q^4 + q^5 + 2*q^6 - 2*q^7 - 2*q^9 - 2*q^10 + q^11 - 
2*q^12 + 4*q^13 + 4*q^14 - q^15 - 4*q^16 - 2*q^17 + 4*q^18 + O(q^20),
1 + 12/5*q + 36/5*q^2 + 48/5*q^3 + 84/5*q^4 + 72/5*q^5 + 144/5*q^6 + 
96/5*q^7 + 36*q^8 + 156/5*q^9 + 216/5*q^10 + 12/5*q^11 + 336/5*q^12 + 
168/5*q^13 + 288/5*q^14 + 288/5*q^15 + 372/5*q^16 + 216/5*q^17 + 
468/5*q^18 + 48*q^19 + O(q^20)

]

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/64337a19-6c75-a78d-2579-1c06c771754b%40hemmecke.org.

Re: [sage-devel] RealField isn't doing it right

[Nils Bruin]

On Monday, 17 April 2023 at 05:04:00 UTC-7 Emmanuel Briand wrote:

Real literals are created in preparsing and provide a way to allow casting 
into higher precision rings.

Shouldn't RR(11/10) have the same fate?

No, because RR(11/10) is not a literal. In principle 11/10 could be a 
"rational literal" but we don't have that in sage: rational numbers have no 
benefit. By the time you apply a conversion to it (and in this case the 
conversion needs to do something!) it's definitely not a literal any more.

If you want a "real number" 11/10 that has these kinds of exact properties, 
RealLazyField()(11/10) is probably the way to go, but that field will have 
quite a different performance profile than RR does.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/d9bbb936-36ad-4466-9852-712236ec46dfn%40googlegroups.com.

Re: [sage-devel] RealField isn't doing it right

[kcrisman]

This has been an interesting discussion, because it brings up again the 
inherent tradeoffs present in writing general-purpose software.  We (not 
just Sage, but other similar systems) want something that is usable by 
those who need floating-point to do what it must do, as well as be 
intelligible to those who write 1/3 = 0.333 and assume it is correct.

Although the discussion is not about teaching, it seems that the worst-case 
scenario of users are in that context.  I think the compromise reached in 
Sage is acceptable for all teaching purposes I have ever had to encounter, 
for two reasons.

1) For many things, instructors need to provide an extra layer of sugar 
anyway.  I have a nice activity I stole from someone else for showing the 
effect of various matrices on simple graphics, and for students just seeing 
matrices for the first time, I am not going to expect them to program the 
whole thing yet.  In such cases, an instructor should understand at least 
the basics that can "go wrong" and shield users if necessary.  The rank 
example falls into this category - as soon as we are doing actual matrix 
computations "for realsies", students MUST be led to understand that there 
is numerical error inherent.  

Michael said, "But if you're learning linear algebra for the first time and 
typing a matrix into the Sage notebook, typing 0.5 instead of 1/2 should 
not ruin the entire assignment without so much as a warning." 
 Unfortunately, having taught this materials to complete beginners many 
time, I have to say that anything that goes beyond integer values to learn 
the terminology should be mentioning this issue in class, even in an 
Excel-based math for business course (for example).  What level we go to in 
explaining why they should be careful will depend on their background, but 
explaining that Excel (or Sage, or whatever) has this limit is very 
important, even if we then say, "our examples will be selected to avoid 
this in our beginners' course, but be sure to work with your quantitative 
people/statisticians if you get weird answers."  Maybe that means Nils' 
allusion is right and rank needs to be disabled (or yield error) on 
non-exact matrices?  I'd be loathe to do that, I'd rather have to deal with 
the issue in class (and have done so, answering exactly these kinds of 
questions.).  I have to talk about NOT using Excel to get determinants for 
this reason :-)


2) For other things, anyone using them should know the conventions.  The 
RealField(120)(RR(13/10)) is an example of this - no one who doesn't know 
what RealField is doing should be put in a position to even worry about 
this.  This particular example was discussed very fully above, but my point 
on it is that if someone encounters this before a numerical analysis course 
(in which case it is expected behavior), then someone is asking students to 
do a computation in a way that isn't appropriate for that course.  (That 
doesn't mean students shouldn't see this kind of thing earlier - there are 
some very nice examples with things like limits [1] which are very 
appropriate to talk about in calculus, but we don't talk about 
floating-point precision in detail, just that we have to be careful 
"trusting" the computer instead of using analytical tools.)

[1] 
https://sagecell.sagemath.org/?z=eJwrSyzSUM_MKygtUdfk5SpKLS7NKVGwVdBIzi_WAAtr6hpq6oNZcUa8XAU5-SUaEFU6EHkdXT0DMDDUgTE0NQGwjxmm=sage=eJyLjgUAARUAuQ==

I used to feel more like the OP about " A user should be able to send any 
argument to a function, and it's the responsibility of the programmer to 
make sure one of two things happen ..." but when I found out why PARI does 
not return an error message when you ask for the primitive root of a number 
that doesn't have a primitive root (namely, efficiency in avoiding the 
process of checking for bad input), I modified that to take into account 
who the intended end users are.  Anyone using RealField(120) should be 
aware of these issues.  It's possible that the conventions are wrong, but 
they are spelled out.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/86a1734c-21cb-4ad2-9401-feaf09454f23n%40googlegroups.com.

Re: [sage-devel] RealField isn't doing it right

[Nils Bruin]

On Monday, 17 April 2023 at 04:13:51 UTC-7 John Cremona wrote:

Even in the light of the detailed explanations already given, I do find it 
hard to see how these outputs are so different:

sage: RealField(200)(RR(11/10))
1.100088817841970012523233890533447265625000
sage: RealField(200)(RR(1.1))
1.10

You can increase 200 to 1000: the second one gives all zeros (hooray!) 
while the first one gives those extra digits which are exactly 1/(5 * 
2^51).  Both RR(11/10) and RR(1.1) have parent  Real Field with 53 bits of 
precision, where they compare equal, but pushing them into RealField(200) 
gives different results.  And the "better" result (all 0s) somes from the 
input with the literal 1.1, not from the "rational" input 11/10.   To me, 
that is mysterious.  Can someone explain?


That one is surprising to me as well. The mechanism is easy to uncover:

sage: type(RR(1.1))

 
I suspect it's because the literal 1.1 advertises its "default" precision 
as 53 (as you remark) and therefore the coercion system probably concludes 
that for the conversion R(1.1) no further action is required. Hence, the 
same literal is returned with the funny side-effect that you mention.

We can ruin this effect quite easily by specifying the literal in such a 
way that it reports a different parent:

sage: RealField(200)(RR(1.100))
1.100088817841970012523233890533447265625000

and now it occurs with a different "magic intermediate precision"":

sage: RealField(200)(RealField(54)(1.100))
1.10

This is a rather complicated edge case that follows from the way literals 
are implemented. I'm not sure it's worth fixing; especially because the 
edge case is probably caused by the coercion framework: the implementation 
of RealLiteral probably doesn't even get a chance to do something.

One possible fix would be to change the reported parent of a RealLiteral. 
That might have performance consequences.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/d5455027-a77e-41dd-b8f5-7503c5eb1f88n%40googlegroups.com.

Re: [sage-devel] RealField isn't doing it right

[Emmanuel Briand]

Interesting. The two inputs have different types

type(RR(11/10))



type(RR(1.1))



Then from the documention at
https://doc.sagemath.org/html/en/reference/rings_numerical/sage/rings/real_mpfr.html


*class *sage.rings.real_mpfr.RealLiteral

Bases: RealNumber


Real literals are created in preparsing and provide a way to allow casting
into higher precision rings.


Shouldn't RR(11/10) have the same fate?


Emmanuel



El lun, 17 abr 2023 a las 13:13, John Cremona ()
escribió:

> Even in the light of the detailed explanations already given, I do find it
> hard to see how these outputs are so different:
>
> sage: RealField(200)(RR(11/10))
> 1.100088817841970012523233890533447265625000
> sage: RealField(200)(RR(1.1))
> 1.10
>
> You can increase 200 to 1000: the second one gives all zeros (hooray!)
> while the first one gives those extra digits which are exactly 1/(5 *
> 2^51).  Both RR(11/10) and RR(1.1) have parent  Real Field with 53 bits of
> precision, where they compare equal, but pushing them into RealField(200)
> gives different results.  And the "better" result (all 0s) somes from the
> input with the literal 1.1, not from the "rational" input 11/10.   To me,
> that is mysterious.  Can someone explain?
>
> John
>
> PS It is a red herring to give examples using the equality relation ==, as
> that is a separate issue.  In Python == is not even associative.
>
> On Sat, 15 Apr 2023 at 22:39, aw  wrote:
>
>> Guys, this is serious. Any dev who starts reading this, give it a hard
>> look, ok?
>>
>> Below I give some examples where Sage give the wrong answer, with no
>> error message or any indication that the answer is not correct.
>>
>> Probably the single most important rule in software is, never ever give
>> users the wrong answer.
>>
>> Either give them the right answer, or give them no answer along with an
>> error message explaining why the right answer can't be given.
>>
>> Why the heck is Sage not following this rule?
>>
>> After finding these examples, it's hard for me to trust any answer I get
>> from Sage, unless I check it against other software, like Wolfram Alpha.
>>
>> One possible response to my examples below is, I am not using Sage
>> functions in an approved way.
>>
>> But that's not a valid objection. A user should be able to send any
>> argument to a function, and it's the responsibility of the programmer to
>> make sure one of two things happen:
>>
>> (a) the user is given the right answer;
>> or (b) the user is given no answer and an error message.
>>
>> Sage is failing to do this.
>>
>> On to the examples.
>>
>> Example 1, straight from the sage RealField docs:
>>
>> RealField(120)(RR(13/10))
>> 1.3000444089209850062616
>>
>> RR has default 53 bits, so this is really:
>>
>> RealField(120)(RealField(53)(13/10))
>>
>> Here's the same thing with less precision to make it clear that this has
>> nothing to do with Python's single or double precision floats:
>>
>> RealField(18)(RealField(12)(13/10)) (A)
>>
>> What should happen here is this:
>> RealField(12) should eval 13/10 as 1.30
>> RealField(12) should pass to RealField(18) only those digits, 1.30
>> RealField(18) should then zero-pad that to 18 bits, yielding 1.3000
>>
>> Here's what sage does:
>>
>> RealField(18)(RealField(12)(13/10))
>> 1.2998
>>
>> Let's check the types of all args:
>>
>> type(13/10)
>> sage.rings.rational.Rational
>>
>> type(18)# type(12) is the same
>> sage.rings.integer.Integer
>>
>> All args to RealField in (A) are Sage types.
>> Hence everything in the calculation (A) is under the complete control of
>> Sage.
>> Hence Sage could easily do the right thing here.
>>
>> But it doesn't.
>>
>> You might say, this is an artificial example, passing the output of one
>> RealField to another in a non-sanctioned way.
>> Ok then, let's just pass arguments to one RealField.
>> Can we get it to give wrong answers?
>>
>> Yes, very easily, by passing it an arithmetic expression.
>>
>> Sending in arithmetic expressions should be totally fine, because the
>> RealField docs say: "This is a binding for the MPFR arbitrary-precision
>> floating point library."
>>
>> The purpose of MPFR is to be able to do basic arithmetic in arbitrary
>> precision.
>> Basic arithmetic means any expression using the following ops (and maybe
>> some others): +, -, *, /, ^
>>
>> So let's pass an arithmetic expression to RealField.
>> The whole point of MPFR is to always give the right answer for the value
>> of such an expression, for any expression and any requested precision.
>> The docs say RealField is a binding for MPFR.
>> So RealField should only give right answers.
>> But in fact it sometimes gives the wrong answer.
>>
>> Here's one:
>>
>> RealField(200)(2*1.1)
>> 

Re: [sage-devel] RealField isn't doing it right

[Dima Pasechnik]

On Mon, Apr 17, 2023 at 12:20 PM Michael Orlitzky  wrote:
>
> On Sun, 2023-04-16 at 19:46 -0700, aw wrote:
> >
> > Unbelievable.
> > This is failing a basic consistency check: if x==y, then we should have
> > f(x)==f(y) for any function f.
> >
> > The problem here is that float literals are being mishandled. The string
> > "0.5" should be interpreted as 1/2, unless the user overrides that.
> >
> > Can you post the other "permabugs" you know of that involve float literals?
> >
>
> They're all variations on a theme. Floating point sucks, and Sage
> inherits that:
>
>   sage: (0.1 + 0.2) + 0.3 == 0.1 + (0.2 + 0.3)
>   False
>
> Whenever you perform an operation with two different types of "number,"
> Sage essentially picks the worst of the two and performs the operation
> there. Every example is basically,
>
>   1. Something returns a float where you don't expect it
>   2. You use that result with some other object
>   3. Now the other object is made of float
>   4. Nothing works in floating point
>
> The conversion to float is consistent with all of the other intelligent
> coercions that Sage can do (embedding ZZ into QQ, for example), so it
> goes off silently. But floating point is a uniquely bad base ring for
> most of Sage.

for some tasks, at least, built-in RBF and CBF does wonders, e.g. for
the example
earlier in the thread:


sage: A = matrix([[-3, 2, 1 ],
: [ 2,-4, 4 ],
: [ 1, 2,-5 ]])
sage: B = (2 * 0.5 * A)
sage: B.rank() # bad
3
sage: matrix(RBF,B).rank() # right!
2
sage: type(matrix(RBF,B)) # this is not even using what's available in
arb for matrices


>
> --
> You received this message because you are subscribed to the Google Groups 
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/44b14f57528ac06463e2294fa52cf3a661cc2cc0.camel%40orlitzky.com.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq38u9%3DdEX0xcY0rHyOgHTfXr%2BFVu0GfF6SKbbK7VpZ79g%40mail.gmail.com.

Re: [sage-devel] RealField isn't doing it right

[Michael Orlitzky]

On Sun, 2023-04-16 at 19:46 -0700, aw wrote:
>  
> Unbelievable. 
> This is failing a basic consistency check: if x==y, then we should have 
> f(x)==f(y) for any function f.
> 
> The problem here is that float literals are being mishandled. The string 
> "0.5" should be interpreted as 1/2, unless the user overrides that.
> 
> Can you post the other "permabugs" you know of that involve float literals?
> 

They're all variations on a theme. Floating point sucks, and Sage
inherits that:

  sage: (0.1 + 0.2) + 0.3 == 0.1 + (0.2 + 0.3)
  False

Whenever you perform an operation with two different types of "number,"
Sage essentially picks the worst of the two and performs the operation
there. Every example is basically,

  1. Something returns a float where you don't expect it
  2. You use that result with some other object
  3. Now the other object is made of float
  4. Nothing works in floating point

The conversion to float is consistent with all of the other intelligent
coercions that Sage can do (embedding ZZ into QQ, for example), so it
goes off silently. But floating point is a uniquely bad base ring for
most of Sage.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/44b14f57528ac06463e2294fa52cf3a661cc2cc0.camel%40orlitzky.com.

Re: [sage-devel] RealField isn't doing it right

[John Cremona]

Even in the light of the detailed explanations already given, I do find it
hard to see how these outputs are so different:

sage: RealField(200)(RR(11/10))
1.100088817841970012523233890533447265625000
sage: RealField(200)(RR(1.1))
1.10

You can increase 200 to 1000: the second one gives all zeros (hooray!)
while the first one gives those extra digits which are exactly 1/(5 *
2^51).  Both RR(11/10) and RR(1.1) have parent  Real Field with 53 bits of
precision, where they compare equal, but pushing them into RealField(200)
gives different results.  And the "better" result (all 0s) somes from the
input with the literal 1.1, not from the "rational" input 11/10.   To me,
that is mysterious.  Can someone explain?

John

PS It is a red herring to give examples using the equality relation ==, as
that is a separate issue.  In Python == is not even associative.

On Sat, 15 Apr 2023 at 22:39, aw  wrote:

> Guys, this is serious. Any dev who starts reading this, give it a hard
> look, ok?
>
> Below I give some examples where Sage give the wrong answer, with no error
> message or any indication that the answer is not correct.
>
> Probably the single most important rule in software is, never ever give
> users the wrong answer.
>
> Either give them the right answer, or give them no answer along with an
> error message explaining why the right answer can't be given.
>
> Why the heck is Sage not following this rule?
>
> After finding these examples, it's hard for me to trust any answer I get
> from Sage, unless I check it against other software, like Wolfram Alpha.
>
> One possible response to my examples below is, I am not using Sage
> functions in an approved way.
>
> But that's not a valid objection. A user should be able to send any
> argument to a function, and it's the responsibility of the programmer to
> make sure one of two things happen:
>
> (a) the user is given the right answer;
> or (b) the user is given no answer and an error message.
>
> Sage is failing to do this.
>
> On to the examples.
>
> Example 1, straight from the sage RealField docs:
>
> RealField(120)(RR(13/10))
> 1.3000444089209850062616
>
> RR has default 53 bits, so this is really:
>
> RealField(120)(RealField(53)(13/10))
>
> Here's the same thing with less precision to make it clear that this has
> nothing to do with Python's single or double precision floats:
>
> RealField(18)(RealField(12)(13/10)) (A)
>
> What should happen here is this:
> RealField(12) should eval 13/10 as 1.30
> RealField(12) should pass to RealField(18) only those digits, 1.30
> RealField(18) should then zero-pad that to 18 bits, yielding 1.3000
>
> Here's what sage does:
>
> RealField(18)(RealField(12)(13/10))
> 1.2998
>
> Let's check the types of all args:
>
> type(13/10)
> sage.rings.rational.Rational
>
> type(18)# type(12) is the same
> sage.rings.integer.Integer
>
> All args to RealField in (A) are Sage types.
> Hence everything in the calculation (A) is under the complete control of
> Sage.
> Hence Sage could easily do the right thing here.
>
> But it doesn't.
>
> You might say, this is an artificial example, passing the output of one
> RealField to another in a non-sanctioned way.
> Ok then, let's just pass arguments to one RealField.
> Can we get it to give wrong answers?
>
> Yes, very easily, by passing it an arithmetic expression.
>
> Sending in arithmetic expressions should be totally fine, because the
> RealField docs say: "This is a binding for the MPFR arbitrary-precision
> floating point library."
>
> The purpose of MPFR is to be able to do basic arithmetic in arbitrary
> precision.
> Basic arithmetic means any expression using the following ops (and maybe
> some others): +, -, *, /, ^
>
> So let's pass an arithmetic expression to RealField.
> The whole point of MPFR is to always give the right answer for the value
> of such an expression, for any expression and any requested precision.
> The docs say RealField is a binding for MPFR.
> So RealField should only give right answers.
> But in fact it sometimes gives the wrong answer.
>
> Here's one:
>
> RealField(200)(2*1.1)
> 2.20017763568394002504646778106689453125
>
> Let's check the types:
>
> type(2)
> 
>
> type(1.1)
> 
>
> type(2*1.1)
> 
>
> Here the expression 2*1.1 is not only a Sage type, it's a Sage type
> designed to work with MPFR. Hence passing 2*1.1 to RealField should yield
> the right answer.
>
> But it doesn't.
>
> How the heck was this not noticed earlier?
>
> I think I have a workaround for expressions such as 2*1.1: enter the 1.1
> as a sage rational, 11/10:
>
> RealField(200)(2*11/10)
> 2.20
>
> That works for this expression, but I worry that with other kinds of
> expression I could still get wrong answers.
>
> By the way, in this example i used numbers where we know the answer in
> advance, so it's easy to 

Re: [sage-devel] RealField isn't doing it right

[Michael Orlitzky]

On Sun, 2023-04-16 at 12:47 +0100, Dima Pasechnik wrote:
> 
> perhaps the preparser should have an option to convert the floating
> point input into rationals.

We should try ZZ first, but yeah, something like that. If Sage thinks
QQ(x) == float(x), then the former should be preferred. Or maybe it
only needs to kick in when an exact value would be coerced to an
inexact one (with the goal of avoiding that). I don't think it would be
easy; there would be lots of fine-tuning and unintended consequences,
but none of that makes the complaint invalid.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ab099fea5d0bae4b4b70d4d58dd29ec240ca1813.camel%40orlitzky.com.

Re: [sage-devel] RealField isn't doing it right

[Michael Orlitzky]

On Sun, 2023-04-16 at 10:50 -0700, Nils Bruin wrote:
>  
> That's a facetious example that sticks to values that can be exactly 
> represented in binary floats. These identities don't hold generally:
> 
> sage: 49*(1.0/49) == ZZ(1)
> False
> 
> (it depends on your working precision if rounding makes this come out as an 
> exact match or not, but at 53 bits this one fails to give equality. In all 
> cases, there are values where this breaks; necessarily)

I didn't make that example up to make a point, it's a real problem I
reported ~15 years ago in undergrad. And the fact that it's an easy
case only makes it *more* surprising that sage doesn't handle it.

We don't need a perfect solution to get it right most of the time. How
often does someone type 1/49 = 0.02040816326530612... into a matrix?
But Sage actually knows that number too:

  $ sage -python
  Python 3.11.2 (main, Mar 16 2023, 15:12:59) [GCC 12.2.1 20230121] on 
  linux
  Type "help", "copyright", "credits" or "license" for more 
  information.
  >>> from sage.all import *
  >>> QQ(0.02040816326530612)
  1/49


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/b2e128ee0d91cc0f8f05fd160e07d23da1f0714f.camel%40orlitzky.com.