Hi,
On 2013-02-17, Simon King wrote:
> UniqueRepresentation is not just about "caching of an object by means of the
> arguments used to create it"! In addition, it is about objects that compare
> equal if and only if they are identical. Hence, overriding __eq__ simply
> makes no sense for sub-cla
Since I ran into the same question with named matrix groups (SL/GL/...) I
second that: separate out the cached constructor from the unique comparison
so the user can use whichever suits best.
On Sunday, February 17, 2013 7:59:49 AM UTC, Simon King wrote:
>
> - have a new class CachedRepresen
Hi Volker,
On 2013-02-17, Volker Braun wrote:
> --=_Part_1_1221513.1361103999361
> Content-Type: text/plain; charset=ISO-8859-1
>
> Since I ran into the same question with named matrix groups (SL/GL/...) I
> second that: separate out the cached constructor from the unique comparison
> so th
Its not published yet, I'm still working on it.
On Sunday, February 17, 2013 2:28:35 PM UTC, Simon King wrote:
>
> Is your "named matrix group" patch already merged? What version, what
> ticket? Because with my current (not yet published) cythonised
> UniqueRepresentation from #14054, I saw tro
Hi Simon!
On Sun, Feb 17, 2013 at 12:51:13AM +, Simon King wrote:
> Currently I try to make hash and comparison of UniqueRepresentation
> faster. When my attempts broke some tests, I found that
> UniqueRepresentation is used improperly in some locations.
>
> For example, it is used on
Hi Nicolas,
On 2013-02-17, Nicolas M. Thiery wrote:
> Now I certainly understand that you don't want to attack this issue
> upfront, for it's a big task and there will be resistance in the
> community. However, please make sure that the default behavior is that
> subclasses of UniqueRepresentatio
Hi Simon,
Probably good to make this difference. Some comments below.
On Feb 17, 7:48 am, Simon King wrote:
> - Have a class CachedRepresentation. If your class inherits from it, then
> calling your class with equal arguments returns identical instances,
> and pickling is automatically provi
Hi Nils,
On 2013-02-17, Nils Bruin wrote:
> Why "Representation"?
Because we already have Unique "Representation", and at least I wouldn't
like to change the name of UniqueRepresentation. But perhaps one could
think of Cached "Presentation", because the way of presenting the object
is used for c
On Feb 17, 9:56 am, Simon King wrote:
> You see, the class of a unique instance is like a good red wine in a
> bottle: The bottle remains the same, but the wine may improve in the
> course of time...
a bottle shared by many. And improvement is a matter of taste. If you
got a bottle because you t
Hi Nils,
On 2013-02-17, Nils Bruin wrote:
>> By the way, assigning to tp_hash results in a hash that is 1/3 faster
>> than defining
>> def __hash__(self):
>> return id(self)
>> in an extension class.
>
> Strange ... You'd think that Cython would register __hash__ functions
> *exactly*
PS:
On 2013-02-17, Nils Bruin wrote:
> a bottle shared by many. And improvement is a matter of taste. If you
> got a bottle because you thought you were getting a nice Merlot but it
> turns out that someone has changed it to a Rieslinger because they
> thought that was an improvement, you're prob
On Feb 17, 11:10 am, Simon King wrote:
> Yes. But the C code generated by Cython is *much* longer than what you get
> from
> cdef long hash_by_id(PyObject *o):
> return o
>
> So, if you assign the latter to tp_hash, it is faster. I could be
> mistaken, but I think *this* makes the diff
Hi Nils,
On 2013-02-17, Nils Bruin wrote:
> Wouldn't it be possible to accomplish this by assigning hash_by_id to
> tp_hash in, for instance, unique_representation_c.__cinit__?
> Given the
> order in which python executes __alloc__ on extension types, I think
> that would still offer subclasses
On Feb 17, 12:27 pm, Simon King wrote:
> Question: Do we *want* that subclasses can override it? After all, if
> they are sub-class of UniqueRepresentation, then they are supposed to
> show the unique representation behaviour---which includes that
> comparison is by identity.
I think we shouldn't
On Feb 17, 1:09 pm, Nils Bruin wrote:
> """
> User-defined classes have __cmp__() and __hash__() methods by default;
> with them, all objects compare unequal (except with themselves) and
> x.__hash__() returns id(x).
> """
The Python documentation is plainly wrong on that one by the way:
sage: A=
Hell !!
This is because "named groups" override the __eq__ method of
> UniqueRepresentation, but do not override the __hash__ method. So,
> that's broken. Similar things happen a lot in sage/graphs.
>
Looks like the only occurrence of UniqueRepresentation in graphs is in
i
Hello!
I have just noticed (accidentally) that there is a Russian interface
for Notebook. Well, that's great, but I didn't know somebody started
the Notebook interface localization. Or have I missed the announcement?
Anyway, I would like to take part in translation of Sage Notebook
interface.
On Sat, 16 Feb 2013 11:00:05 Thierry Dumont wrote:
> Dear Colleagues,
>
> I am wondering if a Sage interface to Shibboleth
> (http://en.wikipedia.org/wiki/Shibboleth_%28Internet2%29) would be
> inresting / difficult to build.
>
I may be able to find out.
> In France, Shibboleth is popular in ac
Hi Nils,
On 2013-02-17, Nils Bruin wrote:
> On Feb 17, 12:27 pm, Simon King wrote:
>> Question: Do we *want* that subclasses can override it? After all, if
>> they are sub-class of UniqueRepresentation, then they are supposed to
>> show the unique representation behaviour---which includes that
>
Hi Nathann,
On 2013-02-17, Nathann Cohen wrote:
> Looks like the only occurrence of UniqueRepresentation in graphs is in
> isgci.py. If you want to remove it, please help yourself as it is totally
> useless.
Yep! That's where everything broke :)
>> But in addition, the hash is broken in the e
Hi,
I'm having problems installing Sage 5.6 from source, in particular, the package
ecl-11.1.2.cvs2020.p2.
My host system is Linux 2.6.10-1.771_FC2smp with gcc version 4.6.3. The
ecl-11.1.2.cvs2020.p2.log file recorded this error message:
gcc -DECLDIR="\"/home/cjiali/Sage5.6/sage-5.6
On Feb 17, 3:25 pm, Simon King wrote:
> So, it would work. Note, however, that your suggestion is intrusive as
> well. It would be impossible to use a different hash in a sub-class:
> sage: cython("""
> : from sage.misc.fast_methods import provide_hash_by_id
> : cdef class Foo:
> .
Hi,
On 2013-02-18, Nils Bruin wrote:
> sage: cython("""cdef class Foo(object): ...""")
> sage: provide_hash_by_id(Foo)
That would indeed be the plan for the less intrusive version, but...
> If we can't resolve why setting "tp_hash" manually is different from
> providing a "def __hash__" then in
Hi,
On 2013-02-18, Simon King wrote:
> *If* possible. I don't see what I did wrong here, but when I assign to
> the tp_hash of Foo (before or after creating instances) and then create
> a sub-class, the sub-class forgets everything about the hash.
>
> Which might actually be what we want, because
On Feb 17, 3:25 pm, Simon King wrote:
> However, subclasses forget everything about the hash:
> sage: class Bar(Foo):
> : pass
> :
> sage: b = Bar()
> sage: hash(b) == id(b)
> False
> sage: hash(b) == id(b) >> 4
> True
OK, I think I've found the problem. I think cytho
On Feb 17, 10:35 pm, Nils Bruin wrote:
> Indeed, we have
>
> sage: MyHash.__dict__["__hash__"](h)
> 0
> sage: print MyHash.__hash__(h)
> 0
> sage: h.__hash__()
> 0
Incidentally, this suggests that hash(a) does the following:
1] see if type(a).tp_hash is set. If so, use this
2] see if type(a) i
On Feb 17, 10:35 pm, Nils Bruin wrote:
> The only reason I can think of for inheritance not to pick up on the
> changed tp_hash field is that PyType_Ready gets called on the data
> structure formed for MyHash before we get a chance to change the
> tp_hash field.
Indeed, PyType_Ready calls add_ope
Simon ran into the following snag:
* To provide a hash function on a python extension class, one needs
to assign a function pointer of type
long (PyObject *). One can do exactly that using a "cdef" in
cython
* Cython only accepts "def __hash__(self):" to define this hash
function. This function
How about cpdef, does that work? It might give you the best of both worlds.
--
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
On Feb 17, 11:47 pm, Jeroen Demeyer wrote:
> How about cpdef, does that work? It might give you the best of both worlds.
Could be, but cython does need to take special action: It needs to
recognize a cdef of the right signature is available and plug that
straight into the slot (such as tp_hash) r
30 matches
Mail list logo
