Re: [sage-devel] Re: How to define a new ring class ? [We need a class representing genuine real field]

2014-03-14 Thread mmarco



 I would advocate that RLF is a very good approximation of what should 
 be RR. Perhaps one good direction to take is to try to make RLF 
 smarter and contains all constants from pi to cos(42^e). 

 Somehow, it already does (i.e. internally it keeps track of their 
symbollic nature):

{{{
 sage: b=RLF(cos(42^e))
sage: b
0.9578837974?
sage: b.eval(SR)
cos(42^e)
}}}

Maybe the issue is that there is no coercion between SR and RLF (there is 
conversion from SR to RLF, and the .eval() method that can take elements 
from RLF to SR, though).  


-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: How to define a new ring class ? [We need a class representing genuine real field]

2014-03-14 Thread Vincent Delecroix
2014-03-14 10:45 UTC+01:00, mmarco mma...@unizar.es:

 I would advocate that RLF is a very good approximation of what should
 be RR. Perhaps one good direction to take is to try to make RLF
 smarter and contains all constants from pi to cos(42^e).

 Somehow, it already does (i.e. internally it keeps track of their
 symbollic nature):

 {{{
  sage: b=RLF(cos(42^e))
 sage: b
 0.9578837974?
 sage: b.eval(SR)
 cos(42^e)
 }}}

 Maybe the issue is that there is no coercion between SR and RLF (there is
 conversion from SR to RLF, and the .eval() method that can take elements
 from RLF to SR, though).

This is half good, I am happy that RLF wraps symbolic constants. But,
first of all there can not be any reasonable coercion from SR to RLF
as SR is much bigger. Secondly, SR is not consistent with evaluation

sage: cos(1.).parent()
Real Field with 53 bits of precision
sage: cos(1).parent()
Symbolic Ring

I would prefer the second parent to be something like
RealSymbolicField or RealNumbers or whatever but not symbolic ring.

Thirdly, I would like to be able to compare real numbers built from
different sources :
 - algebraic numbers (built from QQbar and NumberField)
 - symbolic constants
 - continued fractions
 - binary expansions
 - ...

But currently:

sage: R.X = QQ[]
sage: K.a = NumberField(X^4 - 5*X^2 + 5, embedding=1.17)
sage: RLF(a)
1.75570504584947?
sage: expr = 2 * cos(3*pi/10)
sage: RLF(expr)
1.17557050458946?
sage: RLF(a) == RLF(expr)  # does not work in RLF
False
sage: bool(SR(a) == SR(expr)) # does not work in SR
False

Even if they are equal as real numbers. So what is broken : comparison
in SR? comparison in RLF?

Vincent

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: How to define a new ring class ? [We need a class representing genuine real field]

2014-03-14 Thread mmarco




 This is half good, I am happy that RLF wraps symbolic constants. But, 
 first of all there can not be any reasonable coercion from SR to RLF 
 as SR is much bigger. Secondly, SR is not consistent with evaluation 

 sage: cos(1.).parent() 
 Real Field with 53 bits of precision 
 sage: cos(1).parent() 
 Symbolic Ring 


I don't see much problem: 1. is a floating point number, and hence an 
inexact element. So it makes sense to compute is cosine as an inexact 
number too.
On the other hand, 1 is an exact element, so it makes sense to keep its 
cosine as an exact number.
 

 I would prefer the second parent to be something like 
 RealSymbolicField or RealNumbers or whatever but not symbolic ring. 

 Thirdly, I would like to be able to compare real numbers built from 
 different sources : 
  - algebraic numbers (built from QQbar and NumberField) 
  - symbolic constants 
  - continued fractions 
  - binary expansions 
  - ... 

 But currently: 

 sage: R.X = QQ[] 
 sage: K.a = NumberField(X^4 - 5*X^2 + 5, embedding=1.17) 
 sage: RLF(a) 
 1.75570504584947? 
 sage: expr = 2 * cos(3*pi/10) 
 sage: RLF(expr) 
 1.17557050458946? 
 sage: RLF(a) == RLF(expr)  # does not work in RLF 
 False 
 sage: bool(SR(a) == SR(expr)) # does not work in SR 
 False 

 Even if they are equal as real numbers. So what is broken : comparison 
 in SR? comparison in RLF? 


IIRC  it is not known if that problem is decidable or not. That is, in 
practice, comparison in SR or RLF will always be broken. It could be 
improved, but there will always be cases where the computer can not 
determine if two expressions are equal or not.

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: How to define a new ring class ? [We need a class representing genuine real field]

2014-03-14 Thread Vincent Delecroix
2014-03-14 14:24 UTC+01:00, mmarco mma...@unizar.es:




 This is half good, I am happy that RLF wraps symbolic constants. But,
 first of all there can not be any reasonable coercion from SR to RLF
 as SR is much bigger. Secondly, SR is not consistent with evaluation

 sage: cos(1.).parent()
 Real Field with 53 bits of precision
 sage: cos(1).parent()
 Symbolic Ring


 I don't see much problem: 1. is a floating point number, and hence an
 inexact element. So it makes sense to compute is cosine as an inexact
 number too.
 On the other hand, 1 is an exact element, so it makes sense to keep its
 cosine as an exact number.

I agree with you but it is a real number not any symbolic expression.
If you read my previous post 1.2 * pi behaves badly because it
should be coerced into RR and not kept into SR (coercion should be
from more precision to less precision). This is the reason why I do
not want to keep symbolic constants into the symbolic ring. Am I wrong
?

 I would prefer the second parent to be something like
 RealSymbolicField or RealNumbers or whatever but not symbolic ring.

 Thirdly, I would like to be able to compare real numbers built from
 different sources :
  - algebraic numbers (built from QQbar and NumberField)
  - symbolic constants
  - continued fractions
  - binary expansions
  - ...

 But currently:

 sage: R.X = QQ[]
 sage: K.a = NumberField(X^4 - 5*X^2 + 5, embedding=1.17)
 sage: RLF(a)
 1.75570504584947?
 sage: expr = 2 * cos(3*pi/10)
 sage: RLF(expr)
 1.17557050458946?
 sage: RLF(a) == RLF(expr)  # does not work in RLF
 False
 sage: bool(SR(a) == SR(expr)) # does not work in SR
 False

 Even if they are equal as real numbers. So what is broken : comparison
 in SR? comparison in RLF?


 IIRC  it is not known if that problem is decidable or not. That is, in
 practice, comparison in SR or RLF will always be broken. It could be
 improved, but there will always be cases where the computer can not
 determine if two expressions are equal or not.

Any number cos(rational x pi) is algebraic and equality of algebraic
numbers is decidable. Moreover, it is not because something is
undecidable that Sage should return a wrong answer. In that case, it
would be good to have a third party in comparison (either returning
Unknown or raising exception).

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: How to define a new ring class ? [We need a class representing genuine real field]

2014-03-14 Thread mmarco



 Any number cos(rational x pi) is algebraic and equality of algebraic 
 numbers is decidable. Moreover, it is not because something is 
 undecidable that Sage should return a wrong answer. In that case, it 
 would be good to have a third party in comparison (either returning 
 Unknown or raising exception). 


Yes, in this particular case, you are right (and in fact, you can check for 
equality of those two elements if you convert them to AA), but in general, 
 determining if a real number given by a symbollic expression involving 
e,pi, rationals, roots, logarithms... is zero or not is not doable. So, no 
matter how you implement this new field of real numbers, it will have 
broken comparison.

But maybe you are right about the Unknown answer. Although it might cause 
some other problems: you cannot know if you can take the inverse, or the 
logarithm of a real numbers. We could have then something like the NaN 
problem: an unknown thing that contaminates everything it touches. I 
don't really think we can find a good solution.

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: How to define a new ring class ?

2014-03-13 Thread Vincent Delecroix
I do not agree with Miguel: it makes sense to have a Parent modeling
the set of all real numbers (even if it has no element). And the
natural name for it would be RR.

Now, concerning concrete computation, what you can do is either :
 - use floating points (ie approximate operations +, x, -, / and exact equality)
 - use computable numbers (ie exact operations but approximate equality)
 - deal with a nice subsets of RR (such as algebraic numbers, finite
transcendantal extensions, ...) where you can deal with exact
operations and exact equality.
 - mix of the one above
It is bad that only QQ, QQbar and SR can handle arbitrary precision
real number. It would make more sense to have pi, e, cos(3/4), ... in
a ring of exact reals.

It deviates from the initial subject but it is always good to say that
real numbers should not be in SR and that RR is misnamed !

Vincent

2014-03-12 21:29 UTC+01:00, mmarco mma...@unizar.es:
 Since the ring you want will be an algebra over the reals, the best fit for

 base ring would be the reals.

 Now, since it is impossible to represent the real field in practice, there
 are different possible solutions in sage:

 RR if you don't care about the lack of exactness
 QQ or some extension (like AA) if you want exactness but don't mind the
 lack of transcendentals
 SR if you want to allow arbitrary expressions, with the problem of speed
 and maybe the lack of a unique form for each element.

 I don't think that you can do much better than that to work with the reals.

 In practice, since in every computation there will only be a finite number
 of symbols involved, it can be done in something like AA(t1,t2,...,tn) (a
 trascendental extension of the algebraic reals) or QQ[a](t1,t2,...,tn) with

 a in AA. But working in those rings can be extremely slow, and you would
 need in advance which numbers would appear, which are algebraic and which
 trascendental and so on. So i wouldn't advise it.


 El miércoles, 12 de marzo de 2014 20:37:00 UTC+1, Eric Gourgoulhon
 escribió:

 Thanks for your answer and suggestions.

 Best wishes,

 Eric.

 Le mercredi 12 mars 2014 17:55:46 UTC+1, Nils Bruin a écrit :

 On Wednesday, March 12, 2014 6:41:07 AM UTC-7, Eric Gourgoulhon wrote:

 The issue here is that CommutativeRing.__init__ requires the argument
 base_ring and in the present context, I don't know what to put here:
 the
 ring C^oo(N) does not depend upon any other ring. Shall I put self, i.e.

 write CommutativeRing.__init__(self, self) ?


 Every ring ultimately has ZZ as a base, by virtue of being an additive
 group. You could use that. On the other hand, if you expect the thing to
 be
 finitely generated over its base then perhaps the ring should be its own

 base (I don't think that's a formal requirement, given that
 `ZZ[['x']].base_ring()==ZZ`). This does happen in Sage elsewhere:

 sage: ZZ.base_ring()
 Integer Ring
 sage: QQ.base_ring()
 Rational Field
 sage: GF(3).base_ring()
 Finite Field of size 3

 On the other hand, if you find it's doable to avoid specifying a base,
 perhaps that's the better way to go.



 --
 You received this message because you are subscribed to the Google Groups
 sage-devel group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sage-devel+unsubscr...@googlegroups.com.
 To post to this group, send email to sage-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/sage-devel.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: How to define a new ring class ? [We need a class representing genuine real field]

2014-03-13 Thread Vincent Delecroix
Salut Thierry,

I did not see your post before posting mine ! I mostly agreed but I
would love to have something better. There are two kinds of
approximation that one can have when dealing with computations :
 - approximate operations +, -, x, / (that allows for example to deal
with a finite subset)
 - approximate equality
The term exact in Sage (as in RR.is_exact()) currently refers to the
first kind. Now if you deal with computable numbers, or large enough
subset of the reals, then you can not guarantee equality (and this is
the case for example with SR that can answer False to A == B even if
it is True). I know that there are other issue with SR, but it was
just to claim that the set of reals that it handle is somewhat too
large to ensure exact equality.

A first step in having sane reals would be to refined this notion of
exactness. This implies to declare convention about the answer of A ==
B. I think that this should be the mathematical answer (True, False)
or an exception that can be either of the kind raise
NotAbleToSolveTheProblem or return Unkown (from sage.misc.unknown).

Now, concerning implementation, I see at least there levels of fields
 - subrings with exact computations and identity problem solvable, ie
