------=_Part_2648_639839841.1493644429632
Content-Type: multipart/alternative;
 boundary="----=_Part_2649_1305921466.1493644429633"

------=_Part_2649_1305921466.1493644429633
Content-Type: text/plain; charset=UTF-8

Hello Folks,

I'd just like to bring up the topic of matrices in C++ again.
It has been discussed only superficially by this
<https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/matrix/std-proposals/R9jeBjwJmKo/T-1RWPOvBAAJ>
 thread.
"Superficially" because two-dimensional arrays/fields/tables are not what
I'd like to ask feedback for in this thread.

Has there been any proposal yet to bring the concept of mathematical
matrices into discussion?

With the approval of the mathematical special functions (Tech. Rep.), C++
has clearly stated, It wants to support mathematical computing.
A support for matrices along (mathematical) vectors feel very natural in
this sence.


*Note: By "mathematical vectors" I refer to column or row vectors, which
basically represent matrices of height or width 1.*

If C++ wants to support matrix based computing, this would
infer the following (incomplete and necessarily subjective) list of
features:

*Something lika a std::matrix class (-template)*
Here two questions would be,

1. should the dimensions of a matrix instance compile-time constant or
runtime variable?

2. in what way should a matrix behave like and be iterable lika a
(2-dimensional (?)) container?


*Basic Marix operator overloads*
This includes a matrix-matrix operations as well as constant-matrix
operations and unary matrix

operations like transposition and conjugation. Note: An unary operator' for
transposition would be nice to have.

*Mathematical manipulations and information retrieveing on matrices*
This includes operations like

- computing the determinant, trace, eigenvectors and eigenvalues of a
matrix,

- swapping of rows and columns as well as deriving submatrices

- detection of different attributes (symmetry, hermeticness, orthogonality,
invertability).


*Before people start discussing about potential features of such a class,*
*I'd like to ask for*
*- information about already present proposals or papers if any,*
*- feedback on whether you think such an area shall be permeated by C++*

Let me hear from you!

Cheers
Jakob

--
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/2f08ba29-2cdd-4519-a023-208297256d08%40isocpp.org.

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

<div dir=3D"ltr">Hello Folks,<div><br></div><div>I&#39;d just like to bring=
 up the topic of matrices in C++ again.</div><div>It has been discussed onl=
y superficially by <a href=3D"https://groups.google.com/a/isocpp.org/forum/=
#!searchin/std-proposals/matrix/std-proposals/R9jeBjwJmKo/T-1RWPOvBAAJ">thi=
s</a>=C2=A0thread.</div><div>&quot;Superficially&quot; because two-dimensio=
nal arrays/fields/tables are not what I&#39;d like to ask feedback for in t=
his thread.</div><div><br></div><div>Has there been any proposal yet to bri=
ng the concept of mathematical matrices into discussion?</div><div><br></di=
v><div>With the approval of the mathematical special functions (Tech. Rep.)=
, C++ has clearly stated, It wants to support mathematical computing.</div>=
<div>A support for matrices along (mathematical) vectors feel very natural =
in this sence.</div><div><br></div><div><i>Note: By &quot;mathematical vect=
ors&quot; I refer to column or row vectors, which basically represent matri=
ces of height or width 1.<br></i></div><div><br></div><div><font size=3D"2"=
>If C++ wants to support matrix based computing, this would</font></div><di=
v><font size=3D"2">infer the following (incomplete and necessarily subjecti=
ve) list of features:</font></div><div><br></div><blockquote style=3D"margi=
n: 0 0 0 40px; border: none; padding: 0px;"><div><b>Something lika a std::m=
atrix class (-template)</b></div><div>Here two questions would be,</div></b=
lockquote><blockquote style=3D"margin: 0 0 0 40px; border: none; padding: 0=
px;"><blockquote style=3D"margin: 0 0 0 40px; border: none; padding: 0px;">=
<div>1. should the dimensions of a matrix instance compile-time constant or=
 runtime variable?</div></blockquote></blockquote><blockquote style=3D"marg=
in: 0 0 0 40px; border: none; padding: 0px;"><blockquote style=3D"margin: 0=
 0 0 40px; border: none; padding: 0px;"><div>2. in what way should a matrix=
 behave like and be iterable lika a (2-dimensional (?)) container?</div></b=
