Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

## open-axiom-help — Discussions about uses of OpenAxiom

You can subscribe to this list here.

 2008 2009 2010 2011 2012 2013 2014 Jan (4) Feb (2) Mar Apr May Jun Jul Aug (2) Sep Oct (27) Nov Dec (6) Jan (3) Feb Mar Apr (1) May Jun (27) Jul Aug Sep (3) Oct (22) Nov (12) Dec Jan (11) Feb (3) Mar (2) Apr (11) May (29) Jun (59) Jul Aug (3) Sep (2) Oct (8) Nov (3) Dec Jan (5) Feb Mar Apr (6) May Jun Jul (13) Aug (4) Sep (4) Oct (19) Nov Dec (2) Jan (2) Feb (1) Mar (3) Apr May Jun Jul (1) Aug Sep Oct Nov Dec Jan Feb Mar Apr May (78) Jun (10) Jul Aug Sep Oct Nov Dec (2) Jan (2) Feb Mar Apr May Jun Jul Aug Sep Oct 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)

Showing 11 results of 11

 Re: [open-axiom-help] series composition From: Gabriel Dos Reis - 2010-01-31 15:46:12 ```Kostas Oikonomou 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 ```
 Re: [open-axiom-help] problem with series reversion From: Gabriel Dos Reis - 2010-01-31 15:37:03 ```Kostas Oikonomou 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 ```
 Re: [open-axiom-help] problem with series reversion From: Kostas Oikonomou - 2010-01-30 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 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 ```
 Re: [open-axiom-help] problem with series reversion From: Gabriel Dos Reis - 2010-01-28 16:34:13 ```Kostas Oikonomou 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 ```
 Re: [open-axiom-help] problem with series reversion From: Gabriel Dos Reis - 2010-01-28 16:17:38 ```Gabriel Dos Reis writes: | Kostas Oikonomou 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 ```
 Re: [open-axiom-help] problem with series reversion From: Gabriel Dos Reis - 2010-01-28 16:11:54 ```Kostas Oikonomou 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 ```
 [open-axiom-help] problem with series reversion From: Kostas Oikonomou - 2010-01-20 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 ```
 Re: [open-axiom-help] question about recursive definition From: Gabriel Dos Reis - 2010-01-11 11:40:59 ```Gabriel Dos Reis 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/((k-m)*a(1)) * sum(((m+1)*i-(k-m))*a(i+1)*A(k-i,m), i=1..k-m) | 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 anti-derivative 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,m|km) == s : EXPR INT := 0 for i in 1..(k-m) repeat s := s + ((m+1) * i - (k-m)) * a(i+1) * A(k-i, m) 1/((k-m)*a(1)) * s ```
 Re: [open-axiom-help] question about recursive definition From: Gabriel Dos Reis - 2010-01-11 09:32:35 ```Kostas Oikonomou 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,m|k A(k,m|k=m) == a(1)^m; | | Type: Void | (4) -> A(k,m|k>m) == 1/((k-m)*a(1)) * | sum(((m+1)*i-(k-m))*a(i+1)*A(k-i,m), i=1..k-m); | | 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 | package-calling 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 | package-calling 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 "km" 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/((k-m)*a(1)) * sum(((m+1)*i-(k-m))*a(i+1)*A(k-i,m), i=1..k-m) 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 super-domain 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 sub-expression "(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 sub-expression 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 ```
 [open-axiom-help] question about recursive definition From: Kostas Oikonomou - 2010-01-11 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,m|k A(k,m|k=m) == a(1)^m; Type: Void (4) -> A(k,m|k>m) == 1/((k-m)*a(1)) * sum(((m+1)*i-(k-m))*a(i+1)*A(k-i,m), i=1..k-m); 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 package-calling 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 package-calling 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 "km" 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 ```
 Re: [open-axiom-help] sum with power series From: Gabriel Dos Reis - 2010-01-08 16:02:16 ```Kostas Oikonomou 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 ```

Showing 11 results of 11