On Saturday, 2 May 2015 at 10:18:07 UTC, Per Nordlöw wrote:
> On Friday, 1 May 2015 at 19:30:08 UTC, Ilya Yaroshenko wrote:
>> Both variants are wrong because uniq needs sorted ranges.
>>
>> Probably you need something like that:
>>
>> x = x.chain(y).sort.uniq.array;
>
> Interesting.
>
> Is
>
>     x = x.chain(y).sort
>
> faster than
>
>     x ~= y;
>     x.sort;
>
> ?
>
> If so why?

Probably the latter is slower than the former, at the very least because the latter requires memory allocation whereas the former does not.

On Saturday, 2 May 2015 at 11:16:30 UTC, Meta wrote:
> Probably the latter is slower than the former, at the very least because the latter requires memory allocation whereas the former does not.

Ahh!,

    auto x = [11, 3, 2, 4, 5, 1];
    auto y = [0, 3, 10, 2, 4, 5, 1];

    auto z = x.chain(y).sort; // sort them in place

    assert(x == [0, 1, 1, 2, 2, 3]);
    assert(y == [3, 4, 4, 5, 5, 10, 11]);

is very cool, provided that y is allowed to mutate. Now I understand why chain is useful.

A reallocation will however be needed in the final assignment though. But no temporary!

On Saturday, 2 May 2015 at 04:08:04 UTC, Ali Çehreli wrote:
> Interesting idea. I have defined a simple algorithm below to see how it could work (my skipped() function instead of uniq()).

That's a bit above my current D experience to decide.

What about just tweaking uniq() for now to propagate SortedRange and leave the rest for later? Or will this break existing uses of uniq?

On 05/03/2015 07:56 AM, "Per =?UTF-8?B?Tm9yZGzDtnci?= <per.nordlow@gmail.com>" wrote:
> On Saturday, 2 May 2015 at 04:08:04 UTC, Ali Çehreli wrote:
>> Interesting idea. I have defined a simple algorithm below to see how
>> it could work (my skipped() function instead of uniq()).
>
> That's a bit above my current D experience to decide.
>
> What about just tweaking uniq() for now to propagate SortedRange and
> leave the rest for later?

The implementation seems trivial to me. If others don't object, I suggest you open an enhancement request.

> Or will this break existing uses of uniq?

Other than the fact that uniq may return SortedRange, I don't see any issue. If an existing piece of code was explicitly checking whether a certain range object was  UniqResult, no code should be affected.

Another possibility is to return UniqResult in both cases but expose the special SortedRange member functions on it if the input were SortedRange. (Again, trivial.)

Ali

On Friday, 1 May 2015 at 19:08:51 UTC, Per Nordlöw wrote:
> What's the fastest Phobos-way of doing either
>
>     x ~= y; // append
>     x = x.uniq; // remove duplicates
>
> or
>
>     x = (x ~ y).uniq; // append and remove duplicates in one go
>
> provided that
>
>     T[] x, y;
>
> ?

Maybe a way like this could be useful:
http://dpaste.dzfl.pl/7b4b37b490a7

On Wednesday, 6 May 2015 at 16:05:15 UTC, Andrea Fontana wrote:
> Maybe a way like this could be useful:
> http://dpaste.dzfl.pl/7b4b37b490a7

If r is a SortedRange this is very unneccesary wasteful because of the use AA.

In that case you, instead, only want to remove equal consequtive elements without the need for any AA.

I'm guessing there's already an algorithm for this somewhere in Phobos.

Ideas anyone?

On Thursday, 7 May 2015 at 06:53:39 UTC, Per Nordlöw wrote:
> On Wednesday, 6 May 2015 at 16:05:15 UTC, Andrea Fontana wrote:
>> Maybe a way like this could be useful:
>> http://dpaste.dzfl.pl/7b4b37b490a7
>
> If r is a SortedRange this is very unneccesary wasteful because of the use AA.
>
> In that case you, instead, only want to remove equal consequtive elements without the need for any AA.
>
> I'm guessing there's already an algorithm for this somewhere in Phobos.
>
> Ideas anyone?

It's not that difficult to implement.
You just need to implement a merge() range that returns the min of all ranges' front(). Then you can define distinct() for SortedRange as:

merge(sortedrange1, sortedrange2, sortedrange3).uniq

Andrea

On Thursday, 7 May 2015 at 08:03:41 UTC, Andrea Fontana wrote:
> It's not that difficult to implement.
> You just need to implement a merge() range that returns the min of all ranges' front(). Then you can define distinct() for SortedRange as:
>
> merge(sortedrange1, sortedrange2, sortedrange3).uniq
>
> Andrea

Why do you need variadics here? Why the need for sortedrange1, sortedrange2 and sortedrange3?

I was only interested in removing equal consequtive elements within the same range.

On Thursday, 7 May 2015 at 09:21:58 UTC, Per Nordlöw wrote:
> I was only interested in removing equal consequtive elements within the same range.

I looked at UniqResult. What we need is to fix the typesystem with perhaps some traits the figure out which ranges (multi-layered meta-ranges) posses the sorted property or not.

On Thursday, 7 May 2015 at 09:21:58 UTC, Per Nordlöw wrote:
> On Thursday, 7 May 2015 at 08:03:41 UTC, Andrea Fontana wrote:
>> It's not that difficult to implement.
>> You just need to implement a merge() range that returns the min of all ranges' front(). Then you can define distinct() for SortedRange as:
>>
>> merge(sortedrange1, sortedrange2, sortedrange3).uniq
>>
>> Andrea
>
> Why do you need variadics here? Why the need for sortedrange1, sortedrange2 and sortedrange3?
>
> I was only interested in removing equal consequtive elements within the same range.

Because it is a more generic operation and you can work on a lazy range.
Anyway, to sort and to do uniq it isn't the fastest way.

Or maybe I just didn't understand what you really need. :)