lockquote></blockquote><blockquote style=3D"margin: 0 0 0 40px; border: non=
e; padding: 0px;"><div><br></div><div><b>Basic Marix operator overloads</b>=
</div><div>This includes a matrix-matrix operations as well as constant-mat=
rix operations and unary matrix</div></blockquote><blockquote style=3D"marg=
in: 0 0 0 40px; border: none; padding: 0px;"><div>operations like transposi=
tion and conjugation. Note: An unary operator&#39; for transposition would =
be nice to have.</div><div><br></div><div><b>Mathematical manipulations and=
 information retrieveing on matrices</b></div><div>This includes operations=
 like</div></blockquote><blockquote style=3D"margin: 0 0 0 40px; border: no=
ne; padding: 0px;"><blockquote style=3D"margin: 0 0 0 40px; border: none; p=
adding: 0px;"><div>- computing the determinant, trace, eigenvectors and eig=
envalues of a matrix,</div></blockquote></blockquote><blockquote style=3D"m=
argin: 0 0 0 40px; border: none; padding: 0px;"><blockquote style=3D"margin=
: 0 0 0 40px; border: none; padding: 0px;"><div>- swapping of rows and colu=
mns as well as deriving submatrices</div></blockquote></blockquote><blockqu=
ote style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><blockquote s=
tyle=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div>- detection o=
f different attributes (symmetry, hermeticness, orthogonality, invertabilit=
y).</div></blockquote></blockquote><blockquote style=3D"margin: 0 0 0 40px;=
 border: none; padding: 0px;"><div></div></blockquote><div>=C2=A0</div><div=
><b><i>Before</i> people start discussing about potential features of such =
a class,</b></div><div><b>I&#39;d like to ask for</b></div><div><b>- inform=
ation about already present proposals or papers if any,</b></div><div><b>- =
feedback on whether you think such an area shall be permeated by C++</b></d=
iv><div><b><br></b></div><div>Let me hear from you!</div><div><br></div><di=
v>Cheers</div><div>Jakob</div><div><b><br></b></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/2f08ba29-2cdd-4519-a023-208297256d08%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2f08ba29-2cdd-4519-a023-208297256d08=
%40isocpp.org</a>.<br />

------=_Part_2649_1305921466.1493644429633--

------=_Part_2648_639839841.1493644429632--

.

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

Yes, some discussion here:
https://groups.google.com/a/isocpp.org/forum/m/#!msg/sg14/5uZE4G6qFdM/xMkLHrhSBwAJ

On Mon, May 1, 2017, 6:13 AM Jakob Riedle <jakob.riedle@gmail.com> wrote:

> Hello Folks,
>
> I'd just like to bring up the topic of matrices in C++ again.
> It has been discussed only superficially by this
> <https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/matrix/std-proposals/R9jeBjwJmKo/T-1RWPOvBAAJ>
>  thread.
> "Superficially" because two-dimensional arrays/fields/tables are not what
> I'd like to ask feedback for in this thread.
>
> Has there been any proposal yet to bring the concept of mathematical
> matrices into discussion?
>
> With the approval of the mathematical special functions (Tech. Rep.), C++
> has clearly stated, It wants to support mathematical computing.
> A support for matrices along (mathematical) vectors feel very natural in
> this sence.
>
>
> *Note: By "mathematical vectors" I refer to column or row vectors, which
> basically represent matrices of height or width 1.*
>
> If C++ wants to support matrix based computing, this would
> infer the following (incomplete and necessarily subjective) list of
> features:
>
> *Something lika a std::matrix class (-template)*
> Here two questions would be,
>
> 1. should the dimensions of a matrix instance compile-time constant or
> runtime variable?
>
> 2. in what way should a matrix behave like and be iterable lika a
> (2-dimensional (?)) container?
>
>
> *Basic Marix operator overloads*
> This includes a matrix-matrix operations as well as constant-matrix
> operations and unary matrix
>
> operations like transposition and conjugation. Note: An unary operator'
> for transposition would be nice to have.
>
> *Mathematical manipulations and information retrieveing on matrices*
> This includes operations like
>
> - computing the determinant, trace, eigenvectors and eigenvalues of a
> matrix,
>
> - swapping of rows and columns as well as deriving submatrices
>
> - detection of different attributes (symmetry, hermeticness,
> orthogonality, invertability).
>
>
> *Before people start discussing about potential features of such a class,*
> *I'd like to ask for*
> *- information about already present proposals or papers if any,*
> *- feedback on whether you think such an area shall be permeated by C++*
>
> Let me hear from you!
>
> Cheers
> Jakob
>
> --
> 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/2f08ba29-2cdd-4519-a023-208297256d08%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2f08ba29-2cdd-4519-a023-208297256d08%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/CABPJVnReAOy4iS%3DW6p0cNBrte8jfrZ83RwRGDZDn1fYisnwGLg%40mail.gmail.com.

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

<p dir=3D"ltr">Yes, some discussion here: <a href=3D"https://groups.google.=
com/a/isocpp.org/forum/m/#!msg/sg14/5uZE4G6qFdM/xMkLHrhSBwAJ">https://group=
s.google.com/a/isocpp.org/forum/m/#!msg/sg14/5uZE4G6qFdM/xMkLHrhSBwAJ</a></=
p>
<br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, May 1, 2017, 6:13 A=
M Jakob Riedle &lt;<a href=3D"mailto:jakob.riedle@gmail.com">jakob.riedle@g=
mail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr">Hello Folks,<div><br></div><div>I&#39;d just like to bring up the top=
ic of matrices in C++ again.</div><div>It has been discussed only superfici=
ally by <a href=3D"https://groups.google.com/a/isocpp.org/forum/#!searchin/=
std-proposals/matrix/std-proposals/R9jeBjwJmKo/T-1RWPOvBAAJ" target=3D"_bla=
nk">this</a>=C2=A0thread.</div><div>&quot;Superficially&quot; because two-d=
imensional arrays/fields/tables are not what I&#39;d like to ask feedback f=
or in this thread.</div><div><br></div><div>Has there been any proposal yet=
 to bring the concept of mathematical matrices into discussion?</div><div><=
br></div><div>With the approval of the mathematical special functions (Tech=
.. Rep.), C++ has clearly stated, It wants to support mathematical computing=
..</div><div>A support for matrices along (mathematical) vectors feel very n=
atural in this sence.</div><div><br></div><div><i>Note: By &quot;mathematic=
al vectors&quot; I refer to column or row vectors, which basically represen=
t matrices of height or width 1.<br></i></div><div><br></div><div><font siz=
e=3D"2">If C++ wants to support matrix based computing, this would</font></=
div><div><font size=3D"2">infer the following (incomplete and necessarily s=
ubjective) list of features:</font></div><div><br></div><blockquote style=
=3D"margin:0 0 0 40px;border:none;padding:0px"><div><b>Something lika a std=
::matrix class (-template)</b></div><div>Here two questions would be,</div>=
</blockquote><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px=
"><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><div>1. s=
hould the dimensions of a matrix instance compile-time constant or runtime =
variable?</div></blockquote></blockquote><blockquote style=3D"margin:0 0 0 =
40px;border:none;padding:0px"><blockquote style=3D"margin:0 0 0 40px;border=
:none;padding:0px"><div>2. in what way should a matrix behave like and be i=
terable lika a (2-dimensional (?)) container?</div></blockquote></blockquot=
e><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><div><br>=
</div><div><b>Basic Marix operator overloads</b></div><div>This includes a =
matrix-matrix operations as well as constant-matrix operations and unary ma=
trix</div></blockquote><blockquote style=3D"margin:0 0 0 40px;border:none;p=
adding:0px"><div>operations like transposition and conjugation. Note: An un=
ary operator&#39; for transposition would be nice to have.</div><div><br></=
div><div><b>Mathematical manipulations and information retrieveing on matri=
ces</b></div><div>This includes operations like</div></blockquote><blockquo=
te style=3D"margin:0 0 0 40px;border:none;padding:0px"><blockquote style=3D=
"margin:0 0 0 40px;border:none;padding:0px"><div>- computing the determinan=
t, trace, eigenvectors and eigenvalues of a matrix,</div></blockquote></blo=
ckquote><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><bl=
ockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><div>- swappin=
g of rows and columns as well as deriving submatrices</div></blockquote></b=
lockquote><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><=
blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><div>- detec=
tion of different attributes (symmetry, hermeticness, orthogonality, invert=
ability).</div></blockquote></blockquote><blockquote style=3D"margin:0 0 0 =
40px;border:none;padding:0px"><div></div></blockquote><div>=C2=A0</div><div=
><b><i>Before</i> people start discussing about potential features of such =
a class,</b></div><div><b>I&#39;d like to ask for</b></div><div><b>- inform=
ation about already present proposals or papers if any,</b></div><div><b>- =
feedback on whether you think such an area shall be permeated by C++</b></d=
iv><div><b><br></b></div><div>Let me hear from you!</div><div><br></div><di=
v>Cheers</div><div>Jakob</div><div><b><br></b></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" target=3D"_=
blank">std-proposals+unsubscribe@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/2f08ba29-2cdd-4519-a023-208297256d08%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2f08ba29-2cdd-=
4519-a023-208297256d08%40isocpp.org</a>.<br>
</blockquote></div>

<p></p>

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

--001a114b23487cbe3a054e77fac5--

.

------=_Part_1651_1660017740.1493655433578
Content-Type: multipart/alternative;
 boundary="----=_Part_1652_1281544166.1493655433578"

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


Without wishing to sound too negative, I think that attempting to provides=
=20
standardised types for linear algebra is fraught with difficulty. The=20
problem is that such types will generally be used in highly performance=20
sensitive environments, and everyone will have a different view of which=20
compromises they're willing to accept in the name of good performance. The=
=20
danger is that this will lead to one of two scenarios:

   - Much bikeshedding in an attempt to optionally provide every feature=20
   under the sun, leading to an overcomplicated "design by committee" that=
=20
   never gets anywhere, or
   - A "lowest common denominator" compromise that doesn't fully meet=20
   anyone's needs and so goes mostly unused in real-world applications (lik=
e=20
   valarray)

Just off the top of my head, some examples of the kind of questions which=
=20
would need to be answered:

   - Presumably "small" types like vec4 or mat3x3 would be stack-allocated=
=20
   (like std::array) for performance, while larger matrices would be=20
   heap-allocated (like std::vector). But how small is "small"? If we leave=
=20
   it implementation-defined, then it's likely people will stick to using=
=20
   custom libraries which offer known, fixed guarantees.
   - Should we allow row- and column-major ordering? If yes, the design=20
   immediately gets more complicated (needing some sort of matrix_traits=20
   policy class), but if not then anyone who needs to interface with Fortra=
n=20
   libraries (still heavily used today for numerical work) is out of luck
   - What about SIMD support? This would be hard to mandate in the context=
=20
   of the standard's abstract machine, but again if it's left=20
   implementation-defined then people will instead use libraries where thes=
e=20
   guarantees are provided.
   - Should we only provide arrays of rank 1 or 2 (i.e. mathematical=20
   vectors and matrices), or arrays of higher rank too (i.e. tensors)?

In my opinion, rather than providing std::matrix etc *classes*, it would be=
=20
more useful to standardise the interfaces by providing linear algebra=20
*concepts.* (These could be built on top of the interfaces provided by the=
=20
Ranges TS.) That way, I can write an algorithm which works for any=20
(hypothetical) std::Matrix<float, 4, 4>, and it doesn't matter whether the=
=20
user of my library is using GLM, or Eigen, or their own (existing) mat4f=20
from their game engine, or anything else. I have a feeling it would be very=
=20
much easier to persuade the maintainers of large, mature LA libraries like=
=20
Eigen to add standard interface methods to their classes (or provide=20
adaptors), rather than asking them to throw away their hard work and start=
=20
using std::matrix or whatever instead.

Later, once the concepts are in place, we could start talking about=20
defining a simple std::matrix (or whatever) implementation which could be=
=20
used for simple applications or for prototyping.

So in my opinion: focus on the core concepts first, and see whether a=20
useful consensus can be found there.

Just my 2=C2=A2,

Tristan





--=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/a3de1c3f-c9f4-424b-b2e5-4e86241a6954%40isocpp.or=
g.

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

<div dir=3D"ltr"><div><br></div><div>Without wishing to sound too negative,=
 I think that attempting to provides standardised types for linear algebra =
is fraught with difficulty. The problem is that such types will generally b=
e used in highly performance sensitive environments, and everyone will have=
 a different view of which compromises they&#39;re willing to accept in the=
 name of good performance. The danger is that this will lead to one of two =
scenarios:</div><div><ul><li>Much bikeshedding in an attempt to optionally =
provide every feature under the sun, leading to an overcomplicated &quot;de=
sign by committee&quot; that never gets anywhere, or</li><li>A &quot;lowest=
 common denominator&quot; compromise that doesn&#39;t fully meet anyone&#39=
;s needs and so goes mostly unused in real-world applications (like=C2=A0<f=
ont face=3D"courier new, monospace">valarray</font>)</li></ul><div>Just off=
 the top of my head, some examples of the kind of questions which would nee=
d to be answered:</div></div><div><ul><li>Presumably &quot;small&quot; type=
s like vec4 or mat3x3 would be stack-allocated (like <font face=3D"courier =
new, monospace">std::array</font>) for performance, while larger matrices w=
ould be heap-allocated (like <font face=3D"courier new, monospace">std::vec=
tor</font>). But how small is &quot;small&quot;? If we leave it implementat=
ion-defined, then it&#39;s likely people will stick to using custom librari=
es which offer known, fixed guarantees.</li><li>Should we allow row- and co=
lumn-major ordering? If yes, the design immediately gets more complicated (=
needing some sort of <font face=3D"courier new, monospace">matrix_traits</f=
ont> policy class), but if not then anyone who needs to interface with Fort=
ran libraries (still heavily used today for numerical work) is out of luck<=
/li><li>What about SIMD support? This would be hard to mandate in the conte=
xt of the standard&#39;s abstract machine, but again if it&#39;s left imple=
mentation-defined then people will instead use libraries where these guaran=
tees are provided.</li><li>Should we only provide arrays of rank 1 or 2 (i.=
e. mathematical vectors and matrices), or arrays of higher rank too (i.e. t=
ensors)?</li></ul><div>In my opinion, rather than providing <font face=3D"c=
ourier new, monospace">std::matrix</font> etc <i>classes</i>, it would be m=
ore useful to standardise the interfaces by providing linear algebra=C2=A0<=
i>concepts.</i>=C2=A0(These could be=C2=A0built on top of the interfaces pr=
ovided by the Ranges TS.) That way, I can write an algorithm which works fo=
r any (hypothetical) <font face=3D"courier new, monospace">std::Matrix&lt;f=
loat, 4, 4&gt;</font><font face=3D"arial, sans-serif">, and it doesn&#39;t =
matter whether the user of my library is using GLM, or Eigen, or their own =
(existing) </font><font face=3D"courier new, monospace">mat4f</font><font f=
ace=3D"arial, sans-serif"> from their game engine, or anything else. I have=
 a feeling it would be very much easier to persuade the maintainers of larg=
e, mature LA libraries like Eigen to add standard interface methods to thei=
r classes (or provide adaptors), rather than asking them to throw away thei=
r hard work and start using </font><font face=3D"courier new, monospace">st=
d::matrix</font><font face=3D"arial, sans-serif"> or whatever instead.</fon=
t></div><div><br></div><div>Later, once the concepts are in place, we could=
 start talking about defining a simple=C2=A0<font face=3D"courier new, mono=
space">std::matrix</font> (or whatever) implementation which could be used =
for simple applications or for prototyping.</div><div><br></div><div>So in =
my opinion: focus on the core concepts first, and see whether a useful cons=
ensus can be found there.</div><div><br></div><div>Just my 2=C2=A2,</div><d=
iv><br></div><div>Tristan</div><div><font face=3D"arial, sans-serif"><br></=
font></div><div><font face=3D"arial, sans-serif"><br></font></div><div><br>=
</div></div><div><br></div><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/a3de1c3f-c9f4-424b-b2e5-4e86241a6954%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a3de1c3f-c9f4-424b-b2e5-4e86241a6954=
%40isocpp.org</a>.<br />

------=_Part_1652_1281544166.1493655433578--

------=_Part_1651_1660017740.1493655433578--

.

------=_Part_3496_15350120.1493679280140
Content-Type: multipart/alternative;
 boundary="----=_Part_3497_884338379.1493679280140"

------=_Part_3497_884338379.1493679280140
Content-Type: text/plain; charset=UTF-8


>
> So in my opinion: focus on the core concepts first, and see whether a
> useful consensus can be found there.


That seems like a reasonable approach.
I'll try to sit down and prototype a minimal set of Concepts to handle
these interface specifications.

Thanks for the quick response!

Have a nice evening,
Jakob

PS: If anyone wants to express their thoughts, feel free to still do 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/823c51a5-0509-4bce-bd8e-8793c35456bd%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">=
So in my opinion: focus on the core concepts first, and see whether a usefu=
l consensus can be found there.</blockquote><div><br></div><div>That seems =
like a reasonable approach.</div><div>I&#39;ll try to sit down and prototyp=
e a minimal set of Concepts to handle these interface specifications.</div>=
<div><br></div><div>Thanks for the quick response!</div><div><br></div><div=
>Have a nice evening,</div><div>Jakob</div><div><br></div><div>PS: If anyon=
e wants to express their thoughts, feel free to still do that!</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/823c51a5-0509-4bce-bd8e-8793c35456bd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/823c51a5-0509-4bce-bd8e-8793c35456bd=
%40isocpp.org</a>.<br />

------=_Part_3497_884338379.1493679280140--

------=_Part_3496_15350120.1493679280140--

.