Hi there,

The last mailing included a short proposal that I wrote, called
"P0638R0: Crochemore-Perrin search algorithm for std::search":

https://wg21.link/p0638r0

In essence, this proposal extends std::search() to include an
additional algorithm that runs both in linear time and is in-place.
Due to these properties, it can even be marked constexpr. This not
only allows you to fully initialise searchers at compile-time, it can
even perform matching.

My question is, as I won't be going to Toronto for the WG21 meeting,
is anyone interested in presenting this proposal there to the LEWG?
Thanks!

--
Ed Schouten <ed@nuxi.nl>
Nuxi, 's-Hertogenbosch, the Netherlands
KvK-nr.: 62051717

--
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/CABh_MK%3Dm-kbsAed0RUbf33mc486TYSKmULcBq-LyMR-wznvGtw%40mail.gmail.com.

.

------=_Part_2140_1489163107.1499140283187
Content-Type: multipart/alternative;
 boundary="----=_Part_2141_799663228.1499140283187"

------=_Part_2141_799663228.1499140283187
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello.

I work on search algorithms in Boost.Algorithm. And i have some thoughts=20
about your proposal:
1) Do you have comparison between naive search vs Crochemore-Perrin vs=20
Boyer-Moore? I have benchmarked Crochemore-Perrin vs Boyer-Moore, and i can=
=20
say that Crochemore-Perrin (as known as Two-way search algorithm (TW)) is=
=20
always slower. And it's without comparison between Musser-Nishanov=20
algorithm vs TW (Musser-Nishanov is faster than BM).
2) TW requires Random Access Iterators. BM too.

So can you explain me please, why we should add this algorithm to standard=
=20
library?

Useful links:
1) https://www.dmi.unict.it/~faro/smart/algorithms.php
2) https://github.com/smart-tool/smart
3) https://github.com/boostorg/algorithm/pull/25

=D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 27 =D0=B8=D1=8E=D0=BD=D1=8F 201=
7 =D0=B3., 9:51:42 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=
=D1=82=D0=B5=D0=BB=D1=8C Ed Schouten =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=
=D0=BB:
>
> Hi there,=20
>
> The last mailing included a short proposal that I wrote, called=20
> "P0638R0: Crochemore-Perrin search algorithm for std::search":=20
>
> https://wg21.link/p0638r0=20
>
> In essence, this proposal extends std::search() to include an=20
> additional algorithm that runs both in linear time and is in-place.=20
> Due to these properties, it can even be marked constexpr. This not=20
> only allows you to fully initialise searchers at compile-time, it can=20
> even perform matching.=20
>
> My question is, as I won't be going to Toronto for the WG21 meeting,=20
> is anyone interested in presenting this proposal there to the LEWG?=20
> Thanks!=20
>
> --=20
> Ed Schouten <e...@nuxi.nl <javascript:>>=20
> Nuxi, 's-Hertogenbosch, the Netherlands=20
> KvK-nr.: 62051717=20
>

--=20
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 e=
mail 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/dc1fca72-de48-4b97-b554-119a6f13ba36%40isocpp.or=
g.

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

<div dir=3D"ltr">Hello.<div><br></div><div>I work on search algorithms in B=
oost.Algorithm. And i have some thoughts about your proposal:</div><div>1) =
Do you have comparison between naive search vs Crochemore-Perrin vs Boyer-M=
oore? I have benchmarked Crochemore-Perrin vs Boyer-Moore, and i can say th=
at Crochemore-Perrin (as known as Two-way search algorithm (TW)) is always =
slower. And it&#39;s without comparison between Musser-Nishanov algorithm v=
s TW (Musser-Nishanov is faster than BM).</div><div>2) TW requires Random A=
ccess Iterators. BM too.</div><div><br></div><div>So can you explain me ple=
ase, why we should add this algorithm to standard library?</div><div><br></=
div><div>Useful links:</div><div>1)=C2=A0https://www.dmi.unict.it/~faro/sma=
rt/algorithms.php</div><div>2)=C2=A0https://github.com/smart-tool/smart</di=
v><div>3)=C2=A0https://github.com/boostorg/algorithm/pull/25<br><br>=D0=B2=
=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 27 =D0=B8=D1=8E=D0=BD=D1=8F 2017 =D0=
=B3., 9:51:42 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=
=D0=B5=D0=BB=D1=8C Ed Schouten =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">Hi there,
<br>
<br>The last mailing included a short proposal that I wrote, called
<br>&quot;P0638R0: Crochemore-Perrin search algorithm for std::search&quot;=
:
<br>
<br><a href=3D"https://wg21.link/p0638r0" target=3D"_blank" rel=3D"nofollow=
" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%=
2F%2Fwg21.link%2Fp0638r0\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGqXnuMQxVg=
IcNfzreOzpEliBIQlQ&#39;;return true;" onclick=3D"this.href=3D&#39;https://w=
ww.google.com/url?q\x3dhttps%3A%2F%2Fwg21.link%2Fp0638r0\x26sa\x3dD\x26sntz=
\x3d1\x26usg\x3dAFQjCNGqXnuMQxVgIcNfzreOzpEliBIQlQ&#39;;return true;">https=
://wg21.link/p0638r0</a>
<br>
<br>In essence, this proposal extends std::search() to include an
<br>additional algorithm that runs both in linear time and is in-place.
<br>Due to these properties, it can even be marked constexpr. This not
<br>only allows you to fully initialise searchers at compile-time, it can
<br>even perform matching.
<br>
<br>My question is, as I won&#39;t be going to Toronto for the WG21 meeting=
,
<br>is anyone interested in presenting this proposal there to the LEWG?
<br>Thanks!
<br>
<br>--=20
<br>Ed Schouten &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"sTob9QsaAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;=
javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;=
;return true;">e...@nuxi.nl</a>&gt;
<br>Nuxi, &#39;s-Hertogenbosch, the Netherlands
<br>KvK-nr.: 62051717
<br></blockquote></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/dc1fca72-de48-4b97-b554-119a6f13ba36%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dc1fca72-de48-4b97-b554-119a6f13ba36=
%40isocpp.org</a>.<br />

------=_Part_2141_799663228.1499140283187--

------=_Part_2140_1489163107.1499140283187--

.