Repository navigation
semantics of slice, now and future (plus near term bug fixes) #276
Description
Activity
If I understand you correctly, you mean that in the
V.slice startIx endIx vecexample if either ofstartIxendIxare incorrect (negative, out of bounds, etc.) we should throw an error, right?If that is what desired, it is fine by me, but keep in mind that it will prevent fusion! In other words, you can't throw an error if you don't ask for the vector length, because without forcing the vector you will not know it.
I personally don't care which way we swing: error/no error, but what is very important I think is that we are consistent, regardless if slicing operator fuses or not! Having an error in ghci, but no error with
-O1is unacceptable.One alternative approach we could pursue is adding something like
safeSlice, that fuses as well as fixes the arguments to prevent errors.Of course, that is why I chose to have manual fusion in
massiv, this way it is up to the user to fuse computation, if such fusion is possible.But that's not the case in
vector, so it is up to us to decide. What you are suggesting would be very easy to achieve, all we gotta do is remove this rewrite rule:
Lines 471 to 472 in da63959
I hate tradeoffs. grrrrr.
i'm going to be a bit slow in digesting this/ looking back through the related discussions.
I think it is worth linking to this comment that has a comparison to list and all previous issues with
slice: #257 (comment)Also worth noting. That it is already possible to implement
slice i n = take n . drop iwhich will have the non-error semantics. So, maybe it is not even worth worrying about it, except possibly improving the docs describing the options.What I think about this. Changing
slicefrom index & length to start index & end index is out of question. Too much code will break. Adding another variant of slice is of course possible. It's trivially implemented in terms of currentslice.Another question is whether slice should be made total as was proposed in #257 (comment)
I think we all agree that changing semantics of
sliceis dangerous. Starting with0.12.1slice will throw an error on invalid offset and size. If we want to add a total version ofslicewe can do that in the future or users can just rely ontake n . drop iwhenever such semantics are desired.I think we can close this ticket. This is the consistent output we get for
slicestarting with 0.12.1 when looking at examples in this #257 (comment):================================================== slice (Vector.Boxed current - fused): [1,2,3,4,5] normal: [2,3,4] negative ix: invalid slice (-2,2,5) negative size: invalid slice (2,-2,5) negative ix and size: invalid slice (-2,-1,5) too large ix: invalid slice (6,2,5) too large size: invalid slice (2,6,5) too large ix size: invalid slice (6,6,5) ================================================== slice (Vector.Primitive current - fused): [1,2,3,4,5] normal: [2,3,4] negative ix: invalid slice (-2,2,5) negative size: invalid slice (2,-2,5) negative ix and size: invalid slice (-2,-1,5) too large ix: invalid slice (6,2,5) too large size: invalid slice (2,6,5) too large ix size: invalid slice (6,6,5) ================================================== slice (Vector current - unfused): [1,2,3,4,5] normal: [2,3,4] negative ix: invalid slice (-2,2,5) negative size: invalid slice (2,-2,5) negative ix and size: invalid slice (-2,-1,5) too large ix: invalid slice (6,2,5) too large size: invalid slice (2,6,5) too large ix size: invalid slice (6,6,5)- Great! :)…On Sat, May 21, 2022 at 4:42 PM Alexey Kuleshevich ***@***.***> wrote: I think we all agree that changing semantics of slice is dangerous. Starting with 0.12.1 slice will throw an error on invalid offset and size. If we want to add a total version of slice we can do that in the future or users can just rely on take n . drop i whenever such semantics are desired. I think we can close this ticket. This is the consistent output we get for slice starting with 0.12.1 when looking at examples in this #257 (comment) <#257 (comment)>: ================================================== slice (Vector.Boxed current - fused): [1,2,3,4,5] normal: [2,3,4] negative ix: invalid slice (-2,2,5) negative size: invalid slice (2,-2,5) negative ix and size: invalid slice (-2,-1,5) too large ix: invalid slice (6,2,5) too large size: invalid slice (2,6,5) too large ix size: invalid slice (6,6,5) ================================================== slice (Vector.Primitive current - fused): [1,2,3,4,5] normal: [2,3,4] negative ix: invalid slice (-2,2,5) negative size: invalid slice (2,-2,5) negative ix and size: invalid slice (-2,-1,5) too large ix: invalid slice (6,2,5) too large size: invalid slice (2,6,5) too large ix size: invalid slice (6,6,5) ================================================== slice (Vector current - unfused): [1,2,3,4,5] normal: [2,3,4] negative ix: invalid slice (-2,2,5) negative size: invalid slice (2,-2,5) negative ix and size: invalid slice (-2,-1,5) too large ix: invalid slice (6,2,5) too large size: invalid slice (2,6,5) too large ix size: invalid slice (6,6,5) — Reply to this email directly, view it on GitHub <#276 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAABBQQCHMLNWIWVU5PJIMTVLFDCXANCNFSM4KN5J4GA> . You are receiving this because you authored the thread.Message ID: ***@***.***>
cc @Shimuuar @lehins
My interpretation of slice, which may not be the universal one, but I believe reflects a common intent, is when I write
i'm always like "what?! I wanted to write an inclusive coordinate interval"
V.slice startIx endIx vecif the user's semantics is "i want/need this interval", throwing an error and promptly aborting is the only option i can see for the current type signature when that interval doesn't exist.
I'd even go further, and suspect that currently
slice with the
base indexandrunlengthapi we currently have is arecurrent gotchaany semantics that doesn't relate to the coordinate interval one might be problematical (though, there are some cut semantical tricks if we think about the coordinates in a modulus sorta sense, a la -1 et al in python sequences, but thats not the current topic)