On Tuesday, 28 May 2013 at 18:38:01 UTC, Ali Çehreli wrote:
On 05/28/2013 11:31 AM, Ali Çehreli wrote:
> @property Array!T opSlice(size_t i, size_t j) {
> // ...
> ret.front_ = i;
>
> I feel like the initialization of front_ above is not right
either.
> Imagine quick sort where we are slicing the right-hand side
of a range
> as [0..10], which has already been sliced before. Setting
front_ to 0
> would be wrong because then opIndex would still be counting
from the
> beginning of the original elements.
My explanation is wrong but I think there is still a bug.
Imagine we are in the right-hand range that has been sliced as
[10..$]. Now front_ is 10 and all is good: s[0] provides the
arr[10] of the original array.
Now imagine our slice again by [5..$]. s_further[0] should
provide arr[15] of the original array but your setting front_
to 5 would unfortunately provide arr[5].
Ali
Yes, exactly.
I believe, the same fix should be applied here: front_ + i,
front_ + j. It passes the sorting test.
Thank you so much, Ali. Feels like to be back in school again.
