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.

[sagetrac-maldun]

comment:9

Hi!

Why not adding a subset of symbolic Ring which forms a Field?
I think a good choice would be the subset of all symbolic functions which are
meromorphic.

The Meromorph functions form a field, and contain most of the symbolic functions in use. Additionally this could be handy if we want to introduce differential algebras for symbolic integration and differentiation.

[pjbruin]

Changed keywords from symbolics matrix to symbolic ring category

[pjbruin]

Branch: u/pbruin/11126-SymbolicRing_not_domain

[pjbruin]

Changed author from duenez to Peter Bruin

[pjbruin]

Commit: 82b9860

[videlec]

comment:15

Hello,

I really do not like the strategy. Starting to have special cases for the symbolic ring will be a nightmare to write and maintain. The symbolic ring is definitely an ugly (and very useful) piece of code but it should not be intrusive. Not speaking about the fact that a line like from sage.symbolic.ring import SymbolicRing takes time to be executed. The current situtation that makes SR thinks that it is a field looks much more natural to me: keep the bullshit in one place.

And do you really think that we should support elliptic curves over the symbolic ring? I saw that there is an example in the doc, but we could just ignore it. From my perspective, SR should not even be a ring.

Could you give more motivation of changing the current situation? I do not get it from the ticket description?

Vincent

[pjbruin]

Dependencies: #18040

[pjbruin]

comment:17

I agree that my patch has to be improved. However, I think that this can be done without globally pretending that the symbolic ring is a field.

[sagetrac-jakobkroeker]

Stopgaps: todo