You can subscribe to this list here.
2007 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}
(73) 
_{Sep}
(57) 
_{Oct}
(138) 
_{Nov}
(91) 
_{Dec}
(99) 

2008 
_{Jan}
(91) 
_{Feb}
(53) 
_{Mar}
(37) 
_{Apr}
(125) 
_{May}
(176) 
_{Jun}
(23) 
_{Jul}
(135) 
_{Aug}
(119) 
_{Sep}
(26) 
_{Oct}
(38) 
_{Nov}
(46) 
_{Dec}
(11) 
2009 
_{Jan}
(4) 
_{Feb}
(2) 
_{Mar}
(5) 
_{Apr}
(15) 
_{May}
(4) 
_{Jun}
(18) 
_{Jul}
(1) 
_{Aug}
(4) 
_{Sep}
(17) 
_{Oct}
(9) 
_{Nov}
(14) 
_{Dec}
(11) 
2010 
_{Jan}
(9) 
_{Feb}
(6) 
_{Mar}
(1) 
_{Apr}
(1) 
_{May}
(4) 
_{Jun}
(3) 
_{Jul}

_{Aug}
(10) 
_{Sep}
(7) 
_{Oct}
(7) 
_{Nov}
(36) 
_{Dec}
(23) 
2011 
_{Jan}
(2) 
_{Feb}
(1) 
_{Mar}
(1) 
_{Apr}
(11) 
_{May}
(5) 
_{Jun}
(17) 
_{Jul}
(2) 
_{Aug}
(26) 
_{Sep}
(14) 
_{Oct}
(51) 
_{Nov}
(39) 
_{Dec}
(7) 
2012 
_{Jan}
(24) 
_{Feb}
(7) 
_{Mar}
(9) 
_{Apr}
(2) 
_{May}
(9) 
_{Jun}
(7) 
_{Jul}
(3) 
_{Aug}
(1) 
_{Sep}
(8) 
_{Oct}
(12) 
_{Nov}
(1) 
_{Dec}

2013 
_{Jan}

_{Feb}

_{Mar}

_{Apr}
(35) 
_{May}
(28) 
_{Jun}
(14) 
_{Jul}
(10) 
_{Aug}
(3) 
_{Sep}
(6) 
_{Oct}

_{Nov}
(1) 
_{Dec}

2014 
_{Jan}

_{Feb}

_{Mar}

_{Apr}
(4) 
_{May}
(3) 
_{Jun}
(2) 
_{Jul}
(2) 
_{Aug}
(2) 
_{Sep}
(1) 
_{Oct}
(3) 
_{Nov}
(5) 
_{Dec}
(8) 
2015 
_{Jan}
(3) 
_{Feb}
(2) 
_{Mar}

_{Apr}

_{May}
(1) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}
(1) 
2016 
_{Jan}
(5) 
_{Feb}
(10) 
_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}
(5) 
2017 
_{Jan}
(2) 
_{Feb}
(2) 
_{Mar}
(5) 
_{Apr}
(1) 
_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 


1

2

3

4
(2) 
5
(5) 
6

7

8
(3) 
9

10

11

12

13

14

15

16
(2) 
17

18

19
(1) 
20

21

22

23
(5) 
24

25

26

27

28

29

30





From: Gabriel Dos Reis <gdr@cs...>  20090623 14:26:07

Bill Page <bill.page@...> writes:  On Tue, Jun 23, 2009 at 5:24 AM, Gabriel Dos Reis wrote:  > Bill Page <bill.page@...> writes:  >  > I meant that in math, when we say the imaginary quantity `i', we don't  > mean the imaginary quantity from Gaussian integers. Rather, what  > we want to say is that quantity in any complex ring of fields such that  > i^2 = 1.   But what guarantee is there that this specification is sufficient to  uniquely determine 'i'? What do you mean by 'uniquely'? We all know that an extension is unique up to its automorphism.  > In OpenAxiom, that is expressed by the operation:  >  > imaginary: () > R ++ imaginary() = sqrt(1) = %i.  >  > in the category ComplexCategory. That operation is reported by the  > database as  >  > )di op imaginary  > [1] > D from D if D has COMPCAT D1 and D1 has COMRING  >  > which is just another notation for  >  > forall (D: CommutativeRing) . imaginary: () > D  >  > that is a (qualified) polymorphic type.   Ok.   > Note that while the library really wants '%i' to be a polymorphic  > constant (as intended in math), the interpreter is currently defective  > in that it does not have the same capability to handle polymorphic  > types (yet).   So what I now understand you to be saying is that you would expect the  interpreter to be able to perform function selection on the output of  unary functions (or constants)  something that it does not do now. somehow, yes.  Given 1+%i, it would not be looking for coercions from  PositiveInteger and Complex(Integer) to types that export +, but  rather finding a solution for the types of functions 'one',  'imaginary' and '+' that make this expression typecorrect. E.g.   one()@Complex(Integer) + imaginary()@Complex(Integer)   Right? Almost. The system would interpret 1 + %i as finding an operation + that takes forall(D: Monoid) . D forall(R: CommutativeRing) . Complex(R) and gives the result as a constant of type forall(R: CommutativeRing) . Complex(R) Note that Complex(Integer) is just one instantiation of that type. This machinery is essentially known to people doing qualified polymorphic types (which Spad categories are). However, more work need to be done to adapt it to the interpreter.  > ...  >  It is not obvious to me how a "true polymorphic type" should interact  >  with such coercions.  >  > Your seem to suggest that 'polymorphic type' are not already the  > foundation of Spad  if that impression is true, then I'm surprised you  > believe that.   No I did not mean to suggest that. OK, I'm relieved to read that.  > Polymorphic types are there, and are the foundation of  > the Spad type system; that is not going to go away.  >  > How polymorphic types interact with coercions is obvious in the compiler.  >  > That interaction is not obvious in the interpreter, and that is why so few  > people (if any) actually understands the coercion mechanism in the  > interpreter AND can explain it succinctly from first principles.   That is exactly what I meant.   > And, that is also why people get so confused by the operation selection  > process  there is almost no coherent set of first principles, only ad  > hoc shortcuts.  >   So do you think that the interpreter can manage entirely without  "automatic" coercions and rely only on polymorphism? If not, what  process would have priority? I do not know. But, I do think that we need to get the interpreter follow first principles, and where it can't (there always be such cases, otherwise we are sure to get to solve undecidable problems) then we must clearly document ad hoc solutions that we will push toward more principled explanation. Yes, if it sounds `research', it is because it is :) There are lot of mathematical insight that can tip the balance one way or the other make push make decisions that has been made differently in other communities facing similar problems.  How will the interpreter resolve ambiguities if there are no builtin  assumptions about which types are basic. If I write just   imaginary()   Should the interpreter silently select imaginary()$Complex(Integer)  over imaginary()$Complex(Float) or complain? Why? That is committing to a decision before knowing all the facts. After all, if I'll be computing in Complex(K) where K is some field that contains all values that I'll need in my calculations (e.g. sqrt(%i)), then an informed premature choice has been made.   >   >  > Now, what should be the domain of sqrt(%i)? Surely, it cannot be  >  > Complex Integer. The choice of Expression Complex Integer, in my  >  > opinion, is overreaching  Expression T is at the current state a sort  >  > of 'black hole' that tends to attract everything and we not know yet  >  > how to effectively handle expressions of such type.  >   >  Agreed, although perhaps it is not quite that bad.  >   >  > Complex AlgebraicNumber? Or Complex of an extension of  >  > Fraction Integer by sqrt(2)? In each case, why not?  >  >  >   >  Complex AlgebraicNumber?  >   >  No, because  >  ...  >  The problem is that %i is not sqrt(1) in this domain.  >  > That is what the implementation says. We should not just trust it.  > We should seek the (computationally) mathematically correct answer  > and then confront the implementation.  >   What I mean is that sqrt(1) is multivalued but %i is not. There is  no unique way to interpret sqrt(1) as %i. sqrt(1) is no more or no less `multivalued' than %i. Both designate the same thing: one of the solutions of the equation %i^2 = 1. Once a choice is made, one should consistently stick with that choice; otherwise madness happens.  >  Complex of an extension of Fraction Integer by sqrt(2)?  >  > Well, after all, many integration algorithms have to consider extensions  > of QQ with some radicals. And those may contain %i.  >   Right.   >  Maybe something like this?  >   >  (1) > S:=Complex SAE(FRAC INT,SUP FRAC INT,x^2+2)  >   >  (1)  >  Complex SimpleAlgebraicExtension(Fraction Integer,SparseUnivariatePolynomial  >  Fraction Integer,+?*?2)  >  Type: Domain  >   >  But support for using SimpleAlgebraicExtension in this way seems  >  rather poor.  >  > Agreed. But, again, my question is what should be the mathematically  > correct answer  not what the implementation currently says. If the  > mathematically correct answer requires better support, then what does it  > take to make it work. If the price is too high, then we may want to  > document the short cut and apologize. Otherwise, maybe it is worth  > the efforts?  > ...  >   >  With a lot of work this might be made more transparent. Can we  >  really avoid the "black hole" this way?  >  > That is some of the question I would like to have answers for.  > Is it the mathematically correct answer? Does it scale?  > What are the alternatives? What are the costs?  > Can we do it in way that requires less plumbing?  >   It is not clear to me in what way a domain like S above would be  superior to EXPR Complex INT. Is it because in S there is no way to  express sqrt(1) except as %i? No, it is because we don't know what EXPR Complex INT is.  But there is no way to express sqrt(%i)  either ... Where do we go from here?   Perhaps as Waldek suggests it is necessary to choose a particular way  of handling complex mulivalued functions such as assuming that all  such functions in Expression are holomorphic in spite of the  unpleasant fact that analytic continuation means functions like 'imag  sqrt(%i)' are complexvalued. On the other hand perhaps there are  partial solutions that do not yet such unexpected behavior? multivalued functions are just one aspect of the problem. They don't really make the problem go away, e.g. what is the mathematically correct answer (including the type of the answer?)  Gaby 
From: Bill Page <bill.page@ne...>  20090623 13:57:06

