On Tue, Mar 5, 2013 at 7:31 PM, Nicolas M. Thiery
wrote:
> Hi Robert, Volker and other fans of lazy import!
>
> Working on #4327 made me want to be able to lazy import a full
> module. That is have:
>
> lazy_import("sage.combinat.root_system.plot")
>
> be a lazy analogue of:
>
>
I'm curious whence the "RuntimeError: Floating point exception,"
perhaps I should just go look at the code...
On Tue, Mar 5, 2013 at 5:02 PM, William Stein wrote:
> On Tue, Mar 5, 2013 at 10:55 AM, Robert Bradshaw
> wrote:
>> On Tue, Mar 5, 2013 at 7:39 AM, David Loeffler
>> wrote:
>>> On 5 Mar
No floating points have been involved in the code. The error should be
caused by divide-by-zero.
If N>46341, a product of two integers might be overflow and result in a
negative number. Consequently, the range of a denominator would start from
a negative integer and end at a positive number, and t
Hey,
Thanks Kannappan for your work on this! By the way: would you mind
> using the occasion to move this method to the CoxeterGroups category?
> Of course, calling "W.longest_element()" for an infinite coxeter group
> W is not a wise thing to do; but we recently had the need for
> computing l
> Of
> course this would only be after it has been broken up into connected
> components. Perhaps I'm over simplifying things...
If I understand it right, Nicolas suggested to move that stuff the the
CoxeterGroups category. In this generality, this approach of checking
finite types doesn't work, b
Dear Sage enthusiasts,
I found this very interesting python package:
http://plumbum.readthedocs.org/en/latest/
I prefer Python for scripting in general, but in some cases a shell script
is just easier, especially if you want to call out to command line
utilities, pipe their output, et cetera.
On 2013-03-06 15:01, Timo Kluck wrote:
> so that we could
> start using Python scripts in many places were we use shell scripts now.
> Think the packaging system
We can't do that, since you would have a circular dependency of the
packaging system on plumbum, plumbum on Python, Python on the packagi
I've logged onto the MAA website twice now and don't even see the March CMJ
available online, let alone that article. I hope it becomes available soon.
john perry
On Tuesday, March 5, 2013 10:51:26 AM UTC-6, kcrisman wrote:
>
> See http://www.maa.org/pubs/cmj_mar13.html and your local library (o
Op woensdag 6 maart 2013 15:06:08 UTC+1 schreef Jeroen Demeyer het volgende:
>
> On 2013-03-06 15:01, Timo Kluck wrote:
> > so that we could
> > start using Python scripts in many places were we use shell scripts now.
> > Think the packaging system
> We can't do that, since you would have a cir
Hi John,
On Thu, Mar 7, 2013 at 2:20 AM, john_perry_usm wrote:
> I've logged onto the MAA website twice now and don't even see the March CMJ
> available online, let alone that article. I hope it becomes available soon.
You might want to try this link to JSTOR:
http://www.jstor.org/stable/10.416
How rude! I pay for online access to MAA magazines (specifically!) and
can't see it yet from the MAA's own website, but for an extra $12 I can buy
it from JSTOR, and see a preview for free? X-O
There's a complaint to the MAA somewhere in this, if only I can be roused
to make it... ;-)
john per
On 2013-03-06 16:23, Timo Kluck wrote:
> you can
> suddenly mix all that piping with with dictionaries, or any
> other things in which python is superior to bash.
This would probably be the best argument.
> Think readability
So you think that
(echo 'print(factor(x^2 - 1))' | xargs[sage['-c']])()
Op woensdag 6 maart 2013 16:46:08 UTC+1 schreef Jeroen Demeyer het volgende:
>
> On 2013-03-06 16:23, Timo Kluck wrote:
> > you can
> > suddenly mix all that piping with with dictionaries, or any
> > other things in which python is superior to bash.
> This would probably be the best argument.
When I doctest a particular Sage enhancement, I receive errors that I do
not know how to handle.
For example, consider the following:
**
File
"/Users/Ben/sage-5.8.beta1/devel/sage-combinat/sage/combinat/crystals/infinity_crys
One approach to figuring out what's going on would be to apply #12415 and
see if the problem goes away.
David
On Wed, Mar 6, 2013 at 6:21 AM, Ben Salisbury wrote:
> When I doctest a particular Sage enhancement, I receive errors that I do
> not know how to handle.
>
> For example, consider the f
On Tue, 05 Mar 2013 at 03:51AM -0800, tom d wrote:
> Yes, I would support such a warning; I've even led tutorials with new sage
> users where defining things called 'max' or 'min' has seemed an obvious
> thing to do and then minutes later been a problem as the default function
> was unavailable.
Recently in a different thread here [1], someone accidentally clobbered
a Python builtin with a symbolic function:
sage: t = (1,2,3)
sage: len(t) = 4
...which overwrites t and the Python builtin len.
I have a patch at #14231 that, at Nils Bruin's suggestion, *always*
prints when defining a
On Wednesday, March 6, 2013 10:40:03 AM UTC-8, Dan Drake wrote:
>
> On Wed, 06 Mar 2013 at 11:05AM -0700, Ivan Andrus wrote:
> > Would it be possible to print the warning only if the session is
> > interactive. Then you wouldn't have to change doctests and wouldn't
> > have to see the warning
On Mar 6, 10:05 am, Ivan Andrus wrote:
> Would it be possible to print the warning only if the session is interactive.
> Then you wouldn't have to change doctests and wouldn't have to see the
> warning when running scripts.
Any time you change the behaviour between interactive and non-
interac
On Mar 6, 2013, at 10:32 AM, Dan Drake wrote:
> Recently in a different thread here [1], someone accidentally clobbered
> a Python builtin with a symbolic function:
>
> sage: t = (1,2,3)
> sage: len(t) = 4
>
> ...which overwrites t and the Python builtin len.
>
> I have a patch at #14231 that
On Wed, 06 Mar 2013 at 11:05AM -0700, Ivan Andrus wrote:
> Would it be possible to print the warning only if the session is
> interactive. Then you wouldn't have to change doctests and wouldn't
> have to see the warning when running scripts.
Sure, good idea. How do we test if we're in an interacti
Timo Kluck wrote:
Op woensdag 6 maart 2013 16:46:08 UTC+1 schreef Jeroen Demeyer het volgende:
On 2013-03-06 16:23, Timo Kluck wrote:
> you can
> suddenly mix all that piping with with dictionaries, or any
> other things in which python is superior to bash.
This would prob
On 2013-03-06 18:02, David Roe wrote:
> One approach to figuring out what's going on would be to apply #12415
> and see if the problem goes away.
I agree. It looks more like a problem with the doctesting framework than
with the test itself.
--
You received this message because you are subscribed
Hi John,
On Thu, Mar 7, 2013 at 2:32 AM, john_perry_usm wrote:
> How rude! I pay for online access to MAA magazines (specifically!) and can't
> see it yet from the MAA's own website, but for an extra $12 I can buy it
> from JSTOR, and see a preview for free? X-O
I believe there has been a break
Minh
You're right that there's a breakdown; I seem to have given you the wrong
impression. You were not rude at all. The "rudeness" is in the MAA, who
provide access to other paying customers but not their own members. & even
that is meant tongue-in-cheek.
john perry
On Wednesday, March 6, 20
On 03/07/2013 02:48 AM, John H Palmieri wrote:
(But don't ask me why DOCTEST_MODE is defined in plot.py...)
AFAIK, it is used to stop Sage from trying to open some image viewer or
the jmol viewer once the picture is generated.
--
You received this message because you are subscribed to the G
On 2013-03-06 19:48, Nils Bruin wrote:
> Any time you change the behaviour between interactive and non-
> interactive sessions you make things harder to debug. Perhaps instead
> of *printing* something, return a value that has a __repr__ that looks
> like an informative message. A string would basi
27 matches
Mail list logo
