[sage-devel] Speed/doc issues in ZZ
I've been looking through the methods for ZZ with a view to doing a Magma/Sage comparison for marketing purposes. I've been noticing a few issues as I go. There's going to be lots of these, so I think I should give my list in small blocks. I can file trac tickets for them once someone verifies that these are really not just me not knowing enough python, or whatever. ZZ Speed Issues: * n.bits takes much longer than n.binary(), but the latter needs to compute the former first!!! * n.coprime_integers uses a hopelessly slow algorithm (we should at least use a sieve) * n.factor is bizarrely slow for small integers (e.g. n 1,000,000) by a HUGE factor * n.exact_log can be done faster for small bases by making careful use of the identity log_m(n) = log_2(n)/log_2(m) (I wrote a crappy broken python implementation and timed this - I don't know how to write it properly as I don't know enough about Sage yet) Missing doc strings: * n.base_extend * n.additive_order * n.category * n.db (doesn't give an example) * n.degree Missing methods: * n.euler_phi * n.random (random integer less than n - I will believe you if you tell me this is not the python way) Weird names: * n.divide_knowing_divisible_by (perhaps div_exact, exact_quotient, divide_exact would be better) Documentation issues: * n.dump says Same as self.save(filename, compress), but compress is not discussed in save docstring Bill. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: mathematica advertising
Funny, I must be receiving a lot fewer adds than everybody else. If I type sagemath into Google, I get no adds whatsoever, if I type sage math I get one add saying: Sage Math Looking for Sage Math? Find almost everything on eBay! As expected, when I click on the link, Ebay returns 0 items. Could it be that the adds returned depend a little bit on the user's individual search history? Anyway, I'm not fussed one way or the other and mostly ignore the 'Sponsored Links' bar in Google, anyway. I think it is much more important to make sure sagemath.org is among the top hits when someone actually searches for a CAS. When I search for computer algebra system, I find links to wikipedia, Yacas, Fermat, Giac, Maxima, Axiom, Reduce and a page at wpi.edu on the first page, but not SAGE. I guess that there is some room for improvement. Cheers, Stan Jason Bandlow wrote: kcrisman wrote: How clever is Google? Perhaps they argue: - On the Sage pages, we frequently find the phrase 'viable open source alternative to Mathematica' (or something in that spirit) - Hence, Mathematica is relevant to Sage. - Hence, if people search for Sage, it makes sense to show them a Mathematica ad. In other words, could it be that the ad shows up due to the negative self-description of Sage? I like this idea. But wouldn't that mean that Maplesoft ads should show up too, or even ones for MathWorks (I assume Magma does not need Google ads for its clientele)? Just curious. FWIW, searching for math sage software brings up a Maplesoft ad, but not the Mathematica (or MathWorks) ad. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: mathematica advertising
On Apr 7, 11:43 pm, Stan Schymanski schym...@gmail.com wrote: Hi Stan, Funny, I must be receiving a lot fewer adds than everybody else. If I type sagemath into Google, I get no adds whatsoever, if I type sage math I get one add saying: Sage Math Looking for Sage Math? Find almost everything on eBay! As expected, when I click on the link, Ebay returns 0 items. I am sure it is geographic, i.e. only Sage users in the US (and maybe Canada?) see the ad. Could it be that the adds returned depend a little bit on the user's individual search history? Anyway, I'm not fussed one way or the other and mostly ignore the 'Sponsored Links' bar in Google, anyway. I think it is much more important to make sure sagemath.org is among the top hits when someone actually searches for a CAS. When I search for computer algebra system, I find links to wikipedia, Yacas, Fermat, Giac, Maxima, Axiom, Reduce and a page at wpi.edu on the first page, but not SAGE. I guess that there is some room for improvement. Well, Sage isn't really sold as a CAS in the classic sense, so that might be part of it. I guess over time this might change :) Cheers, Stan Cheers, Michael Jason Bandlow wrote: kcrisman wrote: How clever is Google? Perhaps they argue: - On the Sage pages, we frequently find the phrase 'viable open source alternative to Mathematica' (or something in that spirit) - Hence, Mathematica is relevant to Sage. - Hence, if people search for Sage, it makes sense to show them a Mathematica ad. In other words, could it be that the ad shows up due to the negative self-description of Sage? I like this idea. But wouldn't that mean that Maplesoft ads should show up too, or even ones for MathWorks (I assume Magma does not need Google ads for its clientele)? Just curious. FWIW, searching for math sage software brings up a Maplesoft ad, but not the Mathematica (or MathWorks) ad. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Divisors
Yeah, the divisors function otherwise kicks proverbial:
Here in Sage (excuse my rubbish python):
def random(n):
a = ZZ.random_element(n)
return a
def z_divisors_test(m):
for j in range(0, m) :
n = random(10)
z = 1
c = 1
for i in range(0, n):
k = random(100).next_prime()
if gcd(k, z) == 1 :
e = random(8)
c = c*(e+1)
z = z*(k^e)
l = z.divisors()
if len(l) != c:
print Error, len(l), !=, c, for integer, z
time z_divisors_test(2000)
Something like 40s.
Here in Magma (excuse my even more rubbish Magma coding skills):
t:= Cputime();
for j := 0 to 2000 do
n := Random(10);
z:=1;
c:=1;
for i := 0 to n do
k := NextPrime(Random(100));
if Gcd(k,z) eq 1 then
e := Random(8);
c := c*(e+1);
z := z*(k^e);
end if;
end for;
l := Divisors(z);
if #l ne c then
print Error;
end if;
end for;
Cputime(t);
Umm, yeah. Not worth waiting up for. :-)
Magma does use half the memory though.
Bill.
On 8 Apr, 06:44, Robert Bradshaw rober...@math.washington.edu wrote:
On Apr 7, 2009, at 10:26 PM, Bill Hart wrote:
William didn't mention the context of this, which is that for small
integers most of the time taken by the divisors method in ZZ is taken
up with factoring. It seems much more likely people will use small
numbers as inputs to this, so this is a shame, given the amount of
work that (I hear) went into optimising that in Sage.
Bill.
Hmm.. that's not always true, at least the cases that inspired this
ticket:
sage: n = ZZ(odd_part(factorial(31)))
sage: timeit('n.factor()')
625 loops, best of 3: 294 µs per loop
sage: timeit('n.divisors()')
5 loops, best of 3: 104 ms per loop
So for some highly composite numbers, factoring is the minority of
the time. (BTW, before the optimization, this took nearly 2.5
seconds!) Of course usually for numbers of this size there are only a
few factors, so the divisors function is dominated by the much harder
problem of factoring (which can clearly use some fixing).
- Robert
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Divisors
I mean half the memory that Sage uses, not half the memory of the
machine.
Bill.
On 8 Apr, 09:21, Bill Hart goodwillh...@googlemail.com wrote:
Yeah, the divisors function otherwise kicks proverbial:
Here in Sage (excuse my rubbish python):
def random(n):
a = ZZ.random_element(n)
return a
def z_divisors_test(m):
for j in range(0, m) :
n = random(10)
z = 1
c = 1
for i in range(0, n):
k = random(100).next_prime()
if gcd(k, z) == 1 :
e = random(8)
c = c*(e+1)
z = z*(k^e)
l = z.divisors()
if len(l) != c:
print Error, len(l), !=, c, for integer, z
time z_divisors_test(2000)
Something like 40s.
Here in Magma (excuse my even more rubbish Magma coding skills):
t:= Cputime();
for j := 0 to 2000 do
n := Random(10);
z:=1;
c:=1;
for i := 0 to n do
k := NextPrime(Random(100));
if Gcd(k,z) eq 1 then
e := Random(8);
c := c*(e+1);
z := z*(k^e);
end if;
end for;
l := Divisors(z);
if #l ne c then
print Error;
end if;
end for;
Cputime(t);
Umm, yeah. Not worth waiting up for. :-)
Magma does use half the memory though.
Bill.
On 8 Apr, 06:44, Robert Bradshaw rober...@math.washington.edu wrote:
On Apr 7, 2009, at 10:26 PM, Bill Hart wrote:
William didn't mention the context of this, which is that for small
integers most of the time taken by the divisors method in ZZ is taken
up with factoring. It seems much more likely people will use small
numbers as inputs to this, so this is a shame, given the amount of
work that (I hear) went into optimising that in Sage.
Bill.
Hmm.. that's not always true, at least the cases that inspired this
ticket:
sage: n = ZZ(odd_part(factorial(31)))
sage: timeit('n.factor()')
625 loops, best of 3: 294 µs per loop
sage: timeit('n.divisors()')
5 loops, best of 3: 104 ms per loop
So for some highly composite numbers, factoring is the minority of
the time. (BTW, before the optimization, this took nearly 2.5
seconds!) Of course usually for numbers of this size there are only a
few factors, so the divisors function is dominated by the much harder
problem of factoring (which can clearly use some fixing).
- Robert
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Speed/doc issues in ZZ
Here's some timings for exact_log: In Sage: def random(n): a = ZZ.random_element(n) return a def z_exact_log_test(m, n, k): for i in range(0, m) : a = random(n) + 2 b = random(k) c = a^b d = c.exact_log(a) if b != d: print Error, b, !=, d time z_exact_log_test(10, 64, 1000) 4.72s In Magma: t:=Cputime(); for i := 0 to 10 do a := Random(64) + 2; b := Random(1000); c := a^b; d := Ilog(a,c); if d ne b then print Error; end if; end for; Cputime(t); 0.72s Bill. On 8 Apr, 07:17, Bill Hart goodwillh...@googlemail.com wrote: I've been looking through the methods for ZZ with a view to doing a Magma/Sage comparison for marketing purposes. I've been noticing a few issues as I go. There's going to be lots of these, so I think I should give my list in small blocks. I can file trac tickets for them once someone verifies that these are really not just me not knowing enough python, or whatever. ZZ Speed Issues: * n.bits takes much longer than n.binary(), but the latter needs to compute the former first!!! * n.coprime_integers uses a hopelessly slow algorithm (we should at least use a sieve) * n.factor is bizarrely slow for small integers (e.g. n 1,000,000) by a HUGE factor * n.exact_log can be done faster for small bases by making careful use of the identity log_m(n) = log_2(n)/log_2(m) (I wrote a crappy broken python implementation and timed this - I don't know how to write it properly as I don't know enough about Sage yet) Missing doc strings: * n.base_extend * n.additive_order * n.category * n.db (doesn't give an example) * n.degree Missing methods: * n.euler_phi * n.random (random integer less than n - I will believe you if you tell me this is not the python way) Weird names: * n.divide_knowing_divisible_by (perhaps div_exact, exact_quotient, divide_exact would be better) Documentation issues: * n.dump says Same as self.save(filename, compress), but compress is not discussed in save docstring Bill. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Speed/doc issues in ZZ
Surely it would be worth testing self.gcd(m)==m early on in the exact_log function, i.e. that m divides self? I may be naive but I would implement this by testing m|a, if so dividing a by m, and continuing. The current method describes itself as extremely stupid code but it still trying to be clever!. John 2009/4/8 Bill Hart goodwillh...@googlemail.com: Here's some timings for exact_log: In Sage: def random(n): a = ZZ.random_element(n) return a def z_exact_log_test(m, n, k): for i in range(0, m) : a = random(n) + 2 b = random(k) c = a^b d = c.exact_log(a) if b != d: print Error, b, !=, d time z_exact_log_test(10, 64, 1000) 4.72s In Magma: t:=Cputime(); for i := 0 to 10 do a := Random(64) + 2; b := Random(1000); c := a^b; d := Ilog(a,c); if d ne b then print Error; end if; end for; Cputime(t); 0.72s Bill. On 8 Apr, 07:17, Bill Hart goodwillh...@googlemail.com wrote: I've been looking through the methods for ZZ with a view to doing a Magma/Sage comparison for marketing purposes. I've been noticing a few issues as I go. There's going to be lots of these, so I think I should give my list in small blocks. I can file trac tickets for them once someone verifies that these are really not just me not knowing enough python, or whatever. ZZ Speed Issues: * n.bits takes much longer than n.binary(), but the latter needs to compute the former first!!! * n.coprime_integers uses a hopelessly slow algorithm (we should at least use a sieve) * n.factor is bizarrely slow for small integers (e.g. n 1,000,000) by a HUGE factor * n.exact_log can be done faster for small bases by making careful use of the identity log_m(n) = log_2(n)/log_2(m) (I wrote a crappy broken python implementation and timed this - I don't know how to write it properly as I don't know enough about Sage yet) Missing doc strings: * n.base_extend * n.additive_order * n.category * n.db (doesn't give an example) * n.degree Missing methods: * n.euler_phi * n.random (random integer less than n - I will believe you if you tell me this is not the python way) Weird names: * n.divide_knowing_divisible_by (perhaps div_exact, exact_quotient, divide_exact would be better) Documentation issues: * n.dump says Same as self.save(filename, compress), but compress is not discussed in save docstring Bill. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Speed/doc issues in ZZ
This is David Harvey trying to write stupid code, so in ordinary person terms that translates as pretty smart. Bill. On 8 Apr, 10:03, John Cremona john.crem...@gmail.com wrote: Surely it would be worth testing self.gcd(m)==m early on in the exact_log function, i.e. that m divides self? I may be naive but I would implement this by testing m|a, if so dividing a by m, and continuing. The current method describes itself as extremely stupid code but it still trying to be clever!. John 2009/4/8 Bill Hart goodwillh...@googlemail.com: Here's some timings for exact_log: In Sage: def random(n): a = ZZ.random_element(n) return a def z_exact_log_test(m, n, k): for i in range(0, m) : a = random(n) + 2 b = random(k) c = a^b d = c.exact_log(a) if b != d: print Error, b, !=, d time z_exact_log_test(10, 64, 1000) 4.72s In Magma: t:=Cputime(); for i := 0 to 10 do a := Random(64) + 2; b := Random(1000); c := a^b; d := Ilog(a,c); if d ne b then print Error; end if; end for; Cputime(t); 0.72s Bill. On 8 Apr, 07:17, Bill Hart goodwillh...@googlemail.com wrote: I've been looking through the methods for ZZ with a view to doing a Magma/Sage comparison for marketing purposes. I've been noticing a few issues as I go. There's going to be lots of these, so I think I should give my list in small blocks. I can file trac tickets for them once someone verifies that these are really not just me not knowing enough python, or whatever. ZZ Speed Issues: * n.bits takes much longer than n.binary(), but the latter needs to compute the former first!!! * n.coprime_integers uses a hopelessly slow algorithm (we should at least use a sieve) * n.factor is bizarrely slow for small integers (e.g. n 1,000,000) by a HUGE factor * n.exact_log can be done faster for small bases by making careful use of the identity log_m(n) = log_2(n)/log_2(m) (I wrote a crappy broken python implementation and timed this - I don't know how to write it properly as I don't know enough about Sage yet) Missing doc strings: * n.base_extend * n.additive_order * n.category * n.db (doesn't give an example) * n.degree Missing methods: * n.euler_phi * n.random (random integer less than n - I will believe you if you tell me this is not the python way) Weird names: * n.divide_knowing_divisible_by (perhaps div_exact, exact_quotient, divide_exact would be better) Documentation issues: * n.dump says Same as self.save(filename, compress), but compress is not discussed in save docstring Bill. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: mayavi spkg packages work
On 04/06/09 17:26, François Bissey wrote: I was toying with the ebuild on Gentoo the other day and there we haven't been able to get rid of the dependency on wxpython although I haven't checked the command line version (was trying The mayavi2 command line application will always require a UI -- qt4 or wxPython. Its the offscreen mlab or the OO API of mayavi that can be used without a particular UI backend. to build a qt4 version, even when you build for qt4 you need wxpython - sad). If I remember well there is a logger module that imports wx directly. Would be great if you got rid of that. Unfortunately, IIRC, that is simply because the logger envisage plugin hasn't been ported over to Qt4. I think Phil Thompson is no longer actively pushing the Qt4 backend either. So someone with enough time and knowledge of qt4 will have to port that -- I don't think it is hard to do but I certainly do not have the time for it at the moment. cheers, prabhu --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Speed/doc issues in ZZ
On Wednesday 08 April 2009 02:17:48 am Bill Hart wrote: * n.bits takes much longer than n.binary(), but the latter needs to compute the former first!!! This is sage types and lack of C-level optimization killing your performance. The binary method does it's work using gmp (mpir, I guess now). I think it could be fixed with-out a lot of fuss. * n.exact_log can be done faster for small bases by making careful use of the identity log_m(n) = log_2(n)/log_2(m) (I wrote a crappy broken python implementation and timed this - I don't know how to write it properly as I don't know enough about Sage yet) I have a patch that's taken a long time for me to be happy with (but I think I just about am now), which overhauls exact_log. It results in 50x speedups for small input and selected large input. For example: -- | Sage Version 3.4, Release Date: 2009-03-11 | | Type notebook() for the GUI, and license() for information.| -- Loading Sage library. Current Mercurial branch is: digits sage: n=3^1000 sage: m=5^34 sage: timeit(n.exact_log(m)) 625 loops, best of 3: 997 ns per loop sage: m=5 sage: timeit(n.exact_log(m)) 625 loops, best of 3: 4.47 µs per loop The conversion to RIF field and computation of the log hideously dominates for small input. In this case, small means something like 3000 bits, which seems to me this is the vast majority of the likely input for this function. My patch degrades gracefully to RIF computations with a fixed cutoff. I will submit it later today to trac. -- Joel --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: mathematica advertising
On Apr 8, 7:43 am, Stan Schymanski schym...@gmail.com wrote: Funny, I must be receiving a lot fewer adds than everybody else. If I type sagemath into Google, I get no adds whatsoever, if I type sage math I get one add saying: There is almost certainly a random element to the ads you see. I can search for sage and math, and get different adverts 5 seconds later. In fact, even Wolfram's advert is not the same. Sometimes I get an ad for Mathematica Home Edition occasionally I get an ad for Mathematica Home Copy I think the 'Edition' comes up about 10x as often as the Copy, but Mathematica Home Copy does come up some times. But there are other ads too, which sometimes appear and sometimes do not. Sage Software Services and interesting one I got just now is algebra Help, Fast with a link to http://www.studentoffortune.com/?gclid=CPTj__mY4ZkCFQFvGgodUBMrWg I assume, the more money you are willing to pay, the higher the probability of your ad appearing. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Speed/doc issues in ZZ
Two more issues for ZZ: Duplicate methods: n.prime_factors and n.prime_divisors do precisely the same thing and have the same docstring, even down to one of the docstrings having examples for the wrong function. Missing methods: n.number_of_divisors (note one does not need to compute the divisors to compute this function) Bill. On 8 Apr, 07:17, Bill Hart goodwillh...@googlemail.com wrote: I've been looking through the methods for ZZ with a view to doing a Magma/Sage comparison for marketing purposes. I've been noticing a few issues as I go. There's going to be lots of these, so I think I should give my list in small blocks. I can file trac tickets for them once someone verifies that these are really not just me not knowing enough python, or whatever. ZZ Speed Issues: * n.bits takes much longer than n.binary(), but the latter needs to compute the former first!!! * n.coprime_integers uses a hopelessly slow algorithm (we should at least use a sieve) * n.factor is bizarrely slow for small integers (e.g. n 1,000,000) by a HUGE factor * n.exact_log can be done faster for small bases by making careful use of the identity log_m(n) = log_2(n)/log_2(m) (I wrote a crappy broken python implementation and timed this - I don't know how to write it properly as I don't know enough about Sage yet) Missing doc strings: * n.base_extend * n.additive_order * n.category * n.db (doesn't give an example) * n.degree Missing methods: * n.euler_phi * n.random (random integer less than n - I will believe you if you tell me this is not the python way) Weird names: * n.divide_knowing_divisible_by (perhaps div_exact, exact_quotient, divide_exact would be better) Documentation issues: * n.dump says Same as self.save(filename, compress), but compress is not discussed in save docstring Bill. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Speed/doc issues in ZZ
2009/4/8 Bill Hart goodwillh...@googlemail.com: Two more issues for ZZ: Duplicate methods: n.prime_factors and n.prime_divisors do precisely the same thing and have the same docstring, even down to one of the docstrings having examples for the wrong function. Somewhere in rings/integer/pyx you see the line prime_factors = prime_divisors which was added a long time ago by me. Perhaps we should do the same for the place you found. I do like having both names available (though I know some don't); certainly both names are used a lot. But I definitely think that when it makes sense to have two alternative names for on function then this should be done as I did it (simple assignment) and _not_ by duplicating code! John Missing methods: n.number_of_divisors (note one does not need to compute the divisors to compute this function) Bill. On 8 Apr, 07:17, Bill Hart goodwillh...@googlemail.com wrote: I've been looking through the methods for ZZ with a view to doing a Magma/Sage comparison for marketing purposes. I've been noticing a few issues as I go. There's going to be lots of these, so I think I should give my list in small blocks. I can file trac tickets for them once someone verifies that these are really not just me not knowing enough python, or whatever. ZZ Speed Issues: * n.bits takes much longer than n.binary(), but the latter needs to compute the former first!!! * n.coprime_integers uses a hopelessly slow algorithm (we should at least use a sieve) * n.factor is bizarrely slow for small integers (e.g. n 1,000,000) by a HUGE factor * n.exact_log can be done faster for small bases by making careful use of the identity log_m(n) = log_2(n)/log_2(m) (I wrote a crappy broken python implementation and timed this - I don't know how to write it properly as I don't know enough about Sage yet) Missing doc strings: * n.base_extend * n.additive_order * n.category * n.db (doesn't give an example) * n.degree Missing methods: * n.euler_phi * n.random (random integer less than n - I will believe you if you tell me this is not the python way) Weird names: * n.divide_knowing_divisible_by (perhaps div_exact, exact_quotient, divide_exact would be better) Documentation issues: * n.dump says Same as self.save(filename, compress), but compress is not discussed in save docstring Bill. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: LaTex representation for SymbolicFunctionEvaluation
On Tue, Apr 7, 2009 at 3:14 PM, Robert Bradshaw rober...@math.washington.edu wrote: Hi, I will be happy to hear any issues that you may find in it, before I open a ticket for this enhancement. I've only been marginally following this issue (thanks for all your work on it BTW) but typically it's better to create tickets sooner rather than later. (In fact, the policy is to create tickets when you start working on something, to avoid duplication of effort). Thanks, so here is the ticket http://trac.sagemath.org/sage_trac/ticket/5711 I will be happy to address any comments/concern from the reviewer. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: FInally the link to download SAGElwlcd ISO!
Alfredo, How are you? Have you had some time to check out the iso image? May I try some changes based on your distro? In that case it may take about a week or so. Greetings, Lucio. On 24 mar, 22:02, Lucio Lastra luciolas...@gmail.com wrote: Alfredo, I'm as glad as you to work together to achieve a better distro in all senses, not to mention the honor it is to me to have this opportunity. I think the way you went choosing the method is perfect and that the key to improve the LiveCD is just to choose which packages to keep and the ones to remove. After all, that's what sagelwlcd is all about (as is written in the README and the code to build it) although is far from the best choice and still has many rough edges among the ones already described by Rob. So my suggestion is to take your latest distro as a base and make a careful selection of packages in order to get it smaller and faster. Maybe to start with it we can pick the ones used by sagelwlcd and then experiment with others that have the same functionality but are more efficient and/or have less dependencies in order to work. For example trying Wicd instead of Network Manager, etc. We can also try what is the outcome using Arch or other distros if you like the idea and think they may be a better option than your latest distro to work as a base. Greetings, Lucio. On Tue, Mar 24, 2009 at 2:47 PM, Alfredo Portes doyenatc...@gmail.comwrote: Hi Lucio, On Tue, Mar 24, 2009 at 1:29 PM, Lucio Lastra luciolas...@gmail.com wrote: I finally got your point. Sincerely I didn't know that such thing as requesting a particular feature in the LiveCD was possible, that's why I built mine. I also want to make clear that my intention is not to take your place or anyone's, I just built that distro and thought it would be nice to share it and that's all. On the contrary Lucio, we have been looking for somebody like you to take my place for a lon time. :-). It feels always that there is not much demand for the LiveCD, which decreases my effort in it. After trying various methods (and I mean a lot of methods), I settle to use: http://www.linux-live.org/ Not sure if you tried it already, a really good project. (This is what SLAX uses, probably after Knopixx the best LiveCD out there.) I would love to contribute to your effort to make the LiveCD better, even using your current methods if everybody find it better. I really dont care what we use (Flux, Gnome, KDE) as long as we achieve what you already trying: smaller and faster. But the method to create/update it has to be easy, if not it becomes unmaintainable. I have no trouble making any contribution or helping in whatever I can in the LiveCD. Rob's idea is the best but I'm not who to determine whether it's going to be taken into account or not. I would be glad to follow your lead in this direction...but the better tools you find the easier this becomes. Again I am very happy that somebody is working on the LiveCD. So on my part I will try you version and give you feedback on things to improve. Thank you very much for your work, Alfredo --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: FInally the link to download SAGElwlcd ISO!
Update: my friend took down the ISO image and its parts from his blog. All it remains are the instructions to build it posted here: http://groups.google.com/group/sage-devel/browse_thread/thread/4cfbbc60579d2e74# Hope you downloaded it or someone you know did. Greetings, Lucio. On 8 abr, 10:18, Lucio Lastra luciolas...@gmail.com wrote: Alfredo, How are you? Have you had some time to check out the iso image? May I try some changes based on your distro? In that case it may take about a week or so. Greetings, Lucio. On 24 mar, 22:02, Lucio Lastra luciolas...@gmail.com wrote: Alfredo, I'm as glad as you to work together to achieve a better distro in all senses, not to mention the honor it is to me to have this opportunity. I think the way you went choosing the method is perfect and that the key to improve the LiveCD is just to choose which packages to keep and the ones to remove. After all, that's what sagelwlcd is all about (as is written in the README and the code to build it) although is far from the best choice and still has many rough edges among the ones already described by Rob. So my suggestion is to take your latest distro as a base and make a careful selection of packages in order to get it smaller and faster. Maybe to start with it we can pick the ones used by sagelwlcd and then experiment with others that have the same functionality but are more efficient and/or have less dependencies in order to work. For example trying Wicd instead of Network Manager, etc. We can also try what is the outcome using Arch or other distros if you like the idea and think they may be a better option than your latest distro to work as a base. Greetings, Lucio. On Tue, Mar 24, 2009 at 2:47 PM, Alfredo Portes doyenatc...@gmail.comwrote: Hi Lucio, On Tue, Mar 24, 2009 at 1:29 PM, Lucio Lastra luciolas...@gmail.com wrote: I finally got your point. Sincerely I didn't know that such thing as requesting a particular feature in the LiveCD was possible, that's why I built mine. I also want to make clear that my intention is not to take your place or anyone's, I just built that distro and thought it would be nice to share it and that's all. On the contrary Lucio, we have been looking for somebody like you to take my place for a lon time. :-). It feels always that there is not much demand for the LiveCD, which decreases my effort in it. After trying various methods (and I mean a lot of methods), I settle to use: http://www.linux-live.org/ Not sure if you tried it already, a really good project. (This is what SLAX uses, probably after Knopixx the best LiveCD out there.) I would love to contribute to your effort to make the LiveCD better, even using your current methods if everybody find it better. I really dont care what we use (Flux, Gnome, KDE) as long as we achieve what you already trying: smaller and faster. But the method to create/update it has to be easy, if not it becomes unmaintainable. I have no trouble making any contribution or helping in whatever I can in the LiveCD. Rob's idea is the best but I'm not who to determine whether it's going to be taken into account or not. I would be glad to follow your lead in this direction...but the better tools you find the easier this becomes. Again I am very happy that somebody is working on the LiveCD. So on my part I will try you version and give you feedback on things to improve. Thank you very much for your work, Alfredo --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Speed/doc issues in ZZ
* n.db (doesn't give an example) I propose removing the db method. It stands for database, and was something I put in I think way before sage-1.0. I have never used it, and I don't know of anybody else who has, and can't imagine it even works. If nobody responds that they have used it, I think it should just be deleted. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Speed/doc issues in ZZ
On Wed, Apr 8, 2009 at 6:29 AM, William Stein wst...@gmail.com wrote: * n.db (doesn't give an example) I propose removing the db method. It stands for database, and was something I put in I think way before sage-1.0. I have never used it, and I don't know of anybody else who has, and can't imagine it even works. If nobody responds that they have used it, I think it should just be deleted. I should add that db is a method on all Sage objects, not just the integers. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Speed/doc issues in ZZ
Missing methods: * n.euler_phi This exists but not as n.euler_phi, in rings/arith.py, so you could probably just put in a call to that - or move some of that code to ZZ if it belongs there, while leaving the direct call euler_phi(7) and plotting available? A lot of the things in rings/arith.py though is of course really about integers, perhaps in this file for historical reasons and/or perhaps not worth moving. - kcrisman --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Benchmark Document
Hello Everybody, Is there any document that compares Matlab, Mathematica and Sage (Plus all the contributing codes, in example Maxima, etc.) functions, properties, toolboxes? In example, Matlab Mathematica Sage Platform NewtonMethod Yes Yes Yes Modified Newton No Yes Yes If not, it will be very good to compare them for marketing purposes. Most people don't use highly detailed methods/toolboxes of commercial applications, and if they know at least Sage can provide them what they need to a certain level, they would choose Sage. Regards AAP --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Benchmark Document
On Wed, Apr 8, 2009 at 2:11 PM, ahmet alper parker aapar...@gmail.com wrote: Hello Everybody, Is there any document that compares Matlab, Mathematica and Sage (Plus all the contributing codes, in example Maxima, etc.) functions, properties, toolboxes? In example, Matlab Mathematica Sage Platform NewtonMethod Yes Yes Yes Modified Newton No Yes Yes If not, it will be very good to compare them for marketing purposes. Most people don't use highly detailed methods/toolboxes of commercial applications, and if they know at least Sage can provide them what they need to a certain level, they would choose Sage. Regards AAP There is no such document. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Benchmark Document
On Wed, Apr 8, 2009 at 2:16 PM, William Stein wst...@gmail.com wrote: On Wed, Apr 8, 2009 at 2:11 PM, ahmet alper parker aapar...@gmail.com wrote: Hello Everybody, Is there any document that compares Matlab, Mathematica and Sage (Plus all the contributing codes, in example Maxima, etc.) functions, properties, toolboxes? In example, Matlab Mathematica Sage Platform NewtonMethod Yes Yes Yes Modified Newton No Yes Yes If not, it will be very good to compare them for marketing purposes. Most people don't use highly detailed methods/toolboxes of commercial applications, and if they know at least Sage can provide them what they need to a certain level, they would choose Sage. Regards AAP There is no such document. However, we did start something related to this for Magma: http://wiki.sagemath.org/magma The goal there is mainly to list things Magma can do but Sage can't. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: FInally the link to download SAGElwlcd ISO!
Hi Lucio, I have not been able to test the image, sorry. I will try to test this weekend. Today I saw this interesting project: http://xpud.org/ Looks ideal for a sage/notebook only interface, but I have not tried yet. Regards, Alfredo --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Error on jsmath()
Thanks for the quick replies! I just upgraded to the binary version 3.2.3 (from what I've seen so far, 3.4 is not yet available for intel atom cpus) and I'm still getting the error mentioned above. Anywhere I could find a version compiled for atom perhaps? --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.4.1.rc1 released
Built from source and passes all tests with sage -t with 64-bit Kubuntu 8.10 on Intel dual core. Rob --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
