New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Words.__contains__ returns wrong answers #15481
Comments
This comment has been minimized.
This comment has been minimized.
Replying to @nathanncohen: First, I want to say that I think all these problems could be solved or get more clean by first finishing the ticket at #12224. It is a big patch, but I am ready to put time on it to continue the review. Vincent : what's the status of it? Do you think we will manage to get your great improvement in Sage anytime soon? Now, I am answering to each of the problem mention in the ticket according to the choices that we made some years ago. If any of the choice we made is bad, then please tell!
The default alphabet when using just
Of course, by default, we could have computed the alphabet from the letters appearing in the word, but this is not efficient when the word is very long or when the word is infinite. So, we decided it is to the user to specify the alphabet. Also, sometimes the word lives in a larger alphabet, so the alphabet can not be computed from the word. In short, the user may specify the alphabet. And this fixes the above problem:
I agree, this is a bug: a finite word must not be in a set of infinite words.
I agree this is a bug: it seems the
This is OK. The alphabet of integers and of str are considered different.
I don't know if the above test what you meant. The above
Maybe you meant this :
Yes, this is a choice we made. Maybe it is wrong. We decided
Same comment as above:
SUMMARYSo, in summary, things must be fixed according to
Do I miss something? About the behavior of containsSo, what should
def __contains__(self, word):
A = self.alphabet()
return all(letter in A for letter in word) This is much too long computations for words we know the alphabet. Also, it doesn't work for infinite words. But if it is what the user expect, why not?
def __contains__(self, word):
A = self.alphabet()
B = word.parent().alphabet()
return B is subset of A This will make code more efficient, but the user must provide an alphabet to the word. Thus, this won't work (if the default alphabet of Word remains the set of all Python objects):
Also, I remember we had this idea of using subset because of the fact that alphabet are ordered and in some cases (I don't remember exactly which case), testing
def __contains__(self, word):
A = self.alphabet()
B = word.parent().alphabet()
return B is A So are you happy with option 2? Any other options? |
comment:3
Yoooooooooooooooo !!
Wow. And it is only 2 years old !!!
Yeah. Like this months ?.. Those are wrong results, guys !
Who cares ? Anybody expects to see "True", there. The question is "how", not what it should return.
Very cool. Now if it makes Sage return answers like that, it should be discarded as a bad design choice.
Well, I see no problem in having sage raise a "IDontKnowException" when asked to tell if an infinite (i.e. lazy) word belongs to a specific set of words. But once more, I don't care whether something is slow or fast. The default behaviour should be mathematically correct, and you are free to add one thousand parameters if you want to make it faster at the cost of correction. For as long as there are warnings everywhere. Those results are mathematically wrong, do we at least agree on that ?
Very cool. Now 1) the user has no way to know that this is what he is expected to do 2) the answer raised by the default behaviour are still wrong. Come on guys ! Let's even do that : if the alphabet is not explicitly given by the user, you HAVE to return mathematically sound answers. If the user gives the alphabet explicitly, then you can do whatever you want (add warnings everywhere) to return more complicated and faster results if you need. But you can't make word equality depend on something which is NOT canonical and NOT explicitly given.
Guys. You are comparing WORDS. Not pairs "word, alphabet". So compare words, unless explicitly asked to do something different.
Yeah, that's because of the class hierarchy. It's not very easy to work with
Note that #15479 fixed something here. Just adding a word to the
Oh. Right. Tricky, but right. You can have two words that are displayed as "123" but the letters of one are integers, the others are letters. Hmmm... Tricky, but right I guess. Okay, I continued reading the other answers and we have to make something clear : when you say that something is a word, it is a word. It is not "a word defined on an alphabet". If you want to have an object defined by both a word and an alphabet, this thing has no right to be displayed as "word: 123". It has to be displayed as "word: 123 on alphabet=['1','2','3']". So you can add whatever class you think are useful for you, for sage, for everybody on earth but what you define as a word is expected to be a word, and nothing else. If you think that the mathematical definitions do not yield sufficiently fast algorithm that's a problem indeed, and you can fix it however you want for as long as nobody can be led to misunderstand the results given. But a word is a sequence of letter, period. A pair "Word, Alphabet" is something else. But sage users have no way to guess that they compare alphabets when they compare words, and they do not have to expect it anyway because comparing words and comparing sets of words is CLEAR. So let's make Sage return true answers first, then there will be no problem to make things faster.
IT MAKES THE RESULTS INCORRECT.
Give this to a colleague of yours who works on words and does not use Sage, ask what he thinks. His answer is what Sage should answer. And it's crystal clear.
Come on guy... "Words" are sets, and you are telling me that if
Word equality and containment should be word equality and containment. The alphabets are NOT involved in any of these things, and Sage should not involve them either to decide whether something is true or false. Of course you can cache the alphabet USED by a word if you need, or whatever suits you to make things faster, but all these operations are defined mathematically and you just don't return wrong answers because it makes the algorithms faster. If you need to have something representing a word and an alphabet, this thing's
Indeed. That's the only mathematical truth. Note that you can cache the set of letters used in a word if you think it helps.
That is NOT word containment. That is not even the equality of pairs "(word, alphabet)". Right now, you have this :
How can you expect ANYBODY to agree with that ?
I can't even understand how a code like that can be 1) written 2) reviewed. Nathann |
comment:7
ping ?... |
comment:8
in recent sage (7.6.beta4) some of the issues above seems fixed; The following examples run forever
|
I have no idea how this can be fixed, so if a Word guy can look at this..
O_o
Nathann
CC: @seblabbe @videlec @sagetrac-sage-combinat @saliola @sagetrac-jakobkroeker
Component: combinatorics
Issue created by migration from https://trac.sagemath.org/ticket/15481
The text was updated successfully, but these errors were encountered: