You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After looking at the code, we (@fingolfin and myself) came to the conclusion that it would be best to forbid zero rings in polynomial ring constructors (both univariate and multivariate) for now.
Why? Most of the code is wrong and it gives silently wrong results. This is because it heavily relies on is_zero(a), but this is not the right thing to check. In the presence of zero rings, one needs to replace this by is_zero(a) && !is_one(a).
This is quite intrusive and we don't have the resources to change this consistently. One probably would need to check any is_zero call.
We would need some optimized is_zero_and_not_one to not make this check twice as slow for most rings.
The next thing to do is to add an is_trivial(R) check to the various constructors and throw an "not implemented (yet)" error.
We can revisit this decision once the need for this construction arises.
The text was updated successfully, but these errors were encountered:
After looking at the code, we (@fingolfin and myself) came to the conclusion that it would be best to forbid zero rings in polynomial ring constructors (both univariate and multivariate) for now.
Why? Most of the code is wrong and it gives silently wrong results. This is because it heavily relies on
is_zero(a)
, but this is not the right thing to check. In the presence of zero rings, one needs to replace this byis_zero(a) && !is_one(a)
.is_zero
call.is_zero_and_not_one
to not make this check twice as slow for most rings.The next thing to do is to add an
is_trivial(R)
check to the various constructors and throw an "not implemented (yet)" error.We can revisit this decision once the need for this construction arises.
The text was updated successfully, but these errors were encountered: