On Thu, Jan 14, 2010 at 04:05:29PM -0800, Robert Bradshaw wrote:
I actually went to that ticket a bit ago, but didn't see any patch
attached. I'll certainly review this during Sage days if no one else
beats me to it.
Excellent!
For the record: all tests passed this night on my machine with
Hello all,
As some of the new Category code was introduced to Sage, the convention
was preserved from MuPAD of referring to a 'monomial' as a 'coefficient'
times a 'term'. Unfortunately, this conflicted with the existing Sage
convention of referring to a 'term' as a 'coefficient' times a
Hi Jason!
Thanks for handling this so promptly and to the full length!
I haven't tried your code yet. Were you able to make it so that F.term
and F.monomial can be temporarily used interchangeably (thanks to
default values) to smooth out the transition?
Cheers,
Robert Bradshaw wrote:
On Jan 14, 2010, at 9:49 PM, Robert Bradshaw wrote:
On Jan 14, 2010, at 5:46 PM, Dr. David Kirkby wrote:
Dr. David Kirkby wrote:
I tried to build sage-4.3.1.alpha2 in 32-bit mode on a Sun Blade
2000. I've installed Sage on that several times before without
issue. But
Em, I'm puzzled by this too. It builds fine with the Sun compiler
kir...@t2:[~] $ /opt/SUNWspro/bin/cc simple_complex.c
kir...@t2:[~] $ ./a.out
CYTHON_CCOMPLEX 1
but not with gcc.
kir...@t2:[~] $ gcc -Wall simple_complex.c
simple_complex.c: In function '__pyx_t_double_complex_from_parts':
On Thu, Jan 14, 2010 at 10:43 PM, andrejv andrej.vodopi...@gmail.com wrote:
On Jan 15, 6:14 am, Craig Citro craigci...@gmail.com wrote:
Yeah, this is wacky. I can tell you why it's happening, though someone
who's ever used Maxima before should really think about the right fix.
Here's the
Hi Andrej,
On Fri, Jan 15, 2010 at 5:43 PM, andrejv andrej.vodopi...@gmail.com wrote:
SNIP
d2 is defined in the testsuite for the Zeilberger algorithm. It is not
necessary to load the tests, in share/contrib/Zeilberger/
zeilberger.mac remove the last line which loads them.
Thank you very
Robert Bradshaw wrote:
Em, I'm puzzled by this too. It builds fine with the Sun compiler
kir...@t2:[~] $ /opt/SUNWspro/bin/cc simple_complex.c
kir...@t2:[~] $ ./a.out
CYTHON_CCOMPLEX 1
but not with gcc.
kir...@t2:[~] $ gcc -Wall simple_complex.c
simple_complex.c: In function
Hi all,
I was recently introduced to sage. I have looked a bit at reduce-sage
interface. I have started with your William's reduce.py and my current
version is available at
http://www-troja.fjfi.cvut.cz/~liska/asdfgh/sage/reduce.py
I hope it is able to do basic interface. I have seen few
On Jan 15, 9:37 am, William Stein wst...@gmail.com wrote:
On Thu, Jan 14, 2010 at 10:43 PM, andrejv andrej.vodopi...@gmail.com wrote:
On Jan 15, 6:14 am, Craig Citro craigci...@gmail.com wrote:
Yeah, this is wacky. I can tell you why it's happening, though someone
who's ever used Maxima
On Jan 15, 3:26 am, William Stein wst...@gmail.com wrote:
Wow! How does that work?
It depends on the client, but in general the system works by
connecting to several servers concurrently given by the metalink
description file and and downloads partial parts of the same file in
parallel. So, 5
These are all caused by the same issue. Yasm is producing 64 bit
binaries and MPIR is trying to build a 32 bit binary, or vice versa.
How precisely is MPIR being built on these machines. Specifically,
what is the exact configure command issued? I suspect someone is
trying to override the compiler
This is a very old issue. It was fixed by Michael Abshoff years ago.
Who knows why it is broken again.
But I agree, the LD_LIBRARY_PATH_64 should be set correctly.
Bill.
On Jan 14, 9:47 pm, Dr. David Kirkby david.kir...@onetel.net
wrote:
Jaap Spies wrote:
Building of linbox on Open Solaris
Actually, I might be thinking of a similar issue which occurs for OSX
64 bit. So perhaps this just hasn't been fixed for solaris yet.
On Jan 15, 12:46 pm, Bill Hart goodwillh...@googlemail.com wrote:
This is a very old issue. It was fixed by Michael Abshoff years ago.
Who knows why it is broken
On Thu, Jan 14, 2010 at 04:05:29PM -0800, Robert Bradshaw wrote:
I actually went to that ticket a bit ago, but didn't see any patch
attached. I'll certainly review this during Sage days if no one else
beats me to it.
Excellent!
For the record: all tests passed this night on my machine with
Hi,
This part of the interface is actually terrible. In particular, I don't
see the rationale for the use of static's here.
Hopefully this will be all gone when we'll switch to have LinBox and
matrix_modn_dense support use natively the same matrix type (#4258).
But given your compilation
Maybe someone who knows Maxima better could point us in the right
direction?
d2 is defined in the testsuite for the Zeilberger algorithm. It is not
necessary to load the tests, in share/contrib/Zeilberger/
zeilberger.mac remove the last line which loads them.
Andrej
Wow, that's
Clement Pernet wrote:
Hi,
This part of the interface is actually terrible. In particular, I don't
see the rationale for the use of static's here.
Hopefully this will be all gone when we'll switch to have LinBox and
matrix_modn_dense support use natively the same matrix type (#4258).
But given
I think javascript is actually a pretty nice language. It has some really nice
functional features, is resembles Scheme in certain ways. The only problem I
have with javascript is that it is not the same language as sage (python). If
sage were written in Javascript, then of course it would be
Just after successfully built dsage -- which I believe is the last
spkg which gets installed. The sphinx build fails quite strangely.
Running ./sage fails with the same error (TypeError: unsupported
operand parent(s) for '+': 'Integer Ring' and 'Integer Ring')
Gonzalo
Finished installing
So I have no idea what's causing this, but here are at least some
reasonable things to try:
building 'sage.libs.fplll.fplll' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wall -g -Wall -g -fPIC -
I/mnt/usb1/scratch/rlm/sage-4.3.1.alpha3/local/include/fplll -I/mnt/
This could all be avoided if before changing a variable to maxima we
prepended it with _sage_var_ (say), and stripped those off when moving
from maxima back to Sage. This is worth considering...
I think we'll have to do something along these lines.
Basically, right now, any time that one
On Fri, Jan 15, 2010 at 9:42 AM, Robert Bradshaw
rober...@math.washington.edu wrote:
On Jan 15, 2010, at 7:25 AM, Andy Somogyi wrote:
I think javascript is actually a pretty nice language. It has some really
nice functional features, is resembles Scheme in certain ways. The only
problem I
1) Kill the -O3, and see if the file compiles. If so, start bumping it
back up until you see the hang.
With -O2, it compiles fine. With -O3, it seems to hang.
2) Kill the -w at the end, so you can at least see some commentary
from the compiler. (-w suppresses all warnings.)
* With -O3,
Robert Miller wrote:
One of the patches recently merged into rc0 is causing fplll to take
forever to compile on {sage, boxen...}.math:
building 'sage.libs.fplll.fplll' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wall -g -Wall -g -fPIC -
1) Kill the -O3, and see if the file compiles. If so, start bumping it
back up until you see the hang.
With -O2, it compiles fine. With -O3, it seems to hang.
Well, this means we've got an easy workaround for the time being.
Glancing at the two sets of warning messages below, I don't see
On Jan 15, 2010, at 9:58 AM, Craig Citro wrote:
As to Craig's point, yes you can make another Maxima session, but in
general all internal Maxima use either uses _maxima_(), which calls
the calculus copy, or directly uses the calculus copy of Maxima.
For instance for assumptions we really want
Bill Hart wrote:
Actually, I might be thinking of a similar issue which occurs for OSX
64 bit. So perhaps this just hasn't been fixed for solaris yet.
Micheal made endless fixes like
if [ $SAGE64 = yes -a `uname` = Darwin ] then ;
some OS X fix.
fi
Since 99% of those fixes, such as adding
Gonzalo Tornaria wrote:
sys 7m59.726s
sphinx-build -b html -d
/scratch/tornaria/sage-4.3.1.alpha3/devel/sage/doc/output/doctrees/en/developer
/scratch/tornaria/sage-4.3.1.alpha3/devel/sage/doc/en/developer
I thought you had made a mistake, but see your path contains 4.3.1.alpha3. Is
On Fri, Jan 15, 2010 at 4:45 PM, Dr. David Kirkby
david.kir...@onetel.net wrote:
Gonzalo Tornaria wrote:
sys 7m59.726s
sphinx-build -b html -d
/scratch/tornaria/sage-4.3.1.alpha3/devel/sage/doc/output/doctrees/en/developer
I think we do. Maxima sessions can have so much state that it's nice to keep
them separate to ensure consistency of the calculus modules. Also, that
means you won't be accidently clobbering your calculus variables, functions,
etc.
I think I agree in principle, but maybe not in practice. For
On Fri, Jan 15, 2010 at 10:16 AM, Robert Bradshaw
rober...@math.washington.edu wrote:
On Jan 15, 2010, at 9:58 AM, Craig Citro wrote:
As to Craig's point, yes you can make another Maxima session, but in
general all internal Maxima use either uses _maxima_(), which calls
the calculus copy, or
On Fri, Jan 15, 2010 at 11:07 AM, Craig Citro craigci...@gmail.com wrote:
I think we do. Maxima sessions can have so much state that it's nice to keep
them separate to ensure consistency of the calculus modules. Also, that
means you won't be accidently clobbering your calculus variables,
On Jan 14, 11:43 pm, andrejv andrej.vodopi...@gmail.com wrote:
d2 is defined in the testsuite for the Zeilberger algorithm. It is not
necessary to load the tests, in share/contrib/Zeilberger/
zeilberger.mac remove the last line which loads them.
As a superficial correction, I threw a bit of
(2) making the
assume() command available at top-level point to
sage.calculus.calculus.maxima.assume *would* make it so that the user
could easily compute the integral that's frustrating them.
Again, (2) *was* the case since the beginning, and if it isn't now, it
is because somebody
On Jan 15, 7:00 am, kcrisman kcris...@gmail.com wrote:
Maybe Nils has a comment on whether library use of Maxima would make
it easier to work around this problem? I know he's hoping to do
something with this at the Bug Days.
If we use maxima via a library interface and communicate
2) We start them with different options, which is why maxima(d2)
just returns d2, but sage.calculus.calculus.maxima(d2) returns the
factorial business that started this thread. Do we want to have some
of the options used to start sage.calculus.calculus.maxima also used
in
On Jan 15, 2010, at 11:14 AM, William Stein wrote:
On Fri, Jan 15, 2010 at 10:16 AM, Robert Bradshaw
rober...@math.washington.edu wrote:
On Jan 15, 2010, at 9:58 AM, Craig Citro wrote:
As to Craig's point, yes you can make another Maxima session, but
in
general all internal Maxima use
Again, (2) *was* the case since the beginning, and if it isn't now, it
is because somebody screwed stuff up and introduced a *huge* bug into
Sage recently.
We have done a few things in assumptions in the last few months, so
that is possible. However, in this case none of the doctests caught
This also occurs on debian64 and opensuse64, in the build farm.
On Fri, Jan 15, 2010 at 10:55 AM, Gonzalo Tornaria
torna...@math.utexas.edu wrote:
On Fri, Jan 15, 2010 at 4:45 PM, Dr. David Kirkby
david.kir...@onetel.net wrote:
Gonzalo Tornaria wrote:
sys 7m59.726s
sphinx-build -b html
On Jan 15, 1:37 am, William Stein wst...@gmail.com wrote:
This could all be avoided if before changing a variable to maxima we
prepended it with _sage_var_ (say), and stripped those off when moving
from maxima back to Sage. This is worth considering...
Well, I think there is a neater way to
Well, I think there is a neater way to go about it, which is
to exploit the Lisp package (i.e. namespace) machinery.
In summary, one can define groups of symbols at run time.
To quote the Zen of Python:
Namespaces are one honking great idea -- let's do more of those!
-cc
--
To post to this
* This is what mpir's config is:
CC Version
gcc -v
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
Hi Vincent,
That thread probably was about the old Live CD. The current Live CD is done by
Lucio Lastra, and the instruction as different.
On Fri, Jan 15, 2010 at 3:28 PM, Vincent D 20100.delecr...@gmail.com wrote:
The link of the old (2006) thread dealing about how to build the live
cd is
On 2010-Jan-14 22:15:19 +, Dr. David Kirkby david.kir...@onetel.net
wrote:
Here's the patch.
http://trac.sagemath.org/sage_trac/attachment/ticket/7898/singular-variables-to-names.patch
I'm ambivalent about using 'cp' or '$CP' etc (though there are slight
debugging advantages to the latter)
I like this project to create Live CDs : http://www.linux-live.org/ ,
but I know Lucio
currently uses another method.
On Fri, Jan 15, 2010 at 3:34 PM, Alfredo Portes doyenatc...@gmail.com wrote:
Hi Vincent,
That thread probably was about the old Live CD. The current Live CD is done by
Lucio
On 2010-Jan-15 12:21:09 -0800, Robert Miller r...@rlmiller.org wrote:
* This is what mpir's config is:
CC Version
gcc -v
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
...
I'm not sure whether you are trying to build a 32-bit or 64-bit
sage (there's nothing in prereq which clearly states one way or
the other) but it looks like mpir is building all the assembler
code in 64-bit mode and all the C code in 32-bit mode. That
definitely isn't going to work.
This is
Robert Miller wrote:
I'm not sure whether you are trying to build a 32-bit or 64-bit
sage (there's nothing in prereq which clearly states one way or
the other) but it looks like mpir is building all the assembler
code in 64-bit mode and all the C code in 32-bit mode. That
definitely isn't going
Robert Bradshaw wrote:
Em, I'm puzzled by this too. It builds fine with the Sun compiler
kir...@t2:[~] $ /opt/SUNWspro/bin/cc simple_complex.c
kir...@t2:[~] $ ./a.out
CYTHON_CCOMPLEX 1
but not with gcc.
I'll report this as a gcc bug, as that would seem the most likely reason.
Of course,
This was caused by #7818. See ticket for details.
On Fri, Jan 15, 2010 at 11:53 AM, Robert Miller r...@rlmiller.org wrote:
This also occurs on debian64 and opensuse64, in the build farm.
On Fri, Jan 15, 2010 at 10:55 AM, Gonzalo Tornaria
torna...@math.utexas.edu wrote:
On Fri, Jan 15, 2010
On Jan 15, 2010, at 1:46 PM, Dr. David Kirkby wrote:
Robert Bradshaw wrote:
Em, I'm puzzled by this too. It builds fine with the Sun compiler
kir...@t2:[~] $ /opt/SUNWspro/bin/cc simple_complex.c
kir...@t2:[~] $ ./a.out
CYTHON_CCOMPLEX 1
but not with gcc.
I'll report this as a gcc bug, as
Ultimately, this was caused by #7818 removing the -fno-strict-aliasing
option. This only effects -O3 compiled code, which is where gcc starts
using strict aliasing if it can. Thanks to RWB for helping with this.
On Fri, Jan 15, 2010 at 10:08 AM, Craig Citro craigci...@gmail.com wrote:
1) Kill
Another victim of 7818 :)
On Fri, Jan 15, 2010 at 12:35 PM, Peter Jeremy peterjer...@acm.org wrote:
On 2010-Jan-14 22:15:19 +, Dr. David Kirkby david.kir...@onetel.net
wrote:
Here's the patch.
http://trac.sagemath.org/sage_trac/attachment/ticket/7898/singular-variables-to-names.patch
I'm
54 matches
Mail list logo
