You can subscribe to this list here.
2008 
_{Jan}
(4) 
_{Feb}
(2) 
_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}
(2) 
_{Sep}

_{Oct}
(27) 
_{Nov}

_{Dec}
(6) 

2009 
_{Jan}
(3) 
_{Feb}

_{Mar}

_{Apr}
(1) 
_{May}

_{Jun}
(27) 
_{Jul}

_{Aug}

_{Sep}
(3) 
_{Oct}
(22) 
_{Nov}
(12) 
_{Dec}

2010 
_{Jan}
(11) 
_{Feb}
(3) 
_{Mar}
(2) 
_{Apr}
(11) 
_{May}
(29) 
_{Jun}
(59) 
_{Jul}

_{Aug}
(3) 
_{Sep}
(2) 
_{Oct}
(8) 
_{Nov}
(3) 
_{Dec}

2011 
_{Jan}
(5) 
_{Feb}

_{Mar}

_{Apr}
(6) 
_{May}

_{Jun}

_{Jul}
(13) 
_{Aug}
(4) 
_{Sep}
(4) 
_{Oct}
(19) 
_{Nov}

_{Dec}
(2) 
2012 
_{Jan}
(2) 
_{Feb}
(1) 
_{Mar}
(3) 
_{Apr}

_{May}

_{Jun}

_{Jul}
(1) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2013 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}
(78) 
_{Jun}
(10) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}
(2) 
2014 
_{Jan}
(2) 
_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}
(1) 
_{Oct}
(1) 
_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1

2

3

4

5

6

7

8
(1) 
9

10

11
(3) 
12

13

14

15

16

17

18

19

20
(1) 
21

22

23

24

25

26

27

28
(3) 
29

30
(1) 
31
(2) 






From: Gabriel Dos Reis <gdr@cs...>  20100131 15:46:12

Kostas Oikonomou <ko@...> writes:  Gaby,   Sorry for the barrage of questions, but now I can't figure out how to  compose two formal power series. For example, if   P := series(n +> a(n), x=0, 1..)   and   Q := series(n +> b(n), x=0)   how do I find Q(P)? eval(Q,P) gives a type/domain error, as I  expected from reading its documentation. The notation Q(P) gives the composition of P by Q. In this case, it gives something that starts with 2 2 b(0) + a(1)b(1)x + (a(1) b(2) + a(2)b(1))x + 3 3 (a(1) b(3) + 2a(1)a(2)b(2) + a(3)b(1))x + 4 2 2 4 (a(1) b(4) + 3a(1) a(2)b(3) + (2a(1)a(3) + a(2) )b(2) + a(4)b(1))x + 5 3 2 2 a(1) b(5) + 4a(1) a(2)b(4) + (3a(1) a(3) + 3a(1)a(2) )b(3) + (2a(1)a(4) + 2a(2)a(3))b(2) + a(5)b(1) * 5 x + 6 4 3 2 2 a(1) b(6) + 5a(1) a(2)b(5) + (4a(1) a(3) + 6a(1) a(2) )b(4) + 2 3 (3a(1) a(4) + 6a(1)a(2)a(3) + a(2) )b(3) + 2 (2a(1)a(5) + 2a(2)a(4) + a(3) )b(2) + a(6)b(1) * 6 x ...  Gaby 
From: Gabriel Dos Reis <gdr@cs...>  20100131 15:37:03

Kostas Oikonomou <ko@...> writes:  Gaby,   Thanks. Requiring the first coefficient to be 1 can catch the unwary,  like me, who assumed that the only requirement for reversion is that  a(0)=0.   Would it be too hard to fix "revert" to not require this? it is conceivable to refine the requirements. At the moment, the requirement on the coefficients is that they form Ring.   In my case, defining P like   P := x + series(n +> a(n), x=0, 2..)   complicates the notation for what I want to do after the reversion.  So for now I can divide everything by a(1). I understand. Either way, I think there ought to be a way of unambiguously failing early instead of producing nonsensical results.  Gaby 
From: Kostas Oikonomou <ko@re...>  20100130 16:37:10

