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}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 



1

2
(6) 
3
(12) 
4
(3) 
5
(8) 
6
(4) 
7
(9) 
8
(15) 
9
(22) 
10
(8) 
11

12
(1) 
13

14
(2) 
15

16

17

18

19

20
(4) 
21
(4) 
22

23
(14) 
24
(4) 
25
(4) 
26

27

28

29
(2) 
30
(3) 



From: Martin Rubey <martin.rubey@un...>  20080430 13:02:50

Ralf Hemmecke <ralf@...> writes: > On 04/30/2008 02:10 PM, Martin Rubey wrote: > > In my case, I consider x and y in fact as formal power series in t > > themselves, and I think I also want that sqrt(x^2)=x. > > Replace x by the formal power series in t having only the constant term 1. I know, but (I believe that) my formal power series has positive leading coefficient. Martin 
From: Ralf Hemmecke <ralf@he...>  20080430 12:53:51

On 04/30/2008 02:10 PM, Martin Rubey wrote: > In my case, I consider x and y in fact as formal power series in t > themselves, and I think I also want that sqrt(x^2)=x. Replace x by the formal power series in t having only the constant term 1. Ralf 
From: Martin Rubey <martin.rubey@un...>  20080430 12:47:00

Dear William, Dear Waldek, many thanks for your help! I guess, the real problem is that (71) > ex := ((2*t*x*y)+(2*t*x^2))/(y*(t^2*y^4+((4*t^2)+(2*t))*x*y^3+((6*t^2)+1)*x^2*y^2+((4*t^2)+(2*t))*x^3*y+t^2*x^4)^(1/2)+t*y^3+(x*y^2)+t*x^2*y) 2  2t x y  2t x (71)  ++  2 4 2 3 2 2 2 2 3 2 4 3 2 2 y\t y + ( 4t  2t)x y + ( 6t + 1)x y + ( 4t  2t)x y + t x + t y  x y + t x y Type: Expression Integer (72) > series(ex, t=0) 2 3 2 2 3  2x y  2x  2y  2x y  2x y  2x 2 3 (72)  t +  t + O(t ) ++ ++  2 2 2 2  2 2 3 y\x y  x y y \x y  x y Type: UnivariatePuiseuxSeries(Expression Integer,t,0) is not correct in general, eg., when x*y > 0. In my case, I consider x and y in fact as formal power series in t themselves, and I think I also want that sqrt(x^2)=x. Martin 
From: Waldek Hebisch <hebisch@ma...>  20080429 19:22:11

Martin Rubey wrote: > > I'd be very grateful if somebody could look at the input file below. (Don't be > afraid, most of the definitions are not needed) > > I would have thought that bug() would yield twice the same thing. It may be a > mistake on my side, of course, but note that > > * axiom does not compute > > map(c +> sqrtrule c, series(first Phi Psi Phi [x,y,Z.2], t=0)::ULS(EXPR INT, t, 0)) > Using FriCAS I get errors. I would prefer clearer error message, but as William Sit noted, this can not really work due to zero denominators. > * neither axiom nor fricas can compute > > map(c +> sqrtrule c, series(first Phi Psi Phi [x,y,Z.2], t=0)::ULS(EXPR INT, t, 0))first Phi Psi Phi [x,y,Z2] > > > since this is actual work, I'd be extremely grateful for help! > > Martin > >  > K := ((t*y+t*x)*z*z+(t*y*y+(x*y)+t*x*x)*z+t*x*y*y+t*x*x*y) > Z := zerosOf(K, z) > > sqrtrule := rule sqrt(a^2*?b) == a*sqrt b > Z1 := map(c +> sqrtrule c, series(Z.1, t=0)::ULS(EXPR INT, t, 0))::ULS(FRAC POLY INT, t, 0) > Z2 := map(c +> sqrtrule c, series(Z.2, t=0)::ULS(EXPR INT, t, 0))::ULS(FRAC POLY INT, t, 0) > > Phi l == [l.2 * l.3/ l.1, l.2, l.3] > > Psi l == [l.1, l.1 * l.3/l.2, l.3] > >  I guess the following is a bug: >  I cannot even subtract the two! > bug() == > output map(c +> sqrtrule c, series(first Phi Psi Phi [x,y,Z.2], t=0)::ULS(EXPR INT, t, 0)) > output first Phi Psi Phi [x,y,Z2] > You may consider alternative way of doing computation: sd := x*y*sqrt(argument (kernels(numer(Z.1)::Expression Integer + t*y^2_ x*y + t*x^2).1).1/(x^2*y^2)) ZZ1 := (sd  (t*y^2 x*y + t*x^2))/(2*t*(x+y)) ZZ2 := (sd  (t*y^2 x*y + t*x^2))/(2*t*(x+y)) then series(first Phi Psi Phi [x,y,ZZ2], t=0)::ULS(EXPR INT, t, 0)_  first Phi Psi Phi [x,y,Z2] gives me 0.  Waldek Hebisch hebisch@... 
From: Martin Rubey <martin.rubey@un...>  20080429 16:01:00

