Fix category of Symbolic Ring

[sagetrac-duenez]

The symbolic ring (SR) in Sage currently considers itself to be a field and therefore also an integral domain:

sage: SR.is_field()
True
sage: SR.is_integral_domain()
True

However, it is confused about its category:

sage: SR.category()
Category of commutative rings
sage: SR in PrincipalIdealDomains()
False
sage: SR in Fields()
True

The last command causes the category of SR to be refined, and running the same commands again gives a different output:

sage: SR.category()
Category of fields
sage: SR in PrincipalIdealDomains()
True
sage: SR in Fields()
True

This ticket makes SR.is_field() and SR.is_integral_domain() return False.

Because of this, one now has to indicate explicitly in the code when one takes the risk of treating the symbolic ring as a field. This is currently only done for a couple of linear algebra methods and for points on elliptic curves over the symbolic ring.

A few constructions (which were mathematically meaningless anyway) are now disallowed:

• quaternion algebras over the symbolic ring
• converting a symbolic expression into a rational function over the symbolic ring
• minimal polynomials of matrices over the symbolic ring

Depends on #18040

CC: @rwst

Component: symbolics

Keywords: symbolic ring category

Stopgaps: todo

Author: Peter Bruin

Branch/Commit: u/pbruin/11126-SymbolicRing_not_domain @ 82b9860

Issue created by migration from https://trac.sagemath.org/ticket/11126

[tscrim]

comment:1

This seemed to be fixed at some point. Worked for me in 5.5.rc0.

sage: SR.is_integral_domain()
True

[nbruin]

comment:2

An error is actually the more appropriate thing to return, since the symbolic ring is neither a field nor an integral domain and code that is interested in knowing these things is likely making invalid use of the symbolic ring:

kronecker_delta(x,0)*(1-kronecker_delta(x,0))

[sagetrac-duenez]

comment:3

The problem with SR not being reported as a field (or integral domain) is that several Linear Algebra methods require this behavior. For example solving a linear system with symbolic variables, eigen-value computation, etc. Or at least that was the original reason why I raised this issue. It might no longer be true.

Cheers,

Edgar

[nbruin]

comment:4

Replying to @sagetrac-duenez:

The problem with SR not being reported as a field (or integral domain) is that several Linear Algebra methods require this behavior. For example solving a linear system with symbolic variables, eigen-value computation, etc. Or at least that was the original reason why I raised this issue. It might no longer be true.

I have little doubt it still is. I suspect that one should just be pragmatic with SR and just keep fingers crossed when trying computations with SR. If they succeed: great! The answer might even be correct. If not: formulate the problem in another way.

[sagetrac-duenez]

comment:5

I am a bit confused... It seems to me you are suggesting that I should simply accept that sage might refuse to perform symbolic calculations when solving systems of linear equations... or worse yet, perform them and be wrong. Also, I should just deal with it if it doesn't work like I want.

If this is not what you meant, I apologize, but if it is, I think you are having a very alienating attitude towards your user-base. Sure, one has to be thankful for what one receives for free. I appreciate sage so very much. But to tell me to "suck it up" is hardly the way. Is it really that unreasonable to ask for some intelligent discussion about the implementation, definition and use of the symbolic ring?

If you ask me, you either split symbolics into symbolic group, ring, field, etc., or decide to be as permissive as possible with the operations that you are allowing and shift the responsibility into the user. Ideally you would expose which assumptions were used, or which assumptions should be used when performing a symbolic calculation.

Regards,

[nbruin]

comment:6

Replying to @sagetrac-duenez:

I am a bit confused... It seems to me you are suggesting that I should simply accept that sage might refuse to perform symbolic calculations when solving systems of linear equations... or worse yet, perform them and be wrong. Also, I should just deal with it if it doesn't work like I want.

What I suspect is happening is that linear algebra over SR tries to use generic linear algebra code which wants to know some properties of the ring it's working over in order to know how to proceed (i.e., is it a field? an integral domain?). The symbolic ring doesn't really fit such a rigorous approach and I suspect that most of its benefits stem from that: It's just an algebra of "expression trees". If SR were honest, and report it's not a field and not an integral domain, hardly anything would work. There's a benefit to lying and a lot of things WILL sort of work, because zero-divisors are relatively hard to construct. However, they do exist in SR, so I suspect that you can construct linear algebra examples for which a wrong answer is generated, because the code runs into a zero divisor (which was promised to not exist by claiming it's an integral domain).

SR is just trying to be a bit too much to expect a rigorous algebraic approach to apply to it and still end up with something useful. Testing equality in it is known to be undecidable.

I certainly wouldn't want to stand in the way of an intelligent discussion to improve the situation. Great mathematics happens in the face of great problems. I just thought a word of caution to moderate expectations was in order.

A similar thing happens (for different reasons) with the "numerical" rings. RR and CC claim to be fields too, but due to the numerical nature of the representation of their elements, they are not. Operations aren't even commutative and any float operations that rely on true equality testing are inherently broken. Linear algebra there is really quite tenuous and we can't rely on the generic approaches at all.
How to deal with that is an entire field of mathematics.

(now note that SR in fact contains float arithmetic as well to see that you can't really hope that generic approaches are always safe for SR).

[KPanComputes]

comment:7

Given the discussion here, I think we should discuss this further and decide. Certainly, it seems to me that this is not sage_invalid. I shall set this to needs_info while we discuss this issue.