On Tue, Jun 23, 2009 at 5:24 AM, Gabriel Dos Reis wrote: > Bill Page <bill.page@...> writes: > > I meant that in math, when we say the imaginary quantity `i', we don't > mean the imaginary quantity from Gaussian integers. Rather, what > we want to say is that quantity in any complex ring of fields such that > i^2 = 1. But what guarantee is there that this specification is sufficient to uniquely determine 'i'? > In OpenAxiom, that is expressed by the operation: > > imaginary: () > R ++ imaginary() = sqrt(1) = %i. > > in the category ComplexCategory. That operation is reported by the > database as > > )di op imaginary > [1] > D from D if D has COMPCAT D1 and D1 has COMRING > > which is just another notation for > > forall (D: CommutativeRing) . imaginary: () > D > > that is a (qualified) polymorphic type. Ok. > Note that while the library really wants '%i' to be a polymorphic > constant (as intended in math), the interpreter is currently defective > in that it does not have the same capability to handle polymorphic > types (yet). So what I now understand you to be saying is that you would expect the interpreter to be able to perform function selection on the output of unary functions (or constants)  something that it does not do now. Given 1+%i, it would not be looking for coercions from PositiveInteger and Complex(Integer) to types that export +, but rather finding a solution for the types of functions 'one', 'imaginary' and '+' that make this expression typecorrect. E.g. one()@Complex(Integer) + imaginary()@Complex(Integer) Right? > ... >  It is not obvious to me how a "true polymorphic type" should interact >  with such coercions. > > Your seem to suggest that 'polymorphic type' are not already the > foundation of Spad  if that impression is true, then I'm surprised you > believe that. No I did not mean to suggest that. > Polymorphic types are there, and are the foundation of > the Spad type system; that is not going to go away. > > How polymorphic types interact with coercions is obvious in the compiler. > > That interaction is not obvious in the interpreter, and that is why so few > people (if any) actually understands the coercion mechanism in the > interpreter AND can explain it succinctly from first principles. That is exactly what I meant. > And, that is also why people get so confused by the operation selection > process  there is almost no coherent set of first principles, only ad > hoc shortcuts. > So do you think that the interpreter can manage entirely without "automatic" coercions and rely only on polymorphism? If not, what process would have priority? How will the interpreter resolve ambiguities if there are no builtin assumptions about which types are basic. If I write just imaginary() Should the interpreter silently select imaginary()$Complex(Integer) over imaginary()$Complex(Float) or complain? >  >  > Now, what should be the domain of sqrt(%i)? Surely, it cannot be >  > Complex Integer. The choice of Expression Complex Integer, in my >  > opinion, is overreaching  Expression T is at the current state a sort >  > of 'black hole' that tends to attract everything and we not know yet >  > how to effectively handle expressions of such type. >  >  Agreed, although perhaps it is not quite that bad. >  >  > Complex AlgebraicNumber? Or Complex of an extension of >  > Fraction Integer by sqrt(2)? In each case, why not? >  > >  >  Complex AlgebraicNumber? >  >  No, because >  ... >  The problem is that %i is not sqrt(1) in this domain. > > That is what the implementation says. We should not just trust it. > We should seek the (computationally) mathematically correct answer > and then confront the implementation. > What I mean is that sqrt(1) is multivalued but %i is not. There is no unique way to interpret sqrt(1) as %i. >  Complex of an extension of Fraction Integer by sqrt(2)? > > Well, after all, many integration algorithms have to consider extensions > of QQ with some radicals. And those may contain %i. > Right. >  Maybe something like this? >  >  (1) > S:=Complex SAE(FRAC INT,SUP FRAC INT,x^2+2) >  >  (1) >  Complex SimpleAlgebraicExtension(Fraction Integer,SparseUnivariatePolynomial >  Fraction Integer,+?*?2) >  Type: Domain >  >  But support for using SimpleAlgebraicExtension in this way seems >  rather poor. > > Agreed. But, again, my question is what should be the mathematically > correct answer  not what the implementation currently says. If the > mathematically correct answer requires better support, then what does it > take to make it work. If the price is too high, then we may want to > document the short cut and apologize. Otherwise, maybe it is worth > the efforts? > ... >  >  With a lot of work this might be made more transparent. Can we >  really avoid the "black hole" this way? > > That is some of the question I would like to have answers for. > Is it the mathematically correct answer? Does it scale? > What are the alternatives? What are the costs? > Can we do it in way that requires less plumbing? > It is not clear to me in what way a domain like S above would be superior to EXPR Complex INT. Is it because in S there is no way to express sqrt(1) except as %i? But there is no way to express sqrt(%i) either ... Where do we go from here? Perhaps as Waldek suggests it is necessary to choose a particular way of handling complex mulivalued functions such as assuming that all such functions in Expression are holomorphic in spite of the unpleasant fact that analytic continuation means functions like 'imag sqrt(%i)' are complexvalued. On the other hand perhaps there are partial solutions that do not yet such unexpected behavior? Regards, Bill Page. 
From: Gabriel Dos Reis <gdr@cs...>  20090623 09:25:29

Bill Page <bill.page@...> writes:  On Tue, Jun 23, 2009 at 12:35 AM, Gabriel Dos Reis wrote:  >  > I have been thinking about your patch for a while. As I said  > in the bug audit trail, I fully agree that the bug originates from  > explogs2trigs. However, the more I think about it, I more I  > become undecided what the proper fix should be  this is not  > a criticism of your patch, I really just don't know the actual fix  > should be. For several reasons.  >   Great. Thanks for passing on your thoughts. I also have doubts some of  which I have also recently discussed with Waldek on the FriCAS list.   > First, assuming the the operation makes sense, there is an  > immediate issue of branch cuts  the decision has to be made  > and done consistently across the symbolic and numeric spectrum,  > otherwise this is just a disaster waiting to happen and most likely  > harder to debug. To get branch cuts done effectively, we would  > need to propagate properties about (symbolic) expressions that  > we currently do.  >   I think that deciding on branchcuts is in general an unsolvable  problem. What is needed instead is some convenient method for Branch cuts for definite numeric values and constructive reals is decidable. Branch cuts in general is undoable without further propagations of the properties of the expressions.  specifying branches. At the moment I favor the view that multivalued  functions ought to be defined with signatures like the following:   sqrt: Union(pos:Float,neg:Float) > Float   and then I would have to write:   sqrt(neg 9.0)   indicating the negative branch, to obtain   3.0   where 'pos' and 'neg' are injections into the Union. Of course Union  doesn't actually work like that but see for example  http://axiomwiki.newsynthesis.org/SandBoxSum . Unions of this kind  should be viewed as an abstraction of a kind of "manifold". In the  Complex domain sqrt would be viewed as holomorphic map between such  manifolds. I know you like Unions a lot  and you know I believe we should do without them when we can. I believe that is not a debate we solve today or tomorrow or even after tomorrow. So, the question is where do we go from there?  Of course this might not be viewed as "convenient" by most people and  we would need a convention that allows the interpreter to  automatically choose a coercion based on the 'pos' injection. In  library code however we would be stuck having to do it the hard way.   But this is (obviously) still only a halfbaked idea.   > Second, the expression '%i' currently has type defaulted to  > Complex Integer  this is a pure hack in the interpreter because we  > do not have true polymorphic type in the system yet, but this is a  > debate I do not want to have now; that was just an observation.   Ok, I suppose you mean that it's type should be something like  'exists(R,IntegralDomain).Complex(R)' without actually saying exactly  what domain R stands for? No, not really. I meant that in math, when we say the imaginary quantity `i', we don't mean the imaginary quantity from Gaussian integers. Rather, what we want to say is that quantity in any complex ring of fields such that i^2 = 1. In OpenAxiom, that is expressed by the operation: imaginary: () > R ++ imaginary() = sqrt(1) = %i. in the category ComplexCategory. That operation is reported by the database as )di op imaginary [1] > D from D if D has COMPCAT D1 and D1 has COMRING which is just another notation for forall (D: CommutativeRing) . imaginary: () > D that is a (qualified) polymorphic type. Note that while the library really wants '%i' to be a polymorphic constant (as intended in math), the interpreter is currently defective in that it does not have the same capability to handle polymorphic types (yet). Consequently, a hack was introduced in the interpreter so that '%i' is defined macro that expands to 'complex(0,1)', and crossing fingers that somehow wih enough coercions, things would just magically work out. Sometimes, the magic works. Sometime it doesn't. Ideally, the type of '%i' should be forall(D: CommutativeRing) . Complex(R) as intended by the library.  But the interpreter also says:   (1) > 1   (1) 1  Type: PositiveInteger   which surely is a similar "hack". Two wrongs don't make a right. I never said that wasn't a hack.  The point being that the interpreter  will also freely choose coercions which make this choice the obvious ^^^^^^^^^^^^^^^^^^^^^^  kind of "minimal assumption" from which other types are derived as ^^^^ This is where we get surprises: things are not as obvious as they look.  required by the function selection algorithm. Similar coercions exist  for Complex Integer.   It is not obvious to me how a "true polymorphic type" should interact  with such coercions. Your seem to suggest that 'polymorphic type' are not already the foundation of Spad  if that impression is true, then I'm surprised you believe that. Polymorphic types are there, and are the foundation of the Spad type system; that is not going to go away. How polymorphic types interact with coercions is obvious in the compiler. That interaction is not obvious in the interpreter, and that is why so few people (if any) actually understands the coercion mechanism in the interpreter AND can explain it succinctly from first principles. And, that is also why people get so confused by the operation selection process  there is almost no coherent set of first principles, only ad hoc shortcuts.   > Now, what should be the domain of sqrt(%i)? Surely, it cannot be  > Complex Integer. The choice of Expression Complex Integer, in my  > opinion, is overreaching  Expression T is at the current state a sort  > of 'black hole' that tends to attract everything and we not know yet  > how to effectively handle expressions of such type.   Agreed, although perhaps it is not quite that bad.   > Complex AlgebraicNumber? Or Complex of an extension of  > Fraction Integer by sqrt(2)? In each case, why not?  >   Complex AlgebraicNumber?   No, because   (1) > sqrt(1)::Complex AN   Complex AlgebraicNumber is not a valid type. But that does not answer why that is wrong. It only says what the current system (which has many bugs) says. That does not explain why it should be incorrect.  but we already have:   (1) > q:= sqrt(sqrt(1))   ++  \ 1 + 1  (1)   ++  \2  Type: AlgebraicNumber   The problem is that %i is not sqrt(1) in this domain. That is what the implementation says. We should not just trust it. We should seek the (computationally) mathematically correct answer and then confront the implementation.  Complex of an extension of Fraction Integer by sqrt(2)? Well, after all, many integration algorithms have to consider extensions of QQ with some radicals. And those may contain %i.  Maybe something like this?   (1) > S:=Complex SAE(FRAC INT,SUP FRAC INT,x^2+2)   (1)  Complex SimpleAlgebraicExtension(Fraction Integer,SparseUnivariatePolynomial  Fraction Integer,+?*?2)  Type: Domain   But support for using SimpleAlgebraicExtension in this way seems  rather poor. Agreed. But, again, my question is what should be the mathematically correct answer  not what the implementation currently says. If the mathematically correct answer requires better support, then what does it take to make it work. If the price is too high, then we may want to document the short cut and apologize. Otherwise, maybe it is worth the efforts?  This was the best I could manage to come up with in the  current version of OpenAxiom:   (1) > S:=SAE(FRAC INT,SUP(FRAC INT),x^22)   (1)  SimpleAlgebraicExtension(Fraction Integer,SparseUnivariatePolynomial Fraction  Integer,+?*?2)  Type: Domain  (2) > sqrt(2)==generator()$S  Type: Void  (3) > sqrt(2)^2   (3) 2  Type: SimpleAlgebraicExtension(Fraction  Integer,SparseUnivariatePolynomial Fraction Integer,+?*?2)   (4) > p:=(%i::Complex(S)+1)/sqrt(2)   1 1  (4)  ? +  ? %i  2 2  Type: Complex SimpleAlgebraicExtension(Fraction  Integer,SparseUnivariatePolynomial Fraction Integer,+?*?2)   (5) > p^2   (5) %i  Type: Complex SimpleAlgebraicExtension(Fraction  Integer,SparseUnivariatePolynomial Fraction Integer,+?*?2)   (6) > (p^2)::Complex EXPR INT::Complex INT   (6) %i  Type: Complex Integer      With a lot of work this might be made more transparent. Can we really  avoid the "black hole" this way? That is some of the question I would like to have answers for. Is it the mathematically correct answer? Does it scale? What are the alternatives? What are the costs? Can we do it in way that requires less plumbing?  Gaby 
From: Bill Page <bill.page@ne...>  20090623 08:19:48

