------=_Part_34976_499175726.1526999570049
Content-Type: multipart/alternative;
 boundary="----=_Part_34977_330108994.1526999570049"

------=_Part_34977_330108994.1526999570049
Content-Type: text/plain; charset="UTF-8"

Considering how each set of options dramatically changes the actual
algorithm being employed, I don't see why this should be a flag-based
function rather than a set of different sort algorithms. For example, we
already have `std::stable_sort` for those needing stability.

What's the point of an all-in-one function here?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5d2d43e0-9996-48b4-b153-d59331b5662e%40isocpp.org.

------=_Part_34977_330108994.1526999570049
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Considering how each set of options dramatically chan=
ges the actual algorithm being employed, I don&#39;t see why this should be=
 a flag-based function rather than a set of different sort algorithms. For =
example, we already have `std::stable_sort` for those needing stability.</d=
iv><div><br></div><div>What&#39;s the point of an all-in-one function here?=
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5d2d43e0-9996-48b4-b153-d59331b5662e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5d2d43e0-9996-48b4-b153-d59331b5662e=
%40isocpp.org</a>.<br />

------=_Part_34977_330108994.1526999570049--

------=_Part_34976_499175726.1526999570049--

.

------=_Part_35864_396696778.1527003100979
Content-Type: multipart/alternative;
 boundary="----=_Part_35865_1406228864.1527003100979"

------=_Part_35865_1406228864.1527003100979
Content-Type: text/plain; charset="UTF-8"

I generally prefer the approach of hiding complexity by default, but keep
everything available.  In this instance, it makes more intuitive sense to
get an idea of what the user wants, then select the best algorithm for the
given constraints.  This would make sense over adding a unique function
declaration for each combination of constraints a user would specify.  It
is a cleaner and more flexible interface for users and gives implementers
significant flexibility in implementation.

On Tuesday, May 22, 2018 at 10:32:50 AM UTC-4, Nicol Bolas wrote:
>
> Considering how each set of options dramatically changes the actual
> algorithm being employed, I don't see why this should be a flag-based
> function rather than a set of different sort algorithms. For example, we
> already have `std::stable_sort` for those needing stability.
>
> What's the point of an all-in-one function here?
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1394e8f8-802f-4fd8-b5e3-c3ebc2e13f90%40isocpp.org.

------=_Part_35865_1406228864.1527003100979
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I generally prefer the approach of hiding complexity by de=
fault, but keep everything available.=C2=A0 In this instance, it makes more=
 intuitive sense to get an idea of what the user wants, then select the bes=
t algorithm for the given constraints.=C2=A0 This would make sense over add=
ing a unique function declaration for each combination of constraints a use=
r would specify.=C2=A0 It is a cleaner and more flexible interface for user=
s and gives implementers significant flexibility in implementation.<br><br>=
On Tuesday, May 22, 2018 at 10:32:50 AM UTC-4, Nicol Bolas wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Considering how ea=
ch set of options dramatically changes the actual algorithm being employed,=
 I don&#39;t see why this should be a flag-based function rather than a set=
 of different sort algorithms. For example, we already have `std::stable_so=
rt` for those needing stability.</div><div><br></div><div>What&#39;s the po=
int of an all-in-one function here?</div></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1394e8f8-802f-4fd8-b5e3-c3ebc2e13f90%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1394e8f8-802f-4fd8-b5e3-c3ebc2e13f90=
%40isocpp.org</a>.<br />

------=_Part_35865_1406228864.1527003100979--

------=_Part_35864_396696778.1527003100979--

.

------=_Part_41732_124560125.1527075432201
Content-Type: multipart/alternative;
 boundary="----=_Part_41733_1750836965.1527075432201"

------=_Part_41733_1750836965.1527075432201
Content-Type: text/plain; charset="UTF-8"

I couldn't figure out how to do that with all the other specifiers which
would need to be added in a way that was elegant.  I'm certainly open to
suggestions.

On Wednesday, May 23, 2018 at 2:06:29 AM UTC-4, Vishal Oza wrote:
>
> I just was curious why not put the tag in the execution policy similar to
> the parallelism ts?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/24da39c0-2372-4cd2-8604-7fc27e1139f1%40isocpp.org.

------=_Part_41733_1750836965.1527075432201
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I couldn&#39;t figure out how to do that with all the othe=
r specifiers which would need to be added in a way that was elegant.=C2=A0 =
I&#39;m certainly open to suggestions.<br><br>On Wednesday, May 23, 2018 at=
 2:06:29 AM UTC-4, Vishal Oza wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">I just was curious why not put the tag in the execution policy simila=
r to the parallelism ts?</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/24da39c0-2372-4cd2-8604-7fc27e1139f1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/24da39c0-2372-4cd2-8604-7fc27e1139f1=
%40isocpp.org</a>.<br />

