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

9

10

11

12
(2) 
13

14
(19) 
15
(1) 
16
(3) 
17
(2) 
18

19

20

21

22

23

24

25

26

27

28

29

30

31


From: Stephen MontgomerySmith <stephen@ma...>  20081017 23:04:50

Gabriel Dos Reis wrote: > On Thu, Oct 16, 2008 at 4:19 PM, Stephen MontgomerySmith > <stephen@...> wrote: >> So the reason I am asking this is so that I persuade axiom to write x^y as >> Pow(x,y) (i.e. make it more C friendly). >> >> >> So I did this: >> Pow:=operator 'Pow >> powerrule := rule x^y == Pow(x,y) >> >> >> Then I get good results with this: >> >> powerrule(sqrt(x+y))::InputForm >> gives Pow(y + x,1/2) >> >> But then I was rather surprised at this: >> >> powerrule(81) >> gives Pow(3,Pow(2,2)) >> >> It seems that its attempts to deconstruct '81' are rather aggressive. > > Pattern matching in OpenAxiom is semantics based, as opposed to being > just syntactical. That explains the decomposition of 81. I do not > think we have a purely syntactic rewrite system at the moment. > >> Then I tried this: >> Mult:=operator 'Mult >> multrule := rule x^y == Mult(x,y) >> >> The results here are inconsistent: >> multrule(6) >> gives 6 >> but >> multrule(81) >> as I would (now) expect gives Mult(3,Mult(2,2)) > > Hmm, I'm not clear on why the result is inconsistent. As far as I can see > 'Pow' was replaced by 'Mult'. Am I overlooking something? My mistake. I meant Mult:=operator 'Mult multrule := rule x*y == Mult(x,y) I would expect multrule(6) to give the prime factorization, but it doesn't. 
From: Gabriel Dos Reis <gdr@in...>  20081017 15:50:12

On Thu, Oct 16, 2008 at 4:19 PM, Stephen MontgomerySmith <stephen@...> wrote: > So the reason I am asking this is so that I persuade axiom to write x^y as > Pow(x,y) (i.e. make it more C friendly). > > > So I did this: > Pow:=operator 'Pow > powerrule := rule x^y == Pow(x,y) > > > Then I get good results with this: > > powerrule(sqrt(x+y))::InputForm > gives Pow(y + x,1/2) > > But then I was rather surprised at this: > > powerrule(81) > gives Pow(3,Pow(2,2)) > > It seems that its attempts to deconstruct '81' are rather aggressive. Pattern matching in OpenAxiom is semantics based, as opposed to being just syntactical. That explains the decomposition of 81. I do not think we have a purely syntactic rewrite system at the moment. > > Then I tried this: > Mult:=operator 'Mult > multrule := rule x^y == Mult(x,y) > > The results here are inconsistent: > multrule(6) > gives 6 > but > multrule(81) > as I would (now) expect gives Mult(3,Mult(2,2)) Hmm, I'm not clear on why the result is inconsistent. As far as I can see 'Pow' was replaced by 'Mult'. Am I overlooking something?  Gaby 
From: Stephen MontgomerySmith <stephen@ma...>  20081016 21:19:48

So the reason I am asking this is so that I persuade axiom to write x^y as Pow(x,y) (i.e. make it more C friendly). So I did this: Pow:=operator 'Pow powerrule := rule x^y == Pow(x,y) Then I get good results with this: powerrule(sqrt(x+y))::InputForm gives Pow(y + x,1/2) But then I was rather surprised at this: powerrule(81) gives Pow(3,Pow(2,2)) It seems that its attempts to deconstruct '81' are rather aggressive. Then I tried this: Mult:=operator 'Mult multrule := rule x^y == Mult(x,y) The results here are inconsistent: multrule(6) gives 6 but multrule(81) as I would (now) expect gives Mult(3,Mult(2,2)) 
From: Gabriel Dos Reis <gdr@in...>  20081016 03:40:36

