On May 14, 10:01 pm, Simon King wrote:
> Indeed, when I created the AttributeErrorMessage, it was suggested on
> trac to use LazyString instead. It turns out that a special purpose
> cythoned AttributeErrorMessage is faster, but I agree that in the
> general case (when it makes no sense to have a
Hi Nils,
On 2013-05-15, Nils Bruin wrote:
> We already have a tool for delaying string assembly and it indeed
> makes a difference in creating Exception objects:
>
> sage: from sage.misc.lazy_string import lazy_string
> sage: f=lambda op,A,B:"unsupported operand parent(s) for '%s': '%s'
> and '%s
The zeros problem is known:
http://trac.sagemath.org/sage_trac/ticket/11968
I could be responsible for some of this - but not all, as the documentation
was in even worse shape before I attacked it. I might be able to revist
some of this soon, but not immediately.
Rob
On Thursday, May 9, 2013
Has anyone taken a look at this or know what's wrong? Just wanted to bump
this once if anyone missed it
--
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 sage-devel
On May 14, 2:52 pm, Nils Bruin wrote:
> On May 14, 2:13 pm, Simon King wrote:
>
> > There is a lazy object specially designed for attribute errors. See
> > sage.structure.misc.AttributeErrorMessage.
We already have a tool for delaying string assembly and it indeed
makes a difference in creating
On May 14, 3:34 pm, Mike OS wrote:
> F. := GF(5)
> F(0)^0
...
> File "integer_mod.pyx", line 2381, in
> sage.rings.finite_rings.integer_mod.IntegerMod_int.__pow__
> (sage/rings/finite_rings/integer_mod.c:20136)
> ArithmeticError: 0^0 is undefined.
I'm pretty sure that's not the error you got
I have used it in the past, but not for anything essential. As long as
there was support for a search path, that would be fine for me.
On Tuesday, May 14, 2013 4:49:06 AM UTC-5, Volker Braun wrote:
>
> The plan would still be to support a search path, just not look at
> (undocumented) shell envi
Hi All,
A bug I think:
0^0 should be 1, right!
QQ(0)^0
1
F. := GF(5)
F(0)^0
Traceback (most recent call last):
File "", line 1, in
File "_sage_input_16.py", line 10, in
exec compile(u'open("___code___.py","w").write("# -*- coding: utf-8 -*-\\n"
+
_support_.preparse_worksheet_cell(b
On May 14, 2:13 pm, Simon King wrote:
> There is a lazy object specially designed for attribute errors. See
> sage.structure.misc.AttributeErrorMessage.
Cool. Doesn't the coercion framework end up trying all kinds of things
that may generate errors which get caught? Aren't those also different
er
Hi Nils,
On 2013-05-14, Nils Bruin wrote:
> I think someone was considering using a "lazy" object as "message"
> that would only materialize to a full string if it's really asked for.
> Did we ever get to that?
There is a lazy object specially designed for attribute errors. See
sage.structure.mi
On May 14, 11:35 am, Volker Braun wrote:
> Don't do that. Exceptions should be short and to the point. And not do any
> string processing. Don't convert passed values to strings unless you don't
> care about performance.
I agree, but it does happen. And as you see, matrix.__repr__ takes the
whole
When you index an iterable the __index__ method is used, so Sage integers
will work in many contexts.
On Tuesday, 14 May 2013 12:06:35 UTC-7, John H Palmieri wrote:
>
> Why does Python handle Sage Integers well in some cases but not in others?
> For example:
>
> $ sage --python
> Python
Anything that does isinstance(i,int) in the Python standard library is
broken. Usually thats when multiple input types are allowed. In this case
the argument to match.group() could be a string if you use the ?P
syntax to name the match group.
On Tuesday, May 14, 2013 8:06:35 PM UTC+1, John H
Why does Python handle Sage Integers well in some cases but not in others?
For example:
$ sage --python
Python 2.7.4 (default, May 8 2013, 16:25:06)
[GCC 4.7.3] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from sage.all import Integer
On Tuesday, May 14, 2013 6:54:38 PM UTC+1, Nils Bruin wrote:
> Not all "repr"s end up on a terminal, though. They can end up in
> exception messages that get caught, processed, and never printed.
Don't do that. Exceptions should be short and to the point. And not do any
string processing. Don'
On May 14, 10:02 am, Volker Braun wrote:
> I have no opinion on whether or not to do that on each _repr_ call. It
> doesn't do anything for me, but I don't see what the point of flooding the
> terminal even faster is.
Not all "repr"s end up on a terminal, though. They can end up in
exception mess
On Tuesday, May 14, 2013 9:39:22 AM UTC-7, Nils Bruin wrote:
> How about just changing this to "(use str(...) to see all entries)",
> where we rely on the intelligence of the user to interpret "..." to
> mean 'whatever access you have to the matrix'.
>
>
In principle a change like that sounds
I have no opinion on whether or not to do that on each _repr_ call. It
doesn't do anything for me, but I don't see what the point of flooding the
terminal even faster is.
But I do think the functionality to dig for a variable name from an object
is useful, and should be kept.
On Tuesday, Ma
Oh, and sage_getvariablename doesn't quite live up to its advertised
API either:
sage: L=["hi"]
sage: _T=L[0]
sage:
sage.misc.sageinspect.sage_getvariablename(L[0],omit_underscore_names=True)
'_T'
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
T
On http://trac.sagemath.org/sage_trac/ticket/14579 I noticed that sage
is doing something very fancy to produce a short "repr" of a large
matrix: It doesn't print the entries (I knew that), but it even goes
delving in the stack to see if it can find a name to which the matrix
might possibly be boun
I'll be there.
John T
--
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@goo
On May 14, 3:42 am, Jernej Azarija wrote:
> This is what the guys on #python (IRC) told me to consider
>
> >>> d1 = {-1: 0, -2: 0}>>> d2 = {-2: 0, -1: 0}>>> d1{-2: 0, -1: 0}>>> d2{-1:
> >>> 0, -2: 0}>>> d1 == d2True>>> d1.keys()[-2, -1]>>> d2.keys()[-1, -2]>>>
That is an extremely sneaky example
Hi WIlliam:
I'm curious, is there any further progress on this plan of a Use Sage!
series at Springer?
- David
On Thu, May 2, 2013 at 4:27 PM, William Stein wrote:
> Hi Sage-Developers,
>
> There is a big series of small books about R that Springer publishes:
>
> http://www.springer.com/series/
Could anyone have a look at this? Needless to say, this is *extremely*
annoying. Every few minutes the notebook gets completely messed up with
this bug.
I can forgo the Backspace Key, but I need to press Enter, and that just
breaks in the middle of a block then and I'm left with a complete d
u
d1 = {-1: 0, -2: 0}
d2 = {-2: 0, -1: 0}
d1
> {-2: 0, -1: 0}
d2
> {-1: 0, -2: 0}
d1 == d2
> True
d1.keys()
> [-2, -1]
d2.keys()
> [-1, -2]
NOooo
Ookokokokok. Then the code is good a
This is what the guys on #python (IRC) told me to consider
>>> d1 = {-1: 0, -2: 0}>>> d2 = {-2: 0, -1: 0}>>> d1{-2: 0, -1: 0}>>> d2{-1: 0,
>>> -2: 0}>>> d1 == d2True>>> d1.keys()[-2, -1]>>> d2.keys()[-1, -2]>>>
On Tue, May 14, 2013 at 12:12 PM, Nathann Cohen wrote:
> Hello everybody
No, you cannot. You should always think dictionaries as unordered
structures. Dictionary keys depend not only on the keys themselves but
on the operations performed on the dictionary. Take a simple case with
hash collision:
{{{
sage: A={}
sage: B={}
sage: A[hash('a')]=0
sage: A['a']=1
sage: B['a']
> does Axiom have Coercion?
You surely have never looked into AXIOM.
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.132.4943&rep=rep1&type=pdf
> How does it handle this?
> http://www.sagemath.org/doc/reference/coercion/sage/structure/coerce.html
It depends on how much automatic coerci
On 05/14/2013 12:12 PM, Nathann Cohen wrote:
Hello everybody !
I've got a small Python question whose answer you probably know.
Given a dictionary my_dict, I cannot expect my_dict.values() to always
return its elements in the same ordering, as I understand it depends on
the ordering of
Hello everybody !
I've got a small Python question whose answer you probably know.
Given a dictionary my_dict, I cannot expect my_dict.values() to always
return its elements in the same ordering, as I understand it depends on the
ordering of the keys which is machine-dependent.
This bein
The plan would still be to support a search path, just not look at
(undocumented) shell environment variables for it. So you'll still be able
to set a search path via a python function either from init.sage or the
attached source code.
On Tuesday, May 14, 2013 10:41:24 AM UTC+1, leif wrote:
>
For its purpose, see the docstring for /the preparser's/ 'load' (e.g. by
typing 'sage.misc.preparser.load?' at the Sage prompt, or see
[2]), or that of 'reset_load_attach_path' (which in contrast is directly
accessible) [3].
(This environment variable isn't documented anywhere else in /Sage's
As for the question "html( "In which kind of school do they teach
$\\sqrt{-2.4995} = - i 1.58$ ???" );", I think any good school that teaches
about complex numbers should teach that both - i 1.58 and i 1.58
are equally valid (approximate) square roots of -2.4995. One choice is as
good as another. A
On Tuesday, May 14, 2013 2:22:07 AM UTC+2, rjf wrote:
>
> So far
> as I can tell, Python offers no step forward, and maybe a step backward.
>
Sage != Python. Apart from that, does Axiom have Coercion? How does it
handle this?
http://www.sagemath.org/doc/reference/coercion/sage/structure/coerce.
34 matches
Mail list logo
