This is now https://github.com/sagemath/sage/issues/39640
On Wednesday, 5 March 2025 at 23:45:59 UTC-8 Seth Chaiken wrote:
> Revised tests are consistent with Nils' reply. I replaced pi by 10/3. I
> compared the quotient by one variable of the
> two variable ring with a quotient by the one variable in the one variable
> ring and got the results below, the first
> is consistent with the naive approx. Integers()(a*1000)/1000:
>
> 3.33300000000000
> versus
> 3.33333333333333
>
> eps = var("eps")
> edBaseRing=PolynomialRing(RR,[eps])
> edIdeal=ideal(edBaseRing, [eps])
> edRing=edBaseRing.quotient_ring(edIdeal)
>
> rat = 10/3
> print(RR(rat))
> print(edBaseRing(rat))
> print(edRing(rat))
>
> 3.33333333333333
> 3.33333333333333
> 3.33333333333333
>
> eps, dlt = var("eps,dlt")
> edBaseRing=PolynomialRing(RR,[eps, dlt])
>
> #edIdeal=ideal(edBaseRing, [eps, dlt])
> edIdeal=ideal(edBaseRing, [eps])
> edRing=edBaseRing.quotient_ring(edIdeal)
>
> print(RR(rat))
> print(edBaseRing(rat))
> print(edRing(rat))
>
> 3.33333333333333
> 3.33333333333333
> 3.33300000000000
>
> ________________________________________
> From: sage-s...@googlegroups.com <sage-s...@googlegroups.com> on behalf
> of Nils Bruin <nbr...@sfu.ca>
> Sent: Wednesday, March 5, 2025 11:49 PM
> To: sage-support
> Subject: [sage-support] Re: Bug Polynomial Quotient with 2 ideal generator
> rings over RR lose precision of base ring.
>
> I definitely wouldn't expect nontrivial polynomial arithmetic to work
> reliably over RR without special measures. There are definitely methods for
> algebraic geometry with floats, but it needs very special attention to
> numerical stability. That is already true for linear algebra over RR and
> for polynomial algebra it is even worse.
>
> I am pretty sure sage does NOT have facilities for this at the moment.
> Even for linear algebra, I wouldn't trust that sage would select a
> numerically stable approach over RR. There is a good chance it will hit
> just generic implementations that are written for exact linear algebra.
>
> However, the computations you are doing would trigger no polynomial
> arithmetic at all, so the "loss of precision" is very suspect. It's also
> very suspect that it ends up with a number that has a very precise number
> of decimal digits. Indeed, replacing "pi" with something else, such as
> RR(1/3) or sqrt(2) gives the exact same rounding.
>
> I suspect you're hitting code that somehow tries to call the Singular
> library and, since that doesn't support floats, it looks like it takes a
> very naive approximation
> Integers()(a*1000)/1000. That DOES look like a bug. An error would be more
> informative here.
>
> It makes sense this would only happen in a multivariate polynomial ring
> (regardless of what ideal you're actually using): univariate polynomial
> rings would just use euclidean division and not rely on the singular
> library. That would still be numerically unstable in many cases, but in a
> trivial case such as this one, that would not be an issue.
>
> On Wednesday, 5 March 2025 at 10:51:29 UTC-8 Seth Chaiken wrote:
> In Sage 10.4, we tried to inject a RR number into a RR polynomial ring
> quotient. It
> works fine when the ideal had one (monomial) generator but precision is
> lost when
> it had two generators.
>
> One generator example (works):
>
> eps = var("eps")
> edBaseRing=PolynomialRing(RR,[eps])
> edIdeal=ideal(edBaseRing, [eps])
> edRing=edBaseRing.quotient_ring(edIdeal)
> print(RR(pi))
> print(edBaseRing(pi))
> print(edRing(pi))
>
> yields:
> 3.14159265358979
> 3.14159265358979
> 3.14159265358979
>
> But with 2 generators, injecting RR(pi) into the quotient loses precision.
> The analogous output is:
> 3.14159265358979
> 3.14159265358979
> 3.14200000000000
>
> Here's the full code:
>
> eps, dlt = var("eps,dlt")
> edBaseRing=PolynomialRing(RR,[eps, dlt])
> edIdeal=ideal(edBaseRing, [eps, dlt])
> edRing=edBaseRing.quotient_ring(edIdeal)
>
> print(RR(pi))
> print(edBaseRing(pi))
> print(edRing(pi))
>
> Looks like a bug! I isolated it from more complex code where the ideal was
> simply all multiples of the two variables, and a RealField with non-default
> bit precision was used.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "sage-support" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-support/gbBYEbxv8Ow/unsubscribe.
>
> To unsubscribe from this group and all its topics, send an email to
> sage-support...@googlegroups.com<mailto:sage-support...@googlegroups.com>.
> To view this discussion visit
> https://groups.google.com/d/msgid/sage-support/4f5b168e-bc62-423d-8da8-bf45ae3b9744n%40googlegroups.com
> <
> https://groups.google.com/d/msgid/sage-support/4f5b168e-bc62-423d-8da8-bf45ae3b9744n%40googlegroups.com?utm_medium=email&utm_source=footer
> >.
>
--
You received this message because you are subscribed to the Google Groups
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-support+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/sage-support/76d6c497-f5d7-4f03-9a9c-73c3b4de27efn%40googlegroups.com.