On Wed, Oct 15, 2008 at 6:52 PM, Stephen MontgomerySmith <stephen@...> wrote: > I am trying to get axiom to accept the input "f(x)" as meaning "an > unspecified function f applied to the variable x". I looked briefly > through the documentation at > http://www.axiomdeveloper.org/axiomwebsite/documentation.html, but I > am not seeing which section to look at. I can see how to create > functions that do something, but not variable functions. > > > (1) > f(x) > There are no library operations named f > Use HyperDoc Browse or issue > )what op f > to learn if there is any operation containing " f " in its name. > > Cannot find a definition or applicable library operation named f > with argument type(s) > Variable x > > Perhaps you should use "@" to indicate the required return type, > or "$" to specify which version of the function you need. Dear Stephen, The AXIOM family systems differ from the traditional computer algebra systems in that it insists on working on values of some datatype (called domain). What this entails is that every expression is evaluated to a normal form defined by some domain of computation. Specifically, it means that in f(x) OpenAxiom insists that 'f' must be belongs to a domain of computation that can evaluate `f(x)' to some value. The fundamental way that OpenAxiom does that is to start type checking the arguments (and evaluate them where necessary) so that it gets a guidance on how 'f' should be evaluated, therefore the whole expression. The system starts with 'x', and see that there is no declaration for `x'. So, it concludes that 'x' is a value of type Variable x  meaning a variable named x. Next, it tries to figure out whether there is any function named 'f' that can accept a value of type Variable x. It can't find any. Consequently, it declares that the expression 'f(x)' is not meaningful. Hence the error. If OpenAxiom were a symbolic computation system where the fundamental basic datatype is abstract syntax tree (AST), then it would just automatically decide that f(x) is a call to an unspecified function 'f' with unspecified argument 'x'. On the other hand, OpenAxiom (and all systems in the AXIOM family) does have a parameterized domain to support some form of symbolic computation called Expression. Since you think of `f' as a unspecified function, the first thing to do is to tell the interpreter that `f' does stand for an operator (which will be called 'f' for the moment). f := operator 'f so that now 'f' belows to the BasicOperator domain of computation. Next, there is a `function call' operator elt: (BasicOperator, %) > % from the Expression domain of computation that makes an Expression out of a operator applied to another Expression. However, 'x' does not seem to belong to that domain. But,there is an implicit conversion that can take the symbol 'x' into the Expression(Integer) domain, so that the expression f(x) possesses an interpretation in the domain of computation Expression(Integer). Now, Expression(Integer) is a domain that furnishes the basic operations you would need to conduct some form of `symbolic computation' as found in other computer algebra systems (though obviously, there are things that Expression does not do well). I hope you find this explanation useful to get you started with the philosophy behind OpenAxiom and the AXIOM family systems.  Gaby 
From: Bill Page <bill.page@ne...>  20081016 00:47:34

Stephen, On Wed, Oct 15, 2008 at 7:52 PM, you wrote: > I am trying to get axiom to accept the input "f(x)" as meaning > "an unspecified function f applied to the variable x". I looked briefly > through the documentation at > http://www.axiomdeveloper.org/axiomwebsite/documentation.html, > but I am not seeing which section to look at. I think you should read section "9.3 BasicOperator" of the Axiom book. There are also examples of the use of 'operator' scattered throughout the book. > > (1) > f(x) Try: (1) > f:= operator 'f (1) f Type: BasicOperator (2) > f(x) (2) f(x) Type: Expression Integer > I can see how to create functions that do something, but not variable > functions. > The terminology "variable functions" is strange to me. But it is true that f(x) where f is an operator acts like an "unknown" in several different Axiom domains, e.g. in differential equations. By the way, in addition to http://www.axiomdeveloper.org you might also find the Axiom community wiki: http://axiomwiki.newsynthesis.org useful since it also deals specifically with OpenAxiom. Regards, Bill Page. 
From: Stephen MontgomerySmith <stephen@ma...>  20081015 23:53:07

I am trying to get axiom to accept the input "f(x)" as meaning "an unspecified function f applied to the variable x". I looked briefly through the documentation at http://www.axiomdeveloper.org/axiomwebsite/documentation.html, but I am not seeing which section to look at. I can see how to create functions that do something, but not variable functions. (1) > f(x) There are no library operations named f Use HyperDoc Browse or issue )what op f to learn if there is any operation containing " f " in its name. Cannot find a definition or applicable library operation named f with argument type(s) Variable x Perhaps you should use "@" to indicate the required return type, or "$" to specify which version of the function you need. 
From: Bill Page <bill.page@ne...>  20081014 23:13:44

