On Dec 20, 2007 8:18 AM, Carl Witty <[EMAIL PROTECTED]> wrote:
>
> On Dec 19, 4:50 pm, "Ted Kosan" <[EMAIL PROTECTED]> wrote:
> > The following code works in version 2.8.13 of SAGE:
> >
> > a = (16*x - 13)/6 == (3*x + 5)/2 - (4 - x)/3
> >
> > But when I execute it in version 2.9, the followin
On Dec 19, 4:50 pm, "Ted Kosan" <[EMAIL PROTECTED]> wrote:
> The following code works in version 2.8.13 of SAGE:
>
> a = (16*x - 13)/6 == (3*x + 5)/2 - (4 - x)/3
>
> But when I execute it in version 2.9, the following error is generated:
>
> Traceback (most recent call last):
> File "", lin
Here is a graph that uses slightly bigger coefficients, up to 1
bits.
http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/factor2.png
I don't see the speed increase you mentioned for large coefficients,
but this might be due to some special properties of the polynomials
you are
On Dec 20, 5:31 am, "Minh Nguyen" <[EMAIL PROTECTED]> wrote:
Hello,
you patch is very much appreciated and is now #1571.
Cheers,
Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, sen
--- sage-2.8.15/devel/doc-main/tut/tut.tex 2007-12-14
13:05:11.0 +1100
+++ sage-2.8.16/devel/doc-main/tut/tut.tex 2007-12-20
15:17:58.0 +1100
@@ -191,7 +191,7 @@
\ref{sec:compile}), and
\item
{\bf Scripts:}
-by writing a write stand-alone Python scripts that use the \s
Oh, I also forgot to mention, the polynomial sizes are sizes of polys
a and b where we are factoring a*b. So roughly speaking you should
double the bitsizes and poly lengths if you want the sizes of the
polys being factored. I made no attempt to ensure a and b are
irreducible, so they may have fac
Oops, I mean factoring in ZZ[x].
I should also point out that for any given bitsize and polynomial
length the shortest time is taken in each case. This is of course a
stupid way to time factorisation, but it gives a starting point I
suppose.
Bill.
On 20 Dec, 02:39, Bill Hart <[EMAIL PROTECTED]>
Joel,
I agree with your summary. Here is a graph I plotted timing Pari (red)
vs NTL (blue) for factoring in ZZ, where there are at least two
polynomial factors.
http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/factor.png
The scale is log to the base 2. At about length 256 polyno
On Dec 19, 7:59 pm, Francis Clarke <[EMAIL PROTECTED]> wrote:
> --- a/sage/rings/number_field/number_field.py Sun Dec 16 06:37:16
> 2007 -0800
> +++ b/sage/rings/number_field/number_field.py Wed Dec 19 18:54:54
> 2007 +
> @@ -751,7 +751,7 @@ class NumberField_generic(number_field_b
>
>
The following code works in version 2.8.13 of SAGE:
a = (16*x - 13)/6 == (3*x + 5)/2 - (4 - x)/3
But when I execute it in version 2.9, the following error is generated:
Traceback (most recent call last):
File "", line 1, in
File "/home/tkosan/.sage/sage_notebook/worksheets/admin/0/cod
I get 6us per loop for the exponentiation in NTL on sage.math.
On 20 Dec, 00:19, Bill Hart <[EMAIL PROTECTED]> wrote:
> I get about 7us per loop on sage.math for Pari for the exponentiation.
> So perhaps this is all architecture dependent. This would not surprise
> me in the slightest.
>
> At any
you must use gcc >= 3.4
- William
(Sent from my iPhone.)
On Dec 19, 2007, at 3:35 PM, Daniel Bump <[EMAIL PROTECTED]>
wrote:
>
>
> Sage 2.9 fails to build on this machine running Debian Sarge. The
> ggc version is 3.3.5.
>
> gcc version 3.3.5 (Debian 1:3.3.5-13)
> Kernel 2.6.12.6 i686 GNU/Li
On Dec 19, 2007, at 7:19 PM, Bill Hart wrote:
>
> I get about 7us per loop on sage.math for Pari for the exponentiation.
> So perhaps this is all architecture dependent. This would not surprise
> me in the slightest.
>
> At any rate, I suspect the algorithms used for factorisation are
> implemen
I get about 7us per loop on sage.math for Pari for the exponentiation.
So perhaps this is all architecture dependent. This would not surprise
me in the slightest.
At any rate, I suspect the algorithms used for factorisation are
implemented quite differently between NTL and Pari. Since both Pari
a
On 19 Dec, 18:40, "Joel B. Mohler" <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 19, 2007 at 06:03:32PM +, John Cremona wrote:
> > I'm surprised by your comment about integer arithmetic, since both
> > pari and NTL use gmp. AT least, they both *can* use gmp though it
> > might not be the default
On Dec 19, 11:35 pm, Daniel Bump <[EMAIL PROTECTED]> wrote:
Hi Daniel,
> Sage 2.9 fails to build on this machine running Debian Sarge. The
> ggc version is 3.3.5.
>
> gcc version 3.3.5 (Debian 1:3.3.5-13)
> Kernel 2.6.12.6 i686 GNU/Linux
We require at least gcc 3.4 since FLINT and other packa
Sage 2.9 fails to build on this machine running Debian Sarge. The
ggc version is 3.3.5.
gcc version 3.3.5 (Debian 1:3.3.5-13)
Kernel 2.6.12.6 i686 GNU/Linux
Log exerpt below.
Daniel Bump
periods.cc: In constructor `periods_via_lfchi::periods_via_lfchi(const level*,
const newform*)':
peri
On Dec 19, 2007, at 4:07 AM, Joel B. Mohler wrote:
> On Tuesday 18 December 2007 22:54, Jason Grout wrote:
>> How would you propose getting an output like the second command? I
>> guess one possibility is that:
>>
>> sage: latex(var('variable123')) # where 123 could be any number
>> variable_{12
--- a/sage/rings/number_field/number_field.py Sun Dec 16 06:37:16
2007 -0800
+++ b/sage/rings/number_field/number_field.py Wed Dec 19 18:54:54
2007 +
@@ -751,7 +751,7 @@ class NumberField_generic(number_field_b
You can also view a number field as having a different
gener
On Dec 18, 10:49 pm, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> Is this working as intended?
>
> The first statement should return the same as the second, and the
> third statemnt is ok.
>
> sage: solve([3==3, 1.00*x^3 == 0], x)
> []
> sage: solve([1.00*x^3 == 0], x)
I fixed the new/delete error: (insert "delete mwbasis;" on line 105
of qrank/descent.h)
I still get
sage: EllipticCurve('11a').regulator()
-infinity
which could be a wrapping error, since EllipticCurve('11a1').mwrank()
reveals the correct answer (=1), and also the error seems only to
occur whe
On Wed, Dec 19, 2007 at 06:03:32PM +, John Cremona wrote:
> I'm surprised by your comment about integer arithmetic, since both
> pari and NTL use gmp. AT least, they both *can* use gmp though it
> might not be the default. Do you know of the pari and NTL you are
> using are gmp-based?
Well,
Yes, I am sure. :) It's because I was logged into my gmail account and
the google search results then show how many times I visited each
page.
sagemath 40x times, other sage pages 0 times. So he gives me sagemath
as the first one.
Ondrej
On Dec 19, 2007 7:01 PM, John Cremona <[EMAIL PROTECTED]>
I'm surprised by your comment about integer arithmetic, since both
pari and NTL use gmp. AT least, they both *can* use gmp though it
might not be the default. Do you know of the pari and NTL you are
using are gmp-based?
John
On 19/12/2007, Joel B. Mohler <[EMAIL PROTECTED]> wrote:
>
> Ticket
>
Are you sure that you haven't got your Google search bar set to "Sage search"?
John
On 19/12/2007, Ondrej Certik <[EMAIL PROTECTED]> wrote:
>
> I think google makes it user specific, since I just tried that on
> another computer and there sagemath is the first result for "sage"!
>
> Ondrej
>
> O
OK, I'll first make sure my sources are sync'd and then look into it.
I already think I know what one of the problems is. That's what comes
of adding features: new bugs.
John
On 19/12/2007, mabshoff
<[EMAIL PROTECTED]> wrote:
>
>
>
> On Dec 19, 6:09 pm, mabshoff <[EMAIL PROTECTED]
> dortmund.d
On Dec 19, 6:09 pm, mabshoff <[EMAIL PROTECTED]
dortmund.de> wrote:
> Trouble in paradise. With the latest cremona.spkg I get a doctest
> failures with segfaults in
>
> devel/sage-main/sage/schemes/elliptic_curves/ell_rational_field.py
> devel/sage-main/sage/schemes/elliptic_curves/sha.py
> dev
Ticket
http://trac.sagemath.org/sage_trac/ticket/1558
has some new code to use NTL to factor members of ZZ[x]. I'm doing some
benchmarking to confirm or deny the comments in polynomial_element.pyx factor
method. Here's a very brief summary of what I'm finding. I may or may not
provide more d
Trouble in paradise. With the latest cremona.spkg I get a doctest
failures with segfaults in
devel/sage-main/sage/schemes/elliptic_curves/ell_rational_field.py
devel/sage-main/sage/schemes/elliptic_curves/sha.py
devel/sage-main/sage/libs/mwrank/interface.py
That even happens after a "sage -ba".
I think google makes it user specific, since I just tried that on
another computer and there sagemath is the first result for "sage"!
Ondrej
On Dec 18, 2007 11:21 PM, Bill Hart <[EMAIL PROTECTED]> wrote:
>
> Half way up page two in Australia. So in the rankings that really
> count we still have
On Dec 19, 3:52 pm, "John Cremona" <[EMAIL PROTECTED]> wrote:
> Could you try cremona-20071219.p1.spkg, same place as before.
>
> Thanks,
>
> John
>
Hi,
two remarks:
1) you need to rename the directory to the same name as the spkg, i.e.
crem
Could you try cremona-20071219.p1.spkg, same place as before.
Thanks,
John
On 19/12/2007, mabshoff
<[EMAIL PROTECTED]> wrote:
>
>
>
> On Dec 19, 2:49 pm, mabshoff <[EMAIL PROTECTED]
> dortmund.de> wrote:
> > On Dec 19, 2:20 pm, "John Cremona"
> OK, I found out what to do:
>
> Great.
> >
> > The new spkg is
> > athttp://www.warwick.ac.uk/staff/J.E.Cremona/cremona-20071219.spkg
> > and linked from the trac page.
> >
> > I would be grateful if someone could test this.
>
> I did and it fails to c
On Dec 19, 2:49 pm, mabshoff <[EMAIL PROTECTED]
dortmund.de> wrote:
> On Dec 19, 2:20 pm, "John Cremona" <[EMAIL PROTECTED]> wrote:
>
> Hi John,
>
> > OK, I found out what to do:
>
> Great.
>
>
>
> > The new spkg is
> > athttp:
On Dec 19, 2:20 pm, "John Cremona" <[EMAIL PROTECTED]> wrote:
Hi John,
> OK, I found out what to do:
Great.
>
> The new spkg is
> athttp://www.warwick.ac.uk/staff/J.E.Cremona/cremona-20071219.spkg
> and linked from the trac page.
>
> I would be gratef
OK, I found out what to do:
The new spkg is at
http://www.warwick.ac.uk/staff/J.E.Cremona/cremona-20071219.spkg
and linked from the trac page.
I would be grateful if someone could test this.
John
On 19/12/2007, John Cremona <[EMAIL PROTECTED]> wrote:
> Thanks. Just one more quest
wnload and add a link from
> the related ticket. Also add "[with spkg]" to the summary. To do that
> change look toward the bottom of the trac ticket page and edit the
> "Summary" field. It is customary to increment the patch level, the
> date of the spkg or the vers
ion number pf the pskg [that is needed for
updates to work] and also update SPKG.txt with some sort of log entry
and commit that. I would suggest you use cremona-20071219.spkg since
the new spkg has new functionality and is more than "mere" bug fixes.
> If this works, I know what t
; working on my own, but impossible to actually share changes in
> > > practice. I have read the manual. I know that it all works
> > > perfectly for everyone else but me. I don't want to spend the rest of
> > > my sage-devel life emailing patches to mabshoff.
>
of
> > my sage-devel life emailing patches to mabshoff.
>
> Nothing wrong with that, I don't mind doing the integration.
>
> > What am I doing wrong?!!
>
> I assume you might have tried to unbundle against the wrong repo
> since there are two in that spkg,
On Tuesday 18 December 2007 22:54, Jason Grout wrote:
> How would you propose getting an output like the second command? I
> guess one possibility is that:
>
> sage: latex(var('variable123')) # where 123 could be any number
> variable_{123}
>
> but
>
> sage: latex(var('variable_n'))
> variable_{n
nst the wrong repo
since there are two in that spkg, on in the root directory and on in
src. You need to apply against the one in src. That works for me:
[EMAIL PROTECTED]:/tmp/Work-mabshoff/sage-2.9.1.alpha1/spkg/standard/
cremona-20071124.p5/src$ hg unbundle ~/jec-20071219.hg
adding changesets
addin
42 matches
Mail list logo
