------=_Part_296_8719237.1353145924590
Content-Type: text/plain; charset=ISO-8859-1

The draft for special maths functions :
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2850.pdf adds a
lot of new cool and useful stuff. Nevertheless, from my point of view, it
lacks one widely use type of polynomials : the Chebyshev polynomials (if
you google those, you will have more results than the "Laguerre
polynomials" which are included in the draft (just to say that Chebyshev
polynomials are widely used)). One of their application are the spectral
methods used to solve some kinds of differential equations. There are four
types of Chebyshev polynomials defined as (see
http://en.wikipedia.org/wiki/Chebyshev_polynomials and Mason & Handscomb
"Chebyshev Polynomials") :
T_[n](x) = 2*x*T_[n-1](x)-T_[n-2](x) with T_[0](x) = 1 and T[1](x) = x
U_[n](x) = 2*x*U_[n-1](x)-U_[n-2](x) with U_[0](x) = 1 and U[1](x) = 2*x
V_[n](x) = 2*x*V_[n-1](x)-V_[n-2](x) with V_[0](x) = 1 and V[1](x) = 2*x-1
W_[n](x) = 2*x*W_[n-1](x)-W_[n-2](x) with W_[0](x) = 1 and W[1](x) = 2*x+1

The proposal would be to add the following functions to the special math
functions defined in the draft :

// ----------------- CHEBYSHEV POLYNOMIALS OF THE 1ST KIND
----------------- //
double chebyshev_1(unsigned n, double x);
float chebyshev_1f(unsigned n, float x);
long double chebyshev_1l(unsigned n, long double x);
// ----------------- CHEBYSHEV POLYNOMIALS OF THE 2ND KIND
----------------- //
double chebyshev_2(unsigned n, double x);
float chebyshev_2f(unsigned n, float x);
long double chebyshev_2l(unsigned n, long double x);
// ----------------- CHEBYSHEV POLYNOMIALS OF THE 3RD KIND
----------------- //
double chebyshev_3(unsigned n, double x);
float chebyshev_3f(unsigned n, float x);
long double chebyshev_3l(unsigned n, long double x);
// ----------------- CHEBYSHEV POLYNOMIALS OF THE 4TH KIND
----------------- //
double chebyshev_4(unsigned n, double x);
float chebyshev_4f(unsigned n, float x);
long double chebyshev_4l(unsigned n, long double x);
//
------------------------------------------------------------------------- //

What would be the pros & cons for that ?

--




------=_Part_296_8719237.1353145924590
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The draft for special maths functions : http://www.open-std.org/jtc1/sc22/w=
g21/docs/papers/2009/n2850.pdf adds a lot of new cool and useful stuff. Nev=
ertheless, from my point of view, it lacks one widely use type of polynomia=
ls : the Chebyshev polynomials (if you google those, you will have more res=
ults than the "Laguerre polynomials" which are included in the draft (just =
to say that Chebyshev polynomials are widely used)). One of their applicati=
on are the spectral methods used to solve some kinds of differential equati=
ons. There are four types of Chebyshev polynomials defined as (see http://e=
n.wikipedia.org/wiki/Chebyshev_polynomials and Mason & Handscomb "Cheby=
shev Polynomials") :<br><span style=3D"font-family: courier new,monospace;"=
>T_[n](x) =3D 2*x*T_[n-1](x)-T_[n-2](x) with T_[0](x) =3D 1 and T[1](x) =3D=
 x<br>U_[n](x) =3D 2*x*U_[n-1](x)-U_[n-2](x) with U_[0](x) =3D 1 and U[1](x=
) =3D 2*x<br>V_[n](x) =3D 2*x*V_[n-1](x)-V_[n-2](x) with V_[0](x) =3D 1 and=
 V[1](x) =3D 2*x-1<br>W_[n](x) =3D 2*x*W_[n-1](x)-W_[n-2](x) with W_[0](x) =
=3D 1 and W[1](x) =3D 2*x+1</span><br><br>The proposal would be to add the =
following functions to the special math functions defined in the draft :<br=
><br><span style=3D"font-family: courier new,monospace;">// ---------------=
-- CHEBYSHEV POLYNOMIALS OF THE 1ST KIND ----------------- //<br>double che=
byshev_1(unsigned n, double x);<br>float chebyshev_1f(unsigned n, float x);=
<br>long double chebyshev_1l(unsigned n, long double x);<br>// ------------=
----- CHEBYSHEV POLYNOMIALS OF THE 2ND KIND ----------------- //<br>double =
chebyshev_2(unsigned n, double x);<br>float chebyshev_2f(unsigned n, float =
x);<br>long double chebyshev_2l(unsigned n, long double x);<br>// ---------=
-------- CHEBYSHEV POLYNOMIALS OF THE 3RD KIND ----------------- //<br>doub=
le chebyshev_3(unsigned n, double x);<br>float chebyshev_3f(unsigned n, flo=
at x);<br>long double chebyshev_3l(unsigned n, long double x);<br>// ------=
----------- CHEBYSHEV POLYNOMIALS OF THE 4TH KIND ----------------- //<br>d=
ouble chebyshev_4(unsigned n, double x);<br>float chebyshev_4f(unsigned n, =
float x);<br>long double chebyshev_4l(unsigned n, long double x);<br>// ---=
---------------------------------------------------------------------- //</=
span><br><br>What would be the pros &amp; cons for that ?<br><br>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_296_8719237.1353145924590--

.

On 11/17/2012 10:52 AM, VinceRev wrote:
> The draft for special maths functions :
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2850.pdf
> adds a lot of new cool and useful stuff. Nevertheless, from my point
> of view, it lacks one widely use type of polynomials : the Chebyshev
> polynomials (if you google those, you will have more results than the
> "Laguerre polynomials" which are included in the draft (just to say
> that Chebyshev polynomials are widely used)). One of their
> application are the spectral methods used to solve some kinds of
> differential equations. There are four types of Chebyshev polynomials
> defined as (see http://en.wikipedia.org/wiki/Chebyshev_polynomials
> and Mason & Handscomb "Chebyshev Polynomials") :

The draft you're talking about has meanwhile become an International Standard:
ISO/IEC 29123: C++ Special Math Functions

That means WG21 would have to issue an amendment to ISO/IEC 29123 with the
new proposed functions added.

If I remember correctly, the choice of functions was based on ISO 31-11, and
thus carefully considered.

I don't know how widespread implementation of ISO 29123 is.  Adding to its
feature set would make it even larger, possibly slowing its adoption with
implementers.

Anyway, http://isocpp.org/std/submit-a-proposal seems to be a good guideline
for the next steps to follow.  If there is enough support from implementers,
I have no objection to a proposal like this.  Eventually, we (= WG21,
the C++ standardization committee) need to have a paper that explains a
little about the motivation and shows the changes to ISO 29123 (section,
paragraph and exact wording) that you want to have done.

> T_[n](x) = 2*x*T_[n-1](x)-T_[n-2](x) with T_[0](x) = 1 and T[1](x) = x
> U_[n](x) = 2*x*U_[n-1](x)-U_[n-2](x) with U_[0](x) = 1 and U[1](x) = 2*x
> V_[n](x) = 2*x*V_[n-1](x)-V_[n-2](x) with V_[0](x) = 1 and V[1](x) = 2*x-1
> W_[n](x) = 2*x*W_[n-1](x)-W_[n-2](x) with W_[0](x) = 1 and W[1](x) = 2*x+1

So, the only difference between these are the initial conditions?

> The proposal would be to add the following functions to the special math functions defined in the draft :
>
> // ----------------- CHEBYSHEV POLYNOMIALS OF THE 1ST KIND ----------------- //
> double chebyshev_1(unsigned n, double x);
> float chebyshev_1f(unsigned n, float x);
> long double chebyshev_1l(unsigned n, long double x);
> // ----------------- CHEBYSHEV POLYNOMIALS OF THE 2ND KIND ----------------- //
> double chebyshev_2(unsigned n, double x);
> float chebyshev_2f(unsigned n, float x);
> long double chebyshev_2l(unsigned n, long double x);
> // ----------------- CHEBYSHEV POLYNOMIALS OF THE 3RD KIND ----------------- //
> double chebyshev_3(unsigned n, double x);
> float chebyshev_3f(unsigned n, float x);
> long double chebyshev_3l(unsigned n, long double x);
> // ----------------- CHEBYSHEV POLYNOMIALS OF THE 4TH KIND ----------------- //
> double chebyshev_4(unsigned n, double x);
> float chebyshev_4f(unsigned n, float x);
> long double chebyshev_4l(unsigned n, long double x);
> // ------------------------------------------------------------------------- //

Is the numbering clearly recognized as the "default" numbering?  The Wikipedia
page seems to only talk about the first two.

> What would be the pros & cons for that ?

pros: The specification seems to be fairly easy.
cons: Amendment of possibly poorly supported IS fairly shortly after its initial
publication.

Jens

--




.

On Sun, Nov 18, 2012 at 10:08 AM, Jens Maurer <Jens.Maurer@gmx.net> wrote:
> On 11/17/2012 10:52 AM, VinceRev wrote:
>> The draft for special maths functions :
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2850.pdf
>> adds a lot of new cool and useful stuff. Nevertheless, from my point
>> of view, it lacks one widely use type of polynomials : the Chebyshev
>> polynomials (if you google those, you will have more results than the
>> "Laguerre polynomials" which are included in the draft (just to say
>> that Chebyshev polynomials are widely used)). One of their
>> application are the spectral methods used to solve some kinds of
>> differential equations. There are four types of Chebyshev polynomials
>> defined as (see http://en.wikipedia.org/wiki/Chebyshev_polynomials
>> and Mason & Handscomb "Chebyshev Polynomials") :
>
> The draft you're talking about has meanwhile become an International Standard:
> ISO/IEC 29123: C++ Special Math Functions
>
> That means WG21 would have to issue an amendment to ISO/IEC 29123 with the
> new proposed functions added.
>
> If I remember correctly, the choice of functions was based on ISO 31-11, and
> thus carefully considered.
>
> I don't know how widespread implementation of ISO 29123 is.  Adding to its
> feature set would make it even larger, possibly slowing its adoption with
> implementers.
>
> Anyway, http://isocpp.org/std/submit-a-proposal seems to be a good guideline
> for the next steps to follow.  If there is enough support from implementers,
> I have no objection to a proposal like this.  Eventually, we (= WG21,
> the C++ standardization committee) need to have a paper that explains a
> little about the motivation and shows the changes to ISO 29123 (section,
> paragraph and exact wording) that you want to have done.

I'm guessing the chance of adding special math functions one at a time
is very low. But the committee has just set up a Numerics Study Group,
chaired by Lawrence Crowl, so you might want to ask them. Another
option is to talk to John Maddock at Boost.org, since he is
spearheading various major math efforts there.

--Beman

--




.

------=_Part_172_5570986.1353495911951
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thank you for your answers.

In fact, if we add the Chebyshev polynomials (the Wikipedia page=20
effectively miss the types 3 and 4, but they exist and they are well=20
defined (and there is no 5, 6... families)), we could add the jacobi and=20
the zernike polynomials (the Jacobi polynomials are a generalization of=20
Legendre, Chebyshev, and Zernike polynomials). All of that would form a=20
consistent "pack" :

// ---- CHEBYSHEV POLYNOMIALS OF THE 1ST KIND ---- //
double chebyshev_1(unsigned n, double x);
float chebyshev_1f(unsigned n, float x);
long double chebyshev_1l(unsigned n, long double x);
// ---- CHEBYSHEV POLYNOMIALS OF THE 2ND KIND ---- //
double chebyshev_2(unsigned n, double x);
float chebyshev_2f(unsigned n, float x);
long double chebyshev_2l(unsigned n, long double x);
// ---- CHEBYSHEV POLYNOMIALS OF THE 3RD KIND ---- //
double chebyshev_3(unsigned n, double x);
float chebyshev_3f(unsigned n, float x);
long double chebyshev_3l(unsigned n, long double x);
// ---- CHEBYSHEV POLYNOMIALS OF THE 4TH KIND ---- //
double chebyshev_4(unsigned n, double x);
float chebyshev_4f(unsigned n, float x);
long double chebyshev_4l(unsigned n, long double x);
// ------------- JACOBI POLYNOMIALS -------------- //
double jacobi(unsigned n, unsigned alpha, unsigned beta, double x);
float jacobi(unsigned n, unsigned alpha, unsigned beta, float x);
long double jacobi(unsigned n, unsigned alpha, unsigned beta, long double=
=20
x);
// ------------- ZERNIKE POLYNOMIALS ------------- //
double zernike(unsigned n, int m, double x);
float zernike(unsigned n, int m, float x);
long double zernike(unsigned n, int m, long double x);
// ----------------------------------------------- //

Maybe I could write a proposal with this set of functions, and the comittee=
=20
will keep some of them in mind for a future add to the current functions.

Le dimanche 18 novembre 2012 18:47:54 UTC+1, Beman Dawes a =E9crit :
>
> On Sun, Nov 18, 2012 at 10:08 AM, Jens Maurer <Jens....@gmx.net<javascrip=
t:>>=20
> wrote:=20
> > On 11/17/2012 10:52 AM, VinceRev wrote:=20
> >> The draft for special maths functions :=20
> >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2850.pdf=20
> >> adds a lot of new cool and useful stuff. Nevertheless, from my point=
=20
> >> of view, it lacks one widely use type of polynomials : the Chebyshev=
=20
> >> polynomials (if you google those, you will have more results than the=
=20
> >> "Laguerre polynomials" which are included in the draft (just to say=20
> >> that Chebyshev polynomials are widely used)). One of their=20
> >> application are the spectral methods used to solve some kinds of=20
> >> differential equations. There are four types of Chebyshev polynomials=
=20
> >> defined as (see http://en.wikipedia.org/wiki/Chebyshev_polynomials=20
> >> and Mason & Handscomb "Chebyshev Polynomials") :=20
> >=20
> > The draft you're talking about has meanwhile become an International=20
> Standard:=20
> > ISO/IEC 29123: C++ Special Math Functions=20
> >=20
> > That means WG21 would have to issue an amendment to ISO/IEC 29123 with=
=20
> the=20
> > new proposed functions added.=20
> >=20
> > If I remember correctly, the choice of functions was based on ISO 31-11=
,=20
> and=20
> > thus carefully considered.=20
> >=20
> > I don't know how widespread implementation of ISO 29123 is.  Adding to=
=20
> its=20
> > feature set would make it even larger, possibly slowing its adoption=20
> with=20
> > implementers.=20
> >=20
> > Anyway, http://isocpp.org/std/submit-a-proposal seems to be a good=20
> guideline=20
> > for the next steps to follow.  If there is enough support from=20
> implementers,=20
> > I have no objection to a proposal like this.  Eventually, we (=3D WG21,=
=20
> > the C++ standardization committee) need to have a paper that explains a=
=20
> > little about the motivation and shows the changes to ISO 29123 (section=
,=20
> > paragraph and exact wording) that you want to have done.=20
>
> I'm guessing the chance of adding special math functions one at a time=20
> is very low. But the committee has just set up a Numerics Study Group,=20
> chaired by Lawrence Crowl, so you might want to ask them. Another=20
> option is to talk to John Maddock at Boost.org, since he is=20
> spearheading various major math efforts there.=20
>
> --Beman=20
>

--=20




------=_Part_172_5570986.1353495911951
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thank you for your answers.<br><br>In fact, if we add the Chebyshev polynom=
ials (the Wikipedia page effectively miss the types 3 and 4, but they exist=
 and they are well defined (and there is no 5, 6... families)), we could ad=
d the jacobi and the zernike polynomials (the Jacobi polynomials are a gene=
ralization of Legendre, Chebyshev, and Zernike polynomials). All of that wo=
uld form a consistent "pack" :<br><br><span style=3D"font-family: courier n=
ew,monospace;">// ---- CHEBYSHEV POLYNOMIALS OF THE 1ST KIND ---- //<br>dou=
ble chebyshev_1(unsigned n, double x);<br>float chebyshev_1f(unsigned n, fl=
oat x);<br>long double chebyshev_1l(unsigned n, long double x);<br>// ---- =
CHEBYSHEV POLYNOMIALS OF THE 2ND KIND ---- //<br>double chebyshev_2(unsigne=
d n, double x);<br>float chebyshev_2f(unsigned n, float x);<br>long double =
chebyshev_2l(unsigned n, long double x);<br>// ---- CHEBYSHEV POLYNOMIALS O=
F THE 3RD KIND ---- //<br>double chebyshev_3(unsigned n, double x);<br>floa=
t chebyshev_3f(unsigned n, float x);<br>long double chebyshev_3l(unsigned n=
, long double x);<br>// ---- CHEBYSHEV POLYNOMIALS OF THE 4TH KIND ---- //<=
br>double chebyshev_4(unsigned n, double x);<br>float chebyshev_4f(unsigned=
 n, float x);<br>long double chebyshev_4l(unsigned n, long double x);<br>//=
 ------------- JACOBI POLYNOMIALS -------------- //<br>double jacobi(unsign=
ed n, unsigned alpha, unsigned beta, double x);<br>float jacobi(unsigned n,=
 unsigned alpha, unsigned beta, float x);<br>long double jacobi(unsigned n,=
 unsigned alpha, unsigned beta, long double x);<br>// ------------- ZERNIKE=
 POLYNOMIALS ------------- //<br>double zernike(unsigned n, int m, double x=
);<br>float zernike(unsigned n, int m, float x);<br>long double zernike(uns=
igned n, int m, long double x);<br>// -------------------------------------=
---------- //</span><br><br>Maybe I could write a proposal with this set of=
 functions, and the comittee will keep some of them in mind for a future ad=
d to the current functions.<br><br>Le dimanche 18 novembre 2012 18:47:54 UT=
C+1, Beman Dawes a =E9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;">On Sun, Nov 18, 2012 at 10:08 AM, Jens Maurer &lt;<a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"fY6Z5PgY7PsJ">Jens....@gmx.net=
</a>&gt; wrote:
<br>&gt; On 11/17/2012 10:52 AM, VinceRev wrote:
<br>&gt;&gt; The draft for special maths functions :
<br>&gt;&gt; <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/=
2009/n2850.pdf" target=3D"_blank">http://www.open-std.org/jtc1/<wbr>sc22/wg=
21/docs/papers/2009/<wbr>n2850.pdf</a>
<br>&gt;&gt; adds a lot of new cool and useful stuff. Nevertheless, from my=
 point
<br>&gt;&gt; of view, it lacks one widely use type of polynomials : the Che=
byshev
<br>&gt;&gt; polynomials (if you google those, you will have more results t=
han the
<br>&gt;&gt; "Laguerre polynomials" which are included in the draft (just t=
o say
<br>&gt;&gt; that Chebyshev polynomials are widely used)). One of their
<br>&gt;&gt; application are the spectral methods used to solve some kinds =
of
<br>&gt;&gt; differential equations. There are four types of Chebyshev poly=
nomials
<br>&gt;&gt; defined as (see <a href=3D"http://en.wikipedia.org/wiki/Chebys=
hev_polynomials" target=3D"_blank">http://en.wikipedia.org/wiki/<wbr>Chebys=
hev_polynomials</a>
<br>&gt;&gt; and Mason &amp; Handscomb "Chebyshev Polynomials") :
<br>&gt;
<br>&gt; The draft you're talking about has meanwhile become an Internation=
al Standard:
<br>&gt; ISO/IEC 29123: C++ Special Math Functions
<br>&gt;
<br>&gt; That means WG21 would have to issue an amendment to ISO/IEC 29123 =
with the
<br>&gt; new proposed functions added.
<br>&gt;
<br>&gt; If I remember correctly, the choice of functions was based on ISO =
31-11, and
<br>&gt; thus carefully considered.
<br>&gt;
<br>&gt; I don't know how widespread implementation of ISO 29123 is. &nbsp;=
Adding to its
<br>&gt; feature set would make it even larger, possibly slowing its adopti=
on with
<br>&gt; implementers.
<br>&gt;
<br>&gt; Anyway, <a href=3D"http://isocpp.org/std/submit-a-proposal" target=
=3D"_blank">http://isocpp.org/std/submit-<wbr>a-proposal</a> seems to be a =
good guideline
<br>&gt; for the next steps to follow. &nbsp;If there is enough support fro=
m implementers,
<br>&gt; I have no objection to a proposal like this. &nbsp;Eventually, we =
(=3D WG21,
<br>&gt; the C++ standardization committee) need to have a paper that expla=
ins a
<br>&gt; little about the motivation and shows the changes to ISO 29123 (se=
ction,
<br>&gt; paragraph and exact wording) that you want to have done.
<br>
<br>I'm guessing the chance of adding special math functions one at a time
<br>is very low. But the committee has just set up a Numerics Study Group,
<br>chaired by Lawrence Crowl, so you might want to ask them. Another
<br>option is to talk to John Maddock at Boost.org, since he is
<br>spearheading various major math efforts there.
<br>
<br>--Beman
<br></blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_172_5570986.1353495911951--

.

--e89a8fb1f468ad0ca304cf067909
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Is there somewhere a list of the current functions of the ISO/IEC 80000-2
standard (http://en.wikipedia.org/wiki/ISO_80000-2) ? Because it would be
far more easier for me to evaluate the compatibility of the current ISO
standard with the proposed changes by knowing what is in that standard...




2012/11/21 VinceRev <vince.rev@gmail.com>

> Thank you for your answers.
>
> In fact, if we add the Chebyshev polynomials (the Wikipedia page
> effectively miss the types 3 and 4, but they exist and they are well
> defined (and there is no 5, 6... families)), we could add the jacobi and
> the zernike polynomials (the Jacobi polynomials are a generalization of
> Legendre, Chebyshev, and Zernike polynomials). All of that would form a
> consistent "pack" :
>
> // ---- CHEBYSHEV POLYNOMIALS OF THE 1ST KIND ---- //
>
> double chebyshev_1(unsigned n, double x);
> float chebyshev_1f(unsigned n, float x);
> long double chebyshev_1l(unsigned n, long double x);
> // ---- CHEBYSHEV POLYNOMIALS OF THE 2ND KIND ---- //
>
> double chebyshev_2(unsigned n, double x);
> float chebyshev_2f(unsigned n, float x);
> long double chebyshev_2l(unsigned n, long double x);
> // ---- CHEBYSHEV POLYNOMIALS OF THE 3RD KIND ---- //
>
> double chebyshev_3(unsigned n, double x);
> float chebyshev_3f(unsigned n, float x);
> long double chebyshev_3l(unsigned n, long double x);
> // ---- CHEBYSHEV POLYNOMIALS OF THE 4TH KIND ---- //
>
> double chebyshev_4(unsigned n, double x);
> float chebyshev_4f(unsigned n, float x);
> long double chebyshev_4l(unsigned n, long double x);
> // ------------- JACOBI POLYNOMIALS -------------- //
> double jacobi(unsigned n, unsigned alpha, unsigned beta, double x);
> float jacobi(unsigned n, unsigned alpha, unsigned beta, float x);
> long double jacobi(unsigned n, unsigned alpha, unsigned beta, long double
> x);
> // ------------- ZERNIKE POLYNOMIALS ------------- //
> double zernike(unsigned n, int m, double x);
> float zernike(unsigned n, int m, float x);
> long double zernike(unsigned n, int m, long double x);
> // ----------------------------------------------- //
>
> Maybe I could write a proposal with this set of functions, and the
> comittee will keep some of them in mind for a future add to the current
> functions.
>
> Le dimanche 18 novembre 2012 18:47:54 UTC+1, Beman Dawes a =E9crit :
>
>> On Sun, Nov 18, 2012 at 10:08 AM, Jens Maurer <Jens....@gmx.net> wrote:
>> > On 11/17/2012 10:52 AM, VinceRev wrote:
>> >> The draft for special maths functions :
>> >> http://www.open-std.org/jtc1/**sc22/wg21/docs/papers/2009/**n2850.pdf=
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2850.pdf>
>> >> adds a lot of new cool and useful stuff. Nevertheless, from my point
>> >> of view, it lacks one widely use type of polynomials : the Chebyshev
>> >> polynomials (if you google those, you will have more results than the
>> >> "Laguerre polynomials" which are included in the draft (just to say
>> >> that Chebyshev polynomials are widely used)). One of their
>> >> application are the spectral methods used to solve some kinds of
>> >> differential equations. There are four types of Chebyshev polynomials
>> >> defined as (see http://en.wikipedia.org/wiki/**Chebyshev_polynomials<=
http://en.wikipedia.org/wiki/Chebyshev_polynomials>
>> >> and Mason & Handscomb "Chebyshev Polynomials") :
>> >
>> > The draft you're talking about has meanwhile become an International
>> Standard:
>> > ISO/IEC 29123: C++ Special Math Functions
>> >
>> > That means WG21 would have to issue an amendment to ISO/IEC 29123 with
>> the
>> > new proposed functions added.
>> >
>> > If I remember correctly, the choice of functions was based on ISO
>> 31-11, and
>> > thus carefully considered.
>> >
>> > I don't know how widespread implementation of ISO 29123 is.  Adding to
>> its
>> > feature set would make it even larger, possibly slowing its adoption
>> with
>> > implementers.
>> >
>> > Anyway, http://isocpp.org/std/submit-**a-proposal<http://isocpp.org/st=
d/submit-a-proposal>seems to be a good guideline
>> > for the next steps to follow.  If there is enough support from
>> implementers,
>> > I have no objection to a proposal like this.  Eventually, we (=3D WG21=
,
>> > the C++ standardization committee) need to have a paper that explains =
a
>> > little about the motivation and shows the changes to ISO 29123
>> (section,
>> > paragraph and exact wording) that you want to have done.
>>
>> I'm guessing the chance of adding special math functions one at a time
>> is very low. But the committee has just set up a Numerics Study Group,
>> chaired by Lawrence Crowl, so you might want to ask them. Another
>> option is to talk to John Maddock at Boost.org, since he is
>> spearheading various major math efforts there.
>>
>> --Beman
>>
>  --
>
>
>
>



--=20
Vincent Reverdy*
Phd Student @ Laboratory Universe and Theories**
Cosmology and General Relativity Group
Observatory of Paris-Meudon, France
***

--=20




--e89a8fb1f468ad0ca304cf067909
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Is there somewhere a list of the current functions of the ISO/IEC 80000-2 s=
tandard (<a href=3D"http://en.wikipedia.org/wiki/ISO_80000-2">http://en.wik=
ipedia.org/wiki/ISO_80000-2</a>) ? Because it would be far more easier for =
me to evaluate the compatibility of the current ISO standard with the propo=
sed changes by knowing what is in that standard...<br>
<br><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2012/=
11/21 VinceRev <span dir=3D"ltr">&lt;<a href=3D"mailto:vince.rev@gmail.com"=
 target=3D"_blank">vince.rev@gmail.com</a>&gt;</span><br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
Thank you for your answers.<br><br>In fact, if we add the Chebyshev polynom=
ials (the Wikipedia page effectively miss the types 3 and 4, but they exist=
 and they are well defined (and there is no 5, 6... families)), we could ad=
d the jacobi and the zernike polynomials (the Jacobi polynomials are a gene=
ralization of Legendre, Chebyshev, and Zernike polynomials). All of that wo=
uld form a consistent &quot;pack&quot; :<br>
<br><span style=3D"font-family:courier new,monospace">// ---- CHEBYSHEV POL=
YNOMIALS OF THE 1ST KIND ---- //<div class=3D"im"><br>double chebyshev_1(un=
signed n, double x);<br>float chebyshev_1f(unsigned n, float x);<br>long do=
uble chebyshev_1l(unsigned n, long double x);<br>
</div>// ---- CHEBYSHEV POLYNOMIALS OF THE 2ND KIND ---- //<div class=3D"im=
"><br>double chebyshev_2(unsigned n, double x);<br>float chebyshev_2f(unsig=
ned n, float x);<br>long double chebyshev_2l(unsigned n, long double x);<br=
>
</div>// ---- CHEBYSHEV POLYNOMIALS OF THE 3RD KIND ---- //<div class=3D"im=
"><br>double chebyshev_3(unsigned n, double x);<br>float chebyshev_3f(unsig=
ned n, float x);<br>long double chebyshev_3l(unsigned n, long double x);<br=
>
</div>// ---- CHEBYSHEV POLYNOMIALS OF THE 4TH KIND ---- //<div class=3D"im=
"><br>double chebyshev_4(unsigned n, double x);<br>float chebyshev_4f(unsig=
ned n, float x);<br>long double chebyshev_4l(unsigned n, long double x);<br=
>
</div>// ------------- JACOBI POLYNOMIALS -------------- //<br>double jacob=
i(unsigned n, unsigned alpha, unsigned beta, double x);<br>float jacobi(uns=
igned n, unsigned alpha, unsigned beta, float x);<br>long double jacobi(uns=
igned n, unsigned alpha, unsigned beta, long double x);<br>
// ------------- ZERNIKE POLYNOMIALS ------------- //<br>double zernike(uns=
igned n, int m, double x);<br>float zernike(unsigned n, int m, float x);<br=
>long double zernike(unsigned n, int m, long double x);<br>// -------------=
---------------------------------- //</span><br>
<br>Maybe I could write a proposal with this set of functions, and the comi=
ttee will keep some of them in mind for a future add to the current functio=
ns.<br><br>Le dimanche 18 novembre 2012 18:47:54 UTC+1, Beman Dawes a =E9cr=
it=A0:<div class=3D"HOEnZb">
<div class=3D"h5"><blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, Nov 18, 2=
012 at 10:08 AM, Jens Maurer &lt;<a>Jens....@gmx.net</a>&gt; wrote:
<br>&gt; On 11/17/2012 10:52 AM, VinceRev wrote:
<br>&gt;&gt; The draft for special maths functions :
<br>&gt;&gt; <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/=
2009/n2850.pdf" target=3D"_blank">http://www.open-std.org/jtc1/<u></u>sc22/=
wg21/docs/papers/2009/<u></u>n2850.pdf</a>
<br>&gt;&gt; adds a lot of new cool and useful stuff. Nevertheless, from my=
 point
<br>&gt;&gt; of view, it lacks one widely use type of polynomials : the Che=
byshev
<br>&gt;&gt; polynomials (if you google those, you will have more results t=
han the
<br>&gt;&gt; &quot;Laguerre polynomials&quot; which are included in the dra=
ft (just to say
<br>&gt;&gt; that Chebyshev polynomials are widely used)). One of their
<br>&gt;&gt; application are the spectral methods used to solve some kinds =
of
<br>&gt;&gt; differential equations. There are four types of Chebyshev poly=
nomials
<br>&gt;&gt; defined as (see <a href=3D"http://en.wikipedia.org/wiki/Chebys=
hev_polynomials" target=3D"_blank">http://en.wikipedia.org/wiki/<u></u>Cheb=
yshev_polynomials</a>
<br>&gt;&gt; and Mason &amp; Handscomb &quot;Chebyshev Polynomials&quot;) :
<br>&gt;
<br>&gt; The draft you&#39;re talking about has meanwhile become an Interna=
tional Standard:
<br>&gt; ISO/IEC 29123: C++ Special Math Functions
<br>&gt;
<br>&gt; That means WG21 would have to issue an amendment to ISO/IEC 29123 =
with the
<br>&gt; new proposed functions added.
<br>&gt;
<br>&gt; If I remember correctly, the choice of functions was based on ISO =
31-11, and
<br>&gt; thus carefully considered.
<br>&gt;
<br>&gt; I don&#39;t know how widespread implementation of ISO 29123 is. =
=A0Adding to its
<br>&gt; feature set would make it even larger, possibly slowing its adopti=
on with
<br>&gt; implementers.
<br>&gt;
<br>&gt; Anyway, <a href=3D"http://isocpp.org/std/submit-a-proposal" target=
=3D"_blank">http://isocpp.org/std/submit-<u></u>a-proposal</a> seems to be =
a good guideline
<br>&gt; for the next steps to follow. =A0If there is enough support from i=
mplementers,
<br>&gt; I have no objection to a proposal like this. =A0Eventually, we (=
=3D WG21,
<br>&gt; the C++ standardization committee) need to have a paper that expla=
ins a
<br>&gt; little about the motivation and shows the changes to ISO 29123 (se=
ction,
<br>&gt; paragraph and exact wording) that you want to have done.
<br>
<br>I&#39;m guessing the chance of adding special math functions one at a t=
ime
<br>is very low. But the committee has just set up a Numerics Study Group,
<br>chaired by Lawrence Crowl, so you might want to ask them. Another
<br>option is to talk to John Maddock at Boost.org, since he is
<br>spearheading various major math efforts there.
<br>
<br>--Beman
<br></blockquote>

<p></p>

-- <br>
=A0<br>
=A0<br>
=A0<br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Vincent Rev=
erdy<i><br>Phd Student @ Laboratory Universe and Theories</i><i><br>Cosmolo=
gy and General Relativity Group<br>Observatory of Paris-Meudon, France<br>
</i><span><i></i></span><br>
</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--e89a8fb1f468ad0ca304cf067909--

.

------=_Part_10148_1866246556.1518458712453
Content-Type: multipart/alternative;
 boundary="----=_Part_10149_536961191.1518458712453"

------=_Part_10149_536961191.1518458712453
Content-Type: text/plain; charset="UTF-8"

Hi,

Myself and John Maddock have implemented Chebyshev polynomials in
Boost.Math.

Here's the problem: They are useless without a Chebyshev transform, which
requires a type-II DCT. So standardizing the polynomials would require
standardizing an FFT (or making libstdc++ dependent on FFTW3, which is what
myself and John did in boost. I cannot comment on the feasibility of this.)

   Nick

On Saturday, November 17, 2012 at 3:52:04 AM UTC-6, Vincent Reverdy wrote:
>
> The draft for special maths functions :
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2850.pdf adds a
> lot of new cool and useful stuff. Nevertheless, from my point of view, it
> lacks one widely use type of polynomials : the Chebyshev polynomials (if
> you google those, you will have more results than the "Laguerre
> polynomials" which are included in the draft (just to say that Chebyshev
> polynomials are widely used)). One of their application are the spectral
> methods used to solve some kinds of differential equations. There are four
> types of Chebyshev polynomials defined as (see
> http://en.wikipedia.org/wiki/Chebyshev_polynomials and Mason & Handscomb
> "Chebyshev Polynomials") :
> T_[n](x) = 2*x*T_[n-1](x)-T_[n-2](x) with T_[0](x) = 1 and T[1](x) = x
> U_[n](x) = 2*x*U_[n-1](x)-U_[n-2](x) with U_[0](x) = 1 and U[1](x) = 2*x
> V_[n](x) = 2*x*V_[n-1](x)-V_[n-2](x) with V_[0](x) = 1 and V[1](x) = 2*x-1
> W_[n](x) = 2*x*W_[n-1](x)-W_[n-2](x) with W_[0](x) = 1 and W[1](x) = 2*x+1
>
> The proposal would be to add the following functions to the special math
> functions defined in the draft :
>
> // ----------------- CHEBYSHEV POLYNOMIALS OF THE 1ST KIND
> ----------------- //
> double chebyshev_1(unsigned n, double x);
> float chebyshev_1f(unsigned n, float x);
> long double chebyshev_1l(unsigned n, long double x);
> // ----------------- CHEBYSHEV POLYNOMIALS OF THE 2ND KIND
> ----------------- //
> double chebyshev_2(unsigned n, double x);
> float chebyshev_2f(unsigned n, float x);
> long double chebyshev_2l(unsigned n, long double x);
> // ----------------- CHEBYSHEV POLYNOMIALS OF THE 3RD KIND
> ----------------- //
> double chebyshev_3(unsigned n, double x);
> float chebyshev_3f(unsigned n, float x);
> long double chebyshev_3l(unsigned n, long double x);
> // ----------------- CHEBYSHEV POLYNOMIALS OF THE 4TH KIND
> ----------------- //
> double chebyshev_4(unsigned n, double x);
> float chebyshev_4f(unsigned n, float x);
> long double chebyshev_4l(unsigned n, long double x);
> //
> ------------------------------------------------------------------------- //
>
> What would be the pros & cons for that ?
>
>

--
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/748d7807-9112-4c58-9290-c994fd2de145%40isocpp.org.

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

<div dir=3D"ltr">Hi,<div><br></div><div>Myself and John Maddock have implem=
ented Chebyshev polynomials in Boost.Math.</div><div><br></div><div>Here&#3=
9;s the problem: They are useless without a Chebyshev transform, which requ=
ires a type-II DCT. So standardizing the polynomials would require standard=
izing an FFT (or making libstdc++ dependent on FFTW3, which is what myself =
and John did in boost. I cannot comment on the feasibility of this.)</div><=
div><br></div><div>=C2=A0 =C2=A0Nick<br><br>On Saturday, November 17, 2012 =
at 3:52:04 AM UTC-6, Vincent Reverdy wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;">The draft for special maths functions : <a href=3D"http://www.=
open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2850.pdf" target=3D"_blank" r=
el=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q=
\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F20=
09%2Fn2850.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGlR56LF-VZvc9YC26Tqg=
jmrq9Mbg&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.c=
om/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpap=
ers%2F2009%2Fn2850.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGlR56LF-VZvc=
9YC26Tqgjmrq9Mbg&#39;;return true;">http://www.open-std.org/jtc1/<wbr>sc22/=
wg21/docs/papers/2009/<wbr>n2850.pdf</a> adds a lot of new cool and useful =
stuff. Nevertheless, from my point of view, it lacks one widely use type of=
 polynomials : the Chebyshev polynomials (if you google those, you will hav=
e more results than the &quot;Laguerre polynomials&quot; which are included=
 in the draft (just to say that Chebyshev polynomials are widely used)). On=
e of their application are the spectral methods used to solve some kinds of=
 differential equations. There are four types of Chebyshev polynomials defi=
ned as (see <a href=3D"http://en.wikipedia.org/wiki/Chebyshev_polynomials" =
target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://w=
ww.google.com/url?q\x3dhttp%3A%2F%2Fen.wikipedia.org%2Fwiki%2FChebyshev_pol=
ynomials\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHISwkCqTnGteit5SiVUq1wuOke=
RQ&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url=
?q\x3dhttp%3A%2F%2Fen.wikipedia.org%2Fwiki%2FChebyshev_polynomials\x26sa\x3=
dD\x26sntz\x3d1\x26usg\x3dAFQjCNHISwkCqTnGteit5SiVUq1wuOkeRQ&#39;;return tr=
ue;">http://en.wikipedia.org/wiki/<wbr>Chebyshev_polynomials</a> and Mason =
&amp; Handscomb &quot;Chebyshev Polynomials&quot;) :<br><span style=3D"font=
-family:courier new,monospace">T_[n](x) =3D 2*x*T_[n-1](x)-T_[n-2](x) with =
T_[0](x) =3D 1 and T[1](x) =3D x<br>U_[n](x) =3D 2*x*U_[n-1](x)-U_[n-2](x) =
with U_[0](x) =3D 1 and U[1](x) =3D 2*x<br>V_[n](x) =3D 2*x*V_[n-1](x)-V_[n=
-2](x) with V_[0](x) =3D 1 and V[1](x) =3D 2*x-1<br>W_[n](x) =3D 2*x*W_[n-1=
](x)-W_[n-2](x) with W_[0](x) =3D 1 and W[1](x) =3D 2*x+1</span><br><br>The=
 proposal would be to add the following functions to the special math funct=
ions defined in the draft :<br><br><span style=3D"font-family:courier new,m=
onospace">// ----------------- CHEBYSHEV POLYNOMIALS OF THE 1ST KIND ------=
----------- //<br>double chebyshev_1(unsigned n, double x);<br>float chebys=
hev_1f(unsigned n, float x);<br>long double chebyshev_1l(unsigned n, long d=
ouble x);<br>// ----------------- CHEBYSHEV POLYNOMIALS OF THE 2ND KIND ---=
-------------- //<br>double chebyshev_2(unsigned n, double x);<br>float che=
byshev_2f(unsigned n, float x);<br>long double chebyshev_2l(unsigned n, lon=
g double x);<br>// ----------------- CHEBYSHEV POLYNOMIALS OF THE 3RD KIND =
----------------- //<br>double chebyshev_3(unsigned n, double x);<br>float =
chebyshev_3f(unsigned n, float x);<br>long double chebyshev_3l(unsigned n, =
long double x);<br>// ----------------- CHEBYSHEV POLYNOMIALS OF THE 4TH KI=
ND ----------------- //<br>double chebyshev_4(unsigned n, double x);<br>flo=
at chebyshev_4f(unsigned n, float x);<br>long double chebyshev_4l(unsigned =
n, long double x);<br>// ------------------------------<wbr>---------------=
---------------<wbr>------------- //</span><br><br>What would be the pros &=
amp; cons for that ?<br><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/748d7807-9112-4c58-9290-c994fd2de145%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/748d7807-9112-4c58-9290-c994fd2de145=
%40isocpp.org</a>.<br />

------=_Part_10149_536961191.1518458712453--

------=_Part_10148_1866246556.1518458712453--

.

--94eb2c1c1adcf52e70056507ed3c
Content-Type: text/plain; charset="UTF-8"

One question, something that's been bugging me as most of my work involves
using polynomials as entities in their own right:

Why not have a standardised polynomial library? One which includes
multiplication and addition of polynomials to return new polynomials, which
allows infinite polynomial series from which one can select the first N
elements, etc? A polynomial in this sense is just a map from a ring to
itself. It needn't be floats - you can apply them to matrices and other
polynomials, apply them to quantum lattices to transform them into other
quantum lattices, you name it.

I don't see why a polynomial library would take arguments of depth and an
argument x, especially forcing a type on the object which the polynomial is
applied to. Maybe there is an efficiency benefit, but some of the
calculation can be done at compile time if you choose a suitable structure.

On 12 Feb 2018 18:05, "nthompson via ISO C++ Standard - Future Proposals" <
std-proposals@isocpp.org> wrote:

Hi,

Myself and John Maddock have implemented Chebyshev polynomials in
Boost.Math.

Here's the problem: They are useless without a Chebyshev transform, which
requires a type-II DCT. So standardizing the polynomials would require
standardizing an FFT (or making libstdc++ dependent on FFTW3, which is what
myself and John did in boost. I cannot comment on the feasibility of this.)

   Nick

On Saturday, November 17, 2012 at 3:52:04 AM UTC-6, Vincent Reverdy wrote:
>
> The draft for special maths functions : http://www.open-std.org/jtc1/s
> c22/wg21/docs/papers/2009/n2850.pdf adds a lot of new cool and useful
> stuff. Nevertheless, from my point of view, it lacks one widely use type of
> polynomials : the Chebyshev polynomials (if you google those, you will have
> more results than the "Laguerre polynomials" which are included in the
> draft (just to say that Chebyshev polynomials are widely used)). One of
> their application are the spectral methods used to solve some kinds of
> differential equations. There are four types of Chebyshev polynomials
> defined as (see http://en.wikipedia.org/wiki/Chebyshev_polynomials and
> Mason & Handscomb "Chebyshev Polynomials") :
> T_[n](x) = 2*x*T_[n-1](x)-T_[n-2](x) with T_[0](x) = 1 and T[1](x) = x
> U_[n](x) = 2*x*U_[n-1](x)-U_[n-2](x) with U_[0](x) = 1 and U[1](x) = 2*x
> V_[n](x) = 2*x*V_[n-1](x)-V_[n-2](x) with V_[0](x) = 1 and V[1](x) = 2*x-1
> W_[n](x) = 2*x*W_[n-1](x)-W_[n-2](x) with W_[0](x) = 1 and W[1](x) = 2*x+1
>
> The proposal would be to add the following functions to the special math
> functions defined in the draft :
>
> // ----------------- CHEBYSHEV POLYNOMIALS OF THE 1ST KIND
> ----------------- //
> double chebyshev_1(unsigned n, double x);
> float chebyshev_1f(unsigned n, float x);
> long double chebyshev_1l(unsigned n, long double x);
> // ----------------- CHEBYSHEV POLYNOMIALS OF THE 2ND KIND
> ----------------- //
> double chebyshev_2(unsigned n, double x);
> float chebyshev_2f(unsigned n, float x);
> long double chebyshev_2l(unsigned n, long double x);
> // ----------------- CHEBYSHEV POLYNOMIALS OF THE 3RD KIND
> ----------------- //
> double chebyshev_3(unsigned n, double x);
> float chebyshev_3f(unsigned n, float x);
> long double chebyshev_3l(unsigned n, long double x);
> // ----------------- CHEBYSHEV POLYNOMIALS OF THE 4TH KIND
> ----------------- //
> double chebyshev_4(unsigned n, double x);
> float chebyshev_4f(unsigned n, float x);
> long double chebyshev_4l(unsigned n, long double x);
> // -------------------------------------------------------------------------
> //
>
> What would be the pros & cons for that ?
>
> --
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/748d7807-9112-4c58-
9290-c994fd2de145%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/748d7807-9112-4c58-9290-c994fd2de145%40isocpp.org?utm_medium=email&utm_source=footer>
..

--
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/CAC%2B0CCOZSuKmTT4WZ6K6s-%2BU3XcbWHp01ueHyrWc1FRQ_pp47g%40mail.gmail.com.

--94eb2c1c1adcf52e70056507ed3c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">One question, something that&#39;s been bugging me as mos=
t of my work involves using polynomials as entities in their own right:<br>=
<div class=3D"gmail_extra" dir=3D"auto"><br></div><div class=3D"gmail_extra=
" dir=3D"auto">Why not have a standardised polynomial library? One which in=
cludes multiplication and addition of polynomials to return new polynomials=
, which allows infinite polynomial series from which one can select the fir=
st N elements, etc? A polynomial in this sense is just a map from a ring to=
 itself. It needn&#39;t be floats - you can apply them to matrices and othe=
r polynomials, apply them to quantum lattices to transform them into other =
quantum lattices, you name it.</div><div class=3D"gmail_extra" dir=3D"auto"=
><br></div><div class=3D"gmail_extra" dir=3D"auto">I don&#39;t see why a po=
lynomial library would take arguments of depth and an argument x, especiall=
y forcing a type on the object which the polynomial is applied to. Maybe th=
ere is an efficiency benefit, but some of the calculation can be done at co=
mpile time if you choose a suitable structure.</div><div class=3D"gmail_ext=
ra" dir=3D"auto"><br><div class=3D"gmail_quote">On 12 Feb 2018 18:05, &quot=
;nthompson via ISO C++ Standard - Future Proposals&quot; &lt;<a href=3D"mai=
lto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>&gt; wrote:<br ty=
pe=3D"attribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi,<div><br></=
div><div>Myself and John Maddock have implemented Chebyshev polynomials in =
Boost.Math.</div><div><br></div><div>Here&#39;s the problem: They are usele=
ss without a Chebyshev transform, which requires a type-II DCT. So standard=
izing the polynomials would require standardizing an FFT (or making libstdc=
++ dependent on FFTW3, which is what myself and John did in boost. I cannot=
 comment on the feasibility of this.)</div><div><br></div><div>=C2=A0 =C2=
=A0Nick<br><br>On Saturday, November 17, 2012 at 3:52:04 AM UTC-6, Vincent =
Reverdy wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex">The draft for special=
 maths functions : <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/p=
apers/2009/n2850.pdf" rel=3D"nofollow" target=3D"_blank">http://www.open-st=
d.org/jtc1/s<wbr>c22/wg21/docs/papers/2009/n285<wbr>0.pdf</a> adds a lot of=
 new cool and useful stuff. Nevertheless, from my point of view, it lacks o=
ne widely use type of polynomials : the Chebyshev polynomials (if you googl=
e those, you will have more results than the &quot;Laguerre polynomials&quo=
t; which are included in the draft (just to say that Chebyshev polynomials =
are widely used)). One of their application are the spectral methods used t=
o solve some kinds of differential equations. There are four types of Cheby=
shev polynomials defined as (see <a href=3D"http://en.wikipedia.org/wiki/Ch=
ebyshev_polynomials" rel=3D"nofollow" target=3D"_blank">http://en.wikipedia=
..org/wiki/C<wbr>hebyshev_polynomials</a> and Mason &amp; Handscomb &quot;Ch=
ebyshev Polynomials&quot;) :<br><span style=3D"font-family:courier new,mono=
space">T_[n](x) =3D 2*x*T_[n-1](x)-T_[n-2](x) with T_[0](x) =3D 1 and T[1](=
x) =3D x<br>U_[n](x) =3D 2*x*U_[n-1](x)-U_[n-2](x) with U_[0](x) =3D 1 and =
U[1](x) =3D 2*x<br>V_[n](x) =3D 2*x*V_[n-1](x)-V_[n-2](x) with V_[0](x) =3D=
 1 and V[1](x) =3D 2*x-1<br>W_[n](x) =3D 2*x*W_[n-1](x)-W_[n-2](x) with W_[=
0](x) =3D 1 and W[1](x) =3D 2*x+1</span><br><br>The proposal would be to ad=
d the following functions to the special math functions defined in the draf=
t :<br><br><span style=3D"font-family:courier new,monospace">// -----------=
------ CHEBYSHEV POLYNOMIALS OF THE 1ST KIND ----------------- //<br>double=
 chebyshev_1(unsigned n, double x);<br>float chebyshev_1f(unsigned n, float=
 x);<br>long double chebyshev_1l(unsigned n, long double x);<br>// --------=
--------- CHEBYSHEV POLYNOMIALS OF THE 2ND KIND ----------------- //<br>dou=
ble chebyshev_2(unsigned n, double x);<br>float chebyshev_2f(unsigned n, fl=
oat x);<br>long double chebyshev_2l(unsigned n, long double x);<br>// -----=
------------ CHEBYSHEV POLYNOMIALS OF THE 3RD KIND ----------------- //<br>=
double chebyshev_3(unsigned n, double x);<br>float chebyshev_3f(unsigned n,=
 float x);<br>long double chebyshev_3l(unsigned n, long double x);<br>// --=
--------------- CHEBYSHEV POLYNOMIALS OF THE 4TH KIND ----------------- //<=
br>double chebyshev_4(unsigned n, double x);<br>float chebyshev_4f(unsigned=
 n, float x);<br>long double chebyshev_4l(unsigned n, long double x);<br>//=
 ------------------------------<wbr>------------------------------<wbr>----=
--------- //</span><br><br>What would be the pros &amp; cons for that ?<br>=
<br></blockquote></div></div><font color=3D"#888888">

<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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/748d7807-9112-4c58-9290-c994fd2de145%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/748d=
7807-9112-4c58-<wbr>9290-c994fd2de145%40isocpp.org</a><wbr>.<br>
</font></blockquote></div><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/CAC%2B0CCOZSuKmTT4WZ6K6s-%2BU3XcbWHp0=
1ueHyrWc1FRQ_pp47g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCOZSu=
KmTT4WZ6K6s-%2BU3XcbWHp01ueHyrWc1FRQ_pp47g%40mail.gmail.com</a>.<br />

--94eb2c1c1adcf52e70056507ed3c--

.

------=_Part_1977_54844360.1518726117226
Content-Type: multipart/alternative;
 boundary="----=_Part_1978_75234948.1518726117226"

------=_Part_1978_75234948.1518726117226
Content-Type: text/plain; charset="UTF-8"



What would be the pros & cons for that ?
>

None that I can see.  We should put together another bunch of functions.
I am actually implementing these and many others for libstdc++ (gnu) in
github.com/emsr/tr29124_test (fugly name I know, and the thing is a big
messy collection right now).

For these in particular I chose
chebyshev_[tuvw].

In any case, I am targeting similar to
http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3494.pdf.  I think you
wrote this no? ;-)

This has zericke, radpoly.
I think we need airy_ai, airy_bi, ...

Here is the API docs for my ideas:
https://rawgit.com/emsr/tr29124_test/master/html/index.html

Ed

--
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/56673f13-8ba6-42b5-b105-0cdac1ed85f7%40isocpp.org.

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

<div dir=3D"ltr"><br><br><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">What =
would be the pros &amp; cons for that ?<br></blockquote><div>=C2=A0</div><d=
iv>None that I can see.=C2=A0 We should put together another bunch of funct=
ions.<br>I am actually implementing these and many others for libstdc++ (gn=
u) in github.com/emsr/tr29124_test (fugly name I know, and the thing is a b=
ig messy collection right now).<br><br>For these in particular I chose <br>=
chebyshev_[tuvw].<br><br>In any case, I am targeting similar to http://open=
-std.org/JTC1/SC22/WG21/docs/papers/2013/n3494.pdf.=C2=A0 I think you wrote=
 this no? ;-)<br><br>This has zericke, radpoly.<br>I think we need airy_ai,=
 airy_bi, ...<br><br>Here is the API docs for my ideas: https://rawgit.com/=
emsr/tr29124_test/master/html/index.html<br><br>Ed<br><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/56673f13-8ba6-42b5-b105-0cdac1ed85f7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/56673f13-8ba6-42b5-b105-0cdac1ed85f7=
%40isocpp.org</a>.<br />

------=_Part_1978_75234948.1518726117226--

------=_Part_1977_54844360.1518726117226--

.

On 02/12/18 19:05, nthompson via ISO C++ Standard - Future Proposals wrote:

> Here's the problem: They are useless without a Chebyshev transform,
> which requires a type-II DCT. So standardizing the polynomials would

By useless do you mean that they run in O(N^2) rather than O(N log N)
time with FFT?

Would it be worth standardizing Fast Fourier Transform? It can be
used as the basis for many other transforms whether polynomial or
sinusoidal.

--
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/f04b56e4-74a5-278a-95f0-fa9cc691ed84%40mail1.stofanet.dk.

.

------=_Part_4082_338313370.1518797500787
Content-Type: multipart/alternative;
 boundary="----=_Part_4083_385497982.1518797500788"

------=_Part_4083_385497982.1518797500788
Content-Type: text/plain; charset="UTF-8"

> By useless do you mean that they run in O(N^2) rather than O(N log N)
time with FFT?

Yes, forgive me for not making this clear.

> Would it be worth standardizing Fast Fourier Transform? It can be
used as the basis for many other transforms whether polynomial or
sinusoidal.

My view is yes, that would be incredibly useful in a wide range of fields.

However, the question is who has the ability to write such a thing, and
would they be willing to put it in libstdc++? Would it be acceptable to
simply wrap FFTW?

   Nick


On Friday, February 16, 2018 at 4:00:12 AM UTC-6, Bjorn Reese wrote:
>
> On 02/12/18 19:05, nthompson via ISO C++ Standard - Future Proposals
> wrote:
>
> > Here's the problem: They are useless without a Chebyshev transform,
> > which requires a type-II DCT. So standardizing the polynomials would
>
> By useless do you mean that they run in O(N^2) rather than O(N log N)
> time with FFT?
>
> Would it be worth standardizing Fast Fourier Transform? It can be
> used as the basis for many other transforms whether polynomial or
> sinusoidal.
>

--
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/50fb3c83-af72-49aa-9bc4-df5111c0bfae%40isocpp.org.

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

<div dir=3D"ltr">&gt; By useless do you mean that they run in O(N^2) rather=
 than O(N log N)=C2=A0<br>time with FFT?=C2=A0<div><br></div><div>Yes, forg=
ive me for not making this clear.</div><div><br></div><div>&gt; Would it be=
 worth standardizing Fast Fourier Transform? It can be=C2=A0<br>used as the=
 basis for many other transforms whether polynomial or=C2=A0<br>sinusoidal.=
=C2=A0</div><div><br></div><div>My view is yes, that would be incredibly us=
eful in a wide range of fields.</div><div><br></div><div>However, the quest=
ion is who has the ability to write such a thing, and would they be willing=
 to put it in libstdc++? Would it be acceptable to simply wrap FFTW?</div><=
div><br></div><div>=C2=A0 =C2=A0Nick</div><div><br><br>On Friday, February =
16, 2018 at 4:00:12 AM UTC-6, Bjorn Reese wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;">On 02/12/18 19:05, nthompson via ISO C++ Standard - Futur=
e Proposals wrote:
<br>
<br>&gt; Here&#39;s the problem: They are useless without a Chebyshev trans=
form,=20
<br>&gt; which requires a type-II DCT. So standardizing the polynomials wou=
ld=20
<br>
<br>By useless do you mean that they run in O(N^2) rather than O(N log N)
<br>time with FFT?
<br>
<br>Would it be worth standardizing Fast Fourier Transform? It can be
<br>used as the basis for many other transforms whether polynomial or
<br>sinusoidal.
<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/50fb3c83-af72-49aa-9bc4-df5111c0bfae%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/50fb3c83-af72-49aa-9bc4-df5111c0bfae=
%40isocpp.org</a>.<br />

------=_Part_4083_385497982.1518797500788--

------=_Part_4082_338313370.1518797500787--

.

--001a11496eecffe36a05665e040c
Content-Type: text/plain; charset="UTF-8"

On Fri, Feb 16, 2018 at 8:11 AM, nthompson via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:

> > By useless do you mean that they run in O(N^2) rather than O(N log N)
> time with FFT?
>
> Yes, forgive me for not making this clear.
>
> > Would it be worth standardizing Fast Fourier Transform? It can be
> used as the basis for many other transforms whether polynomial or
> sinusoidal.
>
> My view is yes, that would be incredibly useful in a wide range of fields.
>

I agree, but doing it right in C++ is a nontrivial overhead.

However, the question is who has the ability to write such a thing, and
> would they be willing to put it in libstdc++?
>