Gaby, Thanks. Requiring the first coefficient to be 1 can catch the unwary, like me, who assumed that the only requirement for reversion is that a(0)=0. Would it be too hard to fix "revert" to not require this? In my case, defining P like P := x + series(n +> a(n), x=0, 2..) complicates the notation for what I want to do after the reversion. So for now I can divide everything by a(1). Kostas On 01/28/10 11:34 AM, Gabriel Dos Reis wrote: > Kostas Oikonomou<ko@...> writes: > >  I have >  >  a := operator('a,1); >  P := series(n +> a(n), x=0, 1..); >  >  However, when I try >  >  revert(P) > > The documentation for 'revert' requires that the first coefficient of > the series must be '1'. So, if you write > > a := operator('a, 1) > P := x + series(n +> a(n), x=0, 2..) > revert P > > it just works fine. > > >  Gaby 
From: Gabriel Dos Reis <gdr@cs...>  20100128 16:34:13

Kostas Oikonomou <ko@...> writes:  I have   a := operator('a,1);  P := series(n +> a(n), x=0, 1..);   However, when I try   revert(P) The documentation for 'revert' requires that the first coefficient of the series must be '1'. So, if you write a := operator('a, 1) P := x + series(n +> a(n), x=0, 2..) revert P it just works fine.  Gaby 
From: Gabriel Dos Reis <gdr@cs...>  20100128 16:17:38

Gabriel Dos Reis <gdr@...> writes:  Kostas Oikonomou <ko@...> writes:    I have     a := operator('a,1);   P := series(n +> a(n), x=0, 1..);     However, when I try     revert(P)     I get     >> System error:   The value NIL is not of type CONS.   Dear Kostas,   I looked at your testcase, and I have a preliminary explanation   though I suspect you're more interested in a fix :)   The issue has to do with the OpenAxiom compiler doing more optimizations  in concert with the Lisp compiler (in this case SBCL) through type  declarations.   Indeed the domain representation for STREAM reads   Rep := Record(firstElt: S, restOfStream: %)   >From there, the OpenAxiom compiler infers that an value of domain  STREAM has is representationally isomorphic to a record of two  elements. However, a record of two elements is a represented as  a CONS (at the Lisp level). Consequently the OpenAxiom compiler tells  the Lisp compiler that all values of type STREAM are CONS cell, and that  the Lisp compiler is free to do any valid optimization based on that.  The SBCL compiler generates verification for type declarations  even  when it uses that information to generate better code. In this case, it  finds that a NIL was pretending to be a value of type STREAM. So, the  real question is how did a NIL pose as a stream object? Interestingly, it seems like I already ran into issues in this area in the past, and put a comment in the STREAM implementation (which is simply trying to lie to the OpenAxiom compiler and the Lisp compiler.) More specifically, I wrote these comments a while ago:  This description of the rep is not quite true.  The Rep is a pair of one of three forms:  [value: S, rest: %]  [nullstream: Magic, NIL ]  [nonnullstream: Magic, fun: () > %]  Could use a record of unions if we could guarantee no tags.  Gaby 
From: Gabriel Dos Reis <gdr@cs...>  20100128 16:11:54

Kostas Oikonomou <ko@...> writes:  I have   a := operator('a,1);  P := series(n +> a(n), x=0, 1..);   However, when I try   revert(P)   I get   >> System error:  The value NIL is not of type CONS. Dear Kostas, I looked at your testcase, and I have a preliminary explanation  though I suspect you're more interested in a fix :) The issue has to do with the OpenAxiom compiler doing more optimizations in concert with the Lisp compiler (in this case SBCL) through type declarations. Indeed the domain representation for STREAM reads Rep := Record(firstElt: S, restOfStream: %) >From there, the OpenAxiom compiler infers that an value of domain STREAM has is representationally isomorphic to a record of two elements. However, a record of two elements is a represented as a CONS (at the Lisp level). Consequently the OpenAxiom compiler tells the Lisp compiler that all values of type STREAM are CONS cell, and that the Lisp compiler is free to do any valid optimization based on that. The SBCL compiler generates verification for type declarations  even when it uses that information to generate better code. In this case, it finds that a NIL was pretending to be a value of type STREAM. So, the real question is how did a NIL pose as a stream object?  Gaby 
From: Kostas Oikonomou <ko@re...>  20100120 15:47:34