I'd be very grateful if somebody could look at the input file below. (Don't be afraid, most of the definitions are not needed) I would have thought that bug() would yield twice the same thing. It may be a mistake on my side, of course, but note that * axiom does not compute map(c +> sqrtrule c, series(first Phi Psi Phi [x,y,Z.2], t=0)::ULS(EXPR INT, t, 0)) * neither axiom nor fricas can compute map(c +> sqrtrule c, series(first Phi Psi Phi [x,y,Z.2], t=0)::ULS(EXPR INT, t, 0))first Phi Psi Phi [x,y,Z2] since this is actual work, I'd be extremely grateful for help! Martin  K := ((t*y+t*x)*z*z+(t*y*y+(x*y)+t*x*x)*z+t*x*y*y+t*x*x*y) Z := zerosOf(K, z) sqrtrule := rule sqrt(a^2*?b) == a*sqrt b Z1 := map(c +> sqrtrule c, series(Z.1, t=0)::ULS(EXPR INT, t, 0))::ULS(FRAC POLY INT, t, 0) Z2 := map(c +> sqrtrule c, series(Z.2, t=0)::ULS(EXPR INT, t, 0))::ULS(FRAC POLY INT, t, 0) Phi l == [l.2 * l.3/ l.1, l.2, l.3] Psi l == [l.1, l.1 * l.3/l.2, l.3]  I guess the following is a bug:  I cannot even subtract the two! bug() == output map(c +> sqrtrule c, series(first Phi Psi Phi [x,y,Z.2], t=0)::ULS(EXPR INT, t, 0)) output first Phi Psi Phi [x,y,Z2] 
From: Francois Maltey <fmaltey@ne...>  20080425 20:55:17

Martin Rubey tests : > (1) > dot([1,2],[a,b]) > A list isn't a (linear algebra) vector. And dot (vector [1,2], vector [a,b]) seems right... 
From: Francois Maltey <fmaltey@ne...>  20080425 20:48:07

Martin Rubey replies : > I think that the interpreter should try to coerce from List to Vector. > It's not my advice... I prefer that interpreter makes almost no coerce. Coerce might be in *.spad files only... I dislike the coerce from List List R to Matrix R in the interpreter. Its place is in matrix.spad file. Coerce may be limited to obvious transformations, with the same mathematical sense. So I "always" use matrix LLR and I don't use LLR::Matrix R. But I use (Vector R)::Matrix R. In this case a new function matrix : List Vector R > Matrix R may be better. And functions horizConcat and vertConcat from List Matrix R > Matrix R. (even if reduce (horizConcat, List Matrix) is also possible... 
From: Martin Rubey <martin.rubey@un...>  20080425 18:33:58

Waldek Hebisch <hebisch@...> writes: > What do you find wrong? AFAICS everything works as designed  > the messages are not very helpful, but you can see from them > that dot needs vectors as arguments. I think that the interpreter should try to coerce from List to Vector. Martin 
From: Gabriel Dos Reis <gdr@cs...>  20080425 12:59:47

Martin Rubey <martin.rubey@...> writes: [...]  > is there any possibility to download sources for windows?   the quick answer:   svn co https://fricas.svn.sourceforge.net/svnroot/fricas/trunk fricas Or, OpenAxiom svn co https://openaxiom.svn.sf.net/svnroot/openaxiom/trunk oa.trunk The source is the same as one used to build on Unix or GNU/Linux. Once you got it, please look at oa.trunk/INSTALL for requirements. The native Windows binary is here http://downloads.sourceforge.net/openaxiom/OpenAxiom1.1.0.exe?modtime=1204184285&big_mirror=0 You can build it with just MSYS/MinGW, as you would build it on a unix/linux platform ./configure && make && make install  Gaby 
From: Arthur Ralfs <arthur@ma...>  20080424 19:04:30

Bill Page wrote: > Arthur, > > I am very glad that you intend to continue work on your webbased > interface for the Axioms! I think it is great  so far... :) > > Are there any specific points you could make concerning "what you have > in mind" versus the way the Sage "notebook" works? Have you written > any summary or sketch of what you are working toward? > > Regards, > Bill Page. > Bill, I'm thinking in terms of authoring mathematical web documents rather than making a CAS interface, which I think is a significantly different perspective, although what I have in mind can function as a CAS interface too. Such an authoring tool should be capable of producing a nice looking document and the reader may not have any interest in interacting with the CAS backend although that should be a possibility. The tool should also be suitable for producing a well documented program. I want to keep track of all commands in a tree structure and allow pruning and hiding of individual cells or whole branches and sub trees as well as rearranging of cells. In addition I want to allow input of math via a tex2mml mechanism for documentation and support for pamphlets. I imagine allowing the user to select different modes of operation, for instance scroll down mode versus stack mode, or showing all cells in the tree versus showing just the ends of the branches. There's also the question of using MathML versus jsMath. I like the MathML option because it seems to interface more naturally with the xml structure of the document and the DOM. Maybe that preference is a matter of taste but I think there's much more to be done with MathML, for instance I want to produce a content MathML package and allow for at least some conversion of MathML expressions into panAxiom commands. In conjunction with the xhtml interface I'm also interested in developing an XUL extension for Firefox. XUL has the advantage of being much more suited to designing a GUI than xhtml. I had a basic XUL extension for sending and displaying commands set up under Firefox 1.5 but it broke under 2.0 and I haven't gotten back to it yet. These are some of my thoughts but as I work on this project more keep coming up. Finally what it really comes down to is that this is way too interesting to drop in favour of somebody else's project unless they totally obviated everything I want to do. I reiterate that it's unlikely one interface is going to be right for everybody. We have the command line with ASCII art, emacs mode, TeXmacs, and William Stein says that it should be possible in the near future to separate the Sage interface from Sage to provide an interface for panAxiom. I'm focussed on the web interface but some people will prefer a traditional desktop application. It looks like there'll be something for everybody. Arthur > On Wed, Apr 23, 2008 at 11:19 PM, Arthur Ralfs <arthur@...> wrote: > >> After taking a look at the sage web interface I plan to continue with my >> own plans. The sage interface looks very good and well developed but >> is not what I have in mind. >> >> I comment that I think it is unlikely that one interface will be optimal >> for everybody. >> >> > > 
From: Bill Page <bill.page@ne...>  20080424 12:13:32