------=_Part_41733_1750836965.1527075432201--

------=_Part_41732_124560125.1527075432201--

.

------=_Part_6190_1568262580.1527168586720
Content-Type: multipart/alternative;
 boundary="----=_Part_6191_2105158978.1527168586720"

------=_Part_6191_2105158978.1527168586720
Content-Type: text/plain; charset="UTF-8"

Thinking on this further, I think there are a few different approaches
depending on the intended purpose behind the standard library.  First is to
make sure a good algorithm exists to perform tasks that a task requires to
be done adequately.  Second is to make sure a core set of highly optimal
algorithms exist for a developer to easily use and incorporate rather than
depend on finding and using external libraries.  Third is to incorporate
many algorithms a programmer would ever need.  The difference between these
are a minimalist, common usage, and maximalist approach to including items
into the standard library.  What I had put forth is more along the lines of
the second option.  Thinking more overnight, I think I can come up with
something more acceptable along the lines of the first approach.

For a core implementation, what I need and isn't implemented in any way
optimal enough for practical usage is suffix based subordering.  There is
an algorithm called "SACA-K" which is linear in complexity and uses
constant workspace, but tends to be worse performing than an O(n log n)
implementation for divsufsort.  SACA-K is not implemented well anywhere and
I'm working on one in order to have a fair comparison.  In either case,
something the following function should be added:

template< typename _RandomAccessIterator, typename _OutputIterator >
void std::suffix_sort( _RandomAccessIterator first, _RandomAccessIterator
last, _OutputIterator result);
or
template<typename _RandomAccessIterator >
std::vector<size_t> std::suffix_sort( _RandomAccessIterator<T> first,
_RandomAccessIterator<T> last);

I don't like how either of those look.  I want something better, but suffix
array algorithms generate a sequence if indexes into the input sequence.
Iterators may be able to work, but I don't see how off the top of my head.


Later today I will make a new post about that since it may be more
developed and is too different from my original post for this thread.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/22b50e88-f820-4a21-85c5-07073af6a507%40isocpp.org.

------=_Part_6191_2105158978.1527168586720
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Thinking on this further, I think there are a few dif=
ferent approaches depending on the intended purpose behind the standard lib=
rary.=C2=A0 First is to make sure a good algorithm exists to perform tasks =
that a task requires to be done adequately.=C2=A0 Second is to make sure a =
core set of highly optimal algorithms exist for a developer to easily use a=
nd incorporate rather than depend on finding and using external libraries.=
=C2=A0 Third is to incorporate many algorithms a programmer would ever need=
..=C2=A0 The difference between these are a minimalist, common usage, and ma=
ximalist approach to including items into the standard library.=C2=A0 What =
I had put forth is more along the lines of the second option.=C2=A0 Thinkin=
g more overnight, I think I can come up with something more acceptable alon=
g the lines of the first approach.</div><div><br></div><div>For a core impl=
ementation, what I need and isn&#39;t implemented in any way optimal enough=
 for practical usage is suffix based subordering.=C2=A0 There is an algorit=
hm called &quot;SACA-K&quot; which is linear in complexity and uses constan=
t workspace, but tends to be worse performing than an O(n log n) implementa=
tion for divsufsort.=C2=A0 SACA-K is not implemented well anywhere and I&#3=
9;m working on one in order to have a fair comparison.=C2=A0 In either case=
, something the following function should be added:</div><div><br></div><di=
v style=3D"margin-left: 40px;">template&lt; typename _RandomAccessIterator,=
 typename _OutputIterator &gt;</div><div style=3D"margin-left: 40px;">void =
std::suffix_sort( _RandomAccessIterator first, _RandomAccessIterator last, =
_OutputIterator result);</div>or<div style=3D"margin-left: 40px;">template&=
lt;typename _RandomAccessIterator &gt;</div><div style=3D"margin-left: 40px=
;">std::vector&lt;size_t&gt; std::suffix_sort( _RandomAccessIterator&lt;T&g=
t; first, _RandomAccessIterator&lt;T&gt; last);</div><div><br></div><div>I =
don&#39;t like how either of those look.=C2=A0 I want something better, but=
 suffix array algorithms generate a sequence if indexes into the input sequ=
ence.=C2=A0 Iterators may be able to work, but I don&#39;t see how off the =
top of my head.</div><div><br></div><div><br></div><div>Later today I will =
make a new post about that since it may be more developed and is too differ=
ent from my original post for this thread.<br></div><div style=3D"margin-le=
ft: 40px;"><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/22b50e88-f820-4a21-85c5-07073af6a507%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/22b50e88-f820-4a21-85c5-07073af6a507=
%40isocpp.org</a>.<br />

------=_Part_6191_2105158978.1527168586720--

------=_Part_6190_1568262580.1527168586720--

.