You can find the new package here:
http://sage.math.washington.edu/home/page/packages/fricas-1.0.3.spkg
I would really appreciate it if some people interested in using FriCAS
in Sage would download and test this install
$ sage -f fricas-1.0.3.spkg
If it builds for several people, then it will supersede the package
currently being distributed which works only if gcl is installed
separately.
There is a known problem with using FriCAS on some linux platforms
that seems to be related to the behaviour of readline in clisp when
called from pexpect. In some cases there is a failure of
synchronization that results in a communication problem between Sage
and the FriCAS process. For example the command:
sage: axiom('1+1')
will initially seem to produce no output (You should of course expect
to see '2') and subsequent commands may produce output from previously
entered commands.
A work-a-round is to force clisp to disable readline by forcing clisp
input and output to different streams. So far as I know this can only
be done by running FriCAS inside a separate shell and piping output
through another process such as 'cat'.
If this happens on your linux distribution please let me know. To
corrent the problem you must patch the file
'./devel/sage-main/sage/interfaces/axiom.py' as follows:
Expect.__init__(self,
name = 'axiom',
prompt = '\([0-9]+\) -> ',
command = "sh -c 'axiom -nox -noclef | cat'",
...
Rebuild Sage with the command
$ sage -b
(If you are applying this change to a binary install of Sage, the
first time you use -b it will generate a large amount of output and
take about 20 minutes to re-compile the core part of Sage.) Then
restart Sage and try FriCAS again:
sage: axiom('1+1')
If this affects a large number of users, it may be necessary to
include this change in a new releases of Sage.
Regards,
Bill Page.
On Intel OS X 10.5 absolutely everything (install, usage, tests)
worked perfectly.
William
This happens on amd64 hardy heron. Sage was compiled from source;
fricas was installed by downloading the spkg file and using your sage
-i fricas*
command above.
wdj@hera:~/sagefiles/sage-3.0.6.alpha0$ ./sage
----------------------------------------------------------------------
| SAGE Version 3.0.6.alpha0, Release Date: 2008-07-16 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
sage: axiom('1+1')
sage: axiom('1+1')
2
sage: axiom('1+1')
sage: axiom('1+1')
2
sage:
Exiting SAGE (CPU time 0m0.13s, Wall time 0m13.57s).
Exiting spawned Axiom process.
wdj@hera:~/sagefiles/sage-3.0.6.alpha0$ ./sage
----------------------------------------------------------------------
| SAGE Version 3.0.6.alpha0, Release Date: 2008-07-16 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
sage: axiom('1+1')
sage: axiom('1+1')
2
sage: axiom('1+1')
sage: axiom('1+1')
2
>
> A work-a-round is to force clisp to disable readline by forcing clisp
> input and output to different streams. So far as I know this can only
> be done by running FriCAS inside a separate shell and piping output
> through another process such as 'cat'.
>
> If this happens on your linux distribution please let me know. To
> corrent the problem you must patch the file
> './devel/sage-main/sage/interfaces/axiom.py' as follows:
>
> Expect.__init__(self,
> name = 'axiom',
> prompt = '\([0-9]+\) -> ',
> command = "sh -c 'axiom -nox -noclef | cat'",
> ...
>
> Rebuild Sage with the command
>
> $ sage -b
This had no effect. In other words, I changed line 156 (and only that line) in
the axiom.py file as indicated then rebuilt sage and got exactly the
same output as
reported above.
> Bill Page wrote:
>> There is a known problem with using FriCAS on some linux platforms
>> that seems to be related to the behaviour of readline in clisp when
>> called from pexpect. In some cases there is a failure of
>> synchronization that results in a communication problem between
>> Sage and the FriCAS process. For example the command:
>>
>> sage: axiom('1+1')
>>
>> will initially seem to produce no output (You should of course expect
>> to see '2') and subsequent commands may produce output from
>> previously entered commands.
>
On Wed, Jul 23, 2008 at 3:20 PM, David Joyner wrote:
> This happens on amd64 hardy heron. Sage was compiled from source;
> fricas was installed by downloading the spkg file and using your sage
> -i fricas* command above.
>
It happens for me on the sage.math computer when installing locally in
my home directory, but not on my SuSE linux system. I am still at a
loss to explain these results but I wonder if we might also need to
consider whether there is any systematic difference between multi-
versus single processor configurations.
>> command = "sh -c 'axiom -nox -noclef | cat'",
This change to axiom.py definitely corrects the behavior on sage.math for me.
>
> This had no effect. In other words, I changed line 156 (and only that line)
> in the axiom.py file as indicated then rebuilt sage and got exactly the
> same output as reported above.
>
Hmmm.... well with this counter example I guess I am willing to stop
blaming readline :-)
David, were you able to run the previous clisp-based version of Axiom
on this system? (Note: The version 1.0.2 that is distributed now with
the Sage optional packages is actually based on GCL, not clisp.
Readline is automatically disabled in the GCL-based build and it has
worked for me in all cases, however I think we all agree that the GCL
dependence is undesirable for other reasons.) It was partly for the
reason that I suspected readline.
Although I have tried to log and debug the actual handshaking between
Sage pexpect and Axiom, I have never been able to produce consistent
results except as I indicated in my proposed change. But I have to
admit that I do not consider myself an expert on the details of how
all this works - especially when readline is sandwiched in between
pexpect and axiom. Obviously we need someone of wizard class to take a
closer look ...
Regards,
Bill Page.
Sorry!! It *does* fix it for me - I missed the inner quote marks. (I
need to clean my
glasses and my computer monitor...) Everything works as expected with
that change.
>
>>
>> This had no effect. In other words, I changed line 156 (and only that line)
>> in the axiom.py file as indicated then rebuilt sage and got exactly the
>> same output as reported above.
>>
>
> Hmmm.... well with this counter example I guess I am willing to stop
> blaming readline :-)
>
> David, were you able to run the previous clisp-based version of Axiom
> on this system? (Note: The version 1.0.2 that is distributed now with
> the Sage optional packages is actually based on GCL, not clisp.
> Readline is automatically disabled in the GCL-based build and it has
> worked for me in all cases, however I think we all agree that the GCL
> dependence is undesirable for other reasons.) It was partly for the
> reason that I suspected readline.
>
The 1.0.2 version installs fine but I get worst behaviour:
sage: axiom('1+1')
sage: axiom('1+1')
sage:
When trying to build, I get the following error on 64-bit Ubuntu 8.04:
checking for notangle... notangle
checking for noweave... noweave
checking compiled Lisp file extension... *** - invalid byte #xC3 in
CHARSET:ASCII conversion
configure: error: Could not determine extension for compiled Lisp files
***********************************************************
Failed to configure Axiom.
***********************************************************
--Mike
Great, thanks.
>>...
>> David, were you able to run the previous clisp-based version of Axiom
>> on this system? (Note: The version 1.0.2 that is distributed now with
>> the Sage optional packages is actually based on GCL, not clisp.
>> Readline is automatically disabled in the GCL-based build and it has
>> worked for me in all cases, however I think we all agree that the GCL
>> dependence is undesirable for other reasons.) It was partly for the
>> reason that I suspected readline.
>>
>
> The 1.0.2 version installs fine but I get worst behaviour:
>
> sage: axiom('1+1')
>
> sage: axiom('1+1')
>
> sage:
>
Oh yes, I now recall what I wrote too quickly above. There was some
minor change to some commented out code in 'axiom.py' to support gcl
as well - it is necessary to remove comments to re-enable the command
that disables readline. Any, I think it is irrelevant now.
Regards,
Bill Page.
Thank you so much for working on this...
> http://sage.math.washington.edu/home/page/packages/fricas-1.0.3.spkg
It seems to work nicely for me.
Ralf
It builds for 12 minutes on my laptop.
Yes, unfortunately this affects me. Debian sid. And your patch indeed
fixes that.
BTW, I also tried to compile the latest fricas a week ago by hand and
the compilation segfaulted. So I was curious if this spkg works and
I am surprised that FriCAS not only compiled but it was also very
fast. My last experience with Axiom was that it compiled for 10 hours
and then failed. So reducing 10 hours to 12 minutes is a great job.
Is there a way to forbid fricas to print the output? I'd like to
measure how fast it expands compared to SymPy, but I don't want to
measure the time needed for printing the expression (when it's very
long).
I am asking because currently FriCAS expansion is slower than a pure
Python in the latest SymPy,...
In [1]: e=(x+y+z+1)**20
In [2]: time f=e.expand()
CPU times: user 0.93 s, sys: 0.00 s, total: 0.94 s
Wall time: 0.94 s
sage: time axiom("(x+y+z+1)**20")
CPU times: user 0.39 s, sys: 0.04 s, total: 0.43 s
Wall time: 1.24 s
But when Mateusz (another sympy developer) was at my place, we tried
that in Axiom on his laptop and it was like 10x faster than sympy. So
something is slowing things down here by the factor of 10x. It may be
worth investigating.
Ondrej
Good.
>...
>> There is a known problem with using FriCAS on some linux
>> platforms that seems to be related to the behaviour of readline in
>> clisp when called from pexpect. In some cases there is a failure
>> of synchronization that results in a communication problem
>> between Sage and the FriCAS process.
> ...
> Yes, unfortunately this affects me. Debian sid. And your patch
> indeed fixes that.
>
Thanks for the report. I guess I will recommend to the Sage developers
to include this patch in the next release of Sage. But as you know,
Sage is moving quickly so perhaps soon we will be posting a build
based on ECL which probably wont have this problem.
> BTW, I also tried to compile the latest fricas a week ago by hand
> and the compilation segfaulted.
Maybe a known problem with GCL on some platforms.
> So I was curious if this spkg works and I am surprised that
> FriCAS not only compiled but it was also very fast.
This version of FriCAS is built from cached lisp code using clisp.
clisp is know to be fast to compile but slow to execute.
> Is there a way to forbid fricas to print the output?
In native FriCAS add a ; to the end of the line.
> I'd like to measure how fast it expands compared to SymPy, but
> I don't want to measure the time needed for printing the expression
> (when it's very long).
>
> I am asking because currently FriCAS expansion is slower than a
> pure Python in the latest SymPy,...
>
> In [1]: e=(x+y+z+1)**20
>
> In [2]: time f=e.expand()
> CPU times: user 0.93 s, sys: 0.00 s, total: 0.94 s
> Wall time: 0.94 s
>
Using GCL on Windows with a 3 GHz. dual processor I get:
(1) -> )set message time on
(2) -> e=(x+y+z+1)**20;
Type: Equation Polynomial Integer
Time: 0.03 (EV) = 0.03 sec
>
> sage: time axiom("(x+y+z+1)**20")
> CPU times: user 0.39 s, sys: 0.04 s, total: 0.43 s
> Wall time: 1.24 s
>
This could be mostly due to clisp.
> But when Mateusz (another sympy developer) was at my place, we
> tried that in Axiom on his laptop and it was like 10x faster than
> sympy. So something is slowing things down here by the factor of
> 10x. It may be worth investigating.
>
FriCAS built with ECL is supposed to be even faster than GCL but not
quite as fast as SBCL.In other words, a lot depends on the Lisp you
use.
Regards,
Bill Page.
Yes, that is our experience.
>
>>
>> sage: time axiom("(x+y+z+1)**20")
>> CPU times: user 0.39 s, sys: 0.04 s, total: 0.43 s
>> Wall time: 1.24 s
>>
>
> This could be mostly due to clisp.
>
>> But when Mateusz (another sympy developer) was at my place, we
>> tried that in Axiom on his laptop and it was like 10x faster than
>> sympy. So something is slowing things down here by the factor of
>> 10x. It may be worth investigating.
>>
>
> FriCAS built with ECL is supposed to be even faster than GCL but not
> quite as fast as SBCL.In other words, a lot depends on the Lisp you
> use.
Great. So this means that clisp is quite useless, because it's slower
than an interpreted language Python, right? I am looking forward for
the ECL build.
Ondrej
Depends... clisp is (mostly) a bytecode interpreter not so different
from the Python virtual machine. If you want Lisp with fast
compilation and don't care too much about speed, clisp is a probably
still a good choice.
> I am looking forward for the ECL build.
>
ECL compiles to native machine object code (like GCL) but it's
compiler is much slower. ECL is still new and being actively
developed. If anyone wants to become involved in the ECL build for
FriCAS, please drop by the fricas-devel list.
Regards,
Bill Page.