Oh dear, I should have taken a break. Thank you.
On Saturday 24 February 2024 at 22:47:49 UTC+1 dmo...@deductivepress.ca
wrote:
> Yes. Elements of F are linear combinations of the basis vectors a and b.
> Since 5/3 is not such a linear combination, it is certainly not in F.
>
> On Saturday, Feb
Yes. Elements of F are linear combinations of the basis vectors a and b.
Since 5/3 is not such a linear combination, it is certainly not in F.
On Saturday, February 24, 2024 at 4:35:56 PM UTC-5 Martin R wrote:
> In combinat/free_module.py, CombinatorialFreeModule, I find the doctest
> below.
>
> I must admit that I do not understand the philosophy.
>
Which part?
>
> But apart from that: for classes inheriting from ClonableArray, which have
> to implement equality (because there is no coercion to a common parent), do
> they have to implement _richcmp_ or __richcmp__ or _eq_ or __eq
https://trac.sagemath.org/ticket/34824 has a green bot, please review!
On Tuesday, 13 December 2022 at 10:03:20 UTC+1 Martin R wrote:
> I must admit that I do not understand the philosophy.
>
> But apart from that: for classes inheriting from ClonableArray, which have
> to implement equality (be
I must admit that I do not understand the philosophy.
But apart from that: for classes inheriting from ClonableArray, which have
to implement equality (because there is no coercion to a common parent), do
they have to implement _richcmp_ or __richcmp__ or _eq_ or __eq__? (The
amount of magic i
+1 on what Nils said; I only find it slightly surprising initially. Compare
this with comparing a list to a Partition as well. Equality is a bit
different as a programming concept than a mathematical one. When you
implement a custom __eq__, then you are separating that class from the
coercion-b
On Monday, 12 December 2022 at 00:22:30 UTC-8 axio...@yahoo.de wrote:
> Ah, thank you so much!
>
> Just to make sure that I understand the philosophy: if two elements are
> supposed to compare equal, they should have parents which can be coerced to
> a common parent, right? For example, the fol
Ah, thank you so much!
Just to make sure that I understand the philosophy: if two elements are
supposed to compare equal, they should have parents which can be coerced to
a common parent, right? For example, the following (which is current
behaviour) is not really what we want:
sage: A = SetP
Once again:
https://docs.python.org/3/reference/datamodel.html#object.__hash
__eq__ and __hash__ are tied ad the hip: overriding one prevents
inheritance of the other.
Python takes its contract "equality must imply identical hashes" a little
more seriously than sage, so Python doesn't allow th
Help needed again. I removed the (seemingly) useless overrides, but now
SetPartition and DecoratedPermutation isn't hashable anymore. Curiously,
ParkingFunction is, and I don't see the difference.
On Saturday, 10 December 2022 at 23:45:41 UTC+1 Martin R wrote:
> https://trac.sagemath.org/tick
https://trac.sagemath.org/ticket/34824 now removes the parent from the
hash, and all the overrides I could find.
On Friday, 9 December 2022 at 23:03:38 UTC+1 Nils Bruin wrote:
> On Friday, 9 December 2022 at 02:49:12 UTC-8 axio...@yahoo.de wrote:
>
>> Would it make sense to have a subclass, or pe
On Friday, 9 December 2022 at 02:49:12 UTC-8 axio...@yahoo.de wrote:
> Would it make sense to have a subclass, or perhaps an option to
> ClonableArray.__init__, that determines whether or not to include the
> parent into the hash? The current behaviour seems rather error prone to me.
>
I think
Would it make sense to have a subclass, or perhaps an option to
ClonableArray.__init__, that determines whether or not to include the
parent into the hash? The current behaviour seems rather error prone to me.
On the other hand, I am not sure whether GF(3)(4) == ZZ(4) is desirable.
Martin
On F
Let me mostly rephrase what Nils said above with a bit more of specific
information. I would say this issue comes from a "feature" of
ClonableArray. The default hashing of ClonableArray is to also hash in the
parent and have elements in different parents not (by default) compare
equal. A coerci
On Sunday, 4 December 2022 at 23:45:00 UTC-8 j...@aims.ac.za wrote:
> Note sage 9.2 (debian package) gives an error (sage 9.7 does not):
>
>
Probably the following ticket then (Scrimshaw/Chapoton):
https://trac.sagemath.org/ticket/15216
--
You received this message because you are subscrib
Hi
On Mon, 5 Dec 2022 at 09:38, Nils Bruin wrote:
> On Sunday, 4 December 2022 at 23:15:35 UTC-8 axio...@yahoo.de wrote:
>
>> I accidentally opened a new ticket https://trac.sagemath.org/ticket/34824,
>> which is essentially ready for review. There is another problem, which I
>> do not understa
On Sunday, 4 December 2022 at 23:15:35 UTC-8 axio...@yahoo.de wrote:
> I accidentally opened a new ticket https://trac.sagemath.org/ticket/34824,
> which is essentially ready for review. There is another problem, which I
> do not understand, which may be dealt with in the same ticket, if it is
I accidentally opened a new ticket https://trac.sagemath.org/ticket/34824,
which is essentially ready for review. There is another problem, which I
do not understand, which may be dealt with in the same ticket, if it is
easy:
sage: P = ParkingFunctions(4)
sage: B = P([1, 2, 3, 4, 5, 6])
sage:
It looks like just overriding `_hash_` should do the trick. It's a "cpdef"
method so the code should be there to check if it's overridden on a
descendant class instance. There will be a performance degradation,
although it will be mild because the hash is cached. If that's a problem,
you can cy
I actually don't see how to do this, because ParkingFunction inherits the
implementation of _hash_ from ClonableArray, just the same as, for example
DecoratedPermutation, where the problem does not occur.
Any ideas?
On Saturday, 3 December 2022 at 18:15:35 UTC+1 Nils Bruin wrote:
> On Saturday
On Saturday, 3 December 2022 at 06:41:30 UTC-8 axio...@yahoo.de wrote:
> Note that this does not happen for DyckWords or Permutations.
>
> I think - should we decide that we do not want this - we could try to add
> a test to the category framework. Is there already some structure in place
> to
Hi Dima!
Thank you for your replies! I understand the technicalities, but my main
question is: do we really want that?
I should add that it took me a long while to figure out what's happening,
because in my application I computed orbits under an action, and I observed
that the orbit sizes wer
but you can use Set() (a Sage's class for sets), which is much more sane here:
sage: f in Set(P)
True
sage: g in Set(P)
True
On Fri, Dec 2, 2022 at 5:13 PM Dima Pasechnik wrote:
>
> in fact, you can see that
>
> sP=set(P)
> sP.add(g)
> len([t for t in sP])==len(P)+1
>
> gets you True...
>
>
> O
in fact, you can see that
sP=set(P)
sP.add(g)
len([t for t in sP])==len(P)+1
gets you True...
On Fri, Dec 2, 2022 at 5:08 PM Dima Pasechnik wrote:
>
> On Fri, Dec 2, 2022 at 5:05 PM 'Martin R' via sage-devel
> wrote:
> >
> > OK, thank you, but is this really intentional? I would have thought
On Fri, Dec 2, 2022 at 5:05 PM 'Martin R' via sage-devel
wrote:
>
> OK, thank you, but is this really intentional? I would have thought that x
> in P and x in set(P) should give the same result.
I guess that hashing is done using a .parent()...
>
> On Friday, 2 December 2022 at 16:57:50 UTC+1
OK, thank you, but is this really intentional? I would have thought that x
in P and x in set(P) should give the same result.
On Friday, 2 December 2022 at 16:57:50 UTC+1 dim...@gmail.com wrote:
> On Fri, Dec 2, 2022 at 2:44 PM 'Martin R' via sage-devel
> wrote:
> >
> > a hashing problem, mayb
On Fri, Dec 2, 2022 at 2:44 PM 'Martin R' via sage-devel
wrote:
>
> a hashing problem, maybe?
to me, is't a problem of different "types" (.parent(), to be precise.
See my reply on the ticket)
>
> On Friday, 2 December 2022 at 15:43:33 UTC+1 Martin R wrote:
>>
>> I need help with https://trac.sag
a hashing problem, maybe?
On Friday, 2 December 2022 at 15:43:33 UTC+1 Martin R wrote:
> I need help with https://trac.sagemath.org/ticket/34817
>
> Essentially, I have a list P and an object g such that g in P but g not in
> set(P).
>
> How could this happen?
>
--
You received this message be
On Wednesday, September 26, 2012 5:03:15 PM UTC-4, Simon King wrote:
>
> Hi Greg,
>
> On 2012-09-26, Greg Laun > wrote:
> >
> > sage: matrix(GL(2),2,[1,0,0,1]) in GL(2,CC)
> > True
>
> Do you mean "GF(2)" on the left hand side?
>
Ahh, yes I did mean that.
>
> >
> > so 'in' ignores base
On Wednesday, September 26, 2012 1:19:31 PM UTC-7, Greg Laun wrote:
>
> Whoops, gmail sent the email before I was finished.
>
> I think a more appropriate way to do the comparison would be to check
> if self(x) == x. This is how contains is implemented in parent.pyx.
>
In theory this looks
On 2012-09-26, Greg Laun wrote:
> --=_Part_757_16956430.1348690771123
> Content-Type: text/plain; charset=ISO-8859-1
>
> Whoops, gmail sent the email before I was finished.
>
> I think a more appropriate way to do the comparison would be to check
> if self(x) == x. This is how contains i
Hi Greg,
On 2012-09-26, Greg Laun wrote:
>
> sage: matrix(GL(2),2,[1,0,0,1]) in GL(2,CC)
> True
Do you mean "GF(2)" on the left hand side?
>
> so 'in' ignores base ring. The problem is that __contains__ for
> general_linear.pyx and special_linear.pyx only check whether a matrix can
> be coer
On Wednesday, September 26, 2012 1:07:31 PM UTC-7, Greg Laun wrote:
>
> Hi Everyone,
>
> I'm sorry if this has been discussed, but I can't find a discussion. I
> noticed the following behavior:
>
> sage: matrix(GL(2),2,[1,0,0,1]) in GL(2,CC)
> True
>
> so 'in' ignores base ring. The problem is t
Whoops, gmail sent the email before I was finished.
I think a more appropriate way to do the comparison would be to check
if self(x) == x. This is how contains is implemented in parent.pyx.
Any thoughts?
Thanks,
Greg
On Wednesday, September 26, 2012 4:07:31 PM UTC-4, Greg Laun wrote:
>
34 matches
Mail list logo
