Re: [sage-devel] Re: Vector weirdness: to be or not to be immutable
Thanks for the clarifications, Vincent. On Wednesday, May 27, 2015 at 10:36:31 PM UTC+2, vdelecroix wrote: > What I suggesteded is to modify the code of vector subspace in such way > that the elements have parent the ambient space and not the subspace. > Which is precisely related to the end of your e-mail. > Frankly, I completely agree. But that could have implications for many users in many places. Is the current behaviour a result of long discussions and thought? Should more people chip in before we rush in and change this? > > For your sided question, the fastest way is to use Element._set_parent() > ... Ok, thanks. > > The question in your case is rather do *you* *want* that the elements > have parent the linear code? > Ok, clear explanation and very good question. I certainly don't want the parent to be the vector subspace (as now); it should either be the full vector space or the code. I think the former makes most sense, but that's due to the same logic as above for vector subspaces... Johan -- 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. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Vector weirdness: to be or not to be immutable
On 27/05/15 22:27, Johan S. R. Nielsen wrote: The behavior is bad but I would not call it a bug. You modified wrongly the vector. I disagree: from a user-point of view, a superficially perfectly reasonable sequence of steps were taken, at the end of which Sage prints a result which is mathematically incorrect, without any error or warning. That should never happen! Even for an *unreasonable* sequence of steps. If it was me I would set the parent to be the ambient space and not the subspace itself (but it might break a lot of code). Is the best/fastest/safest way to do this to cast this to the full vector space? I.e. something like y = VS(c) What I suggesteded is to modify the code of vector subspace in such way that the elements have parent the ambient space and not the subspace. Which is precisely related to the end of your e-mail. For your sided question, the fastest way is to use Element._set_parent() sage: V = VectorSpace(QQ,3) sage: U = V.subspace([V((1,1,1))]) sage: v = U.an_element() sage: v._set_parent(V) sage: v (1, 1, 1) sage: v.parent() Vector space of dimension 3 over Rational Field but I would not recommend it. On Wednesday, May 27, 2015 at 10:02:24 PM UTC+2, Volker Braun wrote: IMHO the bug here is a lack of validation. Its perfectly fine to have mutable elements of a vector subspace, but y.__setitem__ should then check that the vector really is in the subspace or raise a ValueError. Of course it would almost always raise, so its not a particularly useful operation. I agree, that's a possibility which is general and makes sense. On a more general note, what is the rationale for defining the subspace - and not the full vector space - as the parent of the vectors? The vector is in many subspaces, and the user just happened to construct it from one of them; but it's just as much part of the other subspaces. I find it somehow slightly arbitrary that this type of sub-structure -- vector space subspaces -- become parents like this. Are there other examples? Perhaps I'm not seeing the bigger picture here. In coding theory there's an echo of the same thing: a codeword of a linear code is a vector which is in the code (the code being a vector subspace). Currently, when you ask for a codeword of the code, you'll get a vector whose parent is the subspace (and not the LinearCode object). This actually surprised me, as I expected the parent to be the full vector space. To be consistent, should we change it so that the LinearCode is the parent of the codewords? Not necessarily. There is a well defined concept of "facade parent" in Sage. It is a parent who does not own its elements. Like Primes: sage: Primes() in Sets().Facade() True sage: Primes().an_element().parent() Integer Ring The question in your case is rather do *you* *want* that the elements have parent the linear code? Vincent -- 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. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Vector weirdness: to be or not to be immutable
On 27/05/15 22:02, Volker Braun wrote: IMHO the bug here is a lack of validation. Its perfectly fine to have mutable elements of a vector subspace, but y.__setitem__ should then check that the vector really is in the subspace or raise a ValueError. Of course it would almost always raise, so its not a particularly useful operation. One alternative is to have something along the clonable arrays with v.clone() as u: u[1] = 3 u[2] = 6 # check here automatically as going out v + v Vincent -- 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. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Vector weirdness: to be or not to be immutable
> The behavior is bad but I would not call it a bug. You modified wrongly > the vector. I disagree: from a user-point of view, a superficially perfectly reasonable sequence of steps were taken, at the end of which Sage prints a result which is mathematically incorrect, without any error or warning. That should never happen! Even for an *unreasonable* sequence of steps. > If it was me I would set the parent to be the ambient space and not the > subspace itself (but it might break a lot of code). Is the best/fastest/safest way to do this to cast this to the full vector space? I.e. something like y = VS(c) On Wednesday, May 27, 2015 at 10:02:24 PM UTC+2, Volker Braun wrote: > > IMHO the bug here is a lack of validation. Its perfectly fine to have > mutable elements of a vector subspace, but y.__setitem__ should then check > that the vector really is in the subspace or raise a ValueError. Of course > it would almost always raise, so its not a particularly useful operation. > I agree, that's a possibility which is general and makes sense. On a more general note, what is the rationale for defining the subspace - and not the full vector space - as the parent of the vectors? The vector is in many subspaces, and the user just happened to construct it from one of them; but it's just as much part of the other subspaces. I find it somehow slightly arbitrary that this type of sub-structure -- vector space subspaces -- become parents like this. Are there other examples? Perhaps I'm not seeing the bigger picture here. In coding theory there's an echo of the same thing: a codeword of a linear code is a vector which is in the code (the code being a vector subspace). Currently, when you ask for a codeword of the code, you'll get a vector whose parent is the subspace (and not the LinearCode object). This actually surprised me, as I expected the parent to be the full vector space. To be consistent, should we change it so that the LinearCode is the parent of the codewords? Johan -- 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. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Vector weirdness: to be or not to be immutable
IMHO the bug here is a lack of validation. Its perfectly fine to have mutable elements of a vector subspace, but y.__setitem__ should then check that the vector really is in the subspace or raise a ValueError. Of course it would almost always raise, so its not a particularly useful operation. O Wednesday, May 27, 2015 at 5:38:18 PM UTC+2, Johan S. R. Nielsen wrote: > > Hi Sage-devel > > We just crashed our heads against a bug in our code due to extremely weird > semantics of Sage. Consider the following code which creates a sub-space C > of the four-dimensional vector space over the binary field, and then > modifies a *copy* of a vector from the subspace: > > F = GF(2) > VS = F^4 > C = VS.subspace([ (F.one(),F.one(),F.one(),F.one()) ]) > w = C([F.one(),F.one(),F.one(),F.one()]) > y = copy(w) > y[0] = F.zero() > print "y's parent is ", y.parent() > print "y is in C: ", y in C > print "y = ", y > > The code above is going to print: > > y's parent is Vector space of degree 4 and dimension 1 over Finite Field > of size 2 > Basis matrix: > [1 1 1 1] > y is in C: True > y = (0, 1, 1, 1) > > So even though y is clearly not in our space C, Sage claims it is. The > reason is that y's parent is still this sub-space. > > Sage disallows that we modify w, the original vector from C. But we are > allowed to modify the copy y (even encouraged by a warning that Sage prints > when you try to modify c). > > I assume everyone agrees the above behaviour is bad? In that case, what is > the bug? > > - Is it that the copy of c is allowed to be mutated (for instance, without > first casting it into the ambient vector space)? > > - Is it that the parent of y is still C immediately after copying? > > - Or is it that the parent of y is still C after modification? > > - Or a fourth option I didn't think of? > > Best, > Johan > -- 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. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.