On Tue, Oct 14, 2008 at 6:47 PM, Martin Rubey wrote: > > Bill Page writes: > >> The reason I think it is not such a good idea is because it explicitly >> introduces the notion of type into InputForm values in an essential >> way. There are no explicit types at all in the following examples: >> >> (float 231808574432053350722  66 2) >> >> (algebraicNumber (** 2 (/ 1 2)) ) >> >> only function calls. In an external environment like Sage, we need >> only map these function calls to something native to Sage. If we pass >> explicit type names, then we will need to handle them is another way, >> making the process more complicated than it really needs to be. > > I'm not sure whether this is true. I think there is very little difference > between > > (:: (** 2 (/ 1 2)) (AlgebraicNumber)) > > and > > (algebraicNumber (** 2 (/ 1 2))) > The difference is that Sage does not have to know anything about the Axiom type AlgebraicNumber. > I just checked: you can do > > QQbar(2)^(1/2) > > but not > > QQbar(2^(1/2)) > > so you need to analyze the expression anyway. > What version of Sage are you using? In 3.1.2 I get: wspage@...:~$ ~/sage*/sage   SAGE Version 3.1.2, Release Date: 20080919   Type notebook() for the GUI, and license() for information.   sage: a=QQbar(2^(1/2)) sage: a? Type: AlgebraicNumber Base Class: <class 'sage.rings.qqbar.AlgebraicNumber'> String Form: 1.414213562373095? Namespace: Interactive Docstring: The class for algebraic numbers (complex numbers which are the roots of a polynomial with integer coefficients). Much of its functionality is inherited from AlgebraicNumber_base. sage: parent(a) Algebraic Field  > As little as I understand of Sage so far, domains seem to be pretty much > mapped to Parents in Sage. I think we should try to keep this similarity. I think Sage parents are more like categories in Axiom, but as a general principle I agree with this. Regards, Bill Page. 
From: Bill Page <bill.page@ne...>  20081014 22:38:12

On Tue, Oct 14, 2008 at 6:17 PM, Martin Rubey wrote: > > Bill Page writes: > >> In principle it is possible to combine both value and type information >> into a single InputForm value. For example, this is the output >> generated by a patch that I have proposed for FriCAS: >> >> (1) > sqrt(2)::InputForm >> >> (1) (:: (** 2 (/ 1 2)) (AlgebraicNumber)) >> Type: InputForm >> >> Here the desired type of the value is given by the final conversion. The >> problem is that I am not convinced that this is really such a good idea. > > Why do you think it's not a good idea? The reason I think it is not such a good idea is because it explicitly introduces the notion of type into InputForm values in an essential way. There are no explicit types at all in the following examples: (float 231808574432053350722  66 2) (algebraicNumber (** 2 (/ 1 2)) ) only function calls. In an external environment like Sage, we need only map these function calls to something native to Sage. If we pass explicit type names, then we will need to handle them is another way, making the process more complicated than it really needs to be. > To convert to Sage (in a spad package), one would have to do a dispatch > depending on the domain. With AlgebraicNumber, it would be SR(2^(1/2)). Currently there is no spad package that does explicit conversion to Sage. The conversion is done on the Sage side in 'axiom.py' interface. If the conversion is done in Spad, then I am not sure that it would necessarily involve InputForm at all. (I am not necessarily against this idea  I am just pointing out that it is not currently done this way.) > Very likely, we cannot determine below and above for > > QQbar.polynomial_root(poly, RIF(below, above)) > > this would only be possible with RECLOS. > The Rep used by AlgebraicNumber is actually 'Expression Integer'. This choice of Rep is a little unusual and is probably the reason that Waldek objected to my notion that we might define value constructors like 'algebraicNumber' based on the underlying Rep. On reflection, I must say that for the most part I agree with his criticism. I think that it is very desirable  when possible  to define a value constructor based on the actual mathematical theory rather than it's particular representation. Some representations are more "naturaul" than others. But even having defined a default way of constructing values for any domain, I think it would be quite normal to override this with something better, when and where possible. Regards, Bill Page. 
From: Bill Page <bill.page@ne...>  20081014 22:14:21

On Tue, Oct 14, 2008 at 2:44 PM, Gabriel Dos Reis wrote: > On Tue, Oct 14, 2008 at 1:07 PM, Bill Page wrote: >> On Tue, Oct 14, 2008 at 12:19 PM, Gabriel Dos Reis wrote: >>> >>> I want >>> >>> '(x + y) >>> >>> to be InputForm, not an OutputForm  and I already has a patch >>> for that. But, that is only a tiny part of the story. >>> >> >> Of course since there is a simple conversion from OutputForm to >> InputForm you can also write: >> >> (1) > '(x+y)::OutputForm::InputForm >> >> (1) (+ x y) >> Type: InputForm >> >> if you wish. > > Again, I did not say "impossible". If one has to write the above > to get '(+ x y) into the system, then the something is wrong with > the interface. > Before one can say "something is wrong" I think it is first necessary to state what are the design intentions of a particular feature  How is it supposed to work? Of course this is often very difficult in the original Axiom where so little of these design decisions were documented. So far as I can see it was not the intention of the design to make it easy to enter commands in the OutputForm notation of the domain InputForm. Instead its seems that it was expected that most InputForm values in the interpreter would be generated either by conversion from other values or by parsing an input string. E.g. (1) > parseString("x+y")$InputForm (1) (+ x y) Type: InputForm I am not convinced that the "cutandpaste" application suggested by Stephen where OpenAxiom output is to be "pasted back" as input is sufficiently welldefined. The problem is that neither the OutputForm nor even the InputForm (as generated by most current domains) contains sufficient semantics to reliably recreate a given value from either the external form alone. It is essential to also know the type. (2) > exp1:Expression Integer := x+y (2) y + x Type: Expression Integer (3) > interpret(exp1::InputForm) (3) y + x Type: Polynomial Integer (4) > interpret(exp1::InputForm)$InputFormFunctions1(Expression Integer) (4) y + x Type: Expression Integer  Although it is displayed as "Polynomial Integer", the actual type of result (3) is "Any". This kind of "duck typing" is necessary because every function in OpenAxiom must return a value of a fixed type. This issue is avoided in (4) by the use of a package call. Exactly these same issues arise in the current Axiom interface in Sage. Since Sage objects are strongly typed it is desirable to be able to convert the result of Axiom computations to Sage objects of the appropriate type. Of course I would like the solution of these problems to be easily portable among the Axiomata and I would also like it to be easy for Sage users to choose the variant of Axiom they want simply by installing the appropriate external package. As I mentioned earlier, I have been thinking about this problem and discussed it on the FriCAS list in the context of the extensions to the existing Axiom interface in Sage. In principle it is possible to combine both value and type information into a single InputForm value. For example, this is the output generated by a patch that I have proposed for FriCAS: (1) > sqrt(2)::InputForm (1) (:: (** 2 (/ 1 2)) (AlgebraicNumber)) Type: InputForm Here the desired type of the value is given by the final conversion. The problem is that I am not convinced that this is really such a good idea. I think a better approach is probably to ensure that all domains export some reliable value constructor, following the model given by the domain Float: (2) > 3.141592::InputForm (2) (float 231808574432053350722  66 2) Type: InputForm So for the case of AlgebraicNumber I think a better result would be: (algebraicNumber (** 2 (/ 1 2)) ) The trouble with this is that this will require a change to almost all domains. I have proposed a solution to this problem on the FriCAS list by relating InputForm values to the Rep of the domain. In principle this would allow us to easily define a default constructor function for each domain, but the objection has been raised that this at least partially exposes the particular choice of Rep for a domain and therefore violates information hiding. I would be very interested in your opinions on this and I would very much like to discuss this further with other interested parties. Regards, Bill Page. 
From: Gabriel Dos Reis <gdr@in...>  20081014 19:01:19

On Mon, Oct 13, 2008 at 8:45 PM, Stephen MontgomerySmith <stephen@...> wrote: > I am looking for something in openaxiom akin to Mathematica's > "InputForm" command. I looked at all the ")set output" possibilities, > and I can find equivalences for "FortranForm" and "TeXForm" but nothing > equivalent to "InputForm". > > Thanks, Stephen Dear Stephen, I have to agree with you that the InputForm domain is currently not sufficiently well supported from user interface point of view. (1) To make it easier to get data into the OpenAxiom system as InputForm, I committed a simple to both 1.2 branch and mainline (therefore you'll get the change in the 1.2.1 release) to allow quoted syntax as InputForm `literal'. E.g. '(x + y) is now an InputForm, so is 'cos(x). Note that parenthesis around function argument argument are mandatory to get the appropriate interpretation. For example 'cos x is not an InputForm. (2) I now believe that the sexpression display of InputForm is not that a good idea after all  parsing simplicity notwithstanding  because there is no simple and elegant way to get the displayed form back into the system again as InputForm  I suspect that is what you referred to as "copy and paste". I've placed this on my TODO list and will work on that. I'm undecided yet whether that particular change should go to the 1.2 branch or deferred until the next major release (1.3.0). The reason being I would not like to introduce a major display/semantics change in a bug release. But, nothing is decided yet. Many thanks. Please feel free to ask questions  don't be afraid to ask a question that might appear `too simple'.  Gaby 
From: Gabriel Dos Reis <gdr@in...>  20081014 18:44:45

On Tue, Oct 14, 2008 at 1:07 PM, Bill Page <bill.page@...> wrote: > On Tue, Oct 14, 2008 at 12:19 PM, Gabriel Dos Reis wrote: >> >> I want >> >> '(x + y) >> >> to be InputForm, not an OutputForm  and I already has a patch for >> that. But, that is only a tiny part of the story. >> > > Of course since there is a simple conversion from OutputForm to > InputForm you can also write: > > (1) > '(x+y)::OutputForm::InputForm > > (1) (+ x y) > Type: InputForm > > if you wish. Again, I did not say "impossible". If one has to write the above to get '(+ x y) into the system, then the something is wrong with the interface. > But I have nothing against making this easier. Good. 
From: Bill Page <bill.page@ne...>  20081014 18:07:26

On Tue, Oct 14, 2008 at 12:19 PM, Gabriel Dos Reis wrote: > > I want > > '(x + y) > > to be InputForm, not an OutputForm  and I already has a patch for > that. But, that is only a tiny part of the story. > Of course since there is a simple conversion from OutputForm to InputForm you can also write: (1) > '(x+y)::OutputForm::InputForm (1) (+ x y) Type: InputForm if you wish. But I have nothing against making this easier. >> >> I agree that it is not very convenient but the method I usually use ... >> Regards, Bill Page. 
From: Gabriel Dos Reis <gdr@in...>  20081014 16:19:15

On Tue, Oct 14, 2008 at 9:38 AM, Bill Page <bill.page@...> wrote: > On Tue, Oct 14, 2008 at 12:18 AM, Gabriel Dos Reis wrote: >> On Mon, Oct 13, 2008 at 11:04 PM, Stephen MontgomerySmith wrote: >> >>>> >>>> In fact InputForm attempts to output a parse tree in *prefix form*  >>>> in the spirit of Lisp's sexpression notation  supposedly easier to >>>> parse  just one token ahead lookup. Is that notation too unsuitable >>>> for your tool? How would you want it to be to it easier for you? >>>> In pure Matemathica full form notation? >>> >>> I could use it. But is it possible to feed an sexpression into axiom? >> >> Ideally, yes. When that does not happen, it is a "bug" until proven a >> design choice. >> > > (1) > (x+y)::InputForm Yes, but to my view, that is not convenient enough. I want '(x + y) to be InputForm, not an OutputForm  and I already has a patch for that. But, that is only a tiny part of the story. > > (1) (+ y x) > Type: InputForm I don't consider this output useful. Because there is no simple convenient way to get (+ y x) into the system and have it interpreted as InputForm. > (2) > interpret(%) > > (2) y + x > Type: Polynomial Integer > >> Now, the next question is how does one get an sexpression form or >> an InputForm into OpenAxiom from the standard input. I just realize >> that the standard method of quoting a list does not properly work. >> E.g. >> >> '(+ x y) :: InputForm >> >> does not parse correctly. >> >> I consider it a bug that there is no convenient way to get an InputForm >> into the system from the standard input. >> >> I'm considering several options. >> > > Gaby, > > I agree that it is not very convenient but the method I usually use > looks like this: > > (1) > convert([_+::InputForm,'x::InputForm,'y::InputForm]) > > (1) (+ x y) > Type: InputForm I know that method; that is why I did not say "impossible". If people have to write the above to get a simple (+ x y) into the system (compute the contenttonoise ratio), then we have a fundamental interface problem  which is my claim.  Gaby 
From: Bill Page <bill.page@ne...>  20081014 15:06:52

On Mon, Oct 13, 2008 at 11:04 PM, Stephen MontgomerySmith wrote: > > The trouble with the "InputForm" generated by axiom is that it looks like > reverse polish notation, and is not something that can be cut and pasted > back into axiom as an input string. And I must admit that it is not clear > to me at all what "unparse" is supposed to do. > ??? That is exactly what "unparse" is supposed to do. Perhaps you could use HyperDoc do find out a little more about these domains and functions. Regards, Bill Page. 
From: Bill Page <bill.page@ne...>  20081014 15:06:51

On Tue, Oct 14, 2008 at 12:18 AM, Gabriel Dos Reis wrote: > On Mon, Oct 13, 2008 at 11:04 PM, Stephen MontgomerySmith wrote: > >>> >>> In fact InputForm attempts to output a parse tree in *prefix form*  >>> in the spirit of Lisp's sexpression notation  supposedly easier to >>> parse  just one token ahead lookup. Is that notation too unsuitable >>> for your tool? How would you want it to be to it easier for you? >>> In pure Matemathica full form notation? >> >> I could use it. But is it possible to feed an sexpression into axiom? > > Ideally, yes. When that does not happen, it is a "bug" until proven a > design choice. > (1) > (x+y)::InputForm (1) (+ y x) Type: InputForm (2) > interpret(%) (2) y + x Type: Polynomial Integer > Now, the next question is how does one get an sexpression form or > an InputForm into OpenAxiom from the standard input. I just realize > that the standard method of quoting a list does not properly work. > E.g. > > '(+ x y) :: InputForm > > does not parse correctly. > > I consider it a bug that there is no convenient way to get an InputForm > into the system from the standard input. > > I'm considering several options. > Gaby, I agree that it is not very convenient but the method I usually use looks like this: (1) > convert([_+::InputForm,'x::InputForm,'y::InputForm]) (1) (+ x y) Type: InputForm Regards, Bill Page. 
From: Gabriel Dos Reis <gdr@in...>  20081014 04:18:42

On Mon, Oct 13, 2008 at 11:04 PM, Stephen MontgomerySmith <stephen@...> wrote: >> >> In fact InputForm attempts to output a parse tree in *prefix form*  >> in the spirit >> of Lisp's sexpression notation  supposedly easier to parse  just one >> token >> ahead lookup. Is that notation too unsuitable for your tool? How would >> you >> want it to be to it easier for you? In pure Matemathica full form >> notation? > > I could use it. But is it possible to feed an sexpression into axiom? Ideally, yes. When that does not happen, it is a "bug" until proven a design choice. Now, the next question is how does one get an sexpression form or an InputForm into OpenAxiom from the standard input. I just realize that the standard method of quoting a list does not properly work. E.g. '(+ x y) :: InputForm does not parse correctly. I consider it a bug that there is no convenient way to get an InputForm into the system from the standard input. I'm considering several options.  Gaby Or > do I need to write my own "unparse" routine? > > (Sorry for what are probably very basic questions  I am definitely just a > superbeginner at using this product.) > > 
From: Stephen MontgomerySmith <stephen@ma...>  20081014 04:11:27

Gabriel Dos Reis wrote: > On Mon, Oct 13, 2008 at 8:45 PM, Stephen MontgomerySmith > <stephen@...> wrote: >> I am looking for something in openaxiom akin to Mathematica's >> "InputForm" command. I looked at all the ")set output" possibilities, >> and I can find equivalences for "FortranForm" and "TeXForm" but nothing >> equivalent to "InputForm". >> >> Thanks, Stephen >> >> Incidentally, I submitted a "port" for FreeBSD, which hopefully will >> become part of the FreeBSD system. Is this worthy of a message to the >> openaxiomannounce mailing list? >> >> http://www.freebsd.org/cgi/querypr.cgi?pr=ports/128034 >> > > Dear Albert, > > This is an FYI that Stephen just submitted a FreeBSD port of OpenAxiom based > on CLisp as indicated above. > > Best, >  Gaby I'll make it an option to use sbcl when I can get it to work (which I am told will happen when version 1.2.1 comes out). 
From: Stephen MontgomerySmith <stephen@ma...>  20081014 04:04:11

Gabriel Dos Reis wrote: > On Mon, Oct 13, 2008 at 10:04 PM, Stephen MontgomerySmith > <stephen@...> wrote: >> On Mon, 13 Oct 2008, Bill Page wrote: >> >>> Perhaps you can describe why you are "looking for something in >>> openaxiom akin to Mathematica's "InputForm" command". What use will >>> you make of this? There might be some other way to accomplish what you >>> want. >> I wrote a program, in perl, that interacts with a computer algebra system >> to do various computations. It interacts with the CAS via the "Expect" >> perl module. The program takes outputs from the CAS, and uses them as >> inputs later on to the CAS. The final result from the perl script is to >> create a C program. >> >> So far my program works with Mathematica (which is commercial) and maxima >> (which has a GPL license), and I was hoping to get it to work with >> something with a BSD license. >> >> (The purpose of the program is to generate numerical programs that solve >> certain PDE's on the sphere using spherical harmonics. >> http://www.math.missouri.edu/~stephen/software/spherical/) >> >> The trouble with the "InputForm" generated by axiom is that it looks like >> reverse polish notation, and is not something that can be cut and pasted >> back into axiom as an input string. And I must admit that it is not clear >> to me at all what "unparse" is supposed to do. > > In fact InputForm attempts to output a parse tree in *prefix form*  > in the spirit > of Lisp's sexpression notation  supposedly easier to parse  just one token > ahead lookup. Is that notation too unsuitable for your tool? How would you > want it to be to it easier for you? In pure Matemathica full form notation? I could use it. But is it possible to feed an sexpression into axiom? Or do I need to write my own "unparse" routine? (Sorry for what are probably very basic questions  I am definitely just a superbeginner at using this product.) 
From: Gabriel Dos Reis <gdr@in...>  20081014 03:56:54

On Mon, Oct 13, 2008 at 8:45 PM, Stephen MontgomerySmith <stephen@...> wrote: > I am looking for something in openaxiom akin to Mathematica's > "InputForm" command. I looked at all the ")set output" possibilities, > and I can find equivalences for "FortranForm" and "TeXForm" but nothing > equivalent to "InputForm". > > Thanks, Stephen > > Incidentally, I submitted a "port" for FreeBSD, which hopefully will > become part of the FreeBSD system. Is this worthy of a message to the > openaxiomannounce mailing list? > > http://www.freebsd.org/cgi/querypr.cgi?pr=ports/128034 > Dear Albert, This is an FYI that Stephen just submitted a FreeBSD port of OpenAxiom based on CLisp as indicated above. Best,  Gaby 
From: Gabriel Dos Reis <gdr@in...>  20081014 03:41:23

On Mon, Oct 13, 2008 at 10:04 PM, Stephen MontgomerySmith <stephen@...> wrote: > On Mon, 13 Oct 2008, Bill Page wrote: > >> Perhaps you can describe why you are "looking for something in >> openaxiom akin to Mathematica's "InputForm" command". What use will >> you make of this? There might be some other way to accomplish what you >> want. > > I wrote a program, in perl, that interacts with a computer algebra system > to do various computations. It interacts with the CAS via the "Expect" > perl module. The program takes outputs from the CAS, and uses them as > inputs later on to the CAS. The final result from the perl script is to > create a C program. > > So far my program works with Mathematica (which is commercial) and maxima > (which has a GPL license), and I was hoping to get it to work with > something with a BSD license. > > (The purpose of the program is to generate numerical programs that solve > certain PDE's on the sphere using spherical harmonics. > http://www.math.missouri.edu/~stephen/software/spherical/) > > The trouble with the "InputForm" generated by axiom is that it looks like > reverse polish notation, and is not something that can be cut and pasted > back into axiom as an input string. And I must admit that it is not clear > to me at all what "unparse" is supposed to do. In fact InputForm attempts to output a parse tree in *prefix form*  in the spirit of Lisp's sexpression notation  supposedly easier to parse  just one token ahead lookup. Is that notation too unsuitable for your tool? How would you want it to be to it easier for you? In pure Matemathica full form notation?  Gaby 
From: Gabriel Dos Reis <gdr@in...>  20081014 03:36:17

On Mon, Oct 13, 2008 at 8:45 PM, Stephen MontgomerySmith <stephen@...> wrote: > > Thanks, Stephen > > Incidentally, I submitted a "port" for FreeBSD, which hopefully will > become part of the FreeBSD system. Is this worthy of a message to the > openaxiomannounce mailing list? > > http://www.freebsd.org/cgi/querypr.cgi?pr=ports/128034 Yes, definitely. Please feel free to send the announcement. I'll update the download page. Many tanks!  Gaby 
From: Bill Page <bill.page@ne...>  20081014 03:20:16

On Mon, Oct 13, 2008 at 9:45 PM, Stephen MontgomerySmith wrote: > I am looking for something in openaxiom akin to Mathematica's > "InputForm" command. I looked at all the ")set output" possibilities, > and I can find equivalences for "FortranForm" and "TeXForm" but > nothing equivalent to "InputForm". > http://reference.wolfram.com/mathematica/ref/InputForm.html Oddly enough what you are probably looking for is also called InputForm in openaxiom. E.g. (1) > ++ 2 \5 (y +  x)z + 1 5 (1)  z Type: Fraction Polynomial AlgebraicNumber (2) > ex2:=ex1::Expression Integer ++ 2 x z\5 + 5y z + 5 (2)  5z Type: Expression Integer (3) > ex2::InputForm (3) (/ (+ (* (* x z) (** 5 (/ 1 2))) (+ (* (* 5 (** y 2)) z) 5)) (* 5 z)) Type: InputForm There are some known limitations in some of openaxiom's domains that prevent direct conversion to InputForm  the domain AlgebraicNumber is one of these. But as shown above it works ok if you first convert this expression to the Expression domain. In openaxiom InputForm is displayed as an "sexpression". It can also be "unparsed" to a string, but I just noticed there are some bugs: (4) > unparse(%) (4) "OVERx*z*5**(1/2)+5*y*y*z+55*z" Type: String There are some corrections to these problems that have been discussed in the context of the other fork of Axiom called FriCAS. I can help you port these changes to openaxiom if InputForm is important to you and turns out to be really what you want. Perhaps you can describe why you are "looking for something in openaxiom akin to Mathematica's "InputForm" command". What use will you make of this? There might be some other way to accomplish what you want. Regards, Bill Page. 
From: Stephen MontgomerySmith <stephen@ma...>  20081014 03:04:49

On Mon, 13 Oct 2008, Bill Page wrote: > Perhaps you can describe why you are "looking for something in > openaxiom akin to Mathematica's "InputForm" command". What use will > you make of this? There might be some other way to accomplish what you > want. I wrote a program, in perl, that interacts with a computer algebra system to do various computations. It interacts with the CAS via the "Expect" perl module. The program takes outputs from the CAS, and uses them as inputs later on to the CAS. The final result from the perl script is to create a C program. So far my program works with Mathematica (which is commercial) and maxima (which has a GPL license), and I was hoping to get it to work with something with a BSD license. (The purpose of the program is to generate numerical programs that solve certain PDE's on the sphere using spherical harmonics. http://www.math.missouri.edu/~stephen/software/spherical/) The trouble with the "InputForm" generated by axiom is that it looks like reverse polish notation, and is not something that can be cut and pasted back into axiom as an input string. And I must admit that it is not clear to me at all what "unparse" is supposed to do. Thanks, Stephen 
From: Bill Page <bill.page@ne...>  20081014 03:00:05

Sorry, I messedup the previous cutandpaste example. I should start like this: (1) > ex1:=x/sqrt(5)+y^2+1/z ++ 2 \5 (y +  x)z + 1 5 (1)  z Type: Fraction Polynomial AlgebraicNumber ... Regards, Bill Page. 
From: Stephen MontgomerySmith <stephen@ma...>  20081014 02:12:20

I am looking for something in openaxiom akin to Mathematica's "InputForm" command. I looked at all the ")set output" possibilities, and I can find equivalences for "FortranForm" and "TeXForm" but nothing equivalent to "InputForm". Thanks, Stephen Incidentally, I submitted a "port" for FreeBSD, which hopefully will become part of the FreeBSD system. Is this worthy of a message to the openaxiomannounce mailing list? http://www.freebsd.org/cgi/querypr.cgi?pr=ports/128034 