Arthur, I am very glad that you intend to continue work on your webbased interface for the Axioms! I think it is great  so far... :) Are there any specific points you could make concerning "what you have in mind" versus the way the Sage "notebook" works? Have you written any summary or sketch of what you are working toward? Regards, Bill Page. On Wed, Apr 23, 2008 at 11:19 PM, Arthur Ralfs <arthur@...> wrote: > After taking a look at the sage web interface I plan to continue with my > own plans. The sage interface looks very good and well developed but > is not what I have in mind. > > I comment that I think it is unlikely that one interface will be optimal > for everybody. > 
From: Gabriel Dos Reis <gdr@in...>  20080424 07:45:01

On Wed, Apr 23, 2008 at 10:19 PM, Arthur Ralfs <arthur@...> wrote: > After taking a look at the sage web interface I plan to continue with my > own plans. The sage interface looks very good and well developed but > is not what I have in mind. > > I comment that I think it is unlikely that one interface will be optimal > for everybody. > > Arthur Thanks for taking the time to make the assessment. OpenAxiom isn't committed to any particular interface, so your work is most welcome. Thanks!  Gaby 
From: Arthur Ralfs <arthur@ma...>  20080424 03:19:38

After taking a look at the sage web interface I plan to continue with my own plans. The sage interface looks very good and well developed but is not what I have in mind. I comment that I think it is unlikely that one interface will be optimal for everybody. Arthur 
From: Michael.Abshoff <michael.abshoff@go...>  20080423 21:34:50

root wrote: > Gary, Hi Tim, > If you're interested in exploring Axiom's type system > the best source of material available is the Jenk's book. > It would be useful if Sage's type hierarchy was close to > the one Axiom uses, making it possible to share algorithms. > If you'll mail me a postal address (offline), > I'll send you a copy of the book. according to http://www.axiomdeveloper.org/axiomwebsite/currentstate.html the "Axiom book" by Jenks is part of Axiom's documentation. Is that correct? > Tim Cheers, Michael > > ~~~~~~~~~ > To post to this group, send email to sagedevel@... > To unsubscribe from this group, send email to sagedevelunsubscribe@... > For more options, visit this group at http://groups.google.com/group/sagedevel > URLs: http://www.sagemath.org > ~~~~~~~~~ > > 
From: Bill Page <bill.page@ne...>  20080423 20:41:17

On Wed, Apr 23, 2008 at 4:33 PM, Martin Rubey wrote: > > Bill Pagewrites: > > > > Why on earth is it interpreting [a,b] as List OrderedVariableList [a,b]? > > > That doesn't make sense! > > > > > > > Why not? Again what would you expect? > > > > (4) > [a,b] > > > > (4) [a,b] > > Type: List OrderedVariableList [a,b] > > > > Off hand this seems like a reasonably conservative choice to me. :) > > Oh dear, you got me there! Well, OK. > Seriously. I think the interpreter usually tries starts by making the most conservative choice of type possible, i.e. it uses the "smallest" type that includes the object of interest. That is why for example: (9) > 1 (9) 1 Type: PositiveInteger (10) > 0 (10) 0 Type: NonNegativeInteger (11) > 1 (11)  1 Type: Integer (12) > Then it tries to use the minimum number of coercions necessary to expand the possibilities until a mode match is found. At least that is how I have come to intuitively understand the algorithm. Regards, Bill Page. 
From: Martin Rubey <martin.rubey@un...>  20080423 20:33:34

"Bill Page" <bill.page@...> writes: > > Why on earth is it interpreting [a,b] as List OrderedVariableList [a,b]? > > That doesn't make sense! > > > > Why not? Again what would you expect? > > (4) > [a,b] > > (4) [a,b] > Type: List OrderedVariableList [a,b] > > Off hand this seems like a reasonably conservative choice to me. :) Oh dear, you got me there! Well, OK. Martin 
From: Bill Page <bill.page@ne...>  20080423 20:21:30

On Wed, Apr 23, 2008 at 4:11 PM, Martin Rubey wrote: Bill Page writes: > > > Are you saying that it should not be necessary to give the > > interpreter such mode hints? > > Not quite sure, but I'd say: no! > Ok. > [...] > > it doesn't try the natural thing: coercing List POLY INT to Vector > POLY INT, even though it is looking at the right modemap... > > It would be great if somebody could try to *really* understand that > algorithm! (Only guessing: there is currently no coerce: > List D > Vector D) > That seems likely. It seems to be called 'vector' (8) > vector([a,b]) (8) [a,b] Type: Vector OrderedVariableList [a,b] Maybe it should really be called coerce. > > Why on earth is it interpreting [a,b] as List OrderedVariableList [a,b]? > That doesn't make sense! > Why not? Again what would you expect? (4) > [a,b] (4) [a,b] Type: List OrderedVariableList [a,b] Off hand this seems like a reasonably conservative choice to me. :) Regards, Bill Page. 
From: Martin Rubey <martin.rubey@un...>  20080423 20:11:21

"Bill Page" <bill.page@...> writes: > Martin, > Are you saying that it should not be necessary to give the interpreter > such mode hints? Not quite sure, but I'd say: no! In any case, look again what the interpreter is doing: (1) > l1: List POLY INT := [a,b]; l2: List POLY INT := [x,y]; Type: List Polynomial Integer (2) > )se me bo on (2) > dot(l1,l2) Function Selection for dot Arguments: (LIST POLY INT,LIST POLY INT) > no appropriate dot found in List Polynomial Integer > no appropriate dot found in Polynomial Integer > no appropriate dot found in List Polynomial Integer > no appropriate dot found in Polynomial Integer Modemaps from Associated Packages no modemaps Remaining General Modemaps [1] (D,D) > D1 from D if D has VECTCAT D1 and D1 has TYPE and D1 has RING [2] (D,D) > D1 from D if D has DIRPCAT(D2,D1) and D1 has TYPE and D1 has RING > no appropriate dot found in Vector Polynomial Integer > no function dot found for arguments (LIST POLY INT,LIST POLY INT) [...] it doesn't try the natural thing: coercing List POLY INT to Vector POLY INT, even though it is looking at the right modemap... It would be great if somebody could try to *really* understand that algorithm! (Only guessing: there is currently no coerce: List D > Vector D) Apart from that: (1) > dot([1,2],[a,b]) There are 2 exposed and 2 unexposed library operations named dot having 2 argument(s) but none was determined to be applicable. Use HyperDoc Browse, or issue )display op dot 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 dot with argument type(s) List PositiveInteger List OrderedVariableList [a,b] Perhaps you should use "@" to indicate the required return type, or "$" to specify which version of the function you need. Why on earth is it interpreting [a,b] as List OrderedVariableList [a,b]? That doesn't make sense! Martin 
From: Waldek Hebisch <hebisch@ma...>  20080423 20:01:22

Martin Rubey wrote: > > I'm currently wondering about the message below. Is this a known misfeature of > the type inference algorithm? > > Martin > > (1) > dot([1,2],[a,b]) > There are 2 exposed and 2 unexposed library operations named dot > having 2 argument(s) but none was determined to be applicable. > Use HyperDoc Browse, or issue > )display op dot > 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 dot > with argument type(s) > List PositiveInteger > List OrderedVariableList [a,b] > > Perhaps you should use "@" to indicate the required return type, > or "$" to specify which version of the function you need. > > (1) > l1: List POLY INT := [a,b]; l2: List POLY INT := [x,y]; > > Type: List Polynomial Integer > (2) > )se me bo on > (2) > dot(l1,l2) > > Function Selection for dot > Arguments: (LIST POLY INT,LIST POLY INT) > > no appropriate dot found in List Polynomial Integer > > no appropriate dot found in Polynomial Integer > > no appropriate dot found in List Polynomial Integer > > no appropriate dot found in Polynomial Integer > > Modemaps from Associated Packages > no modemaps > > Remaining General Modemaps > [1] (D,D) > D1 from D > if D has VECTCAT D1 and D1 has TYPE and D1 has RING > [2] (D,D) > D1 from D > if D has DIRPCAT(D2,D1) and D1 has TYPE and D1 has RING > > no appropriate dot found in Vector Polynomial Integer > > no function dot found for arguments (LIST POLY INT,LIST POLY INT) > [...] > What do you find wrong? AFAICS everything works as designed  the messages are not very helpful, but you can see from them that dot needs vectors as arguments. If I do: l1 := vector [1, 2] l2 := (vector [x,y]) :: Vector POLY INT dot(l1, l2) I get: (5) 2y + x Type: Polynomial Integer as expected.  Waldek Hebisch hebisch@... 
From: Bill Page <bill.page@ne...>  20080423 19:56:16

