Re: [sage-devel] Element.__hash__ stopgap

2015-10-02 Thread Nathann Cohen
> Not really, you did explicitly ask to postpone a Sage release. I'm against > that. I did not comment on the stopgap. I did, and only because I thought others wanted it. I do not mind myself, and I have no objection to a release tomorrow if the stopgap is included. Nathann -- You received this

Re: [sage-devel] Element.__hash__ stopgap

2015-10-02 Thread Jeroen Demeyer
On 2015-10-02 17:17, Nathann Cohen wrote: I merely ask for this dangerous bug to trigger a stopgap warning. Not really, you did explicitly ask to postpone a Sage release. I'm against that. I did not comment on the stopgap. -- You received this message because you are subscribed to the Google

Re: [sage-devel] Element.__hash__ stopgap

2015-10-02 Thread Nathann Cohen
> Why that? If you only want to release Sage when there are no known bugs, we > will never release Sage again. I did not ask for all bugs to be solved. I merely ask for this dangerous bug to trigger a stopgap warning. This is easy to do. Other people here seem more comfortable with the idea of ha

Re: [sage-devel] Element.__hash__ stopgap

2015-10-02 Thread Jeroen Demeyer
On 2015-10-02 08:48, Nathann Cohen wrote: Couldn't we see with Volker if we cannot have a couple of betas again and then release the next stable version next month or so? Why that? If you only want to release Sage when there are no known bugs, we will never release Sage again. Especially given

Re: [sage-devel] Element.__hash__ stopgap

2015-10-02 Thread Nathann Cohen
> > In the real world "needing more time" is a perfectly normal reason to > downgrade blockers. Look at any big project, e.g. > http://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting > You are right, and "fixing all hash functions" is not a blocker, as it is obviously a lot of work. The sto

Re: [sage-devel] Element.__hash__ stopgap

2015-10-02 Thread Volker Braun
In the real world "needing more time" is a perfectly normal reason to downgrade blockers. Look at any big project, e.g. http://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting On Friday, October 2, 2015 at 10:50:52 AM UTC+2, Nathann Cohen wrote: > > > That was exactly William's proposition, ex

Re: [sage-devel] Element.__hash__ stopgap

2015-10-02 Thread Nathann Cohen
> That was exactly William's proposition, except that it will be called > 6.10.betaN instead of 6.9.beta(N+8). This 'except', my dear Volker, is precisely the reason why we are having this gentle chat here. Nathann -- You received this message because you are subscribed to the Google Groups "s

Re: [sage-devel] Element.__hash__ stopgap

2015-10-02 Thread Volker Braun
On Friday, October 2, 2015 at 8:48:03 AM UTC+2, Nathann Cohen wrote: > > version soon? Couldn't we see with Volker if we cannot have a couple of > betas again and then release the next stable version next month or so? > That was exactly William's proposition, except that it will be called 6.10.b

Re: [sage-devel] Element.__hash__ stopgap

2015-10-02 Thread Nathann Cohen
Small update to Vincent's ranking: #19321 now has a positive review. Nathann On 2 October 2015 at 08:48, Nathann Cohen wrote: > Let me add something: is there really *anything* that forces us to release > the next stable version soon? Couldn't we see with Volker if we cannot have > a couple of

Re: [sage-devel] Element.__hash__ stopgap

2015-10-01 Thread Nathann Cohen
Let me add something: is there really *anything* that forces us to release the next stable version soon? Couldn't we see with Volker if we cannot have a couple of betas again and then release the next stable version next month or so? We seem in a hurry to do things, but we have control of the dead

Re: [sage-devel] Element.__hash__ stopgap

2015-10-01 Thread Nathann Cohen
Yoo, About your order of preferences: > 1) fix and merge #19016 before the stable +1, but given the amount of work I do not see it happen quickly enough. > 2) merge #19321 and #19331 before the stable Big +1 to that. With [new individual hash functions] added to [a default hash to

Re: [sage-devel] Element.__hash__ stopgap

2015-10-01 Thread Vincent Delecroix
Hello, Let me try to summarize: 1) The hash of Element is definitely wrong in *some* situations. For the computation of Cayely graphs of finitely presented groups. Or if an element is renamed as in sage: class E(Element): pass sage: e = E(Parent()) sage: e.rename('toto') sage: hash(e) 231405

Re: [sage-devel] Element.__hash__ stopgap

2015-10-01 Thread William Stein
On Thu, Oct 1, 2015 at 12:35 PM, Nathann Cohen wrote: >> This message seems like flamebait [1], > > That's because I took your proposal of hiding bugs under the carpet > and *not tell the users* as an insult against scientific honesty. The > kind of honesty that I would expect if I were a user of

Re: [sage-devel] Element.__hash__ stopgap

2015-10-01 Thread Nathann Cohen
> This message seems like flamebait [1], That's because I took your proposal of hiding bugs under the carpet and *not tell the users* as an insult against scientific honesty. The kind of honesty that I would expect if I were a user of Sage. In the future, I agree that it would be more proper that

Re: [sage-devel] Element.__hash__ stopgap

2015-10-01 Thread William Stein
On Thu, Oct 1, 2015 at 11:27 AM, Nathann Cohen wrote: >[...] > Professionals. That's a joke. This message seems like flamebait [1], hence probably does not belong on this list, and belongs on sage-flame [2] instead. I think it is best if people direct any responses to sage-flame [2] rather than

Re: [sage-devel] Element.__hash__ stopgap

2015-10-01 Thread Nathann Cohen
I will always be amazed at how lightly you take that the code we develop can cause serious harm to our user's computations, as well as their trust in this software. Look how easy it is for you all to say that we will release this "stable" version of Sage with a known dangerous bug inside, witho

Re: [sage-devel] Element.__hash__ stopgap

2015-10-01 Thread William Stein
On Thu, Oct 1, 2015 at 8:07 AM, Travis Scrimshaw wrote: > >>> >>> Thanks Volker for writing an e-mail before the clash. >>> >>> To my mind, it is a complete nonsense to merge this stopgap in a rc0. We >>> would have time to fix the hash issues along a development cycle starting >>> from an early b

Re: [sage-devel] Element.__hash__ stopgap

2015-10-01 Thread Travis Scrimshaw
> >> Thanks Volker for writing an e-mail before the clash. >> >> To my mind, it is a complete nonsense to merge this stopgap in a rc0. We >> would have time to fix the hash issues along a development cycle starting >> from an early beta. And most of them if not all should be fixed before any >

Re: [sage-devel] Element.__hash__ stopgap

2015-10-01 Thread William Stein
On Thursday, October 1, 2015, Vincent Delecroix <20100.delecr...@gmail.com> wrote: > Hello, > > Thanks Volker for writing an e-mail before the clash. > > To my mind, it is a complete nonsense to merge this stopgap in a rc0. We > would have time to fix the hash issues along a development cycle star

Re: [sage-devel] Element.__hash__ stopgap

2015-10-01 Thread Vincent Delecroix
Hello, Thanks Volker for writing an e-mail before the clash. To my mind, it is a complete nonsense to merge this stopgap in a rc0. We would have time to fix the hash issues along a development cycle starting from an early beta. And most of them if not all should be fixed before any stable rel

[sage-devel] Element.__hash__ stopgap

2015-10-01 Thread Volker Braun
Just as a PSA you better get used to this warning: sage: G = FreeGroup(2) sage: x,y = G.gens() sage: H = G / [x**2, y**2] /opt/sage/src/bin/sage-ipython:1: The __hash__ method of Element is broken. Beware of any funct