------=_Part_88_15772444.1356892383283
Content-Type: text/plain; charset=ISO-8859-1

I would prefer the names vector, static_vector and dynamic_vector., but
since vector is already taken... What about introducing a namespace?
std::math::vector comes to my mind.

--




------=_Part_88_15772444.1356892383283
Content-Type: text/html; charset=ISO-8859-1

I would prefer the names vector, static_vector and dynamic_vector., but since vector is already taken... What about introducing a namespace? std::math::vector comes to my mind.<br>

<p></p>

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

------=_Part_88_15772444.1356892383283--

.

On 12/29/2012 11:51 PM, VinceRev wrote:
> Hello.
>
> I have rewritten the beginning of my proposal avoiding the abusive
> word "vectorization"
> (https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/pnZyN07uAak)
> and I tried to improve it a little. Before writing the technical
> specifications, I would like to have some feedback about the
> motivation and the small example at the beginning of the proposal. Do
> you think that a tool that simplifies the design of user-defined
> mathematical containers could fit in the standard library?

I'm mostly looking at Figure 1 in your paper.
Here are a few concerns:

 - Please show a few lines of code that actually make use of
MyMatrix, highlighting the facilities your <mathematizer>
provides "for free".

 - Today's trend is towards SIMD vectorization.  The interface
you need for your static_mathematizer<...> seems be called
"access", and does not convey enough information so that an
implementation of static_mathematizer<...> could actually
employ SIMD vector instructions, simply because "access"
could use non-contiguous memory for storage of the elements.

 - Standardizing a facility that is actually adverse to
SIMD vectorization, yet tries to supply mathematical vectors
and matrices that ought to be perfectly suited for SIMD, seems
to be a non-starter for me.

 - If there is a need in the marketplace for standardization of
2D, 3D, 4D vectors and 2x2, 3x3, 4x4 matrices as well as
dynamically-sized mathematical vectors and matrices, we should
rather invest our energy in providing standard types for these
instead of helping to produce even more user-specific variants.

 - On the other hand, if people are looking for something
like the boost.iterator library that helps to create a "complete"
iterator type from just a few basic operations, I think
the choice of "access" as the only basic operation is not
sufficiently performance-friendly.

 - Is there a concise summary why std::valarray doesn't work?

 - In any case, this is complicated enough that it should go
to boost (or some other public place) first before coming before
the committee as a proposal.

Jens

--




.

--e89a8ff1c2e8b6950b04d242d2f9
Content-Type: text/plain; charset=ISO-8859-1

Thanks for your comments!

---------------------------------------
1) I will update a more detailed example later.
But for example, you can type:
MyMatrix<double, 3, 3> a(1); // A matrix of one
MyMatrix<double, 3, 3> b(2); // A matrix of two
MyMatrix<double, 3, 3> c = a+4*b; // The calculation is done thanks to the
operators provided by static_mathematizer
---------------------------------------
2) I do not master SIMD optimizations enough, but in a very naive way, I
thought that a loop like that (where Size is a constant, and where access is
inlined) could be vectorized by a compiler.

template<class Kind, std::size_t Size, template<class, Parameters...> class
Crtp, class Type, Kind... Parameters>
struct static_mathematizer
{
    template<class OtherType>
    Crtp<Type, Parameters...>& operator+=(const static_mathematizer<Kind,
Size, Crtp, OtherType, Parameters...>& rhs)
    {
        for (std::size_t i = 0; i < Size; ++i) {
            static_cast<Crtp<Type, Parameters...>&>(*this).access(i) +=
rhs.access(i);
        }
        return static_cast<Crtp<Type, Paramters...>&>(*this);
    }
};

I am wrong ?
---------------------------------------
3) I totally agree (so the current design is only ok if you can do
SIMD-ization through CRTP)
---------------------------------------
4) On this point, I do not agree, and in fact that was the starting point
of this proposal. If we provide some Vector2D, Vector3D etc... in a
standardized way and that I want an order 3 tensor with 4*4*4 components
with some tensor_product function, I will have to also reimplement all the
operator+,-,*... from scratch (and that is the whole problem of the
std::valarray) because I cannot derive from the provided containers safely
(absence of virtual destructor/protected destructor) and if I use
composition, I have to provide an acessor function to get the underlying
array, and the user will have to use this accessor for some operations
(like mytensor1.data() += mytensor2.data()) and not for other ones
(tensor_product(mytensor1,
mytensor2)).
---------------------------------------
5) I will answer later
---------------------------------------
6) See 4)
---------------------------------------
7) You are probably right. After having finished my library (that use a
mechanism close to that, but with too many functions for a
standardization), I will provide a basic implementation of the classes
showed in the proposal.
---------------------------------------





2013/1/1 Jens Maurer <Jens.Maurer@gmx.net>

> On 12/29/2012 11:51 PM, VinceRev wrote:
> > Hello.
> >
> > I have rewritten the beginning of my proposal avoiding the abusive
> > word "vectorization"
> > (
> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/pnZyN07uAak
> )
> > and I tried to improve it a little. Before writing the technical
> > specifications, I would like to have some feedback about the
> > motivation and the small example at the beginning of the proposal. Do
> > you think that a tool that simplifies the design of user-defined
> > mathematical containers could fit in the standard library?
>
> I'm mostly looking at Figure 1 in your paper.
> Here are a few concerns:
>
>  - Please show a few lines of code that actually make use of
> MyMatrix, highlighting the facilities your <mathematizer>
> provides "for free".
>
>  - Today's trend is towards SIMD vectorization.  The interface
> you need for your static_mathematizer<...> seems be called
> "access", and does not convey enough information so that an
> implementation of static_mathematizer<...> could actually
> employ SIMD vector instructions, simply because "access"
> could use non-contiguous memory for storage of the elements.
>
>  - Standardizing a facility that is actually adverse to
> SIMD vectorization, yet tries to supply mathematical vectors
> and matrices that ought to be perfectly suited for SIMD, seems
> to be a non-starter for me.
>
>  - If there is a need in the marketplace for standardization of
> 2D, 3D, 4D vectors and 2x2, 3x3, 4x4 matrices as well as
> dynamically-sized mathematical vectors and matrices, we should
> rather invest our energy in providing standard types for these
> instead of helping to produce even more user-specific variants.
>
>  - On the other hand, if people are looking for something
> like the boost.iterator library that helps to create a "complete"
> iterator type from just a few basic operations, I think
> the choice of "access" as the only basic operation is not
> sufficiently performance-friendly.
>
>  - Is there a concise summary why std::valarray doesn't work?
>
>  - In any case, this is complicated enough that it should go
> to boost (or some other public place) first before coming before
> the committee as a proposal.
>
> Jens
>
> --
>
>
>
>


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

--




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

<div dir=3D"ltr"><div><div><div><div><div><div>Thanks for your comments!<br=
><br>---------------------------------------<br>1) I will update a more det=
ailed example later. <br>But for example, you can type:<br></div><span styl=
e=3D"font-family:courier new,monospace">MyMatrix&lt;double, 3, 3&gt; a(1); =
// A matrix of one<br>

</span></div><span style=3D"font-family:courier new,monospace">MyMatrix&lt;=
double, 3, 3&gt; b(2); // A matrix of two<br></span></div><span style=3D"fo=
nt-family:courier new,monospace">MyMatrix&lt;double, 3, 3&gt; c =3D a+4*b; =
// The calculation is done thanks to the operators provided by static_mathe=
matizer</span><br>

---------------------------------------<br></div>2) I do not master SIMD op=
timizations enough, but in a very naive way, I thought that a loop like tha=
t (where <span style=3D"font-family:courier new,monospace">Size </span>is a=
 constant, and where <span style=3D"font-family:courier new,monospace">acce=
ss </span>is inlined) could be vectorized by a compiler.<br>

<br><span style=3D"font-family:courier new,monospace">template&lt;class Kin=
d, std::size_t Size, template&lt;class, Parameters...&gt; class Crtp, class=
 Type, Kind... Parameters&gt;<br>struct static_mathematizer<br>{<br></span>=
</div>

<span style=3D"font-family:courier new,monospace">=A0=A0=A0 template&lt;cla=
ss OtherType&gt; <br>=A0=A0=A0 Crtp&lt;Type, Parameters...&gt;&amp; operato=
r+=3D(const static_mathematizer&lt;Kind, Size, Crtp, OtherType, Parameters.=
...&gt;&amp; rhs) <br>

=A0=A0=A0 {<br>=A0=A0=A0=A0=A0=A0=A0 for (std::size_t i =3D 0; i &lt; Size;=
 ++i) </span><span style=3D"font-family:courier new,monospace"><span style=
=3D"font-family:courier new,monospace">{<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 static_cast&lt;Crtp&lt;Type, Parameters...&gt;&amp;&gt;(*this).</span>a=
ccess(i) +=3D rhs.access(i);<br>

=A0=A0=A0=A0=A0=A0=A0 }<br>=A0=A0=A0=A0=A0=A0=A0 return static_cast&lt;Crtp=
&lt;Type, Paramters...&gt;&amp;&gt;(*this);<br>=A0=A0=A0 }<br>};</span><br>=
<br></div>I am wrong ?<br><div>---------------------------------------<br><=
/div><div>3) I totally agree (so the current design is only ok if you can d=
o SIMD-ization through CRTP)<br>

---------------------------------------<br></div><div>4) On this point, I d=
o not agree, and in fact that was the starting point of this proposal. If w=
e provide some <span style=3D"font-family:courier new,monospace">Vector2D</=
span>, <span style=3D"font-family:courier new,monospace">Vector3D</span> et=
c... in a standardized way and that I want an order 3 tensor with 4*4*4 com=
ponents with some <span style=3D"font-family:courier new,monospace">tensor_=
product</span> function, I will have to also reimplement all the operator+,=
-,*... from scratch (and that is the whole problem of the <span style=3D"fo=
nt-family:courier new,monospace">std::valarray</span>) because I cannot der=
ive from the provided containers safely (absence of virtual destructor/prot=
ected destructor) and if I use composition, I have to provide an acessor fu=
nction to get the underlying array, and the user will have to use this acce=
ssor for some operations (like <span style=3D"font-family:courier new,monos=
pace">mytensor1.data() +=3D mytensor2.data()</span>) and not for other ones=
 (<span style=3D"font-family:courier new,monospace">tensor_product(mytensor=
1, mytensor2)</span>).<br>

</div><div>---------------------------------------<br></div><div>5) I will =
answer later<br></div><div>---------------------------------------<br><div>=
6) See 4)<br></div>---------------------------------------<br></div><div>

7) You are probably right. After having finished my library (that use a mec=
hanism close to that, but with too many functions for a standardization), I=
 will provide a basic implementation of the classes showed in the proposal.=
<br>
</div><div>
---------------------------------------<br><br><br><br></div></div><div cla=
ss=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/1/1 Jens Maurer =
<span dir=3D"ltr">&lt;<a href=3D"mailto:Jens.Maurer@gmx.net" target=3D"_bla=
nk">Jens.Maurer@gmx.net</a>&gt;</span><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">On 1=
2/29/2012 11:51 PM, VinceRev wrote:<br>
&gt; Hello.<br>
&gt;<br>
&gt; I have rewritten the beginning of my proposal avoiding the abusive<br>
&gt; word &quot;vectorization&quot;<br>
&gt; (<a href=3D"https://groups.google.com/a/isocpp.org/forum/#!topic/std-p=
roposals/pnZyN07uAak" target=3D"_blank">https://groups.google.com/a/isocpp.=
org/forum/#!topic/std-proposals/pnZyN07uAak</a>)<br>
&gt; and I tried to improve it a little. Before writing the technical<br>
&gt; specifications, I would like to have some feedback about the<br>
&gt; motivation and the small example at the beginning of the proposal. Do<=
br>
&gt; you think that a tool that simplifies the design of user-defined<br>
&gt; mathematical containers could fit in the standard library?<br>
<br>
</div></div>I&#39;m mostly looking at Figure 1 in your paper.<br>
Here are a few concerns:<br>
<br>
=A0- Please show a few lines of code that actually make use of<br>
MyMatrix, highlighting the facilities your &lt;mathematizer&gt;<br>
provides &quot;for free&quot;.<br>
<br>
=A0- Today&#39;s trend is towards SIMD vectorization. =A0The interface<br>
you need for your static_mathematizer&lt;...&gt; seems be called<br>
&quot;access&quot;, and does not convey enough information so that an<br>
implementation of static_mathematizer&lt;...&gt; could actually<br>
employ SIMD vector instructions, simply because &quot;access&quot;<br>
could use non-contiguous memory for storage of the elements.<br>
<br>
=A0- Standardizing a facility that is actually adverse to<br>
SIMD vectorization, yet tries to supply mathematical vectors<br>
and matrices that ought to be perfectly suited for SIMD, seems<br>
to be a non-starter for me.<br>
<br>
=A0- If there is a need in the marketplace for standardization of<br>
2D, 3D, 4D vectors and 2x2, 3x3, 4x4 matrices as well as<br>
dynamically-sized mathematical vectors and matrices, we should<br>
rather invest our energy in providing standard types for these<br>
instead of helping to produce even more user-specific variants.<br>
<br>
=A0- On the other hand, if people are looking for something<br>
like the boost.iterator library that helps to create a &quot;complete&quot;=
<br>
iterator type from just a few basic operations, I think<br>
the choice of &quot;access&quot; as the only basic operation is not<br>
sufficiently performance-friendly.<br>
<br>
=A0- Is there a concise summary why std::valarray doesn&#39;t work?<br>
<br>
=A0- In any case, this is complicated enough that it should go<br>
to boost (or some other public place) first before coming before<br>
the committee as a proposal.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jens<br>
<br>
--<br>
<br>
<br>
<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br>Vincent R=
everdy<i><br>Phd Student @ Laboratory Universe and Theories</i><i><br>Cosmo=
logy and General Relativity Group<br>Observatory of Paris-Meudon, France<br=
>
</i><span><i></i></span>
</div>

<p></p>

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

--e89a8ff1c2e8b6950b04d242d2f9--

.

------=_Part_151_5161879.1357139534665
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

Hello Vincent,

I got a few thoughts after reading your PDF:

- I don't see a clear goal for the library. Is it getting a bunch of=20
"mathy" functions "for free"? Is it (SIMD) vectorization? Is it both?

- What would be the list of functions that the library provides? Please=20
consider the following questions while filling up the list: What functions?=
=20
Why those? Why only those? And what do they mean? (For example, what would=
=20
operator* do? Element-wise multiplication? I certainly don't want that=20
happening for matrices..)

- Standard C++ should/must/have to work on all platforms, so a quite=20
critical question is of implementability. What would this library do for a=
=20
CPU that does not have any SMID functionality? What would it do on VLIW=20
machine? What would it do on a 8 bit embedded controller without memory=20
unit? What would it do on x86, where there are optional extensions for 128=
=20
and 256 bit "machine vectors" (SSEx and AVX) that either present or not?=20
Would the library's implementation change if I turn on the=20
--use-avx-instructions switch at the compiler? Even, 'best' implementation=
=20
is different for Intel and AMD processors, even if they would have the=20
exact same instruction set - both vendors currently provide a library=20
implementation (called MKL and ACML), those provide implementation to (a=20
subset of) these functions - what are your thoughts on such libraries in=20
the light of this proposal?

- I too don't see why is std::valarray insufficient. The whole problem is=
=20
written *valarray* all over it. The statement *"it *(std::valarray)* is not=
=20
well designed for composition or inheritance. Consequently, it cannot be=20
used as a common base on which one can add new operators or functions."* is=
=20
just nonsense - sorry. Almost all C++ class' are perfectly suited for=20
composition (only 'broken' classes like auto_ptr are not), you just need to=
=20
provide a fa=E7ade-like interface for all the operators you want to use (an=
d=20
only for those - think of operator* and matrices again), and provide=20
additional operators/functions based on what the class means (like tensor=
=20
product), and not fizzle with a .data() accessor function:
class MyDoubleMatrix {
    std::valarray<double> data;
public:
    MyDoubleMatrix& operator+=3D(const MyDoubleMatrix& right) {
        this->data +=3D right.data;
        return *this;
    }
};

int main() {
    MyDoubleMatrix a,b;
    a +=3D b;
}
One place I can see valarray failing is the support for compile-time-size=
=20
containers -> need of a std::valarray<double, 3>?

- This whole thing seems to be good for one thing only. Then why not=20
providing a standard library that allows us to write
typedef std::math::vector<double, 4> Vector4d;
typedef std::math::matrix<float, 3, 3> Matrix33s;
typedef std::math::matrix<double, 3, std::math::dynamic_size> Matrix3Xd;
typedef std::math::multi_matrix<int, 2,3,4> IntegerMatrixOf2x3x4Size;
etc? Or even, have those typedefs already in. Missing a tensor and=20
tensor_product is not really good argument, add them to the list, and all=
=20
your worries are gone - don't write a proposal that is missing something :)=
=20
I can agree with Jens Maurer, let's solve the problem, not the problem of=
=20
implementing a solution to the original problem. I would love to have such=
=20
standard library (so I can stop maintaining my own :) ).

The basic idea is interesting, but in this phase this is more like a highly=
=20
incomplete wish-list than a proposal, and there is a lot work to be done=20
here.

Regards,
Robert

2012. december 29., szombat 23:51:37 UTC+1 id=F5pontban VinceRev a k=F6vetk=
ez=F5t=20
=EDrta:
>
> Hello.
>
> I have rewritten the beginning of my proposal avoiding the abusive word=
=20
> "vectorization" (
> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/pnZyN0=
7uAak)=20
> and I tried to improve it a little. Before writing the technical=20
> specifications, I would like to have some feedback about the motivation a=
nd=20
> the small example at the beginning of the proposal. Do you think that a=
=20
> tool that simplifies the design of user-defined mathematical containers=
=20
> could fit in the standard library?
>
> Thanks,
>
> Vincent
>

--=20




------=_Part_151_5161879.1357139534665
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

Hello Vincent,<br><br>I got a few thoughts after reading your PDF:<br><br>-=
 I don't see a clear goal for the library. Is it getting a bunch of "mathy"=
 functions "for free"? Is it (SIMD) vectorization? Is it both?<br><br>- Wha=
t would be the list of functions that the library provides? Please consider=
 the following questions while filling up the list: What functions? Why tho=
se? Why only those? And what do they mean? (For example, what would operato=
r* do? Element-wise multiplication? I certainly don't want that happening f=
or matrices..)<br><br>- Standard C++ should/must/have to work on all platfo=
rms, so a quite critical question is of implementability. What would this l=
ibrary do for a CPU that does not have any SMID functionality? What would i=
t do on VLIW machine? What would it do on a 8 bit embedded controller witho=
ut memory unit? What would it do on x86, where there are optional extension=
s for 128 and 256 bit "machine vectors" (SSEx and AVX) that either present =
or not? Would the library's implementation change if I turn on the --use-av=
x-instructions switch at the compiler? Even, 'best' implementation is diffe=
rent for Intel and AMD processors, even if they would have the exact same i=
nstruction set - both vendors currently provide a library implementation (c=
alled MKL and ACML), those provide implementation to  (a subset of) these f=
unctions - what are your thoughts on such libraries in the light of this pr=
oposal?<br><br>- I too don't see why is <span style=3D"font-family: courier=
 new,monospace;">std::valarray</span> insufficient. The whole problem is wr=
itten <i>valarray</i> all over it. The statement <i>"it </i>(<span style=3D=
"font-family: courier new,monospace;">std::valarray</span>)<i> is not well =
designed for composition or inheritance. Consequently, it cannot be used as=
 a common base on which one can add new operators or functions."</i> is jus=