Martin, On Wed, Apr 23, 2008 at 3:47 PM, you wrote: > > I'm currently wondering about the message below. Is this a known > misfeature of the type inference algorithm? > > (1) > dot([1,2],[a,b]) > ... I am not really sure what you were expecting. Perhaps something like this? (1) > )di op dot There are 2 exposed functions called dot : [1] (D,D) > D1 from D if D has VECTCAT D1 and D1 has TYPE and D1 has RING [2] (D,D) > D1 from D if D has DIRPCAT(D2,D1) and D1 has TYPE and D1 has RING There are 3 unexposed functions called dot : [1] (Point DoubleFloat,Point DoubleFloat) > DoubleFloat from TubePlotTools [2] (OutputForm,NonNegativeInteger) > OutputForm from OutputForm [3] OutputForm > OutputForm from OutputForm (1) > [1,2]::Vector ? (1) [1,2] Type: Vector PositiveInteger (2) > [a,b]::Vector ? (2) [a,b] Type: Vector OrderedVariableList [a,b] (3) > dot([1,2]::Vector ?,[a,b]::Vector ?) (3) 2b + a Type: Polynomial Integer (4) >  Are you saying that it should not be necessary to give the interpreter such mode hints? Regards, Bill Page. 
From: Martin Rubey <martin.rubey@un...>  20080423 19:47:02

I'm currently wondering about the message below. Is this a known misfeature of the type inference algorithm? Martin (1) > dot([1,2],[a,b]) There are 2 exposed and 2 unexposed library operations named dot having 2 argument(s) but none was determined to be applicable. Use HyperDoc Browse, or issue )display op dot 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 dot with argument type(s) List PositiveInteger List OrderedVariableList [a,b] Perhaps you should use "@" to indicate the required return type, or "$" to specify which version of the function you need. (1) > l1: List POLY INT := [a,b]; l2: List POLY INT := [x,y]; Type: List Polynomial Integer (2) > )se me bo on (2) > dot(l1,l2) Function Selection for dot Arguments: (LIST POLY INT,LIST POLY INT) > no appropriate dot found in List Polynomial Integer > no appropriate dot found in Polynomial Integer > no appropriate dot found in List Polynomial Integer > no appropriate dot found in Polynomial Integer Modemaps from Associated Packages no modemaps Remaining General Modemaps [1] (D,D) > D1 from D if D has VECTCAT D1 and D1 has TYPE and D1 has RING [2] (D,D) > D1 from D if D has DIRPCAT(D2,D1) and D1 has TYPE and D1 has RING > no appropriate dot found in Vector Polynomial Integer > no function dot found for arguments (LIST POLY INT,LIST POLY INT) [...] 
From: Martin Rubey <martin.rubey@un...>  20080423 19:35:34

