Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

loss of digits in multivariate polynomial ring quotients with base ring RR #39640

Open
2 tasks done
nbruin opened this issue Mar 6, 2025 · 1 comment
Open
2 tasks done
Labels

Comments

@nbruin
Copy link
Contributor

nbruin commented Mar 6, 2025

Steps To Reproduce

From https://groups.google.com/g/sage-support/c/gbBYEbxv8Ow:

there is a suspicious loss of digits with coercion into multivariate polynomial quotient rings over RR:

sage: R.<x,y>=RR[]
sage: I=R.ideal(x)
sage: Q=R.quotient(I)
sage: Q(1/3)
0.333300000000000
sage: Q(99998/99999)
1.00000000000000

there is no actual arithmetic happening and note that the rounding is happening at a very precise number of decimal digits, so it looks more like a very naive approximation of floats by small-denominator rational numbers.

Expected Behavior

I would expect an error because imprecise base rings aren't supported for multivariate quotient rings or an approximate answer that doesn't introduce such an egregious and unnecessary rounding error.

Actual Behavior

as above

Additional Information

No response

Environment

any recent sage

Checklist

  • I have searched the existing issues for a bug report that matches the one I want to file, without success.
  • I have read the documentation and troubleshoot guide
@nbruin nbruin added the t: bug label Mar 6, 2025
@nbruin
Copy link
Contributor Author

nbruin commented Mar 6, 2025

A little digging seems to indicate this is how singular converts floats:

sage: RR[x,y](1/3)._singular_()
(3.333e-01)

so we should just not use singular here. Somewhere in the quotient ring code, apparently the use of singular is attempted. We should make sure that attempt explicitly fails with base ring RR etc.

Probably the code in question just does a "try/except" somewhere hoping that the absence of an error means a meaningful result. That hope is unjustified here, unfortunately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant