------=_Part_1506_1204001437.1418075480064
Content-Type: multipart/alternative;
 boundary="----=_Part_1507_2061229625.1418075480064"

------=_Part_1507_2061229625.1418075480064
Content-Type: text/plain; charset=UTF-8

I remembered that the class std::valarray existed and that it is sometimes
useful. It has even been updated in C++11
where it gained support for namespace-level std::swap, std::begin and std::end
as well as a set of constructors
to support move semantics and initializer lists.

std::valarray also supports the terse syntax operation(valarray)for a
number of operations to apply an operation
to every element of the array. However, more mathematical functions were
added to C99 and subsequently to C++11 in order
to complete the existing set of mathematical operations, but std::valarray
wasn't updated to support them. While using
these operations with std::valarray is trivial thanks to the method apply,
it might be better for consistency to add some
std::valarray overloads to some of the mathematical functions. I therefore
propose to add std::valarray overloads
the C99 additions to the following families of mathematical functions for
consistency:

   - Exponential functions: std::exp2, std::expm1, std::log2, std::log1p
   - Power functions: std::cbrt, std::hypot
   - Hyperbolic function: std::asinh, std::acosh, std::atan

A few other C99 additions might be good canditates even though they don't
matter that much with regards to compatibility
compared to the ones aboves. Here they are:

   - Error functions: std::erf, std::erfc
   - Gamma functions: std::gamma, std::lgamma
   - std::fma

The other functions have to do with floating point representation or
floating point specific operations. std::ceil and
std::floor were never part of the functions overloaded for std::valarray,
so floating point functions are not considered in
this proposal.

std::valarray does not seem to be widely used, but these addition seem to
benefit the overall consistency of the standard.
What do you think?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1507_2061229625.1418075480064
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I remembered that the class <span style=3D"font-family: co=
urier new,monospace;">std::valarray</span> existed and that it is sometimes=
 useful. It has even been updated in C++11<br>where it gained support for n=
amespace-level <span style=3D"font-family: courier new,monospace;">std::swa=
p</span>, <span style=3D"font-family: courier new,monospace;">std::begin </=
span>and <span style=3D"font-family: courier new,monospace;">std::end </spa=
n>as well as a set of constructors<br>to support move semantics and initial=
izer lists.<br><br><span style=3D"font-family: courier new,monospace;">std:=
:valarray </span>also supports the terse syntax <span style=3D"font-family:=
 courier new,monospace;">operation(valarray)</span>for a number of operatio=
ns to apply an operation<br>to every element of the array. However, more ma=
thematical functions were added to C99 and subsequently to C++11 in order<b=
r>to complete the existing set of mathematical operations, but <span style=
=3D"font-family: courier new,monospace;">std::valarray</span> wasn't update=
d to support them. While using<br>these operations with <span style=3D"font=
-family: courier new,monospace;">std::valarray</span> is trivial thanks to =
the method <span style=3D"font-family: courier new,monospace;">apply</span>=
, it might be better for consistency to add some<br><span style=3D"font-fam=
ily: courier new,monospace;">std::valarray</span> overloads to some of the =
mathematical functions. I therefore propose to add <span style=3D"font-fami=
ly: courier new,monospace;">std::valarray</span> overloads<br>the C99 addit=
ions to the following families of mathematical functions for consistency:<b=
r><ul><li>Exponential functions: <span style=3D"font-family: courier new,mo=
nospace;">std::exp2</span>, <span style=3D"font-family: courier new,monospa=
ce;">std::expm1</span>, <span style=3D"font-family: courier new,monospace;"=
>std::log2</span>, <span style=3D"font-family: courier new,monospace;">std:=
:log1p</span><br></li><li>Power functions: <span style=3D"font-family: cour=
ier new,monospace;">std::cbrt</span>, <span style=3D"font-family: courier n=
ew,monospace;">std::hypot</span></li><li>Hyperbolic function: <span style=
=3D"font-family: courier new,monospace;">std::asinh</span>, <span style=3D"=
font-family: courier new,monospace;">std::acosh</span>, <span style=3D"font=
-family: courier new,monospace;">std::atan</span></li></ul><span style=3D"f=
ont-family: courier new,monospace;"><span style=3D"font-family: arial,sans-=
serif;">A few other C99 additions might be good canditates even though they=
 don't matter that much with regards to compatibility<br>compared to the on=
es aboves. Here they are:<br></span></span><ul><li>Error functions: <span s=
tyle=3D"font-family: courier new,monospace;">std::erf</span>, <span style=
=3D"font-family: courier new,monospace;">std::erfc</span><br></li><li>Gamma=
 functions: <span style=3D"font-family: courier new,monospace;">std::gamma<=