"Gary Furnish" <gfurnish@...> writes: > I'd be interested in hearing which features of FriCAS/OpenAxiom has that > might be useful in more detail. I'm not quite sure what you are interested in. I attach some things that I know to be working well or that I used recently below. > My main technical concerns are that anything interacting through a pexpect > interface is going to be slow and will not interact with Sage's internal > coercion system (aside from the fact that adding another dependency to the > standard core increases code complexity for symbolics dramatically). I > downloaded FriCAS to try to investigate, but I couldn't find a good > introduction to the high level structure of the FriCAS code (at the file > level). Does such a thing exist? I'll restrict myself to the algebra, i.e., the part that contains the math algorithms. Waldek already posted the more general structure. The algebra is located in the files src/algebra/*.spad.pamphlet. The name "pamphlet" is (in my opinion) an accident and really should be "nw" for noweb. There are several ways to investigate the algebra: 1) the axiom book by Jenks & Sutor 2) hyperdoc 3) )wh th xxx (that is, )what things xxx) I usually start with 3. See an example of my workflow below. But I think it's better to start with the principal concept of types in FriCAS/OpenAxiom, since I have no idea how much this matches Sage's idea of type. Below I'll write only FriCAS, but that's the same for all members of the Axiom family and also for Aldor, of course. FriCAS is statically typed. At all time, every object must have a type. In order to make FriCAS usable, it comes with an "intelligent" interpreter, that tries to "guess" a reasonable type for user input. The algorithm is relatively transparent and general, and can be easily overridden. Types come in 3 flavours: an object can be * a category (eg., Field, Monoid, MultivariateTaylorSeriesCategory) Important note: the concept "category" has (in my opinion) only superficially to do with mathematical categories. Rather, they state which operations a domain satisfying the category has to provide. * a domain (eg., Integer, Float, List Integer, Matrix Complex Expression Integer, etc.) * a member of a Domain (say, an integer like 3, a float like 2.7, a list of integers, a Taylor series, etc.) In principle, a function (which is a member of the domain Mapping) can return an object of any type. This ideal is not quite reached in FriCAS, but completely implemented in Aldor. Now, to explore FriCAS algebra, you need to have an idea what you are interested in. I believe, the best way is to look at some domains: go to HyperDoc, browse, enter the name of a domain, eg., Set, click on "domains", then a short description of Set should appear and a link named SET.spad. Click on it, if your FriCAS is correctly installed, some sort of editor or pager should open with the source code of set in it. Files ending with "cat.spad.pamphlet" contain most of the categories. There are some other naming schemas which are less consequent, like int*.spad.pamphlet for integration. I cannot claim to know all of the algebra. I'd say I know roughly 20 percent  mainly polynomials, matrices, and bits and pieces of expressions. I guess that a considerably large part deals with "Expressions": (I omit .spad.pamphlet. WARNING: this list is probably incomplete and erroneous.) the domain (and related domains) itself: fspace, expr, combfunc, kl, liouv, elemntry, trigcat integration: defintef, defintrf, efstruc, intaf, intalg, intaux, intef, integrat, intpm, intrf, irexpand, laplace, rdesys, rderf, rdeef series: efuls, efupxs, elfuts, expr2ups, fs2expxp, fs2ups limits: limitps (Gruntz has been implemented by Waldek, but is not integrated yet) ODEs: exprode pattern matching: pattern, patmatch1, patmatch2 operators on expressions: op drawing: draw, drawopt, drawpak solving: transsolve Is such a list what you had in mind? Does this answer your question? Martin Recently I needed to do calculus with operators. In the following I separate comments from FriCAS in/output with lines full of "". I said:  (1) > )wh th operator Operations whose names satisfy the above pattern(s): constantOperator operator operators quotedOperators To get more information about an operation such as operators , issue the command )display op operators  Categories  Categories with names matching patterns: operator LODOCAT LinearOrdinaryDifferentialOperatorCategory MLO MonogenicLinearOperator  Domains  Domains with names matching patterns: operator BOP BasicOperator LODO LinearOrdinaryDifferentialOperator LODO1 LinearOrdinaryDifferentialOperator1 LODO2 LinearOrdinaryDifferentialOperator2 LODOCAT LinearOrdinaryDifferentialOperatorCategory& MODOP ModuleOperator OMLO OppositeMonogenicLinearOperator OP Operator  Packages  Packages with names matching patterns: operator BOP1 BasicOperatorFunctions1 COMMONOP CommonOperators LODOF LinearOrdinaryDifferentialOperatorFactorizer LODOOPS LinearOrdinaryDifferentialOperatorsOps NCODIV NonCommutativeOperatorDivision RECOP RecurrenceOperator  System Commands for User Level: development  No system commands at this level matching patterns: operator  System Command Synonyms  No userdefined synonyms satisfying patterns: operator  Then I used HyperDoc to browse the individual documentation. It turned out that the domain "Operator" provided, what I wanted: ++ Description: Algebra of ADDITIVE operators over a ring. (unfortunately, I cannot show HyperDoc in action here...) In my case, I wanted to play with shift operators, acting on arbitrary expressions. I won't go into details, rather just show an example:  (1) > )read /tmp/axiom160050CN.input L: OP(EXPR INT) := operator 'L (1) L Type: Operator Expression Integer evaluate(L, ex +> eval(ex, 'l, 'l+1))$OP(EXPR INT) (2) L Type: Operator Expression Integer N: OP(EXPR INT) := operator 'N (3) N Type: Operator Expression Integer evaluate(N, ex +> eval(ex, 'n, 'n+1))$OP(EXPR INT) (4) N Type: Operator Expression Integer op := L^2*N  q*L*N  q*L + q^2 + q^(l+1) l + 1 2 2 (5) q + q  q L  q L N + L N Type: Operator Expression Integer p := operator 'p (6) p Type: BasicOperator op p(n,l) (7) l + 1 2 p(n,l)q + p(n + 1,l + 2)  q p(n + 1,l + 1)  q p(n,l + 1) + q p(n,l) Type: Expression Integer  some showoffs: try: (axiom is *very* good at indefinite elementary integration. it is currently not very good at definite integration.  f := (x^21)/x + 1/(x+exp x) g := D(exp(f)/exp(x),x) integrate(g, x)  types are useful: (note that the determinant uses the correct multiplication method)  (8) > )read /tmp/axiom16005BNT.input l := [2,1] (8) [2,1] Type: List PositiveInteger p := partition(l)$Partition (9) (2 1) Type: Partition m := matrix [[complete(l.jj+i) for j in 1..#l] for i in 1..#l] + 1 1 2 +   (2) +  (1 ) []   2 2  (10)   1 1 1 3   (3) +  (2 1) +  (1 ) (1) +3 2 6 + Type: Matrix SymmetricPolynomial Fraction Integer output m + 1 1 2 +   (2) +  (1 ) []   2 2    1 1 1 3   (3) +  (2 1) +  (1 ) (1) +3 2 6 + Type: Void determinant m 1 1 3 (12)   (3) +  (1 ) 3 3 Type: SymmetricPolynomial Fraction Integer  multivariate Taylor series work well:  (19) > )read /tmp/axiom16005orl.input X := monomial(1, x, 1)$TaylorSeries Fraction Integer (19) x Type: TaylorSeries Fraction Integer Y := monomial(1, y, 1)$TaylorSeries Fraction Integer (20) y Type: TaylorSeries Fraction Integer sin(X+Y) (21) 1 3 1 2 1 2 1 3 (y + x) + (  y   x y   x y   x ) 6 2 2 6 + 1 5 1 4 1 2 3 1 3 2 1 4 1 5 ( y +  x y +  x y +  x y +  x y +  x ) + O(6) 120 24 12 12 24 120 Type: TaylorSeries Fraction Integer  guessing: (22) > l := [1,1,q+1,q^3+q*q+2*q+1,q^6+q^5+2*q^4+3*q^3+3*q*q+3*q+1,q^10+q^9+2*q^8+3*q^7+5*q^6+5*q^5+7*q^4+7*q^3+6*q*q+4*q+1]; Type: List Polynomial Integer (23) > guessADE(q)(l, maxPower==2) n (23) [[function= [[x ]f(x):  x f(x)f(q x) + f(x)  1= 0],order= 0]] Type: List Record(function: Expression Integer,order: NonNegativeInteger) (24) > guessBinRat [1,1,k+1,(3*k*k+5*k+2)/2,(8*k**3+18*k*k+13*k+3)/3] (k + 1)n (k + 1)n + 1 ( ) ( ) n n (24) [[function= ,order= 0],[function= ,order= 0]] k n + 1 (k + 1)n + 1 Type: List Record(function: Expression Integer,order: NonNegativeInteger) 
From: Bill Page <bill.page@ne...>  20080423 19:12:53

2008/4/23 Waldek Hebisch wrote: > ... > For FriCAS in longer run dropping Lisp is likely  most Lisp code > is machine generated during FriCAS build. With enough effort we > could directly generate C code. Currently effort to drop Lisp would > be prohibitive, but the FriCAS code is constanly cleaned up and > simplified so in the future such change will be much easier. > I have a question that might at first seem heretical, but I think that the answer might possibly be of some interest to the Sage developers... Both you and Gaby have discussed the possibility of defining an abstract machine (aka. runtime system) to replace the role that Lisp plays for Axiom. We also know that Aldor has already defined such a machine called FOAM. FOAM can be implemented either in Lisp (for interface with Axiom) or by a runtime system written entirely in C for stand alone use. In fact this strategy is quite common and we here a lot for example about the Java Virtual Machine. Now it turns out that Python also has this notion of an abstract virtual machine that is the target for the Python interpreter. There are already some languages other than Python that can produce low level code for the Python virtual machine. I believe that the current Python virtual machine would very likely be adequate to support the run time requirements of Axiom/Aldor. So my question is: Is there be any possibility and interest in producing either an Axiom/Spad or Aldor compiler that targets this same virtual machine? In principle (and I admit that this is a big leap) this would allow complete interoperability between Sage and Axiom or Aldor. Perhaps you have other ideas about how to achieve this kind of interoperability? I could imagine for example linking Python directly into the Aldor C runtime system or maybe linking the Python into the lisp image that runs Axiom? What do you think? Is this crazy? Regards, Bill Page. 
From: Bill Page <bill.page@ne...>  20080423 18:52:08

On Wed, Apr 23, 2008 at 1:48 PM, Gary Furnish wrote: > ... > Right now, most functionality of the sage.calculus module is dictated > strictly by how maxima is designed. As we move to our own internal > representation, this obviously will not be sufficient. It is not immediately obvious to me that this is not sufficient. To decide it might first be necessary to define more carefully exactly what you want to be able to do in Sage. > I'd be interested in hearing which features of FriCAS/OpenAxiom has > that might be useful in more detail. Here is a very short and personally biased summary: I think a big difference between Maxima and Sage is that Maxima is *untyped* or rather, there is really only one type of object in Maxima  an expression  while Sage attempts to treat objects as belonging to different mathematical categories. For example: a Polynomial is built over some coefficient Ring, etc. Sage is like Axiom in this respect. On the other hand Axiom has a domain called 'Expression' which fits into the overall mathematical category struture in a welldefined manner, i.e. it consists of a formal extension of the rational functions (Fraction Polynomial). The Expression domain is very different from simply being a "symbolic expression" in the sense used in Maxima. Axiom has another domain called InputForm which is much more like Maxima's symbolic expressions but in Axiom it is used only for the internal representation of input to the interpreter. Very little expression manipulation occurs in Axiom at this level although some people have argued that Axiom should have better support of doing this sort of thing. Closely related to this is another set of domains in Axiom related to pattern matching in Expression and other less highly structured symbolic domains. > My main technical concerns are that anything interacting > through a pexpect interface is going to be slow and will not > interact with Sage's internal coercion system (aside from the > fact that adding another dependency to the standard core > increases code complexity for symbolics dramatically). Could you explain more about why you say this will not (can not?) interact with Sage's coercion system? > I downloaded FriCAS to try to investigate, but I couldn't > find a good introduction to the high level structure of the > FriCAS code (at the file level). Does such a thing exist? > Do you really mean "structure of the code at the file level" or do you want something more conceptual? For example: Have you looked at the Axiom book (a little over 1000 pages). Chapters 11, 12 and 13 describe the tools used to build the Axiom library. Have you tried hyperdoc to navigate the mathematical structure? If you really mean "at the file level", the files that you will probably care most about are those found in the src/algebra directory. Regards, Bill Page. 
From: Bill Page <bill.page@ne...>  20080423 15:54:53

On Wed, Apr 23, 2008 at 4:28 AM, Michael.Abshoff wrote: > > Martin Rubey wrote: > > > I do not see how the problem of differing representations can be > > resolved. Up to now I thought that Sage simply doesn't have an > > "internal" representation, and just uses the one from the external > > program  that's how my polymake interface for FriCAS/Axiom > > works. > > I am not 100% clear, but I believe for elements in a symbolic ring > we do not yet have a Sage internal representation. It is being written > in Cython since arithmetic is probably slowed down by a factor of > 10,000 by using pexpect+Maxima. That is largely the fault of pexpect. > I think that what Martin means is that if Sage has it's own internal representation of something then the problem of converting from one representation to another is unavoidable if the symbolic manipulation is done by an external program. This is independent of whether one uses the pexpect interface or not. Of course if symbolic manipulation is implemented in the Sage interpreter or compiled Cython code, then this conversion may not be necessary. However it is sometimes convenient also to change the internal representation depending on the type of manipulation to be done. So far as I can see Sage does have an internal representation for "Symbolic Ring". But the idea of a "Symbolic Ring" seems very strange to me. What is this from a mathematical point of view? How is it different from, say, a polynomial? Do you really mean that the variables of the ring do not commute as in the sense of a free algebra? http://en.wikipedia.org/wiki/Free_algebra I worry sometimes that the Sage type system is a little too ad hoc... :( Anyway, here is an example computation that includes conversion from the internal Sage representation to the internal Axiom representation of a symbolic object: root@...:~# sage   SAGE Version 3.0, Release Date: 20080422   Type notebook() for the GUI, and license() for information.   sage: # Construct some symbolic expression in Sage sage: var('a b c d') (a, b, c, d) sage: A = matrix([[a,b],[c,d]]) sage: A [a b] [c d] sage: x=det(A) sage: x a*d  b*c sage: x.parent() Symbolic Ring sage: x? Type: SymbolicArithmetic Base Class: <class 'sage.calculus.calculus.SymbolicArithmetic'> String Form: a d  b c Namespace: Interactive Docstring: Represents the result of an arithmetic operation on f and g. sage: # Convert it to an object in Axiom sage: y=axiom(x) sage: y a*d+(b*c) sage: y.type() Polynomial Integer sage: y? Type: AxiomElement Base Class: <class 'sage.interfaces.axiom.AxiomElement'> String Form: a*d+(b*c) Namespace: Interactive Docstring: a*d+(b*c) > ... > So: What should you do: > > a) wait a week or two for ecls and gdbm to become optional > b) build an optional FriCAS/OpenAxiom spkg using ecls > c) write a pexpect interface to use integration/ODE/guess if that > is something where you see FriCAS/OpenAxiom as "better > than anything else". > > In parallel take a look at > > http://wiki.sagemath.org/spkg/InclusionProcedure > > and write some proposal *why* FriCAS/OpenAxiom should become > part of standard Sage and *what* it should/can [via pexpect] do. > ... Martin I would be interested in working with you on doing this (and anyone else who would like to join in), that is provided you are willing to take the lead. :) > Then eventually it will come down to the vote and if for example > FriCAS beats Maxima and the 4Ms at integration I would consider > it very like that it could make it in. FriCAS full [without gcl] weighs > in at 9MB, so if you can strip out unneeded parts for an initial bare > bone distribution it would be great. > Do you mean, for example eliminating the hyperdoc browser and Axiom graphics? I think that trying to eliminate mathematical functionality is not likely to save much in a "bare bones" distribution. Regards, Bill Page. 