Hello,
In the attached sample file I wrote a function that behaves well with
KeyboardInterrupt exceptions but not with OverflowError. More
concretely
sage: %runfile sig_on.pyx
sage: test(2**50,2**30) # Press Ctrl-C here
^C
...
KeybordInterrupt
sage: sig_on_count()
0
So everything is looking
needs review
On Wednesday, February 25, 2015 at 11:51:01 AM UTC+1, vdelecroix wrote:
2015-02-25 11:28 UTC+01:00, John Cremona john.c...@gmail.com
javascript::
On 25 February 2015 at 07:44, Vincent Delecroix
20100.d...@gmail.com javascript: wrote:
2015-02-24 22:58 UTC+01:00, William
with the sample file...
2015-02-25 14:18 UTC+01:00, Vincent Delecroix 20100.delecr...@gmail.com:
Hello,
In the attached sample file I wrote a function that behaves well with
KeyboardInterrupt exceptions but not with OverflowError. More
concretely
sage: %runfile sig_on.pyx
sage:
I'm interested.
Best,
Travis
On Tuesday, February 24, 2015 at 12:29:32 PM UTC-8, William wrote:
Follow-up question:
Is anybody interested in a Sage Days in *SAN DIEGO* May 24-whenever, 2015?
William
On Mon, Feb 23, 2015 at 10:04 AM, William Stein wst...@gmail.com
javascript: wrote:
Hi,
The reason is that 75 is preparsed into a Sage integer. If you want to use
Python int, just do:
sage: np.percentile(a, 75r)
6.25
or
sage: np.percentile(a, int(75))
6.25
If you want to turn Sage preparser off, just do
sage: preparser(False)
sage: np.percentile(a, 75)
6.25
Note that
Dear all,
I just ran into a bug in sage, which is reproducible both in my local Sage
6.3, 6.5 and on sage-cloud using the sage notebook but not when using
iPython, i.e. it seems to really be a sage bug, not a numpy bug.
Any ideas what might be the reason?
Just using the syntax from the
On 2015-02-25 18:58, Vincent Delecroix wrote:
Thanks (even if I do not get exactly what does inside mean).
There should be no Python code between sig_on() and sig_off().
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this
More generally, there should be no Python code inside a sig_on/sig_off
block. Of course, in your example the Python code is very implicit: it's
the conversion Integer - unsigned long.
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe
On Wednesday, February 25, 2015 at 1:56:39 AM UTC-8, Snark wrote:
Hi,
it is a strange problem I have : using either debian's ecl or upstream's
the following code :
(ext:set-limit 'ext:heap-size 0)
(setq a (expt 10 (expt 10 5)))
(setq b (expt a 600))
gives a crash (SIGABRT)
Hello,
Should there be code in Sage which is extremely slow and for educational
purposes only? I am talking about eratosthenes() which is just a very
slow alternative to prime_range().
I would just remove that code, but maybe people have other opinions...
Jeroen.
--
You received this
The answer is very obvious: the OverflowError is raised *inside* the
sig_on/sig_off block.
The general solution would be
sig_on()
try:
mpz_bin_ui(x.value, aa.value, b)
finally:
sig_off()
but in this case you can simply move the conversion:
cdef unsigned long b0 = b# --
Thanks (even if I do not get exactly what does inside mean).
At least it is fixed in #17852.
Vincent
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
Le 25/02/2015 17:20, Nils Bruin a écrit :
On Wednesday, February 25, 2015 at 1:56:39 AM UTC-8, Snark wrote:
Hi,
it is a strange problem I have : using either debian's ecl or upstream's
the following code :
(ext:set-limit 'ext:heap-size 0)
(setq a (expt 10 (expt 10 5)))
(setq b (expt a
On 02/25/2015 02:10 PM, William Stein wrote:
toys.eratosthenes()
or possibly eratosthenes_toy()...
In this case, the name refers to the implementation, not the
functionality, so I don't think it's a big deal. It's not a prime
number routine that just happens to be slow -- it's the
I also feel like we should remove it from the source code. The purpose
of eratosthene is very different from what Andrey pointed out with his
module about the simplex method. The function eratosthene is just an
illustration of how you code a nice Python function. While the
simplex module is more
On Wed, Feb 25, 2015 at 2:10 PM, William Stein wst...@gmail.com wrote:
On Wed, Feb 25, 2015 at 10:15 AM, Michael Orlitzky mich...@orlitzky.com
wrote:
...
I think it's best to name any functionality that is is extremely slow
and for educational
purposes explicitly with toy somewhere in the
Um, can it be perhaps slightly less diminishing? Like education.[tab] or
edu.[tab]?
E.g. I wrote
http://sagemath.org/doc/reference/numerical/sage/numerical/interactive_simplex_method.html
which is certainly not designed for production work, but it was quite a bit
of work on its own ;-)
I am
Um, can it be perhaps slightly less diminishing? Like education.[tab] or
edu.[tab]?
We have a number of crypto examples of toy things, and David J. long ago
wrote quite a few things like Euler's method and so forth. It is very,
very worthwhile (if for no other reason than to have
On Wed, Feb 25, 2015 at 11:57 AM, Michael Orlitzky mich...@orlitzky.com wrote:
On 02/25/2015 02:10 PM, William Stein wrote:
toys.eratosthenes()
or possibly eratosthenes_toy()...
In this case, the name refers to the implementation, not the
functionality, so I don't think it's a big
2015-02-25 19:24 UTC+01:00, Volker Braun vbraun.n...@gmail.com:
Is the number correct? It works for me, but is a closed ticket.
It is correct in the object but not in the body: it is #17852
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To
On Wed, Feb 25, 2015 at 10:15 AM, Michael Orlitzky mich...@orlitzky.com wrote:
On 02/25/2015 12:55 PM, Jeroen Demeyer wrote:
Hello,
Should there be code in Sage which is extremely slow and for educational
purposes only? I am talking about eratosthenes() which is just a very
slow alternative
I had the same kind of trouble as well. But letting it hanging for a
while it finally worked out!
2015-02-25 19:15 UTC+01:00, Jeroen Demeyer jdeme...@cage.ugent.be:
I am unable to make any change to Trac #17582: trac just hangs forever
when I try to change the status to needs_work or add a
Is the number correct? It works for me, but is a closed ticket.
On Wednesday, February 25, 2015 at 7:15:41 PM UTC+1, Jeroen Demeyer wrote:
I am unable to make any change to Trac #17582: trac just hangs forever
when I try to change the status to needs_work or add a comment.
--
You received
I am unable to make any change to Trac #17582: trac just hangs forever
when I try to change the status to needs_work or add a comment.
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from
On 02/25/2015 12:55 PM, Jeroen Demeyer wrote:
Hello,
Should there be code in Sage which is extremely slow and for educational
purposes only? I am talking about eratosthenes() which is just a very
slow alternative to prime_range().
I would just remove that code, but maybe people have
Hi,
Le 25/02/2015 10:56, Julien Puydt a écrit :
it is a strange problem I have : using either debian's ecl or upstream's
the following code :
(ext:set-limit 'ext:heap-size 0)
(setq a (expt 10 (expt 10 5)))
(setq b (expt a 600))
gives a crash (SIGABRT) Duplicate large block deallocation.
On 02/26/15 10:30, Julien Puydt wrote:
Hi,
Le 25/02/2015 10:56, Julien Puydt a écrit :
it is a strange problem I have : using either debian's ecl or upstream's
the following code :
(ext:set-limit 'ext:heap-size 0)
(setq a (expt 10 (expt 10 5)))
(setq b (expt a 600))
gives a crash (SIGABRT)
On 02/25/2015 03:04 PM, William Stein wrote:
Any other implementation will be just as slow.
I'm not sure I agree. This eratosthenes function is pure Python code.
It would probably be 100 times faster if rewritten in Cython using
int's or long's. In fact, this is (more or less) the
On Wednesday, February 25, 2015 at 5:35:33 AM UTC-5, Jeroen Demeyer wrote:
Thanks for the trace.
Unfortunately, it doesn't really help me. Can you temporarily remove
~/.inputrc and try again?
Wow! Removing ~/.inputrc fixed the problem! (Specifically, all tests pass
with 'make ptest'.)
Not really related but it seems ECL saw an update!
On Wednesday, February 25, 2015 at 10:43:28 PM UTC+1, François wrote:
On 02/26/15 10:30, Julien Puydt wrote:
Hi,
Le 25/02/2015 10:56, Julien Puydt a écrit :
it is a strange problem I have : using either debian's ecl or
upstream's
Hi!
On 2015-02-25, Jeroen Demeyer jdeme...@cage.ugent.be wrote:
Should there be code in Sage which is extremely slow and for educational
purposes only?
I believe such code is valuable.
Best regards,
Simon
--
You received this message because you are subscribed to the Google Groups
Le 25/02/2015 22:43, François Bissey a écrit :
That's fun, on Gentoo my ecl from the system just chew it without crashing.
What options are you using to build ecl I currently have
--enable-unicode -with-x and the rest turned off. Would it be thread
related by any chance?
Sage is using mpir
On 26/02/2015, at 20:12, Julien Puydt julien.pu...@laposte.net wrote:
Le 25/02/2015 22:43, François Bissey a écrit :
That's fun, on Gentoo my ecl from the system just chew it without crashing.
What options are you using to build ecl I currently have
--enable-unicode -with-x and the
On 26/02/2015, at 20:14, Julien Puydt julien.pu...@laposte.net wrote:
Salut,
Le 25/02/2015 23:00, Jean-Pierre Flori a écrit :
Not really related but it seems ECL saw an update!
Their homepage says 15.2.21, but the dowload page is always 13.5.1.
As I mentioned, upstream confirmed the
Salut,
Le 25/02/2015 23:00, Jean-Pierre Flori a écrit :
Not really related but it seems ECL saw an update!
Their homepage says 15.2.21, but the dowload page is always 13.5.1.
As I mentioned, upstream confirmed the bug, including for their latest
and greatest.
Snark on #sagemath
--
You
On Wed, 25 Feb 2015, Jeroen Demeyer wrote:
Should there be code in Sage which is extremely slow and for educational
purposes only?
As an additional package educational-algorithms?
--
Jori Mäntysalo
Le 26/02/2015 08:20, Francois Bissey a écrit :
On 26/02/2015, at 20:12, Julien Puydt julien.pu...@laposte.net wrote:
Le 25/02/2015 22:43, François Bissey a écrit :
That's fun, on Gentoo my ecl from the system just chew it without crashing.
What options are you using to build ecl I currently
On 25 February 2015 at 07:44, Vincent Delecroix
20100.delecr...@gmail.com wrote:
2015-02-24 22:58 UTC+01:00, William Stein wst...@gmail.com:
On Tue, Feb 24, 2015 at 1:52 PM, Volker Braun vbraun.n...@gmail.com
wrote:
Fixed in:
Awesome -- thanks!
But very annoying for sage-6.5. users...
We
Thanks for the trace.
Unfortunately, it doesn't really help me. Can you temporarily remove
~/.inputrc and try again?
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
2015-02-25 11:28 UTC+01:00, John Cremona john.crem...@gmail.com:
On 25 February 2015 at 07:44, Vincent Delecroix
20100.delecr...@gmail.com wrote:
2015-02-24 22:58 UTC+01:00, William Stein wst...@gmail.com:
On Tue, Feb 24, 2015 at 1:52 PM, Volker Braun vbraun.n...@gmail.com
wrote:
Fixed in:
Hi,
it is a strange problem I have : using either debian's ecl or upstream's
the following code :
(ext:set-limit 'ext:heap-size 0)
(setq a (expt 10 (expt 10 5)))
(setq b (expt a 600))
gives a crash (SIGABRT) Duplicate large block deallocation.
Where things get interesting, is that I get
41 matches
Mail list logo