algebraic numbers, algebraic reals with exponentials, ...
 - subrings with approximate computations (and identity problem
solvable), ie floating points
 - subrings with exact computations and identity problem unsolvable,
like the RSF and CSF that you propose.

And it defintely makes sense to have a parent RR with no dedicated
class of element.

Best
Vincent

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: How to define a new ring class ?

2014-03-13 Thread mmarco
The problem is that you cannot know if a certain expression involving pi, e 
and cos(3/4) is zero or not (well, you can determine that it is not zero, 
if a numerical approximation is not, but a zero numerical aproximation 
doesn't imply the expression to be zero). That means that, for instance, 
you don't know if you can take its inverse.

If you assume that they are transcendental (that is, that such expressions 
are not zero), you are working on AA(t1,t2.t3) with t1=pi, t2=e, 
t3=cos(3/4).

So maybe the right approach would be to implement arbitrary extensions of 
QQ (that is, QQ(t1,t2...tn)[a], with a algebraic over QQ(t1,t2,...,tn)) 
providing methods to compute numerical aproximations for t1,t2...tn And 
also make it dynamically, so that new symbols can be added on the fly. That 
way we have best of both worlds: algebraic exactness plus the ability to 
get numerical aproximations.

That is, a real would be something that lives in an extension of QQ, with 
a method to get numerical aproximations, and such that all those numerical 
aproximations have no imaginary part

Would that make sense?



El jueves, 13 de marzo de 2014 09:17:34 UTC+1, vdelecroix escribió:

 I do not agree with Miguel: it makes sense to have a Parent modeling 
 the set of all real numbers (even if it has no element). And the 
 natural name for it would be RR. 

 Now, concerning concrete computation, what you can do is either : 
  - use floating points (ie approximate operations +, x, -, / and exact 
 equality) 
  - use computable numbers (ie exact operations but approximate equality) 
  - deal with a nice subsets of RR (such as algebraic numbers, finite 
 transcendantal extensions, ...) where you can deal with exact 
 operations and exact equality. 
  - mix of the one above 
 It is bad that only QQ, QQbar and SR can handle arbitrary precision 
 real number. It would make more sense to have pi, e, cos(3/4), ... in 
 a ring of exact reals. 

 It deviates from the initial subject but it is always good to say that 
 real numbers should not be in SR and that RR is misnamed ! 

 Vincent 

 2014-03-12 21:29 UTC+01:00, mmarco mma...@unizar.es javascript:: 
  Since the ring you want will be an algebra over the reals, the best fit 
 for 
  
  base ring would be the reals. 
  
  Now, since it is impossible to represent the real field in practice, 
 there 
  are different possible solutions in sage: 
  
  RR if you don't care about the lack of exactness 
  QQ or some extension (like AA) if you want exactness but don't mind the 
  lack of transcendentals 
  SR if you want to allow arbitrary expressions, with the problem of speed 
  and maybe the lack of a unique form for each element. 
  
  I don't think that you can do much better than that to work with the 
 reals. 
  
  In practice, since in every computation there will only be a finite 
 number 
  of symbols involved, it can be done in something like AA(t1,t2,...,tn) 
 (a 
  trascendental extension of the algebraic reals) or QQ[a](t1,t2,...,tn) 
 with 
  
  a in AA. But working in those rings can be extremely slow, and you would 
  need in advance which numbers would appear, which are algebraic and 
 which 
  trascendental and so on. So i wouldn't advise it. 
  
  
  El miércoles, 12 de marzo de 2014 20:37:00 UTC+1, Eric Gourgoulhon 
  escribió: 
  
  Thanks for your answer and suggestions. 
  
  Best wishes, 
  
  Eric. 
  
  Le mercredi 12 mars 2014 17:55:46 UTC+1, Nils Bruin a écrit : 
  
  On Wednesday, March 12, 2014 6:41:07 AM UTC-7, Eric Gourgoulhon wrote: 
  
  The issue here is that CommutativeRing.__init__ requires the argument 
  base_ring and in the present context, I don't know what to put 
 here: 
  the 
  ring C^oo(N) does not depend upon any other ring. Shall I put self, 
 i.e. 
  
  write CommutativeRing.__init__(self, self) ? 
  
  
  Every ring ultimately has ZZ as a base, by virtue of being an additive 
  group. You could use that. On the other hand, if you expect the thing 
 to 
  be 
  finitely generated over its base then perhaps the ring should be its 
 own 
  
  base (I don't think that's a formal requirement, given that 
  `ZZ[['x']].base_ring()==ZZ`). This does happen in Sage elsewhere: 
  
  sage: ZZ.base_ring() 
  Integer Ring 
  sage: QQ.base_ring() 
  Rational Field 
  sage: GF(3).base_ring() 
  Finite Field of size 3 
  
  On the other hand, if you find it's doable to avoid specifying a base, 
  perhaps that's the better way to go. 
  
  
  
  -- 
  You received this message because you are subscribed to the Google 
 Groups 
  sage-devel group. 
  To unsubscribe from this group and stop receiving emails from it, send 
 an 
  email to sage-devel+...@googlegroups.com javascript:. 
  To post to this group, send email to 
  sage-...@googlegroups.comjavascript:. 

  Visit this group at http://groups.google.com/group/sage-devel. 
  For more options, visit https://groups.google.com/d/optout. 
  


-- 
You received this message because you are subscribed to the 

Re: [sage-devel] Re: How to define a new ring class ? [We need a class representing genuine real field]

2014-03-13 Thread Volker Braun
On Wednesday, March 12, 2014 8:45:57 PM UTC-4, Thierry 
(sage-googlesucks@xxx) wrote:

 - create RSF (for real symbolic field) to isolate pi and sqrt(2) from 
   cos(x) in the symbolic ring. 


Thats essentially what RLF does.
 

 - re-create RR as an overlay field over the different representations 


Its a basic fact that you can't represent a generic real number on a 
computer. You can argue that one should default to a lazy evaluation and 
not pick a favorite, but that also means that it'll be useless in practice. 
You can't safely  effectively do floating-point computations without 
picking a particular representation first. Trying to pretend otherwise is 
just kidding yourself.

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: How to define a new ring class ? [We need a class representing genuine real field]

2014-03-13 Thread Vincent Delecroix
2014-03-13 21:32 UTC+01:00, Volker Braun vbraun.n...@gmail.com:
 On Wednesday, March 12, 2014 8:45:57 PM UTC-4, Thierry
 (sage-googlesucks@xxx) wrote:

 - create RSF (for real symbolic field) to isolate pi and sqrt(2) from
   cos(x) in the symbolic ring.


 Thats essentially what RLF does.


Nope, pi belongs to SR and not to RLF and there is a huge difference:

sage: RLF(pi) * 1.2  # fine, coercion into RR
3.76991118430775
sage: pi * 1.2# what the f*** ?
1.20*pi

The claim was to put all symbolic constants into RLF or CLF or a
better ring in order to avoid many problems like this one

sage: pi_approx = RR(pi)
sage: bool(pi == SR(pi_approx))
True

and many, many, many others.

 - re-create RR as an overlay field over the different representations


 Its a basic fact that you can't represent a generic real number on a
 computer. You can argue that one should default to a lazy evaluation and
 not pick a favorite, but that also means that it'll be useless in practice.

 You can't safely  effectively do floating-point computations without
 picking a particular representation first. Trying to pretend otherwise is
 just kidding yourself.

Of course, and it was not the argument advanced to redefine RR. Let
say that RR is the set of real numbers. Even if there is no way to
define general operations or comparisons on its elements, we can still
ask
 * if some element belongs to it (in particular NaN and Infinity do not)
 * what is its structure as a topological space
 * what is its cardinality
 * a random element
I would advocate that RLF is a very good approximation of what should
be RR. Perhaps one good direction to take is to try to make RLF
smarter and contains all constants from pi to cos(42^e).

Vincent

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: How to define a new ring class ? [We need a class representing genuine real field]

2014-03-13 Thread Thierry
On Thu, Mar 13, 2014 at 01:32:10PM -0700, Volker Braun wrote:
 On Wednesday, March 12, 2014 8:45:57 PM UTC-4, Thierry 
 (sage-googlesucks@xxx) wrote:
 
  - create RSF (for real symbolic field) to isolate pi and sqrt(2) from 
cos(x) in the symbolic ring. 
 
 Thats essentially what RLF does.

RLF loses some symbolic (resp. algebraic) information compared to SR:

sage: a = sqrt(2)
sage: a^2
2
sage: b = RLF(a)
sage: b^2
2.000?
sage: b^2 == 2
False

  - re-create RR as an overlay field over the different representations 
 
 Its a basic fact that you can't represent a generic real number on a 
 computer. You can argue that one should default to a lazy evaluation and 
 not pick a favorite, but that also means that it'll be useless in practice. 
 You can't safely  effectively do floating-point computations without 
 picking a particular representation first. Trying to pretend otherwise is 
 just kidding yourself.

This is not about floating-point arithmetic nor evaluation, but about a
common parent with some semantics in it.

Not all binary infinite words can be represented by a computer (with the
same countability argument), still Sage proposes a
Words('01', finite=False) parent.

Ciao,
Thierry


-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: How to define a new ring class ? [We need a class representing genuine real field]

2014-03-13 Thread Thierry
On Thu, Mar 13, 2014 at 10:08:05PM +0100, Vincent Delecroix wrote:
[...]
 I would advocate that RLF is a very good approximation of what should
 be RR. Perhaps one good direction to take is to try to make RLF
 smarter and contains all constants from pi to cos(42^e).

A generalisation of RLF could be real computable numbers (the set of
numbers whose digits can be enumerated by a Turing machine). It seems
that some usable implementations do exist already.

I am not sure one representation should be selected above another. Even
if this representation is the most expressive (contains a lot of
elements), it is not able to decide equality, while e.g. AA is.

Ciao,
Thierry

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: How to define a new ring class ? [We need a class representing genuine real field]

2014-03-13 Thread Volker Braun
On Thursday, March 13, 2014 5:10:53 PM UTC-4, Thierry 
(sage-googlesucks@xxx) wrote:

 This is not about floating-point arithmetic nor evaluation, but about a 
 common parent with some semantics in it. 


Its fine to strive for generality, but I don't think its a good idea to 
have something particularly prominent in the namespace for which you can't 
/ don't want to create elements. Also, we can't replace RR without breaking 
lots of existing code or slowing it down to a crawl, so that possibility is 
pretty much out.
  

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Re: How to define a new ring class ?

2014-03-12 Thread Nils Bruin
On Wednesday, March 12, 2014 6:41:07 AM UTC-7, Eric Gourgoulhon wrote:

 The issue here is that CommutativeRing.__init__ requires the argument 
 base_ring and in the present context, I don't know what to put here: the 
 ring C^oo(N) does not depend upon any other ring. Shall I put self, i.e. 
 write CommutativeRing.__init__(self, self) ?


Every ring ultimately has ZZ as a base, by virtue of being an additive 
group. You could use that. On the other hand, if you expect the thing to be 
finitely generated over its base then perhaps the ring should be its own 
base (I don't think that's a formal requirement, given that 
`ZZ[['x']].base_ring()==ZZ`). This does happen in Sage elsewhere:

sage: ZZ.base_ring()
Integer Ring
sage: QQ.base_ring()
Rational Field
sage: GF(3).base_ring()
Finite Field of size 3

On the other hand, if you find it's doable to avoid specifying a base, 
perhaps that's the better way to go.

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Re: How to define a new ring class ?

2014-03-12 Thread Eric Gourgoulhon
Thanks for your answer and suggestions. 

Best wishes,

Eric.

Le mercredi 12 mars 2014 17:55:46 UTC+1, Nils Bruin a écrit :

 On Wednesday, March 12, 2014 6:41:07 AM UTC-7, Eric Gourgoulhon wrote:

 The issue here is that CommutativeRing.__init__ requires the argument 
 base_ring and in the present context, I don't know what to put here: the 
 ring C^oo(N) does not depend upon any other ring. Shall I put self, i.e. 
 write CommutativeRing.__init__(self, self) ?


 Every ring ultimately has ZZ as a base, by virtue of being an additive 
 group. You could use that. On the other hand, if you expect the thing to be 
 finitely generated over its base then perhaps the ring should be its own 
 base (I don't think that's a formal requirement, given that 
 `ZZ[['x']].base_ring()==ZZ`). This does happen in Sage elsewhere:

 sage: ZZ.base_ring()
 Integer Ring
 sage: QQ.base_ring()
 Rational Field
 sage: GF(3).base_ring()
 Finite Field of size 3

 On the other hand, if you find it's doable to avoid specifying a base, 
 perhaps that's the better way to go.


-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Re: How to define a new ring class ?

2014-03-12 Thread mmarco
Since the ring you want will be an algebra over the reals, the best fit for 
base ring would be the reals.

Now, since it is impossible to represent the real field in practice, there 
are different possible solutions in sage:

RR if you don't care about the lack of exactness
QQ or some extension (like AA) if you want exactness but don't mind the 
lack of transcendentals
SR if you want to allow arbitrary expressions, with the problem of speed 
and maybe the lack of a unique form for each element.

I don't think that you can do much better than that to work with the reals. 
In practice, since in every computation there will only be a finite number 
of symbols involved, it can be done in something like AA(t1,t2,...,tn) (a 
trascendental extension of the algebraic reals) or QQ[a](t1,t2,...,tn) with 
a in AA. But working in those rings can be extremely slow, and you would 
need in advance which numbers would appear, which are algebraic and which 
trascendental and so on. So i wouldn't advise it.
 

El miércoles, 12 de marzo de 2014 20:37:00 UTC+1, Eric Gourgoulhon escribió:

 Thanks for your answer and suggestions. 

 Best wishes,

 Eric.

 Le mercredi 12 mars 2014 17:55:46 UTC+1, Nils Bruin a écrit :

 On Wednesday, March 12, 2014 6:41:07 AM UTC-7, Eric Gourgoulhon wrote:

 The issue here is that CommutativeRing.__init__ requires the argument 
 base_ring and in the present context, I don't know what to put here: the 
 ring C^oo(N) does not depend upon any other ring. Shall I put self, i.e. 
 write CommutativeRing.__init__(self, self) ?


 Every ring ultimately has ZZ as a base, by virtue of being an additive 
 group. You could use that. On the other hand, if you expect the thing to be 
 finitely generated over its base then perhaps the ring should be its own 
 base (I don't think that's a formal requirement, given that 
 `ZZ[['x']].base_ring()==ZZ`). This does happen in Sage elsewhere:

 sage: ZZ.base_ring()
 Integer Ring
 sage: QQ.base_ring()
 Rational Field
 sage: GF(3).base_ring()
 Finite Field of size 3

 On the other hand, if you find it's doable to avoid specifying a base, 
 perhaps that's the better way to go.



-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: How to define a new ring class ? [We need a class representing genuine real field]

2014-03-12 Thread Thierry
Hi,

On Wed, Mar 12, 2014 at 01:29:47PM -0700, mmarco wrote:
 RR if you don't care about the lack of exactness
 QQ or some extension (like AA) if you want exactness but don't mind the 
 lack of transcendentals
 SR if you want to allow arbitrary expressions, with the problem of speed 
 and maybe the lack of a unique form for each element.
 
 I don't think that you can do much better than that to work with the reals. 


One could imagine the following improvement (which i would love, at
least to make things easier to learn and teach):

- rename RR as RFF (for real floating field), so that this
  representation is not preferred than the others (especially RDF which
  is faster and allows using more libraries, with the same 53 bits of
  precision). The current name RR suggests it is the right default choice.

- create RSF (for real symbolic field) to isolate pi and sqrt(2) from
  cos(x) in the symbolic ring.

- re-create RR as an overlay field over the different representations
  (numeric (RFF, RDF, RIF), algebraic, symbolic) of the genuine real
  field in Sage. Perhaps could the experience of the community with the
  category framework help in the design of such a meta-representation.

Idem with CFF, CSF, CC for complex numbers.

Ciao,
Thierry

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.