Opened 10 years ago

Last modified 5 years ago

#11126 needs_work defect

Fix category of Symbolic Ring

Reported by: duenez Owned by: burcin
Priority: major Milestone: sage-6.6
Component: symbolics Keywords: symbolic ring category
Cc: rws Merged in:
Authors: Peter Bruin Reviewers:
Report Upstream: N/A Work issues:
Branch: u/pbruin/11126-SymbolicRing_not_domain (Commits) Commit: 82b9860a3d47ee19f944a3b357b9d0e943226a54
Dependencies: #18040 Stopgaps: todo

Description (last modified by pbruin)

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

Change History (18)

comment:1 Changed 8 years ago by tscrim

  • Milestone changed from sage-5.6 to sage-duplicate/invalid/wontfix
  • Status changed from new to needs_review

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

sage: SR.is_integral_domain()
True

comment:2 Changed 8 years ago by nbruin

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))

comment:3 follow-up: Changed 8 years ago by 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.

Cheers,

Edgar

comment:4 in reply to: ↑ 3 Changed 8 years ago by nbruin

Replying to 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.

comment:5 follow-up: Changed 8 years ago by 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.

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,

comment:6 in reply to: ↑ 5 Changed 8 years ago by nbruin

Replying to 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).

comment:7 Changed 8 years ago by knsam

  • Milestone changed from sage-duplicate/invalid/wontfix to sage-5.8
  • Status changed from needs_review to needs_info

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.

comment:8 Changed 7 years ago by jdemeyer

  • Milestone changed from sage-5.11 to sage-5.12

comment:9 Changed 7 years ago by maldun

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.

comment:10 Changed 7 years ago by vbraun_spam

  • Milestone changed from sage-6.1 to sage-6.2

comment:11 Changed 7 years ago by vbraun_spam

  • Milestone changed from sage-6.2 to sage-6.3

comment:12 Changed 6 years ago by vbraun_spam

  • Milestone changed from sage-6.3 to sage-6.4

comment:13 Changed 6 years ago by pbruin

  • Description modified (diff)
  • Keywords symbolic ring category added; symbolics matrix removed
  • Summary changed from Symbolic Ring is_integral_domain() throws exception to Fix category of Symbolic Ring

comment:14 Changed 6 years ago by pbruin

  • Authors changed from duenez to Peter Bruin
  • Branch set to u/pbruin/11126-SymbolicRing_not_domain
  • Commit set to 82b9860a3d47ee19f944a3b357b9d0e943226a54
  • Description modified (diff)
  • Status changed from needs_info to needs_review

comment:15 Changed 6 years ago by vdelecroix

  • Status changed from needs_review to needs_info

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

comment:16 Changed 6 years ago by rws

  • Cc rws added
  • Milestone changed from sage-6.4 to sage-6.6

comment:17 Changed 6 years ago by pbruin

  • Dependencies set to #18040
  • Status changed from needs_info to needs_work

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.

comment:18 Changed 5 years ago by jakobkroeker

  • Stopgaps set to todo
Note: See TracTickets for help on using tickets.