/span>, <span style=3D"font-family: courier new,monospace;">std::lgamma</sp=
an><br></li><li><span style=3D"font-family: courier new,monospace;">std::fm=
a</span></li></ul>The other functions have to do with floating point repres=
entation or floating point specific operations. <span style=3D"font-family:=
 courier new,monospace;">std::ceil </span>and<br><span style=3D"font-family=
: courier new,monospace;">std::floor</span> were never part of the function=
s overloaded for std::valarray, so floating point functions are not conside=
red in<br>this proposal.<br><br>std::valarray does not seem to be widely us=
ed, but these addition seem to benefit the overall consistency of the stand=
ard.<br>What do you think?<br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1507_2061229625.1418075480064--
------=_Part_1506_1204001437.1418075480064--

.

------=_Part_711_716142579.1424462096877
Content-Type: multipart/alternative;
 boundary="----=_Part_712_1709967465.1424462096877"

------=_Part_712_1709967465.1424462096877
Content-Type: text/plain; charset=UTF-8

I agree that it should be extended and updated, but I cannot say I've ever
used std::valarray or seen it being used, so it seems as added work for
implementers with little benefit.

On Monday, 8 December 2014 22:51:20 UTC+1, Ed wrote:
>
> I remembered that the class std::valarray existed and that it is
> sometimes useful. It has even been updated in C++11
> where it gained support for namespace-level std::swap, std::begin and std::end
> as well as a set of constructors
> to support move semantics and initializer lists.
>
> std::valarray also supports the terse syntax operation(valarray)for a
> number of operations to apply an operation
> to every element of the array. However, more mathematical functions were
> added to C99 and subsequently to C++11 in order
> to complete the existing set of mathematical operations, but std::valarray
> wasn't updated to support them. While using
> these operations with std::valarray is trivial thanks to the method apply,
> it might be better for consistency to add some
> std::valarray overloads to some of the mathematical functions. I
> therefore propose to add std::valarray overloads
> the C99 additions to the following families of mathematical functions for
> consistency:
>
>    - Exponential functions: std::exp2, std::expm1, std::log2, std::log1p
>    - Power functions: std::cbrt, std::hypot
>    - Hyperbolic function: std::asinh, std::acosh, std::atan
>
> A few other C99 additions might be good canditates even though they don't
> matter that much with regards to compatibility
> compared to the ones aboves. Here they are:
>
>    - Error functions: std::erf, std::erfc
>    - Gamma functions: std::gamma, std::lgamma
>    - std::fma
>
> The other functions have to do with floating point representation or
> floating point specific operations. std::ceil and
> std::floor were never part of the functions overloaded for std::valarray,
> so floating point functions are not considered in
> this proposal.
>
> std::valarray does not seem to be widely used, but these addition seem to
> benefit the overall consistency of the standard.
> What do you think?
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_712_1709967465.1424462096877
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I agree that it should be extended and updated, but I cann=
ot say I've ever used std::valarray or seen it being used, so it seems as a=
dded work for implementers with little benefit.<br><br>On Monday, 8 Decembe=
r 2014 22:51:20 UTC+1, Ed  wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div dir=3D"ltr">I remembered that the class <span style=3D"font-family:=
courier new,monospace">std::valarray</span> existed and that it is sometime=
s useful. It has even been updated in C++11<br>where it gained support for =
namespace-level <span style=3D"font-family:courier new,monospace">std::swap=
</span>, <span style=3D"font-family:courier new,monospace">std::begin </spa=
n>and <span style=3D"font-family:courier new,monospace">std::end </span>as =
well as a set of constructors<br>to support move semantics and initializer =
lists.<br><br><span style=3D"font-family:courier new,monospace">std::valarr=
ay </span>also supports the terse syntax <span style=3D"font-family:courier=
 new,monospace">operation(valarray)</span>for a number of operations to app=
ly an operation<br>to every element of the array. However, more mathematica=
l functions were added to C99 and subsequently to C++11 in order<br>to comp=
lete the existing set of mathematical operations, but <span style=3D"font-f=
amily:courier new,monospace">std::valarray</span> wasn't updated to support=
 them. While using<br>these operations with <span style=3D"font-family:cour=
