On Thu, Jun 2, 2016 at 11:01 PM, Jori Mäntysalo wrote:
> Why do we have cached results?
>
> Beginners do something like
>
> for x in small_list:
> if x in SimpleThing(42).list():
> echo("Found!", x)
>
> Advanced users should know how to do
>
> temp = ComplicatedThing(10^6).list()
> mat
As others, I think that having X.list() returning a tuple will be really
misleading for many users.
Le 02/06/2016 22:39, Volker Braun a écrit :
The ones that understand the difference between list and tuple also
understand why a cached_method can't return a list.
I think this is completely fa
Alternative idea to sidestep the whole list/tuple discussion: implement
a new type immutable_list which inherits from list. It is yet another
container type, but it is less confusing (the thing really behaves like
a list except that it cannot be modified).
Jeroen.
--
You received this message
Surely one problem with having a list method as in F.list() is that
the informal meaning of "give me a list of the elements of F so that I
do stuff with it" is being confused with a technical computing term
"list" which has certain properties, such as mutability.
If the method was called something
On 2016-06-03 10:53, John Cremona wrote:
> If the method was called something else such as F.elements()
+1
(and maybe deprecate .list() as it does not give you an idea what this
list contains)
The objects (as GF(5)) are and should be still iterable, thus one can
use list(GF(5)) and tuple(GF(5))
Le jeudi 2 juin 2016 22:33:45 UTC+2, Volker Braun a écrit :
>
> I'm guessing that this won't fly with upstream ;-)
>
> Is it really faster? A new __unary_div__ method everywhere? Is it really
> faster than special-casing the 1/x case in __div__?
>
By analogy to __neg__ the new unary method
migh
what is the output of `which cpp`?
normally, /lib/cpp (what pops up in your error message)
should be a symbolic link to /etc/alternatives/cpp ` like this:
$ file /lib/cpp
/lib/cpp: symbolic link to `/etc/alternatives/cpp'
$ file /etc/alternatives/cpp
/etc/alternatives/cpp: symbolic link to `/us
Hi Dima,
Here are the commands and outputs
~$ which cpp
/usr/bin/cpp
~$ file /lib/cpp
/lib/cpp: symbolic link to /etc/alternatives/cpp
~$ file /etc/alternatives/cpp
/etc/alternatives/cpp: symbolic link to /usr/bin/cpp
~$ cpp -v
Using built-in specs.
COLLECT_GCC=cpp
Target: x86_64-linux-gnu
Conf
Oh, I see. You need c++ compiler (g++) installed, and you do not have it.
The error message could be better.
On Friday, June 3, 2016 at 3:09:32 PM UTC+1, Adetokunbo Arogbonlo wrote:
>
> Hi Dima,
> Here are the commands and outputs
> ~$ which cpp
> /usr/bin/cpp
>
> ~$ file /lib/cpp
> /lib/cpp: symb
On Friday, June 3, 2016, Samuel Lelievre wrote:
>
>
> Le jeudi 2 juin 2016 22:33:45 UTC+2, Volker Braun a écrit :
>>
>> I'm guessing that this won't fly with upstream ;-)
>>
>> Is it really faster? A new __unary_div__ method everywhere? Is it really
>> faster than special-casing the 1/x case in _
On Friday, June 3, 2016 at 3:14:20 PM UTC+1, Dima Pasechnik wrote:
>
> Oh, I see. You need c++ compiler (g++) installed, and you do not have it.
>
in fact
http://doc.sagemath.org/html/en/installation/source.html#prerequisites
says:
# debian
sudo apt-get install binutils gcc g++ gfortran ma
Thanks. How could you tell? I thought with gcc came with g++ by default.
On Saturday, June 4, 2016 at 12:25:50 AM UTC+10, Dima Pasechnik wrote:
>
>
>
> On Friday, June 3, 2016 at 3:14:20 PM UTC+1, Dima Pasechnik wrote:
>>
>> Oh, I see. You need c++ compiler (g++) installed, and you do not have it.
On Thursday, June 2, 2016 at 5:41:59 PM UTC-4, William wrote:
>
>X.list()
> might very well return a tuple of four *mutable* 2x2 matrices. Then
> this X.tuple() is still very much mutable, and the original problem
> has not been solved.I guess that's my point.
>
But that has is total
On Friday, June 3, 2016, Volker Braun wrote:
> On Thursday, June 2, 2016 at 5:41:59 PM UTC-4, William wrote:
>>
>>X.list()
>> might very well return a tuple of four *mutable* 2x2 matrices. Then
>> this X.tuple() is still very much mutable, and the original problem
>> has not been solved.
On 3 June 2016 at 15:25, William Stein wrote:
>
>
> On Friday, June 3, 2016, Samuel Lelievre wrote:
>>
>>
>>
>> Le jeudi 2 juin 2016 22:33:45 UTC+2, Volker Braun a écrit :
>>>
>>> I'm guessing that this won't fly with upstream ;-)
>>>
>>> Is it really faster? A new __unary_div__ method everywhere
+1 to treating the 1/x as a special case in the coercion model.
It would also help with situations like
{{{
sage: F.=FreeGroup()
sage: 1/x
---
TypeError Traceback (most recent call last)
in (
Hi All,
I know it would considerably slow down @cached_method, but what about the
following:
- When a new item for the cache is first computed, test whether it is
hashable.
- Along with the item, store whether it is hashable or not (so that
there's no need to test hashability again).
- If an i
1 is already special cased in
sage: FreeGroup('ab')(1)
1
But using division or multiplication go through the coercion model. I am
not sure we want to special case 1 in all multiplication/division. It is
likely to slow even more our slow coercion model...
Vincent
On 03/06/16 18:43, mmarco wr
IMHO we shouldn't slow down cached_method just to allow you to write
incorrect code (and caching a returned list is a bug). If anything,
cached_method should print a warning if the result is mutable so people can
fix their code.
On Friday, June 3, 2016 at 1:10:25 PM UTC-4, Simon King wrote:
Am Freitag, 3. Juni 2016 19:11:01 UTC+2 schrieb vdelecroix:
>
> But using division or multiplication go through the coercion model. I am
> not sure we want to special case 1 in all multiplication/division. It is
> likely to slow even more our slow coercion model...
>
>
Note that testing "a==1"
Am Freitag, 3. Juni 2016 19:19:27 UTC+2 schrieb Volker Braun:
>
> IMHO we shouldn't slow down cached_method just to allow you to write
> incorrect code (and caching a returned list is a bug). If anything,
> cached_method should print a warning if the result is mutable so people can
> fix their
On 2016-06-03 19:55, Simon King wrote:
Note that testing "a==1" goes through the coercion model as well.
Sure, but that's not what you want to do. I propose to test something like
(isinstance(a, int) and a == 1) or (type(a) is Integer and a == 1)
but then more efficiently. That should be pret
On 2016-06-03 19:10, Vincent Delecroix wrote:
I am not sure we want to special case 1 in all multiplication/division.
Well, there are a lot of places in Sage where we use ~x currently. This
means that there is a lot of demand for computing 1/x.
--
You received this message because you are su
The title says it all: Is it still state of the art that we cannot get
canonical labels and graph isomorphisms from nauty?
I found this post from last year
https://groups.google.com/d/topic/sage-devel/mKZ1Ar1lJG0/discussion
I just checked the vertex-facet incidence graph of the 24-cell, the
On Friday, June 3, 2016 at 3:52:32 PM UTC+1, Adetokunbo Arogbonlo wrote:
>
> Thanks. How could you tell? I thought with gcc came with g++ by default.
>
well, there are messages in your config.log regarding the absence of c++
compiler.
And no, gcc suite of compilers has quite a few languages sup
On Friday, June 3, 2016 at 2:02:53 PM UTC-4, Simon King wrote:
>
> But my second suggestion was: Add an option to @cached_method, so that one
> can request copy-on-return.
>
I understood what you want, but I'm saying that its bad to have a bug in
the code that is then worked around by a decorato
On Friday, June 3, 2016 at 11:02:53 AM UTC-7, Simon King wrote:
>
>
> But my second suggestion was: Add an option to @cached_method, so that one
> can request copy-on-return.
>
> -1 for bug trap. We don't know what the correct interpretation of "copy"
is. Most of the time, shallow copy will be en
On Friday, June 3, 2016 at 8:09:29 PM UTC+1, Christian Stump wrote:
>
> The title says it all: Is it still state of the art that we cannot get
> canonical labels and graph isomorphisms from nauty?
>
> I found this post from last year
>
> https://groups.google.com/d/topic/sage-devel/mKZ1Ar1lJ
On Friday, June 3, 2016 at 12:42:29 PM UTC-7, Volker Braun wrote:
>
>
> I understood what you want, but I'm saying that its bad to have a bug in
> the code that is then worked around by a decorator. Just don't put the bug
> in the code to begin with. Apart from being the right thing to do, its al
On Friday, June 3, 2016 at 3:54:57 PM UTC-4, Nils Bruin wrote:
>
> It could be that the undecorated code is bug-free
>
That is obviously fine, just don't decorate it with a memoization operator.
But don't code that is manifestly wrong with a memoziation operator but
then fixed by a subtle varia
Hopefully a little more robust benchmark:
sage: cython("""
: from sage.rings.integer import Integer
: from sage.rings.integer cimport Integer
: from sage.rings.rational import Rational
: from sage.rings.rational cimport Rational
: def U(a, n):
: cdef Integer A=a
:
31 matches
Mail list logo