On Tue, Jun 23, 2009 at 12:35 AM, Gabriel Dos Reis wrote: > > I have been thinking about your patch for a while. As I said > in the bug audit trail, I fully agree that the bug originates from > explogs2trigs. However, the more I think about it, I more I > become undecided what the proper fix should be  this is not > a criticism of your patch, I really just don't know the actual fix > should be. For several reasons. > Great. Thanks for passing on your thoughts. I also have doubts some of which I have also recently discussed with Waldek on the FriCAS list. > First, assuming the the operation makes sense, there is an > immediate issue of branch cuts  the decision has to be made > and done consistently across the symbolic and numeric spectrum, > otherwise this is just a disaster waiting to happen and most likely > harder to debug. To get branch cuts done effectively, we would > need to propagate properties about (symbolic) expressions that > we currently do. > I think that deciding on branchcuts is in general an unsolvable problem. What is needed instead is some convenient method for specifying branches. At the moment I favor the view that multivalued functions ought to be defined with signatures like the following: sqrt: Union(pos:Float,neg:Float) > Float and then I would have to write: sqrt(neg 9.0) indicating the negative branch, to obtain 3.0 where 'pos' and 'neg' are injections into the Union. Of course Union doesn't actually work like that but see for example http://axiomwiki.newsynthesis.org/SandBoxSum . Unions of this kind should be viewed as an abstraction of a kind of "manifold". In the Complex domain sqrt would be viewed as holomorphic map between such manifolds. Of course this might not be viewed as "convenient" by most people and we would need a convention that allows the interpreter to automatically choose a coercion based on the 'pos' injection. In library code however we would be stuck having to do it the hard way. But this is (obviously) still only a halfbaked idea. > Second, the expression '%i' currently has type defaulted to > Complex Integer  this is a pure hack in the interpreter because we > do not have true polymorphic type in the system yet, but this is a > debate I do not want to have now; that was just an observation. Ok, I suppose you mean that it's type should be something like 'exists(R,IntegralDomain).Complex(R)' without actually saying exactly what domain R stands for? But the interpreter also says: (1) > 1 (1) 1 Type: PositiveInteger which surely is a similar "hack". The point being that the interpreter will also freely choose coercions which make this choice the obvious kind of "minimal assumption" from which other types are derived as required by the function selection algorithm. Similar coercions exist for Complex Integer. It is not obvious to me how a "true polymorphic type" should interact with such coercions. > Now, what should be the domain of sqrt(%i)? Surely, it cannot be > Complex Integer. The choice of Expression Complex Integer, in my > opinion, is overreaching  Expression T is at the current state a sort > of 'black hole' that tends to attract everything and we not know yet > how to effectively handle expressions of such type. Agreed, although perhaps it is not quite that bad. > Complex AlgebraicNumber? Or Complex of an extension of > Fraction Integer by sqrt(2)? In each case, why not? > Complex AlgebraicNumber? No, because (1) > sqrt(1)::Complex AN Complex AlgebraicNumber is not a valid type. but we already have: (1) > q:= sqrt(sqrt(1)) ++ \ 1 + 1 (1)  ++ \2 Type: AlgebraicNumber The problem is that %i is not sqrt(1) in this domain. Complex of an extension of Fraction Integer by sqrt(2)? Maybe something like this? (1) > S:=Complex SAE(FRAC INT,SUP FRAC INT,x^2+2) (1) Complex SimpleAlgebraicExtension(Fraction Integer,SparseUnivariatePolynomial Fraction Integer,+?*?2) Type: Domain But support for using SimpleAlgebraicExtension in this way seems rather poor. This was the best I could manage to come up with in the current version of OpenAxiom: (1) > S:=SAE(FRAC INT,SUP(FRAC INT),x^22) (1) SimpleAlgebraicExtension(Fraction Integer,SparseUnivariatePolynomial Fraction Integer,+?*?2) Type: Domain (2) > sqrt(2)==generator()$S Type: Void (3) > sqrt(2)^2 (3) 2 Type: SimpleAlgebraicExtension(Fraction Integer,SparseUnivariatePolynomial Fraction Integer,+?*?2) (4) > p:=(%i::Complex(S)+1)/sqrt(2) 1 1 (4)  ? +  ? %i 2 2 Type: Complex SimpleAlgebraicExtension(Fraction Integer,SparseUnivariatePolynomial Fraction Integer,+?*?2) (5) > p^2 (5) %i Type: Complex SimpleAlgebraicExtension(Fraction Integer,SparseUnivariatePolynomial Fraction Integer,+?*?2) (6) > (p^2)::Complex EXPR INT::Complex INT (6) %i Type: Complex Integer  With a lot of work this might be made more transparent. Can we really avoid the "black hole" this way? Regards, Bill Page. 
From: Gabriel Dos Reis <gdr@cs...>  20090623 04:36:08

