Jonathan Bober wrote:
I just posted http://trac.sagemath.org/sage_trac/ticket/7918 but I
thought I would also send an email here to catch the attention of
whomever made the change that caused this slowdown. Hopefully this will
be easy to fix.
Somewhere between sage 4.1 and sage 4.3, log(x) got r
I just posted http://trac.sagemath.org/sage_trac/ticket/7918 but I
thought I would also send an email here to catch the attention of
whomever made the change that caused this slowdown. Hopefully this will
be easy to fix.
Somewhere between sage 4.1 and sage 4.3, log(x) got really slow when x
is a f
brandon.bar...@gmail.com wrote:
psrinfo -v seems to be one option, though I think /proc/cpuinfo seems
to be better in linux.
I gave the output of prsinfo below, but it shows nothing more useful than the
fact there are 8 virtual processors running at 3325 MHz. (It's a quad core Xeon,
with two
psrinfo -v seems to be one option, though I think /proc/cpuinfo seems
to be better in linux.
On Jan 12, 11:08 pm, "Dr. David Kirkby"
wrote:
> Bill Hart wrote:
> > MPIR should detect all known intel and amd CPU's (MPIR 1.3 will also
> > detect via and atom's), but for some reason it doesn't detec
The dropdown menu that shows the different interfaces is missing scilab.
Using %scilab in a notebook cell works though
I opened a ticket about this in
http://trac.sagemath.org/sage_trac/ticket/7911
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this
Bill Hart wrote:
MPIR should detect all known intel and amd CPU's (MPIR 1.3 will also
detect via and atom's), but for some reason it doesn't detect yours.
To perform the detection it asks the CPU what it is, using the CPUID
instruction.
2 possiblities:
1) The CPUID instruction is returning the
MPIR should detect all known intel and amd CPU's (MPIR 1.3 will also
detect via and atom's), but for some reason it doesn't detect yours.
To perform the detection it asks the CPU what it is, using the CPUID
instruction.
2 possiblities:
1) The CPUID instruction is returning the wrong thing
2) It
The algorithm QUICK FACTOR in the von zur Gather - Kaltofen paper
looks very easy to implement and only returns failure if you use a
probabilistic univariate factoring algorithm.
You could implement that in Sage probably with a very small amount of
work.
I don't suggest you'll get it down to 0.1s
Dr. David Kirkby wrote:
Jaap Spies wrote:
Shall I open a trac ticket?
Jaap
I believe you should open a ticket for this.
This is http://trac.sagemath.org/sage_trac/ticket/7910
Jaap
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this grou
Bill Hart wrote:
There aren't any 64 bit 486's. It's misdetecting your CPU.
Bill.
What can I do about that?
Jaap
On Jan 12, 3:31 pm, Jaap Spies wrote:
In Open Solaris in my VirtualBox running under Fedora 12 64 bit on an Intel i7
860:
Finished extraction
***
There aren't any 64 bit 486's. It's misdetecting your CPU.
Bill.
On Jan 12, 3:31 pm, Jaap Spies wrote:
> In Open Solaris in my VirtualBox running under Fedora 12 64 bit on an Intel
> i7 860:
>
> Finished extraction
>
> Host system
> uname -a:
2010/1/12 William Stein :
> On Tue, Jan 12, 2010 at 12:21 PM, John Cremona wrote:
>> In the following:
>>
>> sage: EllipticCurve(0)
>> /home/john/sage-4.3.1.alpha1/local/bin/sage-ipython:1:
>> DeprecationWarning: 'EllipticCurve(j)' is deprecated; use
>> 'EllipticCurve_from_j(j)' or 'EllipticCurve(
On Tue, Jan 12, 2010 at 12:21 PM, John Cremona wrote:
> In the following:
>
> sage: EllipticCurve(0)
> /home/john/sage-4.3.1.alpha1/local/bin/sage-ipython:1:
> DeprecationWarning: 'EllipticCurve(j)' is deprecated; use
> 'EllipticCurve_from_j(j)' or 'EllipticCurve(j=j)' instead.
> #!/usr/bin/env p
In the following:
sage: EllipticCurve(0)
/home/john/sage-4.3.1.alpha1/local/bin/sage-ipython:1:
DeprecationWarning: 'EllipticCurve(j)' is deprecated; use
'EllipticCurve_from_j(j)' or 'EllipticCurve(j=j)' instead.
#!/usr/bin/env python
Elliptic Curve defined by y^2 = x^3 + 1 over Rational Field
Dear Tim,
On Tue, Jan 12, 2010 at 10:58:23PM +0800, Tim Joseph Dumol wrote:
>I've been wondering why sage.combinat.combinat.combinations still exists,
>when sage.combinat.combination.Combinations is much faster, being native
>Sage code, and thus not requiring GAP interfacing (a
The server which had the problem was running 4.3.
On the same machine I started another server using 4.3.1.alpha1 and
there was no problem. That was with my usual user account, not the
sage account.
>From the sage account, I copied my 4.3.1.alpha1 build from my own user
account, but I could not
Jaap Spies wrote:
Dr. David Kirkby wrote:
Jaap Spies wrote:
In Open Solaris in my VirtualBox running under Fedora 12 64 bit on an
Intel i7 860:
[...]
In contrast Jaap is running some other operating system (Linux of some
sort ??), and using VirtualBox to install Open Solaris. I doubt that
Dr. David Kirkby wrote:
Jaap Spies wrote:
In Open Solaris in my VirtualBox running under Fedora 12 64 bit on an
Intel i7 860:
[...]
In contrast Jaap is running some other operating system (Linux of some
sort ??), and using VirtualBox to install Open Solaris. I doubt that
makes any differen
Jaap Spies wrote:
In Open Solaris in my VirtualBox running under Fedora 12 64 bit on an
Intel i7 860:
Finished extraction
Host system
uname -a:
SunOS opensolaris 5.11 snv_111b i86pc i386 i86pc Solaris
*
In Open Solaris in my VirtualBox running under Fedora 12 64 bit on an Intel i7
860:
Finished extraction
Host system
uname -a:
SunOS opensolaris 5.11 snv_111b i86pc i386 i86pc Solaris
***
2010/1/12 YannLC :
>
>
> On Jan 12, 3:44 pm, John Cremona wrote:
>> No, the van Hoeij / Belabas algorithms are for univariate polynomials,
>> over Q (and then over number fields). Pari does not have multivariate
>> polynomial factorization
>
> It might not be implemented in Pari, but the algorith
Willem Jan Palenstijn wrote:
On Tue, Jan 12, 2010 at 01:21:51AM -0800, Robert Bradshaw wrote:
Since the goal is to remove the -j flags, why not
MAKE=`echo $MAKE | sed -E "s/-j +[^ ]+|--jobs=[^ ]+//g"`
This way if any other flags were part of $MAKE they wouldn't get dropped
as well. (Not sure
2010/1/12 William Stein :
> Maybe somebody who speaks Spanish can email this person back?
>
>
> -- Forwarded message --
> From: Kelvy Segura Cuevas
> Date: 2010/1/12
> Subject: Manual en español
> To: "wst...@gmail.com"
>
>
> Estimado William Stein,
>
>
>
> Donde podría encontrar
Robert Bradshaw wrote:
Since the goal is to remove the -j flags, why not
MAKE=`echo $MAKE | sed -E "s/-j +[^ ]+|--jobs=[^ ]+//g"`
This way if any other flags were part of $MAKE they wouldn't get dropped
as well. (Not sure if Solaris can handle extended regex...but that' easy
to fix if it can'
On Jan 12, 3:44 pm, John Cremona wrote:
> No, the van Hoeij / Belabas algorithms are for univariate polynomials,
> over Q (and then over number fields). Pari does not have multivariate
> polynomial factorization
It might not be implemented in Pari, but the algorithm has been
further extended a
Hello,
I've been wondering why sage.combinat.combinat.combinations still exists,
when sage.combinat.combination.Combinations is much faster, being native
Sage code, and thus not requiring GAP interfacing (also more reliable, I
suppose). The huge speed differnce can be seen here:
{{{
sage: timeit(
Maybe somebody who speaks Spanish can email this person back?
-- Forwarded message --
From: Kelvy Segura Cuevas
Date: 2010/1/12
Subject: Manual en español
To: "wst...@gmail.com"
Estimado William Stein,
Donde podría encontrar un manual completo de Sage en español para
poderl
On Tue, Jan 12, 2010 at 4:05 AM, John Cremona wrote:
> I'm running a server under user "sage" using a pool of users sage0,
> sage1 etc to run the worksheets. Sage 4.3 on 64-bit ubuntu. All
> works fine with normal Sage cells, but I get this error when I put
> %magma at the top of a new cell in a
On Tue, Jan 12, 2010 at 6:13 AM, John Cremona wrote:
> thanks for both replies! OK, so there are various fast algorithms and
> Magma has implemented at least one of them. Sage is using Singular.
> I wonder why Singular has not got a fast algorithm for this?
My impression is that historically th
No, the van Hoeij / Belabas algorithms are for univariate polynomials,
over Q (and then over number fields). Pari does not have multivariate
polynomial factorization:
j...@selmer%sage -gp
Reading GPRC: /etc/gprc ...Done.
GP/PARI CALCULATOR Version 2.3.3 (released)
Looking at Mark van Hoeij's website, he has a (maple) implementation
of his algorithm:
http://www.math.fsu.edu/~hoeij/knapsack.html
he also mentions
"My implementation is not tuned in the best possible way. A much
better way (more efficient, more robust and simpler) to tune the
algorithm is give
thanks for both replies! OK, so there are various fast algorithms and
Magma has implemented at least one of them. Sage is using Singular.
I wonder why Singular has not got a fast algorithm for this?
For this application of mine, I need to do a number of one-off
factorizations like this in order
On Jan 12, 2:46 pm, javier wrote:
> There are indeed well known (sort of) fast algorithms for
> factorization of multivariable polynomials over finite
> fields:http://portal.acm.org/citation.cfm?id=808748http://www.jstor.org/stable/2008063?seq=1
>
> In the second paper there is a particular (pr
There are indeed well known (sort of) fast algorithms for
factorization of multivariable polynomials over finite fields:
http://portal.acm.org/citation.cfm?id=808748
http://www.jstor.org/stable/2008063?seq=1
In the second paper there is a particular (probabilistic) algorithm
for bivariate polynomi
I have a polynomial of degree 378 in 2 variables over GF(2), which I
need to factor. (In one of the variables it has degree 84 and has a
degree 6 factor which I need to find).
Sage fails to do this after many hours. Magma can do it in 0.15s so
it cannot be that hard. So how come Sage cannot?!!
I'm running a server under user "sage" using a pool of users sage0,
sage1 etc to run the worksheets. Sage 4.3 on 64-bit ubuntu. All
works fine with normal Sage cells, but I get this error when I put
%magma at the top of a new cell in a new worksheet:
Cell contents:
%magma
2+2;
Output:
Traceb
On Tue, Jan 12, 2010 at 01:21:51AM -0800, Robert Bradshaw wrote:
> Since the goal is to remove the -j flags, why not
>
> MAKE=`echo $MAKE | sed -E "s/-j +[^ ]+|--jobs=[^ ]+//g"`
>
> This way if any other flags were part of $MAKE they wouldn't get dropped
> as well. (Not sure if Solaris can handle
2010/1/12 javier :
> On Jan 12, 12:47 am, William Stein wrote:
>> Isn't the case of non-prime fields also already in Sage? It was in my
>> example.
>
> The __call__ function for a non-prime field yes, was already defined.
> What wasn't was the conversion of a gap non-prime field into a sage
> pr
Since the goal is to remove the -j flags, why not
MAKE=`echo $MAKE | sed -E "s/-j +[^ ]+|--jobs=[^ ]+//g"`
This way if any other flags were part of $MAKE they wouldn't get
dropped as well. (Not sure if Solaris can handle extended regex...but
that' easy to fix if it can't.)
- Robert
On Ja
39 matches
Mail list logo