I have a := operator('a,1); P := series(n +> a(n), x=0, 1..); However, when I try revert(P) I get >> System error: The value NIL is not of type CONS. Kostas 
From: Gabriel Dos Reis <gdr@cs...>  20100111 11:40:59

Gabriel Dos Reis <gdr@...> writes: [...]  What is happening in (5) is that by the time you enter the expression  A(0, 1), the definition of A looks more like this:   A(k, m) ==  k < m => 0  k = m => a(1)^m  k > m => 1/((km)*a(1)) * sum(((m+1)*i(km))*a(i+1)*A(ki,m), i=1..km)  error("impossible case") [...]  Now, how to proceed? There are at least two paths:  (1) make the interpreter smarter.  (2) use a workaround by explicitly saying what you meant. In this  case, it would be that you wanted the map A to have type   A: (INT, INT) > EXPR INT    I tried to do (2) for the time being until the interpreter gets smarter  (but even then, there will always be cases that would surprise people.)  So, by modifying your example as above, I get for A(2,1) the diagnostic   Cannot convert from type Polynomial Integer to Integer for value   i + 2   that is because the interpreter still thinks "k  i" is of type POLY INT.  So, the interpreter needs to get a little bit smarter for expressions  that involve segment binding. I'll work on that. In the mean time you  can write an explicit loop for the sum part. Hmm, maybe not. Consider the expression integrate(x^3, x=0..3) here, we want the interpreter to consider "x^3" as POLY INT, then compute its antiderivative and then return the values of the integral as appropriate. However, if the interpreter propagates the information that 'x' is of type INT because it takes values in the segment 0..3, then it can't logically derive that x^3 is of type POLY INT. The practical implication for your case is that you would have to write an explicit loop for the sum, which has the effect of implicitly declaring that 'i' is of type INT  i.e. what you want. Conclusion, the following works: a := operator('a,1) A: (INT, INT) > EXPR INT A(k,mk<m) == 0 A(k,mk=m) == a(1)^m A(k,mk>m) == s : EXPR INT := 0 for i in 1..(km) repeat s := s + ((m+1) * i  (km)) * a(i+1) * A(ki, m) 1/((km)*a(1)) * s 
From: Gabriel Dos Reis <gdr@cs...>  20100111 09:32:35

Kostas Oikonomou <ko@...> writes:  Hi,   I am trying to define a function A(k,m), where k,m are  integers, as follows:   (1) > a := operator('a,1);   Type: BasicOperator  (2) > A(k,mk<m) == 0;   Type: Void  (3) > A(k,mk=m) == a(1)^m;   Type: Void  (4) > A(k,mk>m) == 1/((km)*a(1)) *  sum(((m+1)*i(km))*a(i+1)*A(ki,m), i=1..km);   Type: Void  (5) > A(0,1)  There are 3 exposed and 1 unexposed library operations  named <  having 2 argument(s) but none was determined to be  applicable.  Use HyperDoc Browse, or issue  )display op <  to learn more about the available operations. Perhaps  packagecalling the operation or using coercions on  the arguments  will allow you to apply the operation.  Cannot find a definition or applicable library operation  named <  with argument type(s)  Polynomial Integer  Integer   Perhaps you should use "@" to indicate the required  return type,  or "$" to specify which version of the function you need.  OpenAxiom will attempt to step through and interpret the  code.  Cannot compile map: A  We will attempt to interpret the code.   (5) 0  (6) > A(3,3)   3  (6) a(1)  Type:  Expression Integer  (7) > A(2,1)  There are 3 exposed and 1 unexposed library operations  named <  having 2 argument(s) but none was determined to be  applicable.  Use HyperDoc Browse, or issue  )display op <  to learn more about the available operations. Perhaps  packagecalling the operation or using coercions on  the arguments  will allow you to apply the operation.   Cannot find a definition or applicable library operation  named <  with argument type(s)  Polynomial Integer  PositiveInteger   Perhaps you should use "@" to indicate the required  return type,  or "$" to specify which version of the function you need.  (7) >    I don't understand what is happening in line (5). How is  the comparison "k<m" resulting in k, m being deduced as  Polynomial Integer and PositiveInteger? But, anyhow, line  (5) succeeds in the end.   The major problem is with line (7). I tried replacing the  "k>m" with (k>m)$Integer, but that didn't help. Why doesn't  a problem of this sort occur with the recursive definition  of the factorial in the tutorial?   Thanks for your help. Dear Kostas, The essence of the issue you are reporting resides in how OpenAxiom (in fact all AXIOMs) handles type inference for maps  function defined at the interpreter level without type annotation. (Some other AXIOMs may not exhibit the problem in this way though.) What is happening in (5) is that by the time you enter the expression A(0, 1), the definition of A looks more like this: A(k, m) == k < m => 0 k = m => a(1)^m k > m => 1/((km)*a(1)) * sum(((m+1)*i(km))*a(i+1)*A(ki,m), i=1..km) error("impossible case") When you call A(0, 1), the interpreter tries to synthesize a mapping (i.e. a function with a definite type) out of a copy of A, that would be appropriate to call with the arguments 0 and 1. This process is always followed every time you define call a map (e.g. function defined at the interpreter level without type annotation). Let's call this process the map instantiation. The map instantiation infers a type for (a copy of) A by looking at the body of A and tring to see what 'reasonable' type it should assign to its local variables 'k' and 'm' that would lead to 'reasonable' result type. It starts with the types NNI and PI (the type of the arguments). For that pair, it quickly finds that for the first branch (i.e. the part that starts with "k < m") it has to coerce the variables k and m to the common superdomain INT, and it finds the operation "<" defined in INT. For the second branch, the operation "=" is found in the domain INT (the common type of k and m). So it follows the consequence of that branch, which is "a(1)^m". Now, it has to type check "a(1)". That expression invokes the function call operator "elt" with two arguments of type BOP and PI. There is no operator taking values of exactly those types. However, the call can succeed if "1" is converted to type EXPR INT. Which the interpreter proceeds to do. At this point, there is no additional constraint on 'k' and 'm'. Finally the interpreter moves to the third branch. The most interesting one :) There is no problem in typechecking the expression "k > m". However the consequence of that branch involves lot of expressions. I'm going to skip the obvious ones and instead focus on the 'sum' part. The interpreter needs to determine the type of the arguments in order to guess which 'sum' to call. It starts with the summand. In that summand, 'i' appears unbound because the interpreter has not looked at the second argument yet. So it assigns to 'i' the type Variable 'i. When it tries to typecheck the subexpression "(m+1) * i" it realizes that there is no operation "*" that takes an INT and a Variable 'i. However, if it can coerce Variable 'i to Symbol, then to a POLY INT, then it can do the multiplication. So, 'i' acquires the type Symbol and the expression "(m+1) * i" has type POLY INT. And so on. It arrives at the subexpression A(k  i, m). By the previous reasoning, the argument "k  i" has type POLY INT, and "m" still retains the type INT. So, now the interpreter tries to synthesize a mapping out of A with argument types POLY INT and INT, for that recursive call to A. And it starts over the game again. There if finds out that it can't typecheck the condition "k < m" when k has type POLY INT and m has type INT. That is the diagnostic message you're seeing. Due to a curiosity in the interpreter implementation, when that part fails, the interpreter just continues (because it realizes that the values of k and m don't require that branch to typecheck). So you get the result you wanted. However for the call A(2,1), the interpreter sees it needs that branch to type check, so it gave up. Now, how to proceed? There are at least two paths: (1) make the interpreter smarter. (2) use a workaround by explicitly saying what you meant. In this case, it would be that you wanted the map A to have type A: (INT, INT) > EXPR INT I tried to do (2) for the time being until the interpreter gets smarter (but even then, there will always be cases that would surprise people.) So, by modifying your example as above, I get for A(2,1) the diagnostic Cannot convert from type Polynomial Integer to Integer for value  i + 2 that is because the interpreter still thinks "k  i" is of type POLY INT. So, the interpreter needs to get a little bit smarter for expressions that involve segment binding. I'll work on that. In the mean time you can write an explicit loop for the sum part. Hope that helps,  Gaby 
From: Kostas Oikonomou <ko@re...>  20100111 02:31:12

Hi, I am trying to define a function A(k,m), where k,m are integers, as follows: (1) > a := operator('a,1); Type: BasicOperator (2) > A(k,mk<m) == 0; Type: Void (3) > A(k,mk=m) == a(1)^m; Type: Void (4) > A(k,mk>m) == 1/((km)*a(1)) * sum(((m+1)*i(km))*a(i+1)*A(ki,m), i=1..km); Type: Void (5) > A(0,1) There are 3 exposed and 1 unexposed library operations named < having 2 argument(s) but none was determined to be applicable. Use HyperDoc Browse, or issue )display op < to learn more about the available operations. Perhaps packagecalling the operation or using coercions on the arguments will allow you to apply the operation. Cannot find a definition or applicable library operation named < with argument type(s) Polynomial Integer Integer Perhaps you should use "@" to indicate the required return type, or "$" to specify which version of the function you need. OpenAxiom will attempt to step through and interpret the code. Cannot compile map: A We will attempt to interpret the code. (5) 0 (6) > A(3,3) 3 (6) a(1) Type: Expression Integer (7) > A(2,1) There are 3 exposed and 1 unexposed library operations named < having 2 argument(s) but none was determined to be applicable. Use HyperDoc Browse, or issue )display op < to learn more about the available operations. Perhaps packagecalling the operation or using coercions on the arguments will allow you to apply the operation. Cannot find a definition or applicable library operation named < with argument type(s) Polynomial Integer PositiveInteger Perhaps you should use "@" to indicate the required return type, or "$" to specify which version of the function you need. (7) > I don't understand what is happening in line (5). How is the comparison "k<m" resulting in k, m being deduced as Polynomial Integer and PositiveInteger? But, anyhow, line (5) succeeds in the end. The major problem is with line (7). I tried replacing the "k>m" with (k>m)$Integer, but that didn't help. Why doesn't a problem of this sort occur with the recursive definition of the factorial in the tutorial? Thanks for your help. Kostas 
From: Gabriel Dos Reis <gdr@cs...>  20100108 16:02:16

Kostas Oikonomou <ko@...> writes:  Hi Gaby,   Whenever you get a chance, could you take a look at the last comment I  posted on bug 2924540?   It has to do with   alpha := operator('alpha,1);  d := operator('d,1);  )set streams calculate 3  mu := series(n +> alpha(n), z=0);  sum(mu^d(i), i=1..2)   There are 6 exposed and 2 unexposed library operations named sum  having 2 argument(s) but none was determined to be applicable.  ... Dear Kostas, I think the issue seems to be that  at the moment  there is no function 'sum' that would take values of type UnivariatePuiseuxSeries as first arguments. Indeed )di op sum displays There are 6 exposed functions called sum : [1] (D1,Symbol) > D1 from FunctionSpaceSum(D3,D1) if D3 has Join(IntegralDomain,RetractableTo Integer, LinearlyExplicitRingOver Integer) and D1 has Join( FunctionSpace D3,CombinatorialOpsCategory, AlgebraicallyClosedField,TranscendentalFunctionCategory) [2] (D1,SegmentBinding D1) > D1 from FunctionSpaceSum(D3,D1) if D1 has Join(FunctionSpace D3,CombinatorialOpsCategory, AlgebraicallyClosedField,TranscendentalFunctionCategory) and D3 has Join(IntegralDomain,RetractableTo Integer, LinearlyExplicitRingOver Integer) [3] (Polynomial D4,Symbol) > Fraction Polynomial D4 from RationalFunctionSum D4 if D4 has Join(IntegralDomain,RetractableTo Integer) [4] (Fraction Polynomial D4,Symbol) > Union(Fraction Polynomial D4, Expression D4) from RationalFunctionSum D4 if D4 has Join(IntegralDomain,RetractableTo Integer) [5] (Polynomial D4,SegmentBinding Polynomial D4) > Fraction Polynomial D4 from RationalFunctionSum D4 if D4 has Join(IntegralDomain,RetractableTo Integer) [6] (Fraction Polynomial D4,SegmentBinding Fraction Polynomial D4) > Union(Fraction Polynomial D4,Expression D4) from RationalFunctionSum D4 if D4 has Join(IntegralDomain,RetractableTo Integer) There are 5 unexposed functions called sum : [1] (D2,D3,Segment D2) > Record(num: D2,den: Integer) from InnerPolySum(D5,D3,D6,D2) if D2 has POLYCAT(D6,D5,D3) and D5 has OAMONS and D3 has ORDSET and D6 has INTDOM [2] (D2,D3) > Record(num: D2,den: Integer) from InnerPolySum(D4,D3, D5,D2) if D4 has OAMONS and D3 has ORDSET and D5 has INTDOM and D2 has POLYCAT(D5,D4,D3) [3] (OutputForm,OutputForm,OutputForm) > OutputForm from OutputForm [4] (OutputForm,OutputForm) > OutputForm from OutputForm [5] OutputForm > OutputForm from OutputForm The only function that would be close is [2], but it is not a match. A workaround is to write an explicit loop that does the summation; e.g. accu := 0@...(Expression Integer,z,0) for i in 1..2 repeat accu := accu + mu^d(i)  Gaby 