t nonsense - sorry. Almost all C++ class' are perfectly suited for composit=
ion (only 'broken' classes like <span style=3D"font-family: courier new,mon=
ospace;">auto_ptr</span> are not), you just need to provide a fa=E7ade-like=
 interface for all the operators you want to use (and only for those - thin=
k of operator* and matrices again), and provide additional operators/functi=
ons based on what the class means (like tensor product), and not fizzle wit=
h a .data() accessor function:<br><div class=3D"prettyprint" style=3D"backg=
round-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-s=
tyle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pret=
typrint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-=
prettify">MyDoubleMatrix</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
&nbsp; &nbsp; std</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">v=
alarray</span><span style=3D"color: #080;" class=3D"styled-by-prettify">&lt=
;double&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> data</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">public</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify"><code class=3D"prettyprint"><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify"><code class=3D"prettyprint"=
><span style=3D"color: #606;" class=3D"styled-by-prettify">&nbsp;&nbsp;&nbs=
p; MyDoubleMatrix</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">operato=
r</span><span style=3D"color: #660;" class=3D"styled-by-prettify">+=3D(</sp=
an></code></span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
<code class=3D"prettyprint"><span style=3D"color: #008;" class=3D"styled-by=
-prettify">const</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">MyD=
oubleMatrix</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> rig=
ht</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">this-&gt;</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify"></span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">data </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">+=3D</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> right</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">data</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color:=
 #008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> *this</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">&nbsp;&nbsp;&nbsp; }</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"></span><span style=3D"color: #660;" class=3D"styled=
-by-prettify"><br></span></code></span></code>}</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify">;<br><br></span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> main</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r>&nbsp; &nbsp; </span><span style=3D"color: #606;" class=3D"styled-by-pret=
tify">MyDoubleMatrix</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> a</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify">b</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; a </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">+=3D</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> b</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div>One place I can see v=
alarray failing is the support for compile-time-size containers -&gt; need =
of a <span style=3D"font-family: courier new,monospace;">std::valarray&lt;d=
ouble, 3&gt;</span>?<br><br>- This whole thing seems to be good for one thi=
ng=20
only. Then why not providing a standard=20
library that allows us to write<br><div class=3D"prettyprint" style=3D"back=
ground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-=
style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pre=
ttyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">typedef</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">math</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">vector<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">double</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> 4</span><span style=3D"colo=
r: #066;" class=3D"styled-by-prettify"></span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">Vector4d</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">ty=
pedef</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">math</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">matrix</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">float</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-p=
rettify">3</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #066;" class=3D"styled-by-prettify">3</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #60=
6;" class=3D"styled-by-prettify">Matrix33s</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify"><code class=3D"prettyprint"><div class=3D"subprettyprint"=
><span style=3D"color: #008;" class=3D"styled-by-prettify">typedef</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">math</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">matrix</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">double</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">3</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">math::dynamic_size</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606=
;" class=3D"styled-by-prettify">Matrix3X</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">d;<br></span></div></code>typedef</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">math</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">multi_matrix</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">int</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">2</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span=
 style=3D"color: #066;" class=3D"styled-by-prettify">3</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #=
066;" class=3D"styled-by-prettify">4</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify"></span><span style=3D"color: #066;" class=3D"styl=
ed-by-prettify"></span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #606;" class=3D"styled-by-prettify">IntegerMa=
trixOf2x3x4</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>Size;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span></div></code></div>etc? Or
 even, have those typedefs already in. Missing a tensor and tensor_product =
is not=20
really good argument, add them to the list, and all your worries are
 gone - don't write a proposal that is missing something :) I can agree=20
with Jens Maurer, let's solve the problem, not the problem of=20
implementing a solution to the original problem. I would love to have=20
such standard library (so I can stop maintaining my own :) ).<br><br>The ba=
sic idea is interesting, but in this phase=20
this is more like a highly incomplete wish-list than a proposal, and there =
is a lot work to be done here.<br><br>Regards,<br>Robert<br><br>2012. decem=
ber 29., szombat 23:51:37 UTC+1 id=F5pontban VinceRev a k=F6vetkez=F5t =EDr=
ta:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">Hello.<br><br>I have rewrit=
ten the beginning of my proposal avoiding the abusive word "vectorization" =
(<a href=3D"https://groups.google.com/a/isocpp.org/forum/#!topic/std-propos=
als/pnZyN07uAak" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.=
org/forum/#!topic/std-<wbr>proposals/pnZyN07uAak</a>) and I tried to improv=
e it a little. Before writing the technical specifications, I would like to=
 have some feedback about the motivation and the small example at the begin=
ning of the proposal. Do you think that a tool that simplifies the design o=
f user-defined mathematical containers could fit in the standard library?<b=
r><br>Thanks,<br><br>Vincent<br></blockquote>

<p></p>

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

------=_Part_151_5161879.1357139534665--

.

------=_Part_99_6866172.1357148728874
Content-Type: text/plain; charset=ISO-8859-1

Hello Robert.

Thanks for your comments.

- On the point "I too don't see why is std::valarray insufficient." you
provide an example of how forwarding the operation to the valarray. Of
course that is the good way to do it (better than .data()), but if there is
like ~70 operators (counting value/valarray lhs/rhs mixes) and it takes 5
lines of code per operator you have 350 lines to write just to be able to
add the function you want to the container.

- On your last point, I agree 100% with you: it would be far better to have
standardized small vector/small matrices/small tensors. So if it is the
ultimate goal, we will have to standardize all the multilinear algebra
operations (and even for a basic tensor you need a metric to raise and
lower you indexes and you have to be able to work with
covariant/contravariant/lie derivatives): and that is a very huge task. If
that is the problem, what would be the first step?

Regards,
Vincent



--




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

Hello Robert.<br><br>Thanks for your comments.<br><br>- On the point "I too=
 don't see why is <span style=3D"font-family:courier new,monospace">std::va=
larray</span> insufficient." you provide an example of how forwarding the o=
peration to the valarray. Of course that is the good way to do it (better t=
han .data()), but if there is like ~70 operators (counting value/valarray l=
hs/rhs mixes) and it takes 5 lines of code per operator you have 350 lines =
to write just to be able to add the function you want to the container.<br>=
<br>- On your last point, I agree 100% with you: it would be far better to =
have standardized small vector/small matrices/small tensors. So if it is th=
e ultimate goal, we will have to standardize all the multilinear algebra op=
erations (and even for a basic tensor you need a metric to raise and lower =
you indexes and you have to be able to work with covariant/contravariant/li=
e derivatives): and that is a very huge task. If that is the problem, what =
would be the first step? <br><br>Regards,<br>Vincent<br><br><br><br>

<p></p>

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

------=_Part_99_6866172.1357148728874--

.

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

And on the point about forwarding operations to valarray, I think that you=
=20
break expression template optimizations by doing that, isn't it?

Le mercredi 2 janvier 2013 18:45:28 UTC+1, VinceRev a =E9crit :
>
> Hello Robert.
>
> Thanks for your comments.
>
> - On the point "I too don't see why is std::valarray insufficient." you=
=20
> provide an example of how forwarding the operation to the valarray. Of=20
> course that is the good way to do it (better than .data()), but if there =
is=20
> like ~70 operators (counting value/valarray lhs/rhs mixes) and it takes 5=
=20
> lines of code per operator you have 350 lines to write just to be able to=
=20
> add the function you want to the container.
>
> - On your last point, I agree 100% with you: it would be far better to=20
> have standardized small vector/small matrices/small tensors. So if it is=
=20
> the ultimate goal, we will have to standardize all the multilinear algebr=
a=20
> operations (and even for a basic tensor you need a metric to raise and=20
> lower you indexes and you have to be able to work with=20
> covariant/contravariant/lie derivatives): and that is a very huge task. I=
f=20
> that is the problem, what would be the first step?=20
>
> Regards,
> Vincent
>
>
>
>

--=20




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

And on the point about forwarding operations to valarray, I think that you =
break expression template optimizations by doing that, isn't it?<br><br>Le =
mercredi 2 janvier 2013 18:45:28 UTC+1, VinceRev a =E9crit&nbsp;:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">Hello Robert.<br><br>Thanks for your com=
ments.<br><br>- On the point "I too don't see why is <span style=3D"font-fa=
mily:courier new,monospace">std::valarray</span> insufficient." you provide=
 an example of how forwarding the operation to the valarray. Of course that=
 is the good way to do it (better than .data()), but if there is like ~70 o=
perators (counting value/valarray lhs/rhs mixes) and it takes 5 lines of co=
de per operator you have 350 lines to write just to be able to add the func=
tion you want to the container.<br><br>- On your last point, I agree 100% w=
ith you: it would be far better to have standardized small vector/small mat=
rices/small tensors. So if it is the ultimate goal, we will have to standar=
dize all the multilinear algebra operations (and even for a basic tensor yo=
u need a metric to raise and lower you indexes and you have to be able to w=
ork with covariant/contravariant/lie derivatives): and that is a very huge =
task. If that is the problem, what would be the first step? <br><br>Regards=
,<br>Vincent<br><br><br><br></blockquote>

<p></p>

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

------=_Part_94_130556.1357172117463--

.

------=_Part_477_841393.1357246414352
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

If you want proxy results for (insert operator here) two matrices, you also=
=20
need to have proxy matrix classes (that wrap the proxy from valarray=20
operators) as well.

To answer the question in the previous mail, if we want a standard linear=
=20
algebra library, first, we should list what we want from it. A look on the=
=20
current implementations (boost::ublas, Eigen, etc.) is a must.

Regards, Robert


2013. janu=C3=A1r 3., cs=C3=BCt=C3=B6rt=C3=B6k 1:15:17 UTC+1 id=C5=91pontba=
n VinceRev a k=C3=B6vetkez=C5=91t=20
=C3=ADrta:
>
> And on the point about forwarding operations to valarray, I think that yo=
u=20
> break expression template optimizations by doing that, isn't it?
>
> Le mercredi 2 janvier 2013 18:45:28 UTC+1, VinceRev a =C3=A9crit :
>>
>> Hello Robert.
>>
>> Thanks for your comments.
>>
>> - On the point "I too don't see why is std::valarray insufficient." you=
=20
>> provide an example of how forwarding the operation to the valarray. Of=
=20
>> course that is the good way to do it (better than .data()), but if there=
 is=20
>> like ~70 operators (counting value/valarray lhs/rhs mixes) and it takes =
5=20
>> lines of code per operator you have 350 lines to write just to be able t=
o=20
>> add the function you want to the container.
>>
>> - On your last point, I agree 100% with you: it would be far better to=
=20
>> have standardized small vector/small matrices/small tensors. So if it is=
=20
>> the ultimate goal, we will have to standardize all the multilinear algeb=
ra=20
>> operations (and even for a basic tensor you need a metric to raise and=
=20
>> lower you indexes and you have to be able to work with=20
>> covariant/contravariant/lie derivatives): and that is a very huge task. =
If=20
>> that is the problem, what would be the first step?=20
>>
>> Regards,
>> Vincent
>>
>>
>>
>>

--=20




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

If you want proxy results for (insert operator here) two matrices, you=20
also need to have proxy matrix classes (that wrap the proxy from=20
valarray operators) as well.<br><br>To answer the question in the previous =
mail, if we want a standard linear algebra library, first, we should list w=
hat we want from it. A look on the current implementations (boost::ublas, E=
igen, etc.) is a must.<br><br>Regards, Robert<br><br><br>2013. janu=C3=A1r =
3., cs=C3=BCt=C3=B6rt=C3=B6k 1:15:17 UTC+1 id=C5=91pontban VinceRev a k=C3=
=B6vetkez=C5=91t =C3=ADrta:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">And=
 on the point about forwarding operations to valarray, I think that you bre=
ak expression template optimizations by doing that, isn't it?<br><br>Le mer=
credi 2 janvier 2013 18:45:28 UTC+1, VinceRev a =C3=A9crit&nbsp;:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
 #ccc solid;padding-left:1ex">Hello Robert.<br><br>Thanks for your comments=
..<br><br>- On the point "I too don't see why is <span style=3D"font-family:=
courier new,monospace">std::valarray</span> insufficient." you provide an e=
xample of how forwarding the operation to the valarray. Of course that is t=
he good way to do it (better than .data()), but if there is like ~70 operat=
ors (counting value/valarray lhs/rhs mixes) and it takes 5 lines of code pe=
r operator you have 350 lines to write just to be able to add the function =
you want to the container.<br><br>- On your last point, I agree 100% with y=
ou: it would be far better to have standardized small vector/small matrices=
/small tensors. So if it is the ultimate goal, we will have to standardize =
all the multilinear algebra operations (and even for a basic tensor you nee=
d a metric to raise and lower you indexes and you have to be able to work w=
ith covariant/contravariant/lie derivatives): and that is a very huge task.=
 If that is the problem, what would be the first step? <br><br>Regards,<br>=
Vincent<br><br><br><br></blockquote></blockquote>

<p></p>

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

------=_Part_477_841393.1357246414352--

.

On 01/02/2013 12:52 AM, Vincent R wrote:
> Thanks for your comments!
>
> ---------------------------------------
> 1) I will update a more detailed example later.
> But for example, you can type:
> MyMatrix<double, 3, 3> a(1); // A matrix of one
> MyMatrix<double, 3, 3> b(2); // A matrix of two
> MyMatrix<double, 3, 3> c = a+4*b; // The calculation is done thanks to the operators provided by static_mathematizer

Ah.  It seems you're discussing the mathematical concept of vector spaces here.

In particular, you seem to be trying to offer an easy way to define
the operations on a vector space, i.e.
 - addition (subtraction) of two items of a vector space is element-wise addition (subtraction)
 - scalar multiplication with an item of a vector space is element-wise multiplication

Are there any other operations you'd like to support in your "static_mathematizer"?
If not, please name it "vector_space_operations" and people will actually know
what you intend to mean.

I'm always looking for generalities, so are there any other mathematical
structures that would benefit from a treatment similar to what you attempt to
offer for vector spaces?

> ---------------------------------------
> 2) I do not master SIMD optimizations enough, but in a very naive way, I thought that a loop like that (where Size is a constant, and where access is inlined) could be vectorized by a compiler.
>
> template<class Kind, std::size_t Size, template<class, Parameters...> class Crtp, class Type, Kind... Parameters>
> struct static_mathematizer
> {
>     template<class OtherType>
>     Crtp<Type, Parameters...>& operator+=(const static_mathematizer<Kind, Size, Crtp, OtherType, Parameters...>& rhs)
>     {
>         for (std::size_t i = 0; i < Size; ++i) {
>             static_cast<Crtp<Type, Parameters...>&>(*this).access(i) += rhs.access(i);
>         }
>         return static_cast<Crtp<Type, Paramters...>&>(*this);
>     }
> };
>
> I am wrong ?

I don't know.  It's at least two abstraction levels away from the C-style array.
Here's another concern:

 - Let's assume we're talking about a 3x3 "float" matrix.  The SIMD on the machine can deal
with 4 floats in one operation.  Let's assume the derived class actually implements
a 4x3 matrix, with the last column ignored, so that there's a nice match to the SIMD
data width.  I don't think we can expect the compiler to "know" that it can use
SIMD instructions right away, because those would modify the fourth column, which would
(in general) be visible to other parts of the code.

Jens

--




.