ier new,monospace">std::valarray</span> is trivial thanks to the method <sp=
an style=3D"font-family:courier new,monospace">apply</span>, it might be be=
tter for consistency to add some<br><span style=3D"font-family:courier new,=
monospace">std::valarray</span> overloads to some of the mathematical funct=
ions. I therefore propose to add <span style=3D"font-family:courier new,mon=
ospace">std::valarray</span> overloads<br>the C99 additions to the followin=
g families of mathematical functions for consistency:<br><ul><li>Exponentia=
l functions: <span style=3D"font-family:courier new,monospace">std::exp2</s=
pan>, <span style=3D"font-family:courier new,monospace">std::expm1</span>, =
<span style=3D"font-family:courier new,monospace">std::log2</span>, <span s=
tyle=3D"font-family:courier new,monospace">std::log1p</span><br></li><li>Po=
wer functions: <span style=3D"font-family:courier new,monospace">std::cbrt<=
/span>, <span style=3D"font-family:courier new,monospace">std::hypot</span>=
</li><li>Hyperbolic function: <span style=3D"font-family:courier new,monosp=
ace">std::asinh</span>, <span style=3D"font-family:courier new,monospace">s=
td::acosh</span>, <span style=3D"font-family:courier new,monospace">std::at=
an</span></li></ul><span style=3D"font-family:courier new,monospace"><span =
style=3D"font-family:arial,sans-serif">A few other C99 additions might be g=
ood canditates even though they don't matter that much with regards to comp=
atibility<br>compared to the ones aboves. Here they are:<br></span></span><=
ul><li>Error functions: <span style=3D"font-family:courier new,monospace">s=
td::erf</span>, <span style=3D"font-family:courier new,monospace">std::erfc=
</span><br></li><li>Gamma functions: <span style=3D"font-family:courier new=
,monospace">std::gamma</span>, <span style=3D"font-family:courier new,monos=
pace">std::lgamma</span><br></li><li><span style=3D"font-family:courier new=
,monospace">std::fma</span></li></ul>The other functions have to do with fl=
oating point representation or floating point specific operations. <span st=
yle=3D"font-family:courier new,monospace">std::ceil </span>and<br><span sty=
le=3D"font-family:courier new,monospace">std::floor</span> were never part =
of the functions overloaded for std::valarray, so floating point functions =
are not considered in<br>this proposal.<br><br>std::valarray does not seem =
to be widely used, but these addition seem to benefit the overall consisten=
cy of the standard.<br>What do you think?<br></div></blockquote></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_712_1709967465.1424462096877--
------=_Part_711_716142579.1424462096877--

.

--Apple-Mail=_3FF97761-BDD1-49D6-A48F-27B54910AA76
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2014=E2=80=9312=E2=80=9309, at 5:51 AM, Ed <morwenn29@gmail.com> wrote=
:
>=20
> std::valarray does not seem to be widely used, but these addition seem to=
 benefit the overall consistency of the standard.
> What do you think?

std::valarray is little used because it=E2=80=99s =E2=80=9Coptimized=E2=80=
=9D for machines with little cache and fast stream-oriented memory. Maybe i=
t could be appropriate for GPGPU, but I don=E2=80=99t think it=E2=80=99s go=
ing anywhere soon.

Many users write third-party math libraries that want to provide <cmath> fu=
nctions over vectors and matrices. Why not design a base class to take care=
 of that, and implementers can let valarray (and std::slice_array and std::=
gslice_array) be clients?

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_3FF97761-BDD1-49D6-A48F-27B54910AA76
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2014=E2=80=9312=
=E2=80=9309, at 5:51 AM, Ed &lt;<a href=3D"mailto:morwenn29@gmail.com" clas=
s=3D"">morwenn29@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-interchan=
ge-newline"><div class=3D""><div dir=3D"ltr" class=3D"">std::valarray does =
not seem to be widely used, but these addition seem to benefit the overall =
consistency of the standard.<br class=3D"">What do you think?<br class=3D""=
></div></div></blockquote><br class=3D""></div><div><font face=3D"Courier" =
class=3D"">std::valarray</font> is little used because it=E2=80=99s =E2=80=
=9Coptimized=E2=80=9D for machines with little cache and fast stream-orient=
ed memory. Maybe it could be appropriate for GPGPU, but I don=E2=80=99t thi=
nk it=E2=80=99s going anywhere soon.</div><div><br class=3D""></div><div>Ma=
ny users write third-party math libraries that want to provide <font face=
=3D"Courier" class=3D"">&lt;cmath&gt;</font> functions over vectors and mat=
rices. Why not design a base class to take care of that, and implementers c=
an let <font face=3D"Courier" class=3D"">valarray</font>&nbsp;(and&nbsp;<fo=
nt face=3D"Courier" class=3D"">std::slice_array</font> and <font face=3D"Co=
urier" class=3D"">std::gslice_array</font>) be clients?</div></body></html>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_3FF97761-BDD1-49D6-A48F-27B54910AA76--

.