There are many implementations of FFTs out there, including FFTW, FFTE (
http://www.ffte.jp/), FFTS (https://github.com/anthonix/ffts), KISSFFT (
http://kissfft.sourceforge.net/), Intel MKL, etc.  Writing a good FFT
implementation is difficult, but many have done it, because it is such an
important operation.  Spiral (http://www.spiral.net/) implements more than
just FFTs.


> Would it be acceptable to simply wrap FFTW?
>

Wrapping FFTW specifically creates licensing issues, because FFTW is GPL
but does not have the GCC Runtime Library Exception (
https://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html) and thus
GPL-incompatible binaries won't be able to use it.

Caveat: I am not a lawyer.  This is not legal advice.  Talk to a lawyer
about software licensing if correctness matters.

Jeff



>    Nick
>
>
> On Friday, February 16, 2018 at 4:00:12 AM UTC-6, Bjorn Reese wrote:
>>
>> On 02/12/18 19:05, nthompson via ISO C++ Standard - Future Proposals
>> wrote:
>>
>> > Here's the problem: They are useless without a Chebyshev transform,
>> > which requires a type-II DCT. So standardizing the polynomials would
>>
>> By useless do you mean that they run in O(N^2) rather than O(N log N)
>> time with FFT?
>>
>> Would it be worth standardizing Fast Fourier Transform? It can be
>> used as the basis for many other transforms whether polynomial or
>> sinusoidal.
>>
> --
> 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/50fb3c83-af72-49aa-
> 9bc4-df5111c0bfae%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/50fb3c83-af72-49aa-9bc4-df5111c0bfae%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>



--
Jeff Hammond
jeff.science@gmail.com
http://jeffhammond.github.io/

--
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/CAGKz%3DuK-0ACNZjkzOGM0xhT0q44TWiTX7%3D62iM8rFS1GQmDz4g%40mail.gmail.com.

--001a11496eecffe36a05665e040c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Feb 16, 2018 at 8:11 AM, nthompson via ISO C++ Standard - Futur=
e Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocpp.or=
g" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span class=
=3D"gmail-">&gt; By useless do you mean that they run in O(N^2) rather than=
 O(N log N)=C2=A0<br>time with FFT?=C2=A0<div><br></div></span><div>Yes, fo=
rgive me for not making this clear.</div><span class=3D"gmail-"><div><br></=
div><div>&gt; Would it be worth standardizing Fast Fourier Transform? It ca=
n be=C2=A0<br>used as the basis for many other transforms whether polynomia=
l or=C2=A0<br>sinusoidal.=C2=A0</div><div><br></div></span><div>My view is =
yes, that would be incredibly useful in a wide range of fields.</div></div>=
</blockquote><div>=C2=A0</div><div>I agree, but doing it right in C++ is a =
nontrivial overhead.</div><div><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr"><div></div><div>However, the question is w=
ho has the ability to write such a thing, and would they be willing to put =
it in libstdc++? </div></div></blockquote><div><br></div><div><span style=
=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-s=
tyle:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-wei=
ght:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transfo=
rm:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,25=
5);text-decoration-style:initial;text-decoration-color:initial;float:none;d=
isplay:inline">There are many implementations of FFTs out there, including =
FFTW, FFTE (<a href=3D"http://www.ffte.jp/">http://www.ffte.jp/</a>), FFTS =
(<a href=3D"https://github.com/anthonix/ffts">https://github.com/anthonix/f=
fts</a>), KISSFFT (<a href=3D"http://kissfft.sourceforge.net/">http://kissf=
ft.sourceforge.net/</a>), Intel MKL, etc.=C2=A0 Writing a good FFT implemen=
tation is difficult, but many have done it, because it is such an important=
 operation.=C2=A0 Spiral (<a href=3D"http://www.spiral.net/">http://www.spi=
ral.net/</a>) implements more than just FFTs.</span><br></div><div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div=
>Would it be acceptable to simply wrap FFTW?</div></div></blockquote><div><=
br></div><div>Wrapping FFTW specifically creates licensing issues, because =
FFTW is GPL but does not have the=C2=A0GCC Runtime Library Exception (<a hr=
ef=3D"https://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html">https:/=
/gcc.gnu.org/onlinedocs/libstdc++/manual/license.html</a>) and thus GPL-inc=
ompatible binaries won&#39;t be able to use it.</div><div><br></div><div>Ca=
veat: I am not a lawyer.=C2=A0 This is not legal advice.=C2=A0 Talk to a la=
wyer about software licensing if correctness matters.</div><div><br></div><=
div>Jeff</div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"><div dir=3D"ltr"><div></div><div>=C2=A0 =C2=A0Nick</di=
v><span class=3D"gmail-"><div><br><br>On Friday, February 16, 2018 at 4:00:=
12 AM UTC-6, Bjorn Reese wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">On 02/12/18 19:05, nthompson via ISO C++ Standard - Future Proposals =
wrote:
<br>
<br>&gt; Here&#39;s the problem: They are useless without a Chebyshev trans=
form,=20
<br>&gt; which requires a type-II DCT. So standardizing the polynomials wou=
ld=20
<br>
<br>By useless do you mean that they run in O(N^2) rather than O(N log N)
<br>time with FFT?
<br>
<br>Would it be worth standardizing Fast Fourier Transform? It can be
<br>used as the basis for many other transforms whether polynomial or
<br>sinusoidal.
<br></blockquote></div></span></div><span class=3D"gmail-">

<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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/50fb3c83-af72-49aa-9bc4-df5111c0bfae%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/50fb=
3c83-af72-49aa-<wbr>9bc4-df5111c0bfae%40isocpp.org</a><wbr>.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature">Jeff Hammond<br><a href=3D"mailto:jeff.science@gmail.c=
om" target=3D"_blank">jeff.science@gmail.com</a><br><a href=3D"http://jeffh=
ammond.github.io/" target=3D"_blank">http://jeffhammond.github.io/</a></div=
>
</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/CAGKz%3DuK-0ACNZjkzOGM0xhT0q44TWiTX7%=
3D62iM8rFS1GQmDz4g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGKz%3DuK-0A=
CNZjkzOGM0xhT0q44TWiTX7%3D62iM8rFS1GQmDz4g%40mail.gmail.com</a>.<br />

--001a11496eecffe36a05665e040c--

.

------=_Part_10428_2019749627.1520145605063
Content-Type: multipart/alternative;
 boundary="----=_Part_10429_1028291915.1520145605064"

------=_Part_10429_1028291915.1520145605064
Content-Type: text/plain; charset="UTF-8"

Being on the scientific computing side of things, I think that having FFTs
in C++ would be extremely valuable, at least for my field.

--
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/a3b994f5-8f2b-45ab-ba99-28d4f207a7a5%40isocpp.org.

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

<div dir=3D"ltr">Being on the scientific computing side of things, I think =
that having FFTs in C++ would be extremely valuable, at least for my field.=
 <br></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/a3b994f5-8f2b-45ab-ba99-28d4f207a7a5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a3b994f5-8f2b-45ab-ba99-28d4f207a7a5=
%40isocpp.org</a>.<br />

------=_Part_10429_1028291915.1520145605064--

------=_Part_10428_2019749627.1520145605063--

.

--001a11356bced9167d05669aa46f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

El 4/3/2018 3:40, "Vincent Reverdy" <vince.rev@gmail.com> escribi=C3=B3:

Being on the scientific computing side of things, I think that having FFTs
in C++ would be extremely valuable, at least for my field.


I acknowledge the utility. I myself also ran almost every year needing FFT
and DSP.
However I just cannot count the amount of implementations I have seen,
varyong in the algorithms, and underlying technologies (SIMD, using GPGPU
or not, other parallelization, etc). And indeed there is not one to rule
them all because it depends where it runs on: the zoo of platforms.
I'm not even sure that an interface could be standardized.

--=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
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/a3b994f5-8f2b-45ab-
ba99-28d4f207a7a5%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a3b994f5-8f2b=
-45ab-ba99-28d4f207a7a5%40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter=
>
..

--=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/CAFdMc-0idx6A_oGpHq7DJ14pOV_VQXyBcuqhxXkEuLn7Tf4=
xwQ%40mail.gmail.com.

--001a11356bced9167d05669aa46f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">El 4/3/2018 3:40, &quot;Vincent Reverdy&quot; &lt;<a href=3D"mail=
to:vince.rev@gmail.com">vince.rev@gmail.com</a>&gt; escribi=C3=B3:<br type=
=3D"attribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Being on the sci=
entific computing side of things, I think that having FFTs in C++ would be =
extremely valuable, at least for my field. <br></div></blockquote></div></d=
iv></div><div dir=3D"auto"><br></div><div dir=3D"auto">I acknowledge the ut=
ility. I myself also ran almost every year needing FFT and DSP.</div><div d=
ir=3D"auto">However I just cannot count the amount of implementations I hav=
e seen, varyong in the algorithms, and underlying technologies (SIMD, using=
 GPGPU or not, other parallelization, etc). And indeed there is not one to =
rule them all because it depends where it runs on: the zoo of platforms.</d=
iv><div dir=3D"auto">I&#39;m not even sure that an interface could be stand=
ardized.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"></div><div class=3D"quoted-text">

<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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a3b994f5-8f2b-45ab-ba99-28d4f207a7a5%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/a3b9=
94f5-8f2b-45ab-<wbr>ba99-28d4f207a7a5%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></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/CAFdMc-0idx6A_oGpHq7DJ14pOV_VQXyBcuqh=
xXkEuLn7Tf4xwQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-0idx6A_oGp=
Hq7DJ14pOV_VQXyBcuqhxXkEuLn7Tf4xwQ%40mail.gmail.com</a>.<br />

--001a11356bced9167d05669aa46f--

.

------=_Part_1309_819632412.1521079742643
Content-Type: multipart/alternative;
 boundary="----=_Part_1310_1621947058.1521079742643"

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

> However I just cannot count the amount of implementations I have seen,=20
varyong in the algorithms, and underlying technologies (SIMD, using GPGPU=
=20
or not, other parallelization, etc).

Newer compilers seem to be taking care of SIMD pretty well, at least for=20
the asm that I've been reading. GPU seems to be a step too far, because=20
there's other things that would have to go into the C++ language to make=20
GPUs first class citizens. Parallelization for multivariate transforms=20
seems natural.

> I'm not even sure that an interface could be standardized.=20

Could you clarify? In my mind, the only thing we have to fight about is=20
whether the scaling is unitary. (Maybe bigint multiplication requires a=20
different type of fft than the one we traditionally think about in floating=
=20
point, but my guess is that bigint multiplication via fft would require a=
=20
custom implementation anyway.)

Jeff Hammond's concern about overhead is the biggest problem-but presumably=
=20
someone could simply write hand-coded asm like they do in OpenBLAS. Nothing=
=20
in the standard would prohibit that.

   Nick

On Monday, March 5, 2018 at 2:47:43 AM UTC+8, dgutson wrote:
>
>
>
> El 4/3/2018 3:40, "Vincent Reverdy" <vinc...@gmail.com <javascript:>>=20
> escribi=C3=B3:
>
> Being on the scientific computing side of things, I think that having FFT=
s=20
> in C++ would be extremely valuable, at least for my field.=20
>
>
> I acknowledge the utility. I myself also ran almost every year needing FF=
T=20
> and DSP.
> However I just cannot count the amount of implementations I have seen,=20
> varyong in the algorithms, and underlying technologies (SIMD, using GPGPU=
=20
> or not, other parallelization, etc). And indeed there is not one to rule=
=20
> them all because it depends where it runs on: the zoo of platforms.
> I'm not even sure that an interface could be standardized.=20
>
> --=20
> You received this message because you are subscribed to the Google Groups=
=20
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
=20
> email to std-proposal...@isocpp.org <javascript:>.
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a3b994f5-8f2=
b-45ab-ba99-28d4f207a7a5%40isocpp.org=20
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a3b994f5-8f=
2b-45ab-ba99-28d4f207a7a5%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
>
>

--=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/fea4a419-c5d1-4772-be1d-18b386817153%40isocpp.or=
g.

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

<div dir=3D"ltr">&gt; However I just cannot count the amount of implementat=
ions I have seen, varyong in the algorithms, and underlying technologies (S=
IMD, using GPGPU or not, other parallelization, etc).<div><br></div><div>Ne=
wer compilers seem to be taking care of SIMD pretty well, at least for the =
asm that I&#39;ve been reading. GPU seems to be a step too far, because the=
re&#39;s other things that would have to go into the C++ language to make G=
PUs first class citizens. Parallelization for multivariate transforms seems=
 natural.</div><div><br></div><div>&gt; I&#39;m not even sure that an inter=
face could be standardized.=C2=A0</div><div><br></div><div>Could you clarif=
y? In my mind, the only thing we have to fight about is whether the scaling=
 is unitary. (Maybe bigint multiplication requires a different type of fft =
than the one we traditionally think about in floating point, but my guess i=
s that bigint multiplication via fft would require a custom implementation =
anyway.)</div><div><br></div><div>Jeff Hammond&#39;s concern about overhead=
 is the biggest problem-but presumably someone could simply write hand-code=
d asm like they do in OpenBLAS. Nothing in the standard would prohibit that=
..</div><div><br></div><div>=C2=A0 =C2=A0Nick<br><br>On Monday, March 5, 201=
8 at 2:47:43 AM UTC+8, dgutson wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;"><div dir=3D"auto"><div><br><div><br><div class=3D"gmail_quote">El 4/=
3/2018 3:40, &quot;Vincent Reverdy&quot; &lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"jyZFJ7HgCwAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hre=
f=3D&#39;javascript:&#39;;return true;">vinc...@gmail.com</a>&gt; escribi=
=C3=B3:<br type=3D"attribution"><blockquote style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Being on the scie=
ntific computing side of things, I think that having FFTs in C++ would be e=
xtremely valuable, at least for my field. <br></div></blockquote></div></di=
v></div><div dir=3D"auto"><br></div><div dir=3D"auto">I acknowledge the uti=
lity. I myself also ran almost every year needing FFT and DSP.</div><div di=
r=3D"auto">However I just cannot count the amount of implementations I have=
 seen, varyong in the algorithms, and underlying technologies (SIMD, using =
GPGPU or not, other parallelization, etc). And indeed there is not one to r=
ule them all because it depends where it runs on: the zoo of platforms.</di=
v><div dir=3D"auto">I&#39;m not even sure that an interface could be standa=
rdized.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div><div =
class=3D"gmail_quote"><blockquote style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"></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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
jyZFJ7HgCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"jyZFJ7HgCwAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a3b994f5-8f2b-45ab-ba99-28d4f207a7a5%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/a3b994f5-8f2b-45ab-ba99-28d4f207a7a5%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/a3b994f5-8f2b-45ab-ba99-28d4f207a7a5%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/a3b994f5-8f2b-45ab-<wbr>ba99-=
28d4f207a7a5%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></div></div>
</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/fea4a419-c5d1-4772-be1d-18b386817153%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fea4a419-c5d1-4772-be1d-18b386817153=
%40isocpp.org</a>.<br />

------=_Part_1310_1621947058.1521079742643--

------=_Part_1309_819632412.1521079742643--

.

--00000000000078987305678b6410
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 14, 2018 at 7:09 PM, nthompson via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:

> > However I just cannot count the amount of implementations I have seen,
> varyong in the algorithms, and underlying technologies (SIMD, using GPGPU
> or not, other parallelization, etc).
>
> Newer compilers seem to be taking care of SIMD pretty well, at least for
> the asm that I've been reading. GPU seems to be a step too far, because
> there's other things that would have to go into the C++ language to make
> GPUs first class citizens. Parallelization for multivariate transforms
> seems natural.
>

Some compilers do a great job with simple vector code.  On the other hand,
it is hard to imagine compilers autovectorizing e.g. scan without pattern
recognition.  For comparison, a good SIMD version is described in
https://software.intel.com/sites/default/files/managed/10/a4/Elusive%20Algo=
rithms%20-%20parallel%20scan.pdf.
I find the AVX-512 equivalent of that code beats compiled C++
implementations by ~3x.

Matrix transposes are another case where compilers are unlikely to do a
good job, given how many google hits there are for "matrix transpose simd"
that show intrinsics or assembly :-)


> > I'm not even sure that an interface could be standardized.
>
> Could you clarify? In my mind, the only thing we have to fight about is
> whether the scaling is unitary. (Maybe bigint multiplication requires a
> different type of fft than the one we traditionally think about in floati=
ng
> point, but my guess is that bigint multiplication via fft would require a
> custom implementation anyway.)
>
> Jeff Hammond's concern about overhead is the biggest problem-but
> presumably someone could simply write hand-coded asm like they do in
> OpenBLAS. Nothing in the standard would prohibit that.
>
>
Sorry I wasn't clear in my statement.  I meant that it would be huge amount
of work to get the standardization part right.  Doing it right means
involving people who understand FFT library interfaces deeply - e.g. Peter
Tang and Matteo Frigo - but those folks aren't involved in WG21 today.

For background, I'd recommend people read
https://doi.org/10.1145/1114268.1114271, which analyzes FFT interfaces.
Some of those issues matter more than others in the C++ context.

Personally, I'd like to see std::matrix and std::tensor in C++ before
std::fft...

Jeff


>    Nick
>
> On Monday, March 5, 2018 at 2:47:43 AM UTC+8, dgutson wrote:
>>
>>
>>
>> El 4/3/2018 3:40, "Vincent Reverdy" <vinc...@gmail.com> escribi=C3=B3:
>>
>> Being on the scientific computing side of things, I think that having
>> FFTs in C++ would be extremely valuable, at least for my field.
>>
>>
>> I acknowledge the utility. I myself also ran almost every year needing
>> FFT and DSP.
>> However I just cannot count the amount of implementations I have seen,
>> varyong in the algorithms, and underlying technologies (SIMD, using GPGP=
U
>> or not, other parallelization, etc). And indeed there is not one to rule
>> them all because it depends where it runs on: the zoo of platforms.
>> I'm not even sure that an interface could be standardized.
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposal...@isocpp.org.
>> To post to this group, send email to std-pr...@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/is
>> ocpp.org/d/msgid/std-proposals/a3b994f5-8f2b-45ab-ba99-
>> 28d4f207a7a5%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a3b994f5-8=
f2b-45ab-ba99-28d4f207a7a5%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>>
>> --
> 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/fea4a419-c5d1-4772-
> be1d-18b386817153%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fea4a419-c5=
d1-4772-be1d-18b386817153%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>



--=20
Jeff Hammond
jeff.science@gmail.com
http://jeffhammond.github.io/

--=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/CAGKz%3DuLcsSw2C_QJL029vrgetmHMkY1AUxW9kwpToY0N0=
QmwkA%40mail.gmail.com.

--00000000000078987305678b6410
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Mar 14, 2018 at 7:09 PM, nthompson via ISO C++ Standard - Futur=
e Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocpp.or=
g" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span class=
=3D"gmail-">&gt; However I just cannot count the amount of implementations =
I have seen, varyong in the algorithms, and underlying technologies (SIMD, =
using GPGPU or not, other parallelization, etc).<div><br></div></span><div>=
Newer compilers seem to be taking care of SIMD pretty well, at least for th=
e asm that I&#39;ve been reading. GPU seems to be a step too far, because t=
here&#39;s other things that would have to go into the C++ language to make=
 GPUs first class citizens. Parallelization for multivariate transforms see=
ms natural.</div></div></blockquote><div><br></div><div>Some compilers do a=
 great job with simple vector code.=C2=A0 On the other hand, it is hard to =
imagine compilers autovectorizing e.g. scan without pattern recognition.=C2=
=A0 For comparison, a good SIMD version is described in=C2=A0<a href=3D"htt=
ps://software.intel.com/sites/default/files/managed/10/a4/Elusive%20Algorit=
hms%20-%20parallel%20scan.pdf">https://software.intel.com/sites/default/fil=
es/managed/10/a4/Elusive%20Algorithms%20-%20parallel%20scan.pdf</a>.=C2=A0 =
I find the AVX-512 equivalent of that code beats compiled C++ implementatio=
ns by ~3x.</div><div><br></div><div>Matrix transposes are another case wher=
e compilers are unlikely to do a good job, given how many google hits there=
 are for &quot;matrix transpose simd&quot; that show intrinsics or assembly=
 :-)</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div dir=3D"ltr"><span class=3D"gmail-"><div></div><div>&gt; I&#39;m not =
even sure that an interface could be standardized.=C2=A0</div><div><br></di=
v></span><div>Could you clarify? In my mind, the only thing we have to figh=
t about is whether the scaling is unitary. (Maybe bigint multiplication req=
uires a different type of fft than the one we traditionally think about in =
floating point, but my guess is that bigint multiplication via fft would re=
quire a custom implementation anyway.)</div><div><br></div><div>Jeff Hammon=
d&#39;s concern about overhead is the biggest problem-but presumably someon=
e could simply write hand-coded asm like they do in OpenBLAS. Nothing in th=
e standard would prohibit that.</div><div><br></div></div></blockquote><div=
><br></div><div>Sorry I wasn&#39;t clear in my statement.=C2=A0 I meant tha=
t it would be huge amount of work to get the standardization part right.=C2=
=A0 Doing it right means involving people who understand FFT library interf=
aces deeply - e.g. Peter Tang and Matteo Frigo - but those folks aren&#39;t=
 involved in WG21 today.</div><div><br></div><div>For background, I&#39;d r=
ecommend people read=C2=A0<a href=3D"https://doi.org/10.1145/1114268.111427=
1">https://doi.org/10.1145/1114268.1114271</a>, which analyzes FFT interfac=
es.=C2=A0 Some of those issues matter more than others in the C++ context.<=
/div><div><br>Personally, I&#39;d like to see std::matrix and std::tensor i=
n C++ before std::fft...</div><div><br></div><div>Jeff</div><div>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><=
/div><div>=C2=A0 =C2=A0Nick<br><br>On Monday, March 5, 2018 at 2:47:43 AM U=
TC+8, dgutson wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"auto"><span class=3D"gmail-"><div><br><div><br><div class=3D"gmail_q=
uote">El 4/3/2018 3:40, &quot;Vincent Reverdy&quot; &lt;<a rel=3D"nofollow"=
>vinc...@gmail.com</a>&gt; escribi=C3=B3:<br type=3D"attribution"><blockquo=
te style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><div dir=3D"ltr">Being on the scientific computing side =
of things, I think that having FFTs in C++ would be extremely valuable, at =
least for my field. <br></div></blockquote></div></div></div><div dir=3D"au=
to"><br></div><div dir=3D"auto">I acknowledge the utility. I myself also ra=
n almost every year needing FFT and DSP.</div><div dir=3D"auto">However I j=
ust cannot count the amount of implementations I have seen, varyong in the =
algorithms, and underlying technologies (SIMD, using GPGPU or not, other pa=
rallelization, etc). And indeed there is not one to rule them all because i=
t depends where it runs on: the zoo of platforms.</div><div dir=3D"auto">I&=
#39;m not even sure that an interface could be standardized.=C2=A0</div><di=
v dir=3D"auto"><br></div></span><div dir=3D"auto"><div><div class=3D"gmail_=
quote"><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"></div><div><span class=
=3D"gmail-">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br></div><span class=3D"gmail-">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a3b994f5-8f2b-45ab-ba99-28d4f207a7a5%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-pr=
oposals<wbr>/a3b994f5-8f2b-45ab-ba99-<wbr>28d4f207a7a5%40isocpp.org</a>.<br=
>
</span></blockquote></div><br></div></div></div>
</blockquote></div></div><span class=3D"gmail-">

<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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fea4a419-c5d1-4772-be1d-18b386817153%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/fea4=
a419-c5d1-4772-<wbr>be1d-18b386817153%40isocpp.org</a><wbr>.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature">Jeff Hammond<br><a href=3D"mailto:jeff.science@gmail.c=
om" target=3D"_blank">jeff.science@gmail.com</a><br><a href=3D"http://jeffh=
ammond.github.io/" target=3D"_blank">http://jeffhammond.github.io/</a></div=
>
</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/CAGKz%3DuLcsSw2C_QJL029vrgetmHMkY1AUx=
W9kwpToY0N0QmwkA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGKz%3DuLcsSw2=
C_QJL029vrgetmHMkY1AUxW9kwpToY0N0QmwkA%40mail.gmail.com</a>.<br />

--00000000000078987305678b6410--

.