OpenAxiom: Scientific Computation System

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.axiom-developer.org/axiom-website/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.axiom-developer.org you might
also find the Axiom community wiki:

  http://axiom-wiki.newsynthesis.org

useful since it also deals specifically with OpenAxiom.

Regards,
Bill Page.

On Wed, Oct 15, 2008 at 6:52 PM, Stephen Montgomery-Smith
<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.axiom-developer.org/axiom-website/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

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))

On Thu, Oct 16, 2008 at 4:19 PM, Stephen Montgomery-Smith
<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

Gabriel Dos Reis wrote:
> On Thu, Oct 16, 2008 at 4:19 PM, Stephen Montgomery-Smith
> <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.

Sorry, I messed-up the previous cut-and-paste 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.

On Mon, 13 Oct 2008, Bill Page wrote:

> Perhaps you can describe why you are "looking for something in
> open-axiom 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

On Mon, Oct 13, 2008 at 9:45 PM, Stephen Montgomery-Smith wrote:
> I am looking for something in open-axiom 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 open-axiom. 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 open-axiom'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 open-axiom InputForm is
displayed as an "s-expression". 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 open-axiom 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
open-axiom 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.

On Mon, Oct 13, 2008 at 8:45 PM, Stephen Montgomery-Smith
<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
> open-axiom-announce mailing list?
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/128034

Yes, definitely.  Please feel free to send the announcement.
I'll update the download page.
Many tanks!

-- Gaby

On Mon, Oct 13, 2008 at 10:04 PM, Stephen Montgomery-Smith
<stephen@...> wrote:
> On Mon, 13 Oct 2008, Bill Page wrote:
>
>> Perhaps you can describe why you are "looking for something in
>> open-axiom 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 s-expression 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

On Mon, Oct 13, 2008 at 8:45 PM, Stephen Montgomery-Smith
<stephen@...> wrote:
> I am looking for something in open-axiom 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
> open-axiom-announce mailing list?
>
> http://www.freebsd.org/cgi/query-pr.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

Gabriel Dos Reis wrote:
> On Mon, Oct 13, 2008 at 10:04 PM, Stephen Montgomery-Smith
> <stephen@...> wrote:
>> On Mon, 13 Oct 2008, Bill Page wrote:
>>
>>> Perhaps you can describe why you are "looking for something in
>>> open-axiom 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 s-expression 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 s-expression 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 super-beginner at using this product.)

Gabriel Dos Reis wrote:
> On Mon, Oct 13, 2008 at 8:45 PM, Stephen Montgomery-Smith
> <stephen@...> wrote:
>> I am looking for something in open-axiom 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
>> open-axiom-announce mailing list?
>>
>> http://www.freebsd.org/cgi/query-pr.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).

On Mon, Oct 13, 2008 at 11:04 PM, Stephen Montgomery-Smith
<stephen@...> wrote:

>>
>> In fact InputForm attempts to output a parse tree in *prefix form* --
>> in the spirit
>> of Lisp's s-expression 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 s-expression 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 s-expression 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
> super-beginner at using this product.)
>
>

On Tue, Oct 14, 2008 at 12:18 AM, Gabriel Dos Reis wrote:
> On Mon, Oct 13, 2008 at 11:04 PM, Stephen Montgomery-Smith wrote:
>
>>>
>>> In fact InputForm attempts to output a parse tree in *prefix form* --
>>> in the spirit of Lisp's s-expression 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 s-expression 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 s-expression 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.

On Mon, Oct 13, 2008 at 11:04 PM, Stephen Montgomery-Smith 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.

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 Montgomery-Smith wrote:
>>
>>>>
>>>> In fact InputForm attempts to output a parse tree in *prefix form* --
>>>> in the spirit of Lisp's s-expression 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 s-expression 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 s-expression 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 content-to-noise ratio), then we have a
fundamental interface problem -- which is my claim.

-- Gaby

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.

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.

On Mon, Oct 13, 2008 at 8:45 PM, Stephen Montgomery-Smith
<stephen@...> wrote:
> I am looking for something in open-axiom 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 s-expression 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

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 "cut-and-paste" application suggested by
Stephen where OpenAxiom output is to be "pasted back" as input is
sufficiently well-defined. 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.

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.

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: 2008-09-19                       |
| 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.