search

sagemath / sage

Main repository of SageMath. Now open for Issues and Pull Requests.
https://www.sagemath.org
Other
1.19k stars 412 forks source link

Fix category of Symbolic Ring #11126

Open 3157018d-0423-4233-85ed-97827ef02713 opened 13 years ago

3157018d-0423-4233-85ed-97827ef02713 commented 13 years ago

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:

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 commented 11 years ago
comment:1

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

sage: SR.is_integral_domain()
True
nbruin commented 11 years ago
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))
3157018d-0423-4233-85ed-97827ef02713 commented 11 years ago
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 commented 11 years ago
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.

3157018d-0423-4233-85ed-97827ef02713 commented 11 years ago
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 commented 11 years ago
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 commented 11 years ago
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.

ac9ad401-3030-4fb0-957e-6c14f81e046a commented 10 years ago
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 commented 9 years ago

Description changed:

--- 
+++ 
@@ -1,41 +1,29 @@
-The symbolic ring (SR) in sage is considered a field:
+The symbolic ring (`SR`) in Sage currently considers itself to be a field and therefore also an integral domain:

-/***/sage-4.6.2-linux-32bit-ubuntu_10.04_lts-i686-Linux-i686-Linux/ in ()

-/***/sage-4.6.2-linux-32bit-ubuntu_10.04_lts-i686-Linux-i686-Linux/local/lib/python2.6/site-packages/sage/matrix/matrix2.so in sage.matrix.matrix2.Matrix.solve_right (sage/matrix/matrix2.c:3387)()

-/***/sage-4.6.2-linux-32bit-ubuntu_10.04_lts-i686-Linux-i686-Linux/local/lib/python2.6/site-packages/sage/rings/ring.so in sage.rings.ring.Ring.is_integral_domain (sage/rings/ring.c:6035)()

-NotImplementedError:

-However, functions like matrix's **solve_right()** (correctly) test for the ring being integral domain before testing for the ring being a field. Thus, matrices with symbolic entries fail with an exception when trying to use **solve_right()** and related functions.
-
-This behavior was introduced by ticket #10481 where they (correctly) changed the behavior of **is_integral_domain() **of a ring to raise an exception instead of returning it.
-
-The problems is that **SR** does not override **is_integral_domain() **correctly. I propose the addition of the following function to sage/symbolic/rings.pyx
-
-```python
-    def is_integral_domain(self, proof = True):
-        """
-        Returns True, since the symbolic expression ring is reported as a
-        field.
-        
-        EXAMPLES::
-        
-            sage: SR.is_integral_domain()
-            True
-        """
-        return True
+sage: SR.category()
+Category of fields
+sage: SR in PrincipalIdealDomains()
+True
+sage: SR in Fields()
+True

- -What do you think? +We should either make SR.is_field() return False (which is the only mathematically correct option) or put SR in Fields() from the beginning.

pjbruin commented 9 years ago

Changed keywords from symbolics matrix to symbolic ring category

pjbruin commented 9 years ago

Description changed:

--- 
+++ 
@@ -26,4 +26,12 @@
 sage: SR in Fields()
 True

-We should either make SR.is_field() return False (which is the only mathematically correct option) or put SR in Fields() from the beginning. +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 +

pjbruin commented 9 years ago

Branch: u/pbruin/11126-SymbolicRing_not_domain

pjbruin commented 9 years ago

Changed author from duenez to Peter Bruin

pjbruin commented 9 years ago

Commit: 82b9860

videlec commented 9 years ago
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 commented 9 years ago

Dependencies: #18040

pjbruin commented 9 years ago
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.

ea1d0bf8-c27a-4548-8cb7-de0b1d02441a commented 8 years ago

Stopgaps: todo