How do I get the most current version of axiom.py
Martin Rubey
axiom.py...
Thanks,
Martin
Bill Page
The patches are at:
http://trac.sagemath.org/sage_trac/attachment/ticket/4036
Click on for example: trac_4036-2.patch
http://trac.sagemath.org/sage_trac/attachment/ticket/4036/trac_4036-2.patch
This displays the patch with additions and deletions highlighted.
At the bottom of the page under the heading: Download in other formats
Click the link
* Original Format
This is the format you can use with patch.
There were a couple of other changes that I suggested in emails to
Mike (including the compiler patch) but he has not yet included them
here yet.
Regards,
Bill Page.
Martin Rubey
> Martin,
>
> The patches are at:
>
> http://trac.sagemath.org/sage_trac/attachment/ticket/4036
>
> Click on for example: trac_4036-2.patch
>
> http://trac.sagemath.org/sage_trac/attachment/ticket/4036/trac_4036-2.patch
>
> This displays the patch with additions and deletions highlighted.
>
> At the bottom of the page under the heading: Download in other formats
> Click the link
>
> * Original Format
>
> This is the format you can use with patch.
Great! I applied this, but
a = axiom(x^2 + 1)
a.sage()
still does not work. I guess I have to tell sage somehow to reconfigure or so?
Martin
Mike Hansen
> Great! I applied this, but
>
> a = axiom(x^2 + 1)
> a.sage()
>
> still does not work. I guess I have to tell sage somehow to reconfigure or so?
You need to run start Sage with "sage -br" (for build and run) to make
the changes active.
--Mike
William Stein
Startup sage by typing
sage -br
where "br" = "build and run".
William
Martin Rubey
Better, but not quite there yet:
sage: a = axiom(x^2 + 1)
sage: a.sage()
---------------------------------------------------------------------------
NotImplementedError Traceback (most recent call last)
/local/scratch/sage-3.1.final/<ipython console> in <module>()
/local/scratch/sage-3.1.final/local/lib/python2.5/site-packages/sage/interfaces/expect.py in sage(self)
1367 Rational Field
1368 """
-> 1369 return self._sage_()
1370
1371 def __repr__(self):
/local/scratch/sage-3.1.final/local/lib/python2.5/site-packages/sage/interfaces/axiom.py in _sage_(self)
609 elif type.startswith('Polynomial'):
610 from sage.rings.all import PolynomialRing
--> 611 base_ring = P(type.lstrip('Polynomial '))._sage_domain()
612 vars = str(self.variables())[1:-1]
613 R = PolynomialRing(base_ring, vars)
/local/scratch/sage-3.1.final/local/lib/python2.5/site-packages/sage/interfaces/axiom.py in _sage_domain(self)
648 return P(name.lstrip('Fraction '))._sage_domain().fraction_field()
649
--> 650 raise NotImplementedError
651
652
NotImplementedError:
sage: a
x*x+1
Martin Rubey
on my computer.
Mostly, because I think the following *should* work...
sage: a = axiom.sin(x)
sage: a
sin(x)
sage: a.sage()
---------------------------------------------------------------------------
NotImplementedError Traceback (most recent call last)
/local/scratch/sage-3.1.final/<ipython console> in <module>()
/local/scratch/sage-3.1.final/local/lib/python2.5/site-packages/sage/interfaces/expect.py in sage(self)
1392 Rational Field
1393 """
-> 1394 return self._sage_()
1395
1396 def __repr__(self):
/local/scratch/sage-3.1.final/local/lib/python2.5/site-packages/sage/interfaces/axiom.py in _sage_(self)
784 return sage.misc.sage_eval.sage_eval(self.unparsed_input_form())
785 except:
--> 786 raise NotImplementedError
787
788
NotImplementedError:
On the other hand, I even get an error -- although different -- trying the
following:
sage.misc.sage_eval.sage_eval('sin(x)')
---------------------------------------------------------------------------
NameError Traceback (most recent call last)
/local/scratch/sage-3.1.final/<ipython console> in <module>()
/local/scratch/sage-3.1.final/local/lib/python2.5/site-packages/sage/misc/sage_eval.py in sage_eval(source, locals, cmds, preparse)
158 return locals['_sage_eval_returnval_']
159 else:
--> 160 return eval(source, sage.all.__dict__, locals)
161
162
/local/scratch/sage-3.1.final/<string> in <module>()
NameError: name 'x' is not defined
Slowly getting started...
Martin
Martin Rubey
> OK, thanks to Bill, Mike and William the axiom interface is now mostly working
> on my computer.
>
> Mostly, because I think the following *should* work...
>
> sage: a = axiom.sin(x)
I hacked around axiom.py a little, and came up with the following:
#If all else fails, try using the unparsed input form
try:
import sage.misc.sage_eval
try:
vars = str(self.variables())[1:-1]
return sage.misc.sage_eval.sage_eval(self.unparsed_input_form(),cmds='var(\''+vars+'\')')
except:
return sage.misc.sage_eval.sage_eval(self.unparsed_input_form())
except:
raise NotImplementedError
This takes into account the fact that in sage we have to introduce all
variables...
Unfortunately, we are still not there, because unparsed_input_form returns
'sin x'
(In FriCAS, one can omit parentheses, if a function takes only a single
argument.)
Is there an easy way to massage this string in python, or should I rather do it
in FriCAS? (I guess I should...)
Martin
Bill Page
>
>
> Mostly, because I think the following *should* work...
>
> sage: a = axiom.sin(x)
>
This does already work for me without any additional changes to axiom.py:
sage: a=axiom.sin(x)
sage: a
sin(x)
sage: a.type()
Expression Integer
Note: In Sage 'x' is the only pre-defined variable.
sage: b=axiom.sin(y)
---------------------------------------------------------------------------
NameError Traceback (most recent call last)
/home/page/<ipython console> in <module>()
NameError: name 'y' is not defined
> I hacked around axiom.py a little, and came up with the following:
>
> #If all else fails, try using the unparsed input form
> try:
> import sage.misc.sage_eval
> try:
> vars = str(self.variables())[1:-1]
> return sage.misc.sage_eval.sage_eval(self.unparsed_input_form(),cmds='var(\''+vars+'\')')
> except:
> return sage.misc.sage_eval.sage_eval(self.unparsed_input_form())
> except:
> raise NotImplementedError
>
> This takes into account the fact that in sage we have to introduce all
> variables...
>
I am not sure I like this change in behavior of Sage.
> Unfortunately, we are still not there, because unparsed_input_form
> returns
>
> 'sin x'
>
> (In FriCAS, one can omit parentheses, if a function takes only a single
> argument.)
>
> Is there an easy way to massage this string in python, or should I rather
> do it in FriCAS? (I guess I should...)
>
??? I think it works already.
Regards,
Bill Page.
Martin Rubey
> On Sat, Sep 13, 2008 at 7:07 PM, Martin Rubey wrote:
> >
> >
> > Mostly, because I think the following *should* work...
> >
> > sage: a = axiom.sin(x)
> >
>
> This does already work for me without any additional changes to axiom.py:
>
> sage: a=axiom.sin(x)
> sage: a
> sin(x)
> sage: a.type()
> Expression Integer
Yes, of course *that* works. But I want
sage: a = axiom.sin(x)
sage: a
sin(x)
sage: a.sage()
to work.
Martin
Bill Page
Ok, I understand now: converting Axiom ---> Sage . I was confused
because the quote was a little out of context. It is clear from your
original email. What you want is for this to work:
axiom('sin y').sage()
And of course in general for any Axiom object. As Waldek suggested
earlier perhaps what we really want is just an "infix" transformation
of the InputForm rather than 'unparse' - or even an operation
specially written in FriCAS for conversion of expressions to Sage.
Regards,
Bill Page.
Bill Page
I think 'unparse' in FriCAS is badly broken. See for example:
(1) -> unparse((sin(x+1))::InputForm)
(1) "sin x+1"
Type: String
Besides it's use in Sage, do you agree that we should fix it anyway?
At the same time we should also remove the Fortranish names and any
other flaws we can find.
The only other alternative for _sage_ in axiom.py that I can see would
be to write something that interprets the S-expression output of
InputForm directly.
Regards,
Bill Page.
Martin Rubey
> Martin,
>
> I think 'unparse' in FriCAS is badly broken. See for example:
>
> (1) -> unparse((sin(x+1))::InputForm)
>
> (1) "sin x+1"
> Type: String
>
> Besides it's use in Sage, do you agree that we should fix it anyway?
Yes, of course.
> At the same time we should also remove the Fortranish names and any other
> flaws we can find.
> The only other alternative for _sage_ in axiom.py that I can see would be to
> write something that interprets the S-expression output of InputForm
> directly.
This may be necessary anyway. I think the plan should be as follows: as you
said already, we would like to have interpret(x::INFORM) equal to the result of
evaluating x (in a fresh environment). I believe, to make this work properly,
x::INFORM should be fully type-decorated. It seems that this is also the
current strategy, some examples below.
Then, we can implement a package SagePackage analogous to OutputPackage, that
exports a single function sage: INFORM -> String. Actually, maybe it's better
to implement this in sage, because it should be possible to pass INFORM objects
as python nested lists of symbols, without going to strings?
Martin
(4) -> (factor(x^2-1))::INFORM
(4)
(* (primeFactor (:: (+ x - 1) (Polynomial (Integer))) 1)
(primeFactor (:: (+ x 1) (Polynomial (Integer))) 1))
Type: InputForm
(10) -> (1::COMPLEX INT)::INFORM
(10) (complex 1 0)
Type: InputForm
I think for aggregates we can have a general rule, but we need a way to specify
package calls
(15) -> construct([1,2,3])$PRIMARR INT::INFORM
Internal Error
The function convert with signature hashcode is missing from domain
PrimitiveArray(Integer)
should be
(29) -> [(packageCall('construct)$INFORM1 PRIMARR INT)::SEX, f::SEX]::SEX::INFORM
(32) (($elt (PrimitiveArray (Integer)) construct) (construct 1 2 3))
Type: InputForm
(29) -> interpret %
(33) [1,2,3]
Type: PrimitiveArray Integer
the following looks fishy, because it forgets the type information:
(13) -> [x,y,z]::List OVAR([x,y,z,q])::INFORM
(13) (construct x y z)
Type: InputForm
Bill Page
> ...
> Bill Page wrote:
>> The only other alternative for _sage_ in axiom.py that I can see would be
>> to write something that interprets the S-expression output of InputForm
>> directly.
>
> This may be necessary anyway. I think the plan should be as follows: as
> you said already, we would like to have interpret(x::INFORM) equal to the
> result of evaluating x (in a fresh environment). I believe, to make this work
> properly, x::INFORM should be fully type-decorated. It seems that this is
> also the current strategy, some examples below.
>
Ok, comments on examples below. After reviewing this, I am not sure
what "fully type-decorated" should mean.
> Then, we can implement a package SagePackage analogous to OutputPackage,
> that exports a single function sage: INFORM -> String. Actually, maybe it's
> better to implement this in sage, because it should be possible to pass
> INFORM objects as python nested lists of symbols, without going to strings?
>
Well, in the current implemention all things are ultimately passed as
strings through the pty interface, so this does not make any
difference in terms of efficiency. But conceptually I think make sense
to design things "as if" we were able to do this. Eventually, maybe we
will be able to call Axiom directly from Sage and to pass objects via
shared memory.
Since Python is such a widely used language, out there on the web are
people who have already dealt with passing Lisp S-expressions to
Python, e.g.
http://www.clsp.jhu.edu/~edrabek/utils/
> Martin
>
> (4) -> (factor(x^2-1))::INFORM
>
> (4)
> (* (primeFactor (:: (+ x - 1) (Polynomial (Integer))) 1)
> (primeFactor (:: (+ x 1) (Polynomial (Integer))) 1))
> Type: InputForm
If we wanted this to be "fully decorated" why not this?
(* (primeFactor (:: (+ (:: x Symbol) - (:: 1 Integer)) (Polynomial
(Integer))) (:: 1 Integer))
(primeFactor (:: (+ (:: x Symbol) (:: 1 Integer)) (Polynomial
(Integer))) (::1 Integer)))
How much can/should be assumed about the library, e.g. the existence
and signature of 'primeFactor' and the coercions that will be
automatically applied by the interpreter?
> (10) -> (1::COMPLEX INT)::INFORM
>
> (10) (complex 1 0)
> Type: InputForm
>
Here we do not see any type decorations. Do we say this is ok since
the signature of 'complex' is known? But 'complex' comes from
Complex(R) for some parameter R that is given here only implicitly.
> I think for aggregates we can have a general rule, but we need a way to specify
> package calls
>
> (15) -> construct([1,2,3])$PRIMARR INT::INFORM
> Internal Error
> The function convert with signature hashcode is missing from domain
> PrimitiveArray(Integer)
>
> should be
>
> (29) -> [(packageCall('construct)$INFORM1 PRIMARR INT)::SEX, f::SEX]::SEX::INFORM
>
> (32) (($elt (PrimitiveArray (Integer)) construct) (construct 1 2 3))
> Type: InputForm
> (29) -> interpret %
>
> (33) [1,2,3]
> Type: PrimitiveArray Integer
>
Yes, I think this is important. I think we also need some way to do
Axiom package calls from Sage. For example maybe
axiom.Complex(Float).sin(1)
should be evaluated in Axiom like:
sin(1)$Complex(Float)
To do this I think we need a new class defined in axiom.py to
specifically represent packages and domains. But right now we get
sage: axiom.Complex(Float)
---------------------------------------------------------------------------
NameError Traceback (most recent call last)
/home/page/<ipython console> in <module>()
NameError: name 'Float' is not defined
> the following looks fishy, because it forgets the type information:
>
> (13) -> [x,y,z]::List OVAR([x,y,z,q])::INFORM
>
> (13) (construct x y z)
> Type: InputForm
I agree. The question is: how much type information do we want in InputForm.
Also, I wonder if specifying only coercions and converisons via the
(:: ... ) construct is a good idea.
Finally, I think this overlaps some work being done by Gaby in
OpenAxiom. OpenAxiom has a new domain called an typed abstract syntax
tree which is specifically intended to capture this kind of type
information.
Regards,
Bill Page.
Waldek Hebisch
>
> On Mon, Sep 15, 2008 at 2:52 PM, Martin Rubey wrote:
> > ...
> > Bill Page wrote:
> >> The only other alternative for _sage_ in axiom.py that I can see would be
> >> to write something that interprets the S-expression output of InputForm
> >> directly.
> >
> > This may be necessary anyway. I think the plan should be as follows: as
> > you said already, we would like to have interpret(x::INFORM) equal to the
> > result of evaluating x (in a fresh environment). I believe, to make this work
> > properly, x::INFORM should be fully type-decorated. It seems that this is
> > also the current strategy, some examples below.
> >
>
> Ok, comments on examples below. After reviewing this, I am not sure
> what "fully type-decorated" should mean.
>
> > Then, we can implement a package SagePackage analogous to OutputPackage,
> > that exports a single function sage: INFORM -> String. Actually, maybe it's
> > better to implement this in sage, because it should be possible to pass
> > INFORM objects as python nested lists of symbols, without going to strings?
> >
>
> > (4) -> (factor(x^2-1))::INFORM
> >
> > (4)
> > (* (primeFactor (:: (+ x - 1) (Polynomial (Integer))) 1)
> > (primeFactor (:: (+ x 1) (Polynomial (Integer))) 1))
> > Type: InputForm
>
> If we wanted this to be "fully decorated" why not this?
>
> (* (primeFactor (:: (+ (:: x Symbol) - (:: 1 Integer)) (Polynomial
> (Integer))) (:: 1 Integer))
> (primeFactor (:: (+ (:: x Symbol) (:: 1 Integer)) (Polynomial
> (Integer))) (::1 Integer)))
>
> How much can/should be assumed about the library, e.g. the existence
> and signature of 'primeFactor' and the coercions that will be
> automatically applied by the interpreter?
>
Conversion to InputForm _is_ part of the library -- for example
convert in Boolean knows that 'true' and 'false' exist in Boolean.
For simple cases we may assume that intepreter will do right things.
But in general we probably need constructs like:
(1$Integer)@Integer
That is: make sure argument are of correct type, package call the
operation and use @ to be really sure that correct signature is
selected.
> > (10) -> (1::COMPLEX INT)::INFORM
> >
> > (10) (complex 1 0)
> > Type: InputForm
> >
>
> Here we do not see any type decorations. Do we say this is ok since
> the signature of 'complex' is known? But 'complex' comes from
> Complex(R) for some parameter R that is given here only implicitly.
>
We have:
(6) -> (1::(COMPLEX POLY INT))::INFORM
(6) (complex 1 0)
Type: InputForm
Which looks wrong: we will get Complex Integer instead of Complex
Polynomial Integer.
> > I think for aggregates we can have a general rule, but we need a way to specify
> > package calls
> >
> > (15) -> construct([1,2,3])$PRIMARR INT::INFORM
> > Internal Error
> > The function convert with signature hashcode is missing from domain
> > PrimitiveArray(Integer)
> >
The above is because convertion to InputForm is unimplemented for
PrimitiveArray, but PrimitiveArray Integer has ConvertibleTo InputForm.
In fact, in Collection(S) we have
....
if S has ConvertibleTo InputForm then ConvertibleTo InputForm
which does not look right: AFAIK our streams also are collections and
are represented by functions. Since we have no way to convert
functions to input forms, there is no way to convert streams
to InputForm.
For finite collections we probably can give reasonable implementation
using members (and package calls).
BTW, to get better convertion to InputForm (and more generally for
use in Sage interface) we need a way to convert types to
InputForm. The following is a first approximation of such
functionality:
)abbrev package GETTYNM GetTypeName
GetTypeName(T : Type) : with
getTypeName : () -> InputForm
== add
getTypeName() == (devaluate(T)$Lisp) pretend InputForm
I say that this is first approximation because it does not handle
correctly types which have ordinary values as parameters -- we
should convert such parameters to InputForm, but we do not
do this (packageCall has the same problem)
BTW2: I found the following (stolen form fortpak.spad) usefull
when experimenting with InputForm:
parse(s:String):InputForm ==
ncParseFromString(s)$Lisp::InputForm
Note that documentation of unparse says that it should work on
output of parse, so that parse(unparse(parse(s))) should
give the same result as parse(s). However, unparse in not
guaranteed to handle more general forms.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Bill Page
Without trying to solve the more general problem of rationalizing
InputForm and unparse in FriCAS, attached is a patch to 'axiom.py'
(relative to sage-3.1.2 + Mike's patches (trac_4036.patch
trac_4036-2.patch trac_4036-3.patch trac_4036-fixes.patch)) that
solves the problem of parsing 'sin x' so that now we get:
sage: axiom(sin(x)).sage()
sin(x)
@@ -693,7 +731,11 @@ in unparse_input_form
+ if r:
+ # juxtaposition is always function application
+ if axiom.get(self.type()) != "String": # except in strings
+ return re.sub(r'([^ ]+) ([^ ]+)',r'\1(\2)', r.groups(0)[0])
+ else:
+ return r.groups(0)[0]
+ else:
+ return s
adds the missing parenthesis. We need to deal here with the special
case of a String.
@@ -761,7 +803,8 @@ in _sage_
+ if type == "String":
+ return self.unparsed_input_form()
handles conversion of Axiom strings to Sage strings.
@@ -559,13 +595,15 @@ is a minor fix to axiom.type so that calls 'typeOf'.
@@ -820,17 +867,17 @@ changes the hack for the ! and ? suffix in Axiom
function names form xxx_e and xxx_q to what I consider a more common
convention of set_xxx and is_xxx.
This patch also includes the necessary code to compile spad files @@
-362,6 +362,41 @@
Regards,
Bill Page.
Bill Page
Perhaps you are already aware that the 'FOO.NRLIB' is not really a
temporary thing. This is where the compiler puts it's object files
prior to loading them. After compiling a spad file like this:
)co foo.spad
which assuming the the file 'foo.spad' starts with
)abbrev domain FOO Foo
...
will create the directory 'FOO.NRLIB', it is also possible (usually in
another session) to just load the file like this:
)lib FOO
and use it as you would any other code in the Axiom library.
After the fricas-1.0.3.spkg installation the Axiom library is located here:
$SAGE_ROOT/local/lib/fricas/target/x86_64-unknown-linux/algebra
This is where all the algebra-related object files are located.
Probably this is also a logical place to set as the default location
when Sage starts FriCAS. That way, after compiling some spad code in
Sage like this
sage: axiom.compile('''
)abbrev package FOO Foo
Foo():with
bar: Integer->Integer
== add
bar(x) == x+1
''')
sage: exit
Later you are assured that you can start Sage again and write:
sage: print axiom.eval(')lib FOO')
Foo will be automatically loaded when needed from
/home/page/sage-3.1.2.alpha4-sage.math-only-x86_64-Linux/devel/sage-main/sage/interfaces/FOO.NRLIB/code
sage: axiom.bar(1)
2
without having to re-compile the source for FOO again. The NRLIB would
remain there indefinitely until replaced or deleted by the user.
Regards,
Bill Page.
On Sat, Sep 13, 2008 at 5:15 PM, Bill Page <bill...@newsynthesis.org> wrote:
> On Sat, Sep 13, 2008 at 3:00 PM, Mike Hansen wrote:
>> Bill Page wrote:
>>> There were a couple of other changes that I suggested in emails
>>> to Mike (including the compiler patch) but he has not yet included
>>> them here yet.
>>
>> I have a patch for your changes, but we need to find a way so that
>> with your example in compile, FriCAS does not make a
>> "FOO.NRLIB" directory in the current directory. I can get a
>> temporary directory from Sage, but I don't know how to tell FriCAS
>> to use it.
>>
>
> In FriCAS you can change the current directory with the commmand:
>
> )cd /tmp
>
> now
>
> )compile ...
>
> will create FOO.NRLIB in /tmp
>
> Regards,
> Bill Page.
>
Bill Page
> ...
> After the fricas-1.0.3.spkg installation the Axiom library is located here:
>
> $SAGE_ROOT/local/lib/fricas/target/x86_64-unknown-linux/algebra
>
> This is where all the algebra-related object files are located.
> Probably this is also a logical place to set as the default location
> when Sage starts FriCAS.
Here is a small patch that sets this default path:
$ diff -a u axiom.py-old axiom.py-new
--- axiom.py-old 2008-09-16 19:32:18.000000000 -0700
+++ axiom.py-new 2008-09-16 19:38:34.000000000 -0700
@@ -29,6 +29,11 @@
the FriCAS fork of the Axiom project by Waldek Hebisch that
uses pre-compiled cached Lisp code to build Axiom very quickly
with clisp.
+ -- Mike Hansen (2008-09) made major improvements to the interface
+ including conversion to and from native Sage.
+ -- Martin Rubey (2008-9) contributed conversion of Axiom expressions
+ like 'sin(x)' to sage expressions.
+ -- Bill Page (2008-9) implemented compiling Spad code
If the string "error" (case insensitive) occurs in the output of
anything from axiom, a RuntimeError exception is raised.
@@ -239,6 +244,7 @@
out = self._eval_line(')set functions compile on', reformat=False)
out = self._eval_line(')set output length 245', reformat=False)
out = self._eval_line(')set message autoload off', reformat=False)
+ out = self._eval_line(')cd
'+SAGE_ROOT+'/local/lib/fricas/target/x86_64-unknown-linux/algebra',
reformat=False)
def _read_in_file_command(self, filename):
"""
@@ -368,7 +374,7 @@
EXAMPLES:
sage: axiom.compile('''
- )abbrev package FOO foo
+ )abbrev package FOO Foo
Foo():with
bar: Integer->Integer
== add
----
Regards,
Bill Page.
Mike Hansen
On Tue, Sep 16, 2008 at 7:11 PM, Bill Page <bill...@newsynthesis.org> wrote:
> After the fricas-1.0.3.spkg installation the Axiom library is located here:
>
> $SAGE_ROOT/local/lib/fricas/target/x86_64-unknown-linux/algebra
>
> This is where all the algebra-related object files are located.
> Probably this is also a logical place to set as the default location
> when Sage starts FriCAS.
This is definitely the wrong place to put the files since you will run
into all sorts of problems with permissions when you have multiple
users of an installation of Sage. It is better to put it somewhere in
DOT_SAGE.
--Mike
Bill Page
> ...
> It is better to put it somewhere in DOT_SAGE
>
You mean like:
out = self._eval_line(')cd '+DOT_SAGE+'/fricas/algebra', reformat=False)
How/when to create this directory?
Regards,
Bill Page.
Bill Page
Here's another patch (stolen from gap.py):
--- axiom.py-old 2008-09-16 19:38:34.000000000 -0700
+++ axiom.py-new 2008-09-16 19:57:52.000000000 -0700
@@ -155,6 +155,9 @@
seq = 0
COMMANDS_CACHE = '%s/axiom_commandlist_cache.sobj'%DOT_SAGE
+if not os.path.exists('%s/fricas/algebra/'%DOT_SAGE):
+ os.makedirs('%s/fricas/algebra/'%DOT_SAGE)
+
# The Axiom commands ")what thing det" ")show Matrix" and ")display
# op det" commands, gives a list of all identifiers that begin in
@@ -244,7 +247,7 @@
out = self._eval_line(')set functions compile on', reformat=False)
out = self._eval_line(')set output length 245', reformat=False)
out = self._eval_line(')set message autoload off', reformat=False)
- out = self._eval_line(')cd
'+SAGE_ROOT+'/local/lib/fricas/target/x86_64-unknown-linux/algebra',
reformat=False)
+ out = self._eval_line(')cd '+DOT_SAGE+'/fricas/algebra',
reformat=False)
def _read_in_file_command(self, filename):
"""
-----
page@sage:~$ ~/sage-3.1.2*/sage
----------------------------------------------------------------------
| SAGE Version 3.1.2.alpha4, Release Date: 2008-09-02 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
sage: axiom.compile('''
....: )abbrev package FOO Foo
....: Foo():with
....: bar: Integer->Integer
....: == add
....: bar(x) == x+1
....: ''')
FOO abbreviates package Foo
initializing NRLIB FOO for Foo
compiling exported bar : Integer -> Integer
FOO;bar;2I;1 is replaced by +x1
Cumulative Statistics for Constructor Foo
finalizing NRLIB FOO
Processing Foo for Browser database:
WARNING in |FOO;bar;2I;1| in line 6 :
variable $ is not used.
Misspelled or missing IGNORE declaration?
0 errors, 1 warning
Foo is now explicitly exposed in frame initial
Foo will be automatically loaded when needed from
/home/page/.sage/fricas/algebra/FOO.NRLIB/code
sage: exit
Exiting SAGE (CPU time 0m0.06s, Wall time 0m4.99s).
Exiting spawned Axiom process.
page@sage:~$ ~/sage-3.1.2*/sage
----------------------------------------------------------------------
| SAGE Version 3.1.2.alpha4, Release Date: 2008-09-02 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
sage: print axiom.eval(')lib FOO')
Foo is now explicitly exposed in frame initial
Foo will be automatically loaded when needed from
/home/page/.sage/fricas/algebra/FOO.NRLIB/code
sage: axiom.bar(1)
2
sage:
Regards,
Bill Page.