Bill  I have been thinking about your patch for a while. As I said in the bug audit trail, I fully agree that the bug originates from explogs2trigs. However, the more I think about it, I more I become undecided what the proper fix should be  this is not a criticism of your patch, I really just don't know the actual fix should be. For several reasons. First, assuming the the operation makes sense, there is an immediate issue of branch cuts  the decision has to be made and done consistently across the symbolic and numeric spectrum, otherwise this is just a disaster waiting to happen and most likely harder to debug. To get branch cuts done effectively, we would need to propagate properties about (symbolic) expressions that we currently do. Second, the expression '%i' currently has type defaulted to Complex Integer  this is a pure hack in the interpreter because we do not have true polymorphic type in the system yet, but this is a debate I do not want to have now; that was just an observation. Now, what should be the domain of sqrt(%i)? Surely, it cannot be Complex Integer. The choice of Expression Complex Integer, in my opinion, is overreaching  Expression T is at the current state a sort of 'black hole' that tends to attract everything and we not know yet how to effectively handle expressions of such type. Complex AlgebraicNumber? Or Complex of an extension of Fraction Integer by sqrt(2)? In each case, why not?  Gaby 
From: Bill Page <bill.page@ne...>  20090619 02:27:24

In a recent report Arnold Doray observed that conjugate sometimes seems to fail when operating on complicated exact complex numbers: http://lists.gnu.org/archive/html/axiommail/200906/msg00027.html To resolve this problem, the following cumulative patch against FriCAS adds 'conjugate' and 'norm' for symbolic complex expressions to the to the patch I sent earlier today. wspage@...:~$ svn diff ~/fricassrc/src/algebra/efstruc.spad.pamphlet > ctrigmnp.patch wspage@...:~$ cat ctrigmnp.patchIndex: /home/wspage/fricassrc/src/algebra/efstruc.spad.pamphlet ===================================================================  /home/wspage/fricassrc/src/algebra/efstruc.spad.pamphlet (revision 627) +++ /home/wspage/fricassrc/src/algebra/efstruc.spad.pamphlet (working copy) @@ 767,6 +767,7 @@ Implementation ==> add ker2explogs: (KG, List KG, List SY) > FG smp2explogs: (PG, List KG, List SY) > FG + nthroot: (GF,GF) > GF supexp : (UP, GF, GF, Z) > GF GR2GF : GR > GF GR2F : GR > F @@ 847,13 +848,24 @@ map(x +> explogs2trigs(x::FG), GR2GF, p)$PolynomialCategoryLifting( IndexedExponents KG, KG, GR, PG, GF)  explogs2trigs f ==  (m := mainKernel f) case "failed" => +  De Moivre's theorem + nthroot(a:GF,n:GF):GF == + r := nthRoot(sqrt(norm(a)),retract(n)@Z) + e := exp(complex(0, 1)*argument(a)/n) + r*e + + explogs2trigs(f:FG):GF == + m := mainKernel f + m case "failed" => GR2GF(retract(numer f)@GR) / GR2GF(retract(denom f)@GR)  op := operator(operator(k := m::KG))$F + k := m::KG + op := operator(operator(k))$F arg := [explogs2trigs x for x in argument k] num := univariate(numer f, k) den := univariate(denom f, k) + is?(op,'nthRoot) => + h := nthroot(first arg, second arg) + supexp(num,h,0,0)/supexp(den,h,0,0) is?(op, 'exp) => e := exp real first arg y := imag first arg @@ 926,6 +938,10 @@ imag : F > F ++ imag(f) returns the imaginary part of \spad{f} where \spad{f} ++ is a complex function. + conjugate:F> F + ++ conjugate(x+%i*y) returns x%i*y + norm : F > F + ++ norm(f) returns f*conjugate(f) real? : F > Boolean ++ real?(f) returns \spad{true} if \spad{f = real f}. complexForm: F > Complex F @@ 952,6 +968,8 @@ real? f == empty?(complexKernels(f).ker) real f == real complexForm f imag f == imag complexForm f + conjugate f == real(f)  sqrt(1) * imag(f) + norm f == f * conjugate(f)  returns [[k1,...,kn], [v1,...,vn]] such that ki should be replaced by vi complexKernels f == @@ 1067,6 +1085,10 @@ imag : F > FR ++ imag(f) returns the imaginary part of \spad{f} where \spad{f} ++ is a complex function. + conjugate:F> F + ++ conjugate(x+%i*y) returns x%i*y + norm : F > FR + ++ norm(f) returns f*conjugate(f) real? : F > Boolean ++ real?(f) returns \spad{true} if \spad{f = real f}. trigs : F > F @@ 1087,6 +1109,8 @@ real f == real complexForm f imag f == imag complexForm f + conjugate f == F2FG real(f)  complex(0,1) * F2FG imag(f) + norm f == FG2F(f * conjugate f) rreal? r == zero? imag r kreal? k == every?(real?, argument k)$List(F) complexForm f == explogs2trigs f wspage@...:~$  Note: These functions treat symbols appearing in values of type 'Expression Complex R' as variables of type R. (1) > conjugate(x+%i*y) (1)  %i y + x Type: Expression(Complex(Integer)) (2) > norm(x+%i*y) 2 2 (2) y + x Type: Expression(Integer) (3) > conjugate(sqrt(x)) ++ (3) \x Type: Expression(Integer) (4) > conjugate(sqrt(x*%i)) ++ ++  2 4 2 (\x  %i x)\x (4)  ++ ++  2 \2 \x Type: Expression(Complex(Integer)) (5) > Further testing is encouraged. Regards, Bill Page. 
From: Bill Page <bill.page@ne...>  20090616 17:08:32

On Sun, Jun 14, 2009 at 10:14 AM, Ralf Hemmecke wrote: > Gaby wrote: >> This patch adds ability to express that using an existential type >> scheme: >> >> x = y == >> case (x,y) is >> (x': exist(S: BasicType) . S, y': S) => x' = y' >> otherwise => EQ(x,y)$Foreign(Builtin) >> >> The expression >> >> exist(S: BasicType) . S >> >> is a type scheme saying that there is domain `S' which belongs to >> the category BasicType. Please, note that that expression does NOT >> designatue a domain. It is a type scheme. > To me, the concept of a "type scheme" and the pattern matching introduced by the 'case' keyword seems entirely foreign to Spad. It is not like any other construction already implemented in the language. Before introducing something this drastically different in Spad I think it would good to have a motivating example much better than the Any domain. But since this is just a subjective statement Gaby might well be justified in simply dismissing it as begin "with with no sound ground or rational explanation". > In case of Any, we have > > http://svn.openaxiom.org/viewvc/openaxiom/trunk/src/algebra/any.spad.pamphlet?revision=1209&view=markup > > Rep := Record(dm: SExpression, ob: None) > > so the actual domain for x and y is explicitly given by x.dm and y.dm. > (Well, basically. Of course SExpression is not the actual domain.) > > Why would one need "exist" (in the particular case of the implementation > of Any) if it more or less could be done with current language > constructs, i.e. > ... Reorganizing your code a little if dom(x) = dom(y) then  (+) if dom(x) has BasicType then obj(x) = obj(y)  (*) else  same memory address check else false I agree that there is no need to introduce typeschemes of the kind proposed by Gaby just to implement Any in a correct typesafe manner. > > (I don't argue in general against "exist", just speaking here of Any.) > Well I do argue against introducing fundamentally new low level constructs in Spad unless there is a very good reason. I think a good reference for existential types is http://portal.acm.org/citation.cfm?id=45065 @article{45065, author = {Mitchell, John C. and Plotkin, Gordon D.}, title = {Abstract types have existential type}, journal = {ACM Trans. Program. Lang. Syst.}, volume = {10}, number = {3}, year = {1988}, issn = {01640925}, pages = {470502}, doi = {http://doi.acm.org/10.1145/44501.45065}, publisher = {ACM}, address = {New York, NY, USA}, } or here: http://theory.stanford.edu/~jcm/papers/mitchplotkin88.pdf but it is not clear to me if Gaby intends existential types in OpenAxiom to implement all of the semantics for existential types that is described here. > Well that would require a definition like > > Rep == Record(X: with, obj: X) > > and > > dom: % > with > Ralf, this nomenclature here is very poor. I would not call this domain 'with' !! There is already a domain in OpenAxiom called Domain. The proper definitions would be: Rep == Record(X: Domain, obj: X) dom: % > Domain > Doesn't have at place (*) the compiler all knowledge it needs to figure > out that the = is actually equality from the domain dom(x) (or dom(y), > but they are identical anyway). > It is important to recall the sideeffect produced by 'has'. In has ensures that all exports of BasicType are available in the thenclause. The extension to the compiler required to compile the code you propose is that the has operator must be able to take a value of type Domain on the lefthand side. dom(x) has BasicType The domain Domain is already treated in a special way by the interpreter so this extension in the compiler does not seem in any way unprecedented. Also I think it is reasonable to expect that the domain Any have the same semantics as Union in the following sense: Any == Union(d for all d in Domain) i.e. the union of all domains. The treatment of values of type Domain in 'has' is essentially the same as: (1) > Union(String,Integer) has BasicType (1) true Type: Boolean But in defense of Gaby's approach I have to admit that the affect of 'has' on scope is in many ways the same as what he achieves in a somewhat more general manner by 'exist' and 'case'. My problem is that I think 'exist' and 'case' are too "lowlevel" for Spad and there introduction could have far reaching affects on how code is written in Spad and what builtin types are presumed necessary. For the most part I like the level at which most code in Spad is written now. Introducing 'exist' seems to make the resulting code a little too lowlevel. > Line (+) would be comparison of domains. Couldn't the compiler simply > check memory addresses here? Or would that be too naive? Equality in Domain is already defined. > I hesitate to suggest a function > > sExpression: with > SExpression > > which would give the SExpression of a domain, because that basically > means reflection of the domain internals. I'm not sure whether any > domain or the compiler should offer such a function. > For more details of reflection in OpenAxiom take a close look at the domains Domain and Syntax. > BTW, in > > > case (x,y) is > > (x': exist(S: BasicType) . S, y': S) => x' = y' > > I don't quite understand what S, x' and y' then actually stand for. > Lacking documentation, I first thought that x' is the same as x, but > with the additional knowledge that it comes from a domain S that has > BasicType. But that doesn't make sense. Since x is either of type % or > Rep. So maybe that syntax means that x' is picking the ob entry from > > Record(dm: SExpression, ob: None) > No I don't think that is right. The new 'case' construct is a "pattern matching" operation. As I understand it it tries to match (x,y) with the pattern (x': exist(S: BasicType) . S, y': S) In effect it searches through all domains that satisfy BasicType until it finds a pair of retractions that take x into S and y into S. In that sense 'case' here is like the existing 'case' used with Union. Rather like 'has', 'case' introduces a new scope where the exports of S are available. > Would your construction also work if the representation were > > Record(ob: None, dm: SExpression, count: Integer) > > where count is just a dummy entry which is filled with a consecutive > number? Also note that I have reversed ob and dm. > Obviously yes. Regards, Bill Page. 
From: Bill Page <bill.page@ne...>  20090616 15:45:49

Arnold, OpenAxiom is a fork of the Axiom project. The OpenAxiom mailing list is openaxiomdevel@... If you are using OpenAxiom you might expect to get more specific answers there. Regards, Bill Page. On Tue, Jun 16, 2009 at 4:20 AM, Arnold Doray wrote: > I'm trying to create a set of orthogonal polynomials using the > GramSchmidt process, but I hit a problem: > > dot(f,g) == integrate(f*g*x^2,x=1..1) > proj(f,g) == dot(f,g)*f/dot(f,f) > > p0 := 1 > p1 := x  proj(p0,x) > p2 := x^2  proj(p0,x^2)  proj(p1,x^2) > > p0 and p1 evaluate correctly, but p2 hits this error: > > ; (DEFUN *2;dot;5;frame1394 ...) is being compiled. > ;; The variable *2;dot;5;frame1394;MV is undefined. > ;; The compiler will assume this variable is a global. > Internal Error > The function coerce with signature OrderedCompletion Integer > > Expression OrderedCompletion Integer is missing from domain > Expression(OrderedCompletion (Integer)) > > I've also tried to define p(n) as a recursive function like so: > > p(0) == 1 > p(n  n > 0) == x^n  sum(proj(p(k),x^n),k=0..n1) > > But get a stack overflow: (eg, evaluating p(1)) > > OpenAxiom will attempt to step through and interpret the code. > Cannot compile map: proj > We will attempt to interpret the code. > Cannot compile map: p > We will attempt to interpret the code. > > >> System error: > Bind stack overflow. > > I would appreciate any pointers where I am going wrong. I'm an Axiom > newbie. These calculations were done using openaxiom 1.2.1 > > Thanks > Arnold > > > > _______________________________________________ > Axiommail mailing list > Axiommail@... > http://lists.nongnu.org/mailman/listinfo/axiommail > 
From: Bill Page <bill.page@ne...>  20090608 17:02:17

On Mon, Jun 8, 2009 at 11:27 AM, Gabriel Dos Reis wrote: > On Mon, Jun 8, 2009 at 9:55 AM, Bill Page wrote: >> Gaby, >> >> I noticed the following commit item in passing: >> >>> <li>Declared variable with no specified values are now handled >>> + as if symbolic value with a specified type.</li> >>> + >> >> Could you explain a little about how this works. Specifically: What is >> meant by "handled as if symbolic value with a specified type"? Have >> you implemented something similar to the ideas in the paper that you >> presented at PLMMS 2008 last year? > > I'm trying to simplify what was presented in that paper (and I'm working on a new implementation.) There are still some work to be done > Great. I believe that treating this properly is very important to OpenAxiom (and Axiom in general). >> Does OpenAxiom behavior now differ from that shown below? > > Yes. > I am very interested! >> >> wspage@...:~$ openaxiom nox >> GCL (GNU Common Lisp) 2.6.7 CLtL1 Sep 1 2008 14:01:57 >> Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl) >> Binary License: GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC) >> Modifications of this banner must retain notice of a compatible license >> Dedicated to the memory of W. Schelter >> >> Use (help) to get some basic information on how to use GCL. >> Temporary directory for compiler files set to /tmp/ >> OpenAxiom: The Open Scientific Computation Platform >> Version: OpenAxiom 1.3.020090308 >> Built on Tuesday March 17, 2009 at 08:13:56 > > A very old trunk version :) > I will rebuild from the current trunk today. >>  >> Issue )copyright to view copyright notices. >> Issue )summary for a summary of useful system commands. >> Issue )quit to leave OpenAxiom and return to shell. >>  >> >> (1) > x:Integer >> Type: Void >> (2) > x+1 >> >> x is declared as being in Integer but has not been given a value. > > (1) > x: Integer > Type: Void > (2) > x + 1 > > (2) x + 1 > Type: Expression Integer > > > There is more to be done/implemented. > In the domain Expression Integer, x is a Symbol. Right? So does this just mean (in the current state of OpenAxiom) that any variable with a declared type that has not yet been given a value can be coerced to a Symbol? If so, I think that is a good first step. Can I now ask, for example (3) > typeOf(variables(x+1).1) and expect to get this: (3) Integer Type: Domain instead of what I used to get: (3) Symbol Type: Domain Regards, Bill Page. 
From: Gabriel Dos Reis <gdr@in...>  20090608 15:27:54

On Mon, Jun 8, 2009 at 9:55 AM, Bill Page<bill.page@...> wrote: > Gaby, > > I noticed the following commit item in passing: > >> <li>Declared variable with no specified values are now handled >> + as if symbolic value with a specified type.</li> >> + > > Could you explain a little about how this works. Specifically: What is > meant by "handled as if symbolic value with a specified type"? Have > you implemented something similar to the ideas in the paper that you > presented at PLMMS 2008 last year? I'm trying to simplify what was presented in that paper (and I'm working on a new implementation.) There are still some work to be done > Does OpenAxiom behavior now differ > from that shown below? Yes. > > wspage@...:~$ openaxiom nox > GCL (GNU Common Lisp) 2.6.7 CLtL1 Sep 1 2008 14:01:57 > Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl) > Binary License: GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC) > Modifications of this banner must retain notice of a compatible license > Dedicated to the memory of W. Schelter > > Use (help) to get some basic information on how to use GCL. > Temporary directory for compiler files set to /tmp/ > OpenAxiom: The Open Scientific Computation Platform > Version: OpenAxiom 1.3.020090308 > Built on Tuesday March 17, 2009 at 08:13:56 A very old trunk version :) >  > Issue )copyright to view copyright notices. > Issue )summary for a summary of useful system commands. > Issue )quit to leave OpenAxiom and return to shell. >  > > (1) > x:Integer > Type: Void > (2) > x+1 > > x is declared as being in Integer but has not been given a value. (1) > x: Integer Type: Void (2) > x + 1 (2) x + 1 Type: Expression Integer There is more to be done/implemented. 
From: Bill Page <bill.page@ne...>  20090608 15:17:28

Gaby, I noticed the following commit item in passing: > <li>Declared variable with no specified values are now handled > + as if symbolic value with a specified type.</li> > + Could you explain a little about how this works. Specifically: What is meant by "handled as if symbolic value with a specified type"? Have you implemented something similar to the ideas in the paper that you presented at PLMMS 2008 last year? Does OpenAxiom behavior now differ from that shown below? wspage@...:~$ openaxiom nox GCL (GNU Common Lisp) 2.6.7 CLtL1 Sep 1 2008 14:01:57 Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl) Binary License: GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC) Modifications of this banner must retain notice of a compatible license Dedicated to the memory of W. Schelter Use (help) to get some basic information on how to use GCL. Temporary directory for compiler files set to /tmp/ OpenAxiom: The Open Scientific Computation Platform Version: OpenAxiom 1.3.020090308 Built on Tuesday March 17, 2009 at 08:13:56  Issue )copyright to view copyright notices. Issue )summary for a summary of useful system commands. Issue )quit to leave OpenAxiom and return to shell.  (1) > x:Integer Type: Void (2) > x+1 x is declared as being in Integer but has not been given a value. (2) > Regards, Bill Page. On Fri, Jun 5, 2009 at 8:38 PM, <dosreis@...> wrote: > Revision: 1190 > http://openaxiom.svn.sourceforge.net/openaxiom/?rev=1190&view=rev > Author: dosreis > Date: 20090606 00:38:03 +0000 (Sat, 06 Jun 2009) > > Log Message: >  > > > Modified Paths: >  > htdocs/1.3/index.html > > Modified: htdocs/1.3/index.html > =================================================================== >  htdocs/1.3/index.html 20090601 17:54:16 UTC (rev 1189) > +++ htdocs/1.3/index.html 20090606 00:38:03 UTC (rev 1190) > @@ 116,6 +116,27 @@ > </li> > </ul> > > + <h4 name="1.3.0changesinterp">2.1.3. Interpreter</h4> > + > + <ul> > + <li>Declared variable with no specified values are now handled > + as if symbolic value with a specified type.</li> > + > + <li>The interpreter now parses a disjunctive expression > + involving the 'is' operator the obvious way. E.g. Now > + <pre> > + T is Integer or T has Ring > + </pre> > + is now understood as > + <pre> > + (T is Integer) or (T has Ring) > + </pre> > + </li> > + > + <li>The interpreter now handles existentially quantified or > + universally quantified expressions</li> > + </ul> > + > <h4 name="1.3.0changesalg">2.1.3. Algebra</h4> > > The following types have been added to OpenAxiom1.3.0 > > > This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. > >  > OpenSolaris 2009.06 is a cutting edge operating system for enterprises > looking to deploy the next generation of Solaris that includes the latest > innovations from Sun and the OpenSource community. Download a copy and > enjoy capabilities such as Networking, Storage and Virtualization. > Go to: http://p.sf.net/sfu/opensolarisget > _______________________________________________ > openaxiomcommit mailing list > openaxiomcommit@... > https://lists.sourceforge.net/lists/listinfo/openaxiomcommit > 
From: Bill Page <bill.page@ne...>  20090605 03:23:41

On Thu, Jun 4, 2009 at 10:47 PM, Gabriel Dos Reis wrote: > ... > I see OpenAxiom as aiming at computational mathematics as opposed > to just being specialized for algebraic computations only. > +1 I am in full agreement with your general goals and methods. Regards, Bill Page. 
From: Bill Page <bill.page@ne...>  20090605 03:22:27

On Thu, Jun 4, 2009 at 4:43 PM, Gabriel Dos Reis wrote: > ... > I would reserve the use of InputForm for syntatic canonical > forms of mathematical objects. > Currently InputForm values can arise both from parsing of input strings and from coercion of values from other domains. Only the latter are in some sense "cononical". But even these are only cononical to the degree that the domain from which they are derived has such properties. So it is not clear to me how one can hope to reserve InputForm for only this use. Regards, Bill Page. 
From: Gabriel Dos Reis <gdr@cs...>  20090605 02:47:02

Bill Page <bill.page@...> writes:  >  On Thu, Jun 4, 2009 at 4:43 PM, Gabriel Dos Reis wrote:  >  > ...  >  > I would reserve the use of InputForm for syntatic canonical  >  > forms of mathematical objects.  >  >  >  Bill Page wrote:  >  Currently InputForm values can arise both from parsing of input  >  strings and  >   On Thu, Jun 4, 2009 at 9:48 PM, Gabriel Dos Reis wrote:  >  > That is the job of Syntax domain in OpenAxiom.  >   Although it sounds logical and desirable, I suppose that direct  conversion of values in the Syntax domain to "canonical" values in  InputForm is a rather hard problem. No? The Syntax domain's primary purpose is as vehicle for terms. Terms are semanticalled analyzed (e.g. type checked, resolved), and evaluated. The evaluation produces a computer representation of a mathematical object, specified by a domain. That domain provides a canonical internal repsentation (e.g. dense vs. sparse, factored vs. fully expanded). To get from internal to external representation, OpenAxiom uses InputForm, which in displayed form is a linear notation for the canonical internal representation. So, I do not know you understand by 'direct conversion'. A Syntax domain object does not necessarily makes sense (e.g. may NOT type check), whereas an InputForm is supposed to have a meaning.  I am tempted to argue in fact that the primary purpose of most of the  rest of panAxiom is to do just this sort of conversion  through the  algebraic "back door" sotospeak ... I see OpenAxiom as aiming at computational mathematics as opposed to just being specialized for algebraic computations only.  Gaby 
From: Bill Page <bill.page@ne...>  20090605 02:34:15

>  On Thu, Jun 4, 2009 at 4:43 PM, Gabriel Dos Reis wrote: >  > ... >  > I would reserve the use of InputForm for syntatic canonical >  > forms of mathematical objects. >  > >  Bill Page wrote: >  Currently InputForm values can arise both from parsing of input >  strings and > On Thu, Jun 4, 2009 at 9:48 PM, Gabriel Dos Reis wrote: > > That is the job of Syntax domain in OpenAxiom. > Although it sounds logical and desirable, I suppose that direct conversion of values in the Syntax domain to "canonical" values in InputForm is a rather hard problem. No? I am tempted to argue in fact that the primary purpose of most of the rest of panAxiom is to do just this sort of conversion  through the algebraic "back door" sotospeak ... Regards, Bill Page. 
From: Gabriel Dos Reis <gdr@cs...>  20090605 02:15:09

Bill Page <bill.page@...> writes:  On Thu, Jun 4, 2009 at 4:43 PM, Gabriel Dos Reis wrote:  > ...  > I would reserve the use of InputForm for syntatic canonical  > forms of mathematical objects.  >   Currently InputForm values can arise both from parsing of input  strings and That is the job of Syntax domain in OpenAxiom.  from coercion of values from other domains. Only the  latter are in some sense "cononical". But even these are only  cononical to the degree that the domain from which they are derived  has such properties. Obviously. For OpenAxiom, a domain that can see its values used as constructor arguments should satisfy both SetCategory and CoercibleTo InputForm. If a domain cannot satisfy those too constraints, there is little point in trying to use its value as constructor arguments.  So it is not clear to me how one can hope to reserve InputForm for  only this use. It is a design choice. However, I fully appreciate there are many choices to make and people are likely to make different choices.  Gaby 
From: Gabriel Dos Reis <gdr@cs...>  20090604 20:43:14

Tim Daly <daly@...> writes:  Gabriel Dos Reis wrote:  > Tim Daly <daly@...> writes:  >  >  I've been reading this thread. It seems to me that what people are seeking  >  is a symbolic algebra rather than a computer algebra system. The distinction  >  is that a symbolic system manipulates input as parse trees in  >  syntactic form.  >  A computer algebra system manipulates input as semantic forms. It appears  >  that you want to recover the syntax from the semantics, a very hard problem.  >  > OpenAxiom has the Syntax domain for matters that are purely syntactic,  >  > OpenAxiom's intended of InputForm is that of expressions the semantics  > of which yield computer representation of mathematical object. In  > particular, you can think of Syntax objects are preInputForm objects   > syntactic objects that have not yet been type checked. So a Syntax object  > is really a member of an initial algebra  unlike InputForm or  > SExpression objects.  >  >  This discussion came up before. At the time I wrote the beginnings of a  >  symbolic front end to Axiom based on Joel Cohen's work. Joel has given  >  me permission to use his books as part of the effort.  >  > I'm familiar with his work (and his two books). I would think that  > there already exist a domain constructor, Expression, that is most  > suited for the work presented in the two volumes. The fundamental  > building block is the Kernel domain constructor. I know some people  > have expressed profound dislikes of the Expression domain constructor.  > But, I suspect that they would have a deeper appreciation of it after  > reading Cohen's work.  >  > The need for InputForm is not just for 'symbolic mathematics'. A proper  > support for the compilation model of the Spad language requires that any  > constructor argument be coercible to InputForm. A fact that is not   > at the moment  enforced, but that is deeply relied upon. See what the  > devaluate functions do and the unspolem assumptions behind.  >  > It is on my TODO list that OpenAxiom1.3.x and up will enforce those  > assumptions.  >  >  Gaby  >  >  So you propose that there are two reasons for this discussion of InputForm,  one of which is to support a computational model of the spad language  and the other is to support symbolic manipulation? No  I did not mean to give an exhaustive list of reasons to have InputForm or not. However, I do recognize instances of situations where the notion of InputForm os relevant and that is what I was trying to say. Futhermore, I do not think the world has to be divided in terms of algebraic computation versus symbolic computation. Rather, my belief is that symbolic mathematics (cross of algebraic computation and symbolic computation) are going to be more and more prevalent.  It is unclear what to expect from InputForm. I think an operational definition of InputForm may be that of syntactic normal forms of mathematical objects. This is required for handling categories and domains properly (or any form of dependent types).  Under the assumption of a computational model it seems that x+y^2 == y^2+x Note that the linear display of the InputForm x + y^2 as y^2 + x reflects the semantics of the polynomial object denoted by that form. As such, I do not think this is a mater of algebraic versus symbolic computation.  Under the assumption of a cohen symbolic model they are not equivalent.  (assuming that plus is associative in both cases) Cohen assumes that + is associative  because he primarily works with polynomials over commutative rings.  Given that there was a comment that the input form was not properly  reproduced  I assumed the discussion involved symbolic issues. Perhaps I misread it.   I do not see how InputForm can be made to support both models. Indeed. I would reserve the use of InputForm for syntatic canonical forms of mathematical objects.  Gaby 
From: Gabriel Dos Reis <gdr@cs...>  20090604 18:43:22

Tim Daly <daly@...> writes:  I've been reading this thread. It seems to me that what people are seeking  is a symbolic algebra rather than a computer algebra system. The distinction  is that a symbolic system manipulates input as parse trees in  syntactic form.  A computer algebra system manipulates input as semantic forms. It appears  that you want to recover the syntax from the semantics, a very hard problem. OpenAxiom has the Syntax domain for matters that are purely syntactic, OpenAxiom's intended of InputForm is that of expressions the semantics of which yield computer representation of mathematical object. In particular, you can think of Syntax objects are preInputForm objects  syntactic objects that have not yet been type checked. So a Syntax object is really a member of an initial algebra  unlike InputForm or SExpression objects.  This discussion came up before. At the time I wrote the beginnings of a  symbolic front end to Axiom based on Joel Cohen's work. Joel has given  me permission to use his books as part of the effort. I'm familiar with his work (and his two books). I would think that there already exist a domain constructor, Expression, that is most suited for the work presented in the two volumes. The fundamental building block is the Kernel domain constructor. I know some people have expressed profound dislikes of the Expression domain constructor. But, I suspect that they would have a deeper appreciation of it after reading Cohen's work. The need for InputForm is not just for 'symbolic mathematics'. A proper support for the compilation model of the Spad language requires that any constructor argument be coercible to InputForm. A fact that is not  at the moment  enforced, but that is deeply relied upon. See what the devaluate functions do and the unspolem assumptions behind. It is on my TODO list that OpenAxiom1.3.x and up will enforce those assumptions.  Gaby 