------=_Part_843_1436366489.1437578600054
Content-Type: multipart/alternative;
 boundary="----=_Part_844_1431065878.1437578600054"

------=_Part_844_1431065878.1437578600054
Content-Type: text/plain; charset=UTF-8

Hello C++ community.
I was wondering if anyone had proposed a Cartesian coordinate system -
based Point class.
This (basic yet effective) class will represent points in a N dimensional
Cartesian coordinate system and the actions you can preform at.
If this class has being proposed before and declined, I would like to get
links on the proposal and the reason why it got declined.
If it has being proposed and currently it is being discussed (for example,
by the Graphics research team), can I get a link to the proposal.
If it has not being proposed at all, I'd like to hear if this class can be
proposed by me, and what are the needed steps to propose such library.

I truly believe I can contribute to the standard with my idea and effort.
thanks in advance! David Haim.


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">Hello C++ community.<div>I was wondering if anyone had pro=
posed a=C2=A0<span style=3D"line-height: 24px;"><font size=3D"2">Cartesian =
coordinate system - based Point class.=C2=A0</font></span></div><div>This (=
basic yet effective) class will represent points in a N dimensional Cartesi=
an<span style=3D"font-size: small; line-height: 24px;">=C2=A0</span><span s=
tyle=3D"font-size: small; line-height: 24px;">coordinate system and the act=
ions you can preform at.=C2=A0</span></div><div><span style=3D"font-size: s=
mall; line-height: 24px;">If this class has being proposed before and decli=
ned, I would like to get links on the proposal and the reason why it got de=
clined.</span></div><div><font size=3D"2"><span style=3D"line-height: 24px;=
">If it has being proposed and currently it is being=C2=A0discussed=C2=A0(f=
or example, by the Graphics research team), can I get a link to the proposa=
l.</span></font></div><div><font size=3D"2"><span style=3D"line-height: 24p=
x;">If it has not being proposed at all, I&#39;d like to hear if this class=
 can be proposed by me, and what are the needed steps to propose such libra=
ry.</span></font></div><div><font size=3D"2"><span style=3D"line-height: 24=
px;"><br></span></font></div><div><font size=3D"2"><span style=3D"line-heig=
ht: 24px;">I truly believe I can contribute to the standard with my idea an=
d effort.</span></font></div><div><font size=3D"2"><span style=3D"line-heig=
ht: 24px;">thanks in advance! David Haim.</span></font></div><div><font siz=
e=3D"2"><span style=3D"line-height: 24px;"><br></span></font></div><div><sp=
an style=3D"line-height: 24px;"><font size=3D"2"><br></font></span></div></=
div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_844_1431065878.1437578600054--
------=_Part_843_1436366489.1437578600054--

.

On 2015-07-22 11:23, dhayim1@gmail.com wrote:
> Hello C++ community.
> I was wondering if anyone had proposed a Cartesian coordinate system -
> based Point class.
> This (basic yet effective) class will represent points in a N dimensional
> Cartesian coordinate system and the actions you can preform at.
> If this class has being proposed before and declined, I would like to get
> links on the proposal and the reason why it got declined.
> If it has being proposed and currently it is being discussed (for example,
> by the Graphics research team), can I get a link to the proposal.
> If it has not being proposed at all, I'd like to hear if this class can be
> proposed by me, and what are the needed steps to propose such library.

I suspect the big problem here is deciding what features to include.
There is a huge array of possibilities ranging from "none" ('struct
point { double x, y };') to quaternion transforms and other complicated
things. To little, and it isn't useful. Too much and a stand-alone
library is a better solution... and these already exist, e.g. Eigen.
Plus it's such a common class that many libraries have already
implemented such a class, and getting them to converge on a common
implementation is going to be a challenge.

(And TBH, this is why I want generalized tuple unpacking; it makes it
much easier to convert between different libraries' point types.)

Don't forget also that you're going to have folks wanting both double
and float (and possibly long double) precision, so it's not just the
dimensionality that should be a template parameter. And, again, we
already have a full-featured library for that: Eigen.

--
Matthew

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

Hi Methew, thank you for your reply.
I was thinking about a template class that looks like this :

template <class T, unsigned int dimension,
typename=std::enable_if<std::is_arithmetic<T>::value,T>::type >
class Point{...}

here, the developer specify both his wanted precision and the dimension of
the Cartesian plane.

about the Eigen class:
well, this is a philosophical question. isn't C++11 borrows heavily from
boost type_traits and thread library? didn't we already have some platforms
and libraries with Thread class in them?  there are many I can think of.
MFC is one of them (for windows).
isn't C++17 is going to borrow heavily from boost networking library and
filesystem library?
does the fact that something already exists outside the standard is enough
to cancel it's standardization? I think the opposite. the fact there there
are many platforms and libraries outside that implement Point class only
proves its necessity.
the standard basically says "we have reviewed this proposal and approved it
for general use. this is an approved C++ feature to use",



2015-07-22 8:59 GMT-07:00, Matthew Woehlke <mwoehlke.floss@gmail.com>:
> On 2015-07-22 11:23, dhayim1@gmail.com wrote:
>> Hello C++ community.
>> I was wondering if anyone had proposed a Cartesian coordinate system -
>> based Point class.
>> This (basic yet effective) class will represent points in a N dimensional
>>
>> Cartesian coordinate system and the actions you can preform at.
>> If this class has being proposed before and declined, I would like to get
>>
>> links on the proposal and the reason why it got declined.
>> If it has being proposed and currently it is being discussed (for example,
>>
>> by the Graphics research team), can I get a link to the proposal.
>> If it has not being proposed at all, I'd like to hear if this class can be
>>
>> proposed by me, and what are the needed steps to propose such library.
>
> I suspect the big problem here is deciding what features to include.
> There is a huge array of possibilities ranging from "none" ('struct
> point { double x, y };') to quaternion transforms and other complicated
> things. To little, and it isn't useful. Too much and a stand-alone
> library is a better solution... and these already exist, e.g. Eigen.
> Plus it's such a common class that many libraries have already
> implemented such a class, and getting them to converge on a common
> implementation is going to be a challenge.
>
> (And TBH, this is why I want generalized tuple unpacking; it makes it
> much easier to convert between different libraries' point types.)
>
> Don't forget also that you're going to have folks wanting both double
> and float (and possibly long double) precision, so it's not just the
> dimensionality that should be a template parameter. And, again, we
> already have a full-featured library for that: Eigen.
>
> --
> Matthew
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/jkY2NskIg1E/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--047d7b4724e2bf3fd9051b79abd4
Content-Type: text/plain; charset=UTF-8

Hi Methew, thank you for your reply.
I was thinking about a template class that looks like this :

template <class T, unsigned int dimension,
typename=std::enable_if<std::is_arithmetic<T>::value,T>::type >
class Point{...}

here, the developer specify both his wanted precision and the dimension of
the Cartesian plane.

about the Eigen class:
well, this is a philosophical question. isn't C++11 borrows heavily from
boost type_traits and thread library? didn't we already have some platforms
and libraries with Thread class in them?  there are many I can think of.
MFC is one of them (for windows).
isn't C++17 is going to borrow heavily from boost networking library and
filesystem library?
does the fact that something already exists outside the standard is enough
to cancel it's standardization? I think the opposite. the fact there there
are many platforms and libraries outside that implement Point class only
proves its necessity.
the standard basically says "we have reviewed this proposal and approved it
for general use. this is an approved C++ feature to use",

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"rtl">Hi Methew, thank you for your reply.<br>I was thinking abo=
ut a template class that looks like this :<br><br>template &lt;class T, uns=
igned int dimension, typename=3Dstd::enable_if&lt;std::is_arithmetic&lt;T&g=
t;::value,T&gt;::type &gt;<br>class Point{...}<br><br>here, the developer s=
pecify both his wanted precision and the dimension of the Cartesian plane.<=
br><br>about the Eigen class: <br>well, this is a philosophical question. i=
sn&#39;t C++11 borrows heavily from boost type_traits and thread library? d=
idn&#39;t we already have some platforms and libraries with Thread class in=
 them?=C2=A0 there are many I can think of. MFC is one of them (for windows=
).<br>isn&#39;t C++17 is going to borrow heavily from boost networking libr=
ary and filesystem library?<br>does the fact that something already exists =
outside the standard is enough to cancel it&#39;s standardization? I think =
the opposite. the fact there there are many platforms and libraries outside=
 that implement Point class only proves its necessity.<br>the standard basi=
cally says &quot;we have reviewed this proposal and approved it for general=
 use. this is an approved C++ feature to use&quot;,=C2=A0 <br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b4724e2bf3fd9051b79abd4--

.

On 2015-07-22 12:53, David Haim wrote:
> about the Eigen class:
> well, this is a philosophical question. isn't C++11 borrows heavily from
> boost type_traits and thread library? didn't we already have some platforms
> and libraries with Thread class in them?  there are many I can think of.
> MFC is one of them (for windows).
> isn't C++17 is going to borrow heavily from boost networking library and
> filesystem library?
> does the fact that something already exists outside the standard is enough
> to cancel it's standardization? I think the opposite. the fact there there
> are many platforms and libraries outside that implement Point class only
> proves its necessity.

I don't disagree; I'm just concerned with finding the right balance of
features that will make a point class sufficiently useful to make real
inroads at replacing existing libraries.

You can also take that another way... should Eigen be standardized?

--
Matthew

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--047d7b4724e2efe699051b79f74e
Content-Type: text/plain; charset=UTF-8

finding the right balance is some issue. I don't think it is something that
can block Point class specifically.

about Eigen, then:
1) I don't see any reason why not to borrow elements or classes from Eigen
(or any other library). I do believe though, that one should not bite more
than it can chew.
standardization for one class is hard enough. standardizing an entire
library could takes years (even dozens of them), it is better to start with
something small and gradually increase the amount of classes you add to the
standard.
2) After digging a bit in the Eigen library, I couldn't find an explicit
Point class, are you sure they have implemented such class?

2015-07-22 20:08 GMT+03:00 Matthew Woehlke <mwoehlke.floss@gmail.com>:

> On 2015-07-22 12:53, David Haim wrote:
> > about the Eigen class:
> > well, this is a philosophical question. isn't C++11 borrows heavily from
> > boost type_traits and thread library? didn't we already have some
> platforms
> > and libraries with Thread class in them?  there are many I can think of.
> > MFC is one of them (for windows).
> > isn't C++17 is going to borrow heavily from boost networking library and
> > filesystem library?
> > does the fact that something already exists outside the standard is
> enough
> > to cancel it's standardization? I think the opposite. the fact there
> there
> > are many platforms and libraries outside that implement Point class only
> > proves its necessity.
>
> I don't disagree; I'm just concerned with finding the right balance of
> features that will make a point class sufficiently useful to make real
> inroads at replacing existing libraries.
>
> You can also take that another way... should Eigen be standardized?
>
> --
> Matthew
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/jkY2NskIg1E/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"rtl"><div dir=3D"ltr">finding the right balance is some issue. =
I don&#39;t think it is something that can block Point class specifically.<=
/div><div dir=3D"ltr"><br></div><div dir=3D"ltr">about Eigen, then:</div><d=
iv dir=3D"ltr">1) I don&#39;t see any reason why not to borrow elements or =
classes from Eigen (or any other library). I do believe though, that one sh=
ould not bite more than it can chew.=C2=A0</div><div dir=3D"ltr">standardiz=
ation for one class is hard enough. standardizing an entire library could t=
akes years (even dozens of them), it is better to start with something smal=
l and gradually increase the amount of classes you add to the standard.</di=
v><div dir=3D"ltr">2) After digging a bit in the Eigen library, I couldn&#3=
9;t find an explicit Point class, are you sure they have implemented such c=
lass?=C2=A0</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote"><div dir=3D"ltr">2015-07-22 20:08 GMT+03:00 Matthew Woehlke <span dir=
=3D"ltr">&lt;<a href=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">=
mwoehlke.floss@gmail.com</a>&gt;</span>:</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><span class=3D"">On 2015-07-22 12:53, David Haim wrote:<br>
&gt; about the Eigen class:<br>
&gt; well, this is a philosophical question. isn&#39;t C++11 borrows heavil=
y from<br>
&gt; boost type_traits and thread library? didn&#39;t we already have some =
platforms<br>
&gt; and libraries with Thread class in them?=C2=A0 there are many I can th=
ink of.<br>
&gt; MFC is one of them (for windows).<br>
&gt; isn&#39;t C++17 is going to borrow heavily from boost networking libra=
ry and<br>
&gt; filesystem library?<br>
&gt; does the fact that something already exists outside the standard is en=
ough<br>
&gt; to cancel it&#39;s standardization? I think the opposite. the fact the=
re there<br>
&gt; are many platforms and libraries outside that implement Point class on=
ly<br>
&gt; proves its necessity.<br>
<br>
</span>I don&#39;t disagree; I&#39;m just concerned with finding the right =
balance of<br>
features that will make a point class sufficiently useful to make real<br>
inroads at replacing existing libraries.<br>
<br>
You can also take that another way... should Eigen be standardized?<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
Matthew<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/jkY2NskIg1E/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/jkY2NskIg1E/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b4724e2efe699051b79f74e--

.

--047d7bf0ef186d275c051b7a0033
Content-Type: text/plain; charset=UTF-8

>
> finding the right balance is some issue. I don't think it is something
> that can block Point class specifically.
>
> about Eigen, then:
> 1) I don't see any reason why not to borrow elements or classes from Eigen
> (or any other library). I do believe though, that one should not bite more
> than it can chew.
> standardization for one class is hard enough. standardizing an entire
> library could takes years (even dozens of them), it is better to start with
> something small and gradually increase the amount of classes you add to the
> standard.
> 2) After digging a bit in the Eigen library, I couldn't find an explicit
> Point class, are you sure they have implemented such class?
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"rtl"><div class=3D"gmail_extra"><div dir=3D"ltr"><div class=3D"=
gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0.8ex;bo=
rder-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:so=
lid;border-right-width:1px;border-right-color:rgb(204,204,204);border-right=
-style:solid;padding-left:1ex;padding-right:1ex"><div class=3D"gmail_extra"=
><div dir=3D"ltr" style=3D"font-size:12.8000001907349px">finding the right =
balance is some issue. I don&#39;t think it is something that can block Poi=
nt class specifically.</div><div dir=3D"ltr" style=3D"font-size:12.80000019=
07349px"><br></div><div dir=3D"ltr" style=3D"font-size:12.8000001907349px">=
about Eigen, then:</div><div dir=3D"ltr" style=3D"font-size:12.800000190734=
9px">1) I don&#39;t see any reason why not to borrow elements or classes fr=
om Eigen (or any other library). I do believe though, that one should not b=
ite more than it can chew.=C2=A0</div><div dir=3D"ltr" style=3D"font-size:1=
2.8000001907349px">standardization for one class is hard enough. standardiz=
ing an entire library could takes years (even dozens of them), it is better=
 to start with something small and gradually increase the amount of classes=
 you add to the standard.</div><div dir=3D"ltr" style=3D"font-size:12.80000=
01907349px">2) After digging a bit in the Eigen library, I couldn&#39;t fin=
d an explicit Point class, are you sure they have implemented such class?=
=C2=A0</div></div>
</blockquote></div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bf0ef186d275c051b7a0033--

.

On 2015-07-22 13:19, David Haim wrote:
> 2) After digging a bit in the Eigen library, I couldn't find an explicit
> Point class, are you sure they have implemented such class?

Yes and no; see the vector class(es). There's not much=C2=B9 benefit to
defining a point class vs. a vector class, and a general vector has more
uses. A "point" is just a vector offset from the origin, which is merely
a semantic distinction; it's fairly common to treat "points" as a
semantic subset of "vectors".

(=C2=B9 Actually, offhand I can't think of *any* benefit except maybe type
distinction, and strong typedefs would make that moot. I feel like
*maybe* there is some benefit, but I can't think what.)

--=20
Matthew

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--047d7b4724e28ab405051b7a5874
Content-Type: text/plain; charset=UTF-8

yes, every vector can be built from the origin to some point, thus any
point can represent a vector (starting from the origin) and vice-versa.
a point is definitely not a vector, and a vector is not a point. saying
that one is redundant is not mathematically right.
plus, let's say in the future we want to implement a "Rectangle" or
"Circle" shape, I don't see how mathematically speaking a rectangle is
composed from 4 vectors. It is composed from 4 points.

also, mathematically speaking, a vector has something a point doesn't have
- direction.
when I say Point(1,2) -> I do not imply any direction. it's a point, it has
no direction what so ever.

but if you insist that a point is a vector , you are recognizing the vast
utilities a Point can have: the entire linear algebra and the virtual
graphics use it as key feature. this is exactly why C++ has to standardize
it.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"rtl"><div class=3D"gmail_extra" dir=3D"ltr">yes, every vector c=
an be built from the origin to some point, thus any point can represent a v=
ector (starting from the origin) and vice-versa.</div><div class=3D"gmail_e=
xtra" dir=3D"ltr">a point is definitely not a vector, and a vector is not a=
 point. saying that one is redundant is not mathematically right.</div><div=
 class=3D"gmail_extra" dir=3D"ltr">plus, let&#39;s say in the future we wan=
t to implement a &quot;Rectangle&quot; or &quot;Circle&quot; shape, I don&#=
39;t see how mathematically speaking a rectangle is composed from 4 vectors=
.. It is composed from 4 points.=C2=A0</div><div class=3D"gmail_extra" dir=
=3D"ltr"><br></div><div class=3D"gmail_extra" dir=3D"ltr">also, mathematica=
lly speaking, a vector has something a point doesn&#39;t have - direction.=
=C2=A0</div><div class=3D"gmail_extra" dir=3D"ltr">when I say Point(1,2) -&=
gt; I do not imply any direction. it&#39;s a point, it has no direction wha=
t so ever.</div><div class=3D"gmail_extra" dir=3D"ltr"><br></div><div class=
=3D"gmail_extra" dir=3D"ltr">but if you insist that a point is a vector , y=
ou are recognizing the vast utilities a Point can have: the entire linear a=
lgebra and the virtual graphics use it as key feature. this is exactly why =
C++ has to standardize it. =C2=A0 =C2=A0</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b4724e28ab405051b7a5874--

.

On 2015-07-22 13:46, David Haim wrote:
> yes, every vector can be built from the origin to some point, thus any
> point can represent a vector (starting from the origin) and vice-versa.
> a point is definitely not a vector, and a vector is not a point. saying
> that one is redundant is not mathematically right.

Maybe not, but from a programming standpoint this is a *semantic*
difference. You will find many instances of geometry libraries that have
a "vector" type that is used interchangeably for both entities. GLSL, to
name a big one.

(That said, I bet I could find mathematicians that would say that a
point *is* a vector... at least in a linear algebra sense, if not a
geometry sense.)

> plus, let's say in the future we want to implement a "Rectangle" or
> "Circle" shape, I don't see how mathematically speaking a rectangle is
> composed from 4 vectors. It is composed from 4 points.

I have a CAD suite I've been working on (off and on) for ages that uses
Eigen for the low level geometry classes. All point locations are given
as Eigen::Vector3D. I don't even have typedefs to semantically separate
"actual" vectors from points.

> but if you insist that a point is a vector , you are recognizing the vast
> utilities a Point can have: the entire linear algebra and the virtual
> graphics use it as key feature. this is exactly why C++ has to standardize
> it.

I think you meant "utilities a Vector can have", but yes, that's exactly
my point; a well-featured vector type can do everything a point type
can, plus a LOT more.

Really, what you want isn't a point type, it's an N-dimensional array of
numbers that supports various linear algebra operations. And really,
that's all a "vector" is in the linear algebra sense; it's usage in a
geometry context that supplies more specific semantics. That's going to
be far more widely useful than something restricted to the semantics of
a geometry "point".

Oh, and, it should also be a subclass of std::array :-).

--
Matthew

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

I'm sorry. but a point is not a vector. the standard must be mathematical
correct.
now, we might want to argue if to name it "vector" class or "point" class
(plus, I don't see how can we push another std::vector class :) standard
C++ does not have an other namespaces other than "std").
I still think that mathematically talking - the 3 fundamental definitions
are "Point" "Line" and "Plane". we need to stick to these definitions from
the bottom up if we want to add new mathematical/graphical objects to
standard C++.

you also didn't took into consideration that not all vectors start from the
origin. this may have crucial impact on future graphical/mathematical
operations later on. if you want a vector object to start not from the
origin you WILL need 2 points.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"rtl"><div dir=3D"ltr">I&#39;m sorry. but a point is not a vecto=
r. the standard must be mathematical correct.</div><div dir=3D"ltr">now, we=
 might want to argue if to name it &quot;vector&quot; class or &quot;point&=
quot; class (plus, I don&#39;t see how can we push another std::vector clas=
s :) standard C++ does not have an other namespaces other than &quot;std&qu=
ot;).</div><div dir=3D"ltr">I still think that mathematically talking - the=
 3 fundamental definitions are &quot;Point&quot; &quot;Line&quot; and &quot=
;Plane&quot;. we need to stick to these definitions from the bottom up if w=
e want to add new mathematical/graphical objects to standard C++.</div><div=
 dir=3D"ltr"><br></div><div dir=3D"ltr">you also didn&#39;t took into consi=
deration that not all vectors start from the origin. this may have crucial =
impact on future graphical/mathematical operations later on. if you want a =
vector object to start not from the origin you WILL need 2 points. =C2=A0 =
=C2=A0</div><div dir=3D"ltr">=C2=A0</div><div dir=3D"ltr"><br></div><div cl=
ass=3D"gmail_extra"><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c2403ef63448051b7b1960--

.

On 2015-07-22 14:40, David Haim wrote:
> I'm sorry. but a point is not a vector. the standard must be mathematical
> correct.
> now, we might want to argue if to name it "vector" class or "point" class
> (plus, I don't see how can we push another std::vector class :) standard
> C++ does not have an other namespaces other than "std").

std::la::vector :-) ('la' being short for 'linear algebra'). Or
'std::algebra', or whatnot.

> I still think that mathematically talking - the 3 fundamental definitions
> are "Point" "Line" and "Plane". we need to stick to these definitions from
> the bottom up if we want to add new mathematical/graphical objects to
> standard C++.

That list MUST include a vector type. Both a line and plane can be
defined by vectors (direction or normal, respectively). So you either
NEED a vector type distinct from a point type, or you need one class
that can be used in either context.

> you also didn't took into consideration that not all vectors start from the
> origin.

Only a minuscule fraction of users actually want "vectors" that have a
defined origin. Everyone else only cares about magnitude and direction,
which is the pure linear algebra definition. (Again, a "vector" in LA is
a numeric tuple; *nothing more*.)

In fact, I'll challenge you to name a use case for a "vector" that is
defined as an magnitude, direction, AND origin. And that isn't actually
a line segment, or a case where the "origin" and "vector" aren't
actually separate concepts (e.g. position and velocity of a particle).

--
Matthew

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

that's easy, gradually paint some line from on point to another (like a
progress bar). something like
mapSurface.drawLineProgressivly({{5,5},{10,10}});

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"rtl"><div class=3D"gmail_extra" dir=3D"ltr">that&#39;s easy, gr=
adually paint some line from on point to another (like a progress bar). som=
ething like</div><div class=3D"gmail_extra" dir=3D"ltr">mapSurface.drawLine=
Progressivly({{5,5},{10,10}});</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--f46d044288ccbe9351051b7b65f9--

.

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

This is a very difficult design problem, because there's a question of
semantics and transformations.

A point is transformed differently by a matrix than a vector (the
difference between points), and each of these are transformed differently
than a normal.  In the Renderman Shading Language, these correspond to
three different functions, "transform", "vtransform", and "ntransform".

Some C++ geometry libraries have made strong type distinctions -
differentiating "point3" from "vector3" from "normal3", and so on, allowing
them to overload the arithmetic operators.  Having used several such
libraries, they're generally frustrating to use because the data is usually
stored simply as "float3" or "double3" or "half3", and the constant
static_cast or reinterpret_casting, or worse, new object creation, is
tedious.

A library I've been using recently, built on top of Eigen and a separate
math library as an alternative, doesn't overload arthmetic operators at
all, but instead uses explicit free functions for readability - so you can
say, transform_point(float4x4, float3), transform_vector(float4x4, float3),
etc.  This also makes it easy to templatize the arguments to these free
functions to any type which meets the minimum requirements.  Many users of
such an approach, however, find the lack of arithmetic operator overloads
deeply annoying.

Yet another library I've had to work with recently simply disallows
transforming a float3 by a mat44, requiring the user to convert the float3
into a homogenous point as a float4.  Then, transform_point becomes
operator*(mat44, float4{float3, 1}), and transform_vector becomes
operator*(mat44, float4{float3, 0}), and transform_normal becomes
operator*(inverse(transpose(mat44)), float4{float3, 0}).  This is tedious
in its own way.

Eigen goes to great (and sometimes frustrating) extents to create odd
intermediate types that allow for compile-time removal of unnecessary
temporaries.  For example, if a matrix is orthonormal, then the operation
inverse(transpose(matrix)) is a no-op, and this can be detected at compile
time using a traits object on things like rigid transformations.  This is
useful with very large dimensions, but has difficulties that the
intermediate types sometimes produce unexpected results when using "auto".

I would imagine a standardization attempt at such a library would be deeply
contentious, but probably valuable if consensus could be reached.  I hope
that members of the graphics and games communities would be involved.

Chris



On Wed, Jul 22, 2015 at 10:29 AM, Matthew Woehlke <mwoehlke.floss@gmail.com=
>
wrote:

> On 2015-07-22 13:19, David Haim wrote:
> > 2) After digging a bit in the Eigen library, I couldn't find an explici=
t
> > Point class, are you sure they have implemented such class?
>
> Yes and no; see the vector class(es). There's not much=C2=B9 benefit to
> defining a point class vs. a vector class, and a general vector has more
> uses. A "point" is just a vector offset from the origin, which is merely
> a semantic distinction; it's fairly common to treat "points" as a
> semantic subset of "vectors".
>
> (=C2=B9 Actually, offhand I can't think of *any* benefit except maybe typ=
e
> distinction, and strong typedefs would make that moot. I feel like
> *maybe* there is some benefit, but I can't think what.)
>
> --
> Matthew
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">This is a very difficult design problem, because there&#39=
;s a question of semantics and transformations.<div><br></div><div>A point =
is transformed differently by a matrix than a vector (the difference betwee=
n points), and each of these are transformed differently than a normal.=C2=
=A0 In the Renderman Shading Language, these correspond to three different =
functions, &quot;transform&quot;, &quot;vtransform&quot;, and &quot;ntransf=
orm&quot;.</div><div><br></div><div>Some C++ geometry libraries have made s=
trong type distinctions - differentiating &quot;point3&quot; from &quot;vec=
tor3&quot; from &quot;normal3&quot;, and so on, allowing them to overload t=
he arithmetic operators.=C2=A0 Having used several such libraries, they&#39=
;re generally frustrating to use because the data is usually stored simply =
as &quot;float3&quot; or &quot;double3&quot; or &quot;half3&quot;, and the =
constant static_cast or reinterpret_casting, or worse, new object creation,=
 is tedious. =C2=A0</div><div><br></div><div>A library I&#39;ve been using =
recently, built on top of Eigen and a separate math library as an alternati=
ve, doesn&#39;t overload arthmetic operators at all, but instead uses expli=
cit free functions for readability - so you can say, transform_point(float4=
x4, float3), transform_vector(float4x4, float3), etc.=C2=A0 This also makes=
 it easy to templatize the arguments to these free functions to any type wh=
ich meets the minimum requirements.=C2=A0 Many users of such an approach, h=
owever, find the lack of arithmetic operator overloads deeply annoying.</di=
v><div><br></div><div>Yet another library I&#39;ve had to work with recentl=
y simply disallows transforming a float3 by a mat44, requiring the user to =
convert the float3 into a homogenous point as a float4.=C2=A0 Then, transfo=
rm_point becomes operator*(mat44, float4{float3, 1}), and transform_vector =
becomes operator*(mat44, float4{float3, 0}), and transform_normal becomes o=
perator*(inverse(transpose(mat44)), float4{float3, 0}).=C2=A0 This is tedio=
us in its own way.</div><div><br></div><div>Eigen goes to great (and someti=
mes frustrating) extents to create odd intermediate types that allow for co=
mpile-time removal of unnecessary temporaries.=C2=A0 For example, if a matr=
ix is orthonormal, then the operation inverse(transpose(matrix)) is a no-op=
, and this can be detected at compile time using a traits object on things =
like rigid transformations.=C2=A0 This is useful with very large dimensions=
, but has difficulties that the intermediate types sometimes produce unexpe=
cted results when using &quot;auto&quot;.</div><div><br></div><div>I would =
imagine a standardization attempt at such a library would be deeply content=
ious, but probably valuable if consensus could be reached.=C2=A0 I hope tha=
t members of the graphics and games communities would be involved.</div><di=
v><br></div><div>Chris</div><div><br></div><div><div><br></div></div></div>=
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Jul 22, 2=
015 at 10:29 AM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=3D"mailto:mw=
oehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail.com</a>&gt;<=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 2015-07=
-22 13:19, David Haim wrote:<br>
&gt; 2) After digging a bit in the Eigen library, I couldn&#39;t find an ex=
plicit<br>
&gt; Point class, are you sure they have implemented such class?<br>
<br>
</span>Yes and no; see the vector class(es). There&#39;s not much=C2=B9 ben=
efit to<br>
defining a point class vs. a vector class, and a general vector has more<br=
>
uses. A &quot;point&quot; is just a vector offset from the origin, which is=
 merely<br>
a semantic distinction; it&#39;s fairly common to treat &quot;points&quot; =
as a<br>
semantic subset of &quot;vectors&quot;.<br>
<br>
(=C2=B9 Actually, offhand I can&#39;t think of *any* benefit except maybe t=
ype<br>
distinction, and strong typedefs would make that moot. I feel like<br>
*maybe* there is some benefit, but I can&#39;t think what.)<br>
<br>
--<br>
Matthew<br>
<br>
--<br>
<br>
---<br>
<span class=3D"">You received this message because you are subscribed to th=
e Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
</span>To unsubscribe from this group and stop receiving emails from it, se=
nd an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">st=
d-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113fd0424e9de2051b7a6357--

.

Am 22.07.2015 um 20:53 schrieb Matthew Woehlke:
> On 2015-07-22 14:40, David Haim wrote:
>> I'm sorry. but a point is not a vector. the standard must be mathematical
>> correct.
>> now, we might want to argue if to name it "vector" class or "point" class
>> (plus, I don't see how can we push another std::vector class :) standard
>> C++ does not have an other namespaces other than "std").
> std::la::vector :-) ('la' being short for 'linear algebra'). Or
> 'std::algebra', or whatnot.
>
>> I still think that mathematically talking - the 3 fundamental definitions
>> are "Point" "Line" and "Plane". we need to stick to these definitions from
>> the bottom up if we want to add new mathematical/graphical objects to
>> standard C++.
> That list MUST include a vector type. Both a line and plane can be
> defined by vectors (direction or normal, respectively). So you either
> NEED a vector type distinct from a point type, or you need one class
> that can be used in either context.
>
>> you also didn't took into consideration that not all vectors start from the
>> origin.
> Only a minuscule fraction of users actually want "vectors" that have a
> defined origin. Everyone else only cares about magnitude and direction,
> which is the pure linear algebra definition. (Again, a "vector" in LA is
> a numeric tuple; *nothing more*.)
>
> In fact, I'll challenge you to name a use case for a "vector" that is
> defined as an magnitude, direction, AND origin. And that isn't actually
> a line segment, or a case where the "origin" and "vector" aren't
> actually separate concepts (e.g. position and velocity of a particle).
>
The word "vector" is heavily overloaded and represented in all kinds of
math disciplines.

You have the linear algebra "vector" that is an element of the real
coordinate space R^n.

In Euclidean space a "spatial vector" is a direction and magnitue
whereas a "position vector" represents the position of a point P in
space relative to an origin O, then there are also "normal vectors" and
a load of other vector types. It's all there in the school books.

Yes, these things are treated differently in Euclidian geometry, which
is why points (i.e. position vectors) are denoted with a different class
of symbols (commonly a capital letter for positional vectors, a
lowercase letter for spatial vectors[*]). There are different kinds of
operations defined for "position vectors" and "spatial vectors", which
some may not take very seriously, but there is technically no definition
of a inner product of two points, even though they are represented by
position *vectors*, they are as well transformed differently. So there
is very good reason for using distinct types for points and vectors as
there is good reason to not use float for the magnitudes of both mass
and acceleration: less bugs.

It can even improve efficiency. For example, if there is a type for
"unit vector", and it can only be created/mutated in operations which
guarantee the result has a magnitude of 1 or preserve the magnitude of
its operand. Now you can overload functions on this type, meaning you
can get rid of normalize() calls in many places that already receive a
unit vector. One just has to be careful about making the interface not
horribly verbose and terribly annoying to use.

Yes, GLSL, HLSL, Metal and others use the same type for all but that has
technical, not mathematical, reasons. Sadly GLM has decided to be source
compatible to GLSL's types and functions (as far as I know), I wish it
was not.

[*] This distinction is often not used in physics because many capital
letters are well known to represent actual physical propertes, like E,
F, M etc, so different notations are used.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Wednesday 22 July 2015 21:40:13 David Haim wrote:
> I'm sorry. but a point is not a vector. the standard must be mathematical
> correct.

The standard is mathematically incorrect by using imprecise floating point.

 809.99f =3D 800.789978f

 =E2=88=83x,y, x =E2=89=A0 0 | x + y =3D y

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--047d7bd9131aeeddfa051b868839
Content-Type: text/plain; charset=UTF-8

@Christopher Horvath , @Miro Knejp
thank you.
so we agree that a point is not a vector, and those 2 should be kept as
separated definitions.
we also agree that the main concern here is the design issue, which
functions should a Point class have as
members, and which should be free-standing ones.
now the question asked, how do I take it on forward? what should I (start)
writing?

@Thiago Macieira
floating point is historical issue, there is no need to keep being
mathematically incorrect in year 2015.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"rtl"><div class=3D"gmail_extra"><div class=3D"gmail_extra" styl=
e=3D"direction:ltr">@Christopher Horvath , @Miro Knejp</div><div class=3D"g=
mail_extra" style=3D"direction:ltr">thank you.</div><div class=3D"gmail_ext=
ra" style=3D"direction:ltr">so we agree that a point is not a vector, and t=
hose 2 should be kept as separated definitions.</div><div class=3D"gmail_ex=
tra" style=3D"direction:ltr">we also agree that the main concern here is th=
e design issue, which functions should a Point class have as=C2=A0</div><di=
v class=3D"gmail_extra" style=3D"direction:ltr">members, and which should b=
e free-standing ones.</div><div class=3D"gmail_extra" style=3D"direction:lt=
r">now the question asked, how do I take it on forward? what should I (star=
t) writing?=C2=A0</div><div class=3D"gmail_extra" style=3D"direction:ltr"><=
br></div><div class=3D"gmail_extra" style=3D"direction:ltr">@Thiago Macieir=
a</div><div class=3D"gmail_extra" style=3D"direction:ltr">floating point is=
 historical issue, there is no need to keep being mathematically incorrect =
in year 2015.</div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bd9131aeeddfa051b868839--

.

On 07/23/2015 10:18 AM, David Haim wrote:

> now the question asked, how do I take it on forward? what should I
> (start) writing?

Start by reviewing existing implementations. For your use-cases it
sounds like the following is a good starting-point (pun intended)

   http://zajo.github.io/boost-qvm/

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

@David Haim,

I definitely agree that points and vectors have different interpretations.
I'm not sure I agree that it is better to represent those differences as
_types_ or through explicit function naming differences.  I can see that
the "c++ way" will probably be that geom::vec<float,3> will be a different
type than geom::point<float,3>.   However, I know from daily use, for years
and years, that this is not the most convenient way to work.

If it were up to me, I'd make a library that was based entirely around free
functions and type traits, and was an amalgam of the tools provided by the
Imath library that is part of Industrial Light & Magic's OpenEXR
distribution (http://www.openexr.com) and Eigen.  This is not unlike the
library I currently work with at Google, and it has proven to be easy and
readable.

I'm happy to work on such a proposal.  I am one of the authors of Alembic (
http://alembic.io), which has become a standard for geometry data exchange
in the visual effects industry.  Alembic did a number of things wrong (we
have P3f and N3f, and it is maddening to use).  However, I'm not as skilled
at standardese as I'd need to be.

Chris



On Thu, Jul 23, 2015 at 1:18 AM, David Haim <dhayim1@gmail.com> wrote:

> @Christopher Horvath , @Miro Knejp
> thank you.
> so we agree that a point is not a vector, and those 2 should be kept as
> separated definitions.
> we also agree that the main concern here is the design issue, which
> functions should a Point class have as
> members, and which should be free-standing ones.
> now the question asked, how do I take it on forward? what should I (start)
> writing?
>
> @Thiago Macieira
> floating point is historical issue, there is no need to keep being
> mathematically incorrect in year 2015.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">@David Haim,<div><br></div><div>I definitely agree that po=
ints and vectors have different interpretations. I&#39;m not sure I agree t=
hat it is better to represent those differences as _types_ or through expli=
cit function naming differences.=C2=A0 I can see that the &quot;c++ way&quo=
t; will probably be that geom::vec&lt;float,3&gt; will be a different type =
than geom::point&lt;float,3&gt;. =C2=A0 However, I know from daily use, for=
 years and years, that this is not the most convenient way to work. =C2=A0<=
/div><div><br></div><div>If it were up to me, I&#39;d make a library that w=
as based entirely around free functions and type traits, and was an amalgam=
 of the tools provided by the Imath library that is part of Industrial Ligh=
t &amp; Magic&#39;s OpenEXR distribution (<a href=3D"http://www.openexr.com=
">http://www.openexr.com</a>) and Eigen.=C2=A0 This is not unlike the libra=
ry I currently work with at Google, and it has proven to be easy and readab=
le.</div><div><br></div><div>I&#39;m happy to work on such a proposal.=C2=
=A0 I am one of the authors of Alembic (<a href=3D"http://alembic.io">http:=
//alembic.io</a>), which has become a standard for geometry data exchange i=
n the visual effects industry.=C2=A0 Alembic did a number of things wrong (=
we have P3f and N3f, and it is maddening to use).=C2=A0 However, I&#39;m no=
t as skilled at standardese as I&#39;d need to be.</div><div><br></div><div=
>Chris</div><div><br></div><div><br></div></div><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote">On Thu, Jul 23, 2015 at 1:18 AM, David Haim =
<span dir=3D"ltr">&lt;<a href=3D"mailto:dhayim1@gmail.com" target=3D"_blank=
">dhayim1@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"rtl"><div class=3D"gmail_extra"><div class=3D"gmail_extra" sty=
le=3D"direction:ltr">@Christopher Horvath , @Miro Knejp</div><div class=3D"=
gmail_extra" style=3D"direction:ltr">thank you.</div><div class=3D"gmail_ex=
tra" style=3D"direction:ltr">so we agree that a point is not a vector, and =
those 2 should be kept as separated definitions.</div><div class=3D"gmail_e=
xtra" style=3D"direction:ltr">we also agree that the main concern here is t=
he design issue, which functions should a Point class have as=C2=A0</div><d=
iv class=3D"gmail_extra" style=3D"direction:ltr">members, and which should =
be free-standing ones.</div><div class=3D"gmail_extra" style=3D"direction:l=
tr">now the question asked, how do I take it on forward? what should I (sta=
rt) writing?=C2=A0</div><div class=3D"gmail_extra" style=3D"direction:ltr">=
<br></div><div class=3D"gmail_extra" style=3D"direction:ltr">@Thiago Maciei=
ra</div><div class=3D"gmail_extra" style=3D"direction:ltr">floating point i=
s historical issue, there is no need to keep being mathematically incorrect=
 in year 2015.</div></div></div><span class=3D"">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></span>
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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c11f3ea46d16051b8bc70b--

.

------=_Part_217_1199727764.1437717154592
Content-Type: multipart/alternative;
 boundary="----=_Part_218_213498592.1437717154592"

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

On Wednesday, 22 July 2015 21:19:24 UTC+2, Christopher Horvath wrote:
>
> This is a very difficult design problem, because there's a question of=20
> semantics and transformations.
>
> A point is transformed differently by a matrix than a vector (the=20
> difference between points), and each of these are transformed differently=
=20
> than a normal.  In the Renderman Shading Language, these correspond to=20
> three different functions, "transform", "vtransform", and "ntransform".
>
> Some C++ geometry libraries have made strong type distinctions -=20
> differentiating "point3" from "vector3" from "normal3", and so on, allowi=
ng=20
> them to overload the arithmetic operators.  Having used several such=20
> libraries, they're generally frustrating to use because the data is usual=
ly=20
> stored simply as "float3" or "double3" or "half3", and the constant=20
> static_cast or reinterpret_casting, or worse, new object creation, is=20
> tedious. =20
>
> A library I've been using recently, built on top of Eigen and a separate=
=20
> math library as an alternative, doesn't overload arthmetic operators at=
=20
> all, but instead uses explicit free functions for readability - so you ca=
n=20
> say, transform_point(float4x4, float3), transform_vector(float4x4, float3=
),=20
> etc.  This also makes it easy to templatize the arguments to these free=
=20
> functions to any type which meets the minimum requirements.  Many users o=
f=20
> such an approach, however, find the lack of arithmetic operator overloads=
=20
> deeply annoying.
>
> Yet another library I've had to work with recently simply disallows=20
> transforming a float3 by a mat44, requiring the user to convert the float=
3=20
> into a homogenous point as a float4.  Then, transform_point becomes=20
> operator*(mat44, float4{float3, 1}), and transform_vector becomes=20
> operator*(mat44, float4{float3, 0}), and transform_normal becomes=20
> operator*(inverse(transpose(mat44)), float4{float3, 0}).  This is tedious=
=20
> in its own way.
>
> Eigen goes to great (and sometimes frustrating) extents to create odd=20
> intermediate types that allow for compile-time removal of unnecessary=20
> temporaries.  For example, if a matrix is orthonormal, then the operation=
=20
> inverse(transpose(matrix)) is a no-op, and this can be detected at compil=
e=20
> time using a traits object on things like rigid transformations.  This is=
=20
> useful with very large dimensions, but has difficulties that the=20
> intermediate types sometimes produce unexpected results when using "auto"=
..
>
> I would imagine a standardization attempt at such a library would be=20
> deeply contentious, but probably valuable if consensus could be reached. =
 I=20
> hope that members of the graphics and games communities would be involved=
..
>
> Chris
>
>
>
> On Wed, Jul 22, 2015 at 10:29 AM, Matthew Woehlke <mwoehlk...@gmail.com=
=20
> <javascript:>> wrote:
>
>> On 2015-07-22 13:19, David Haim wrote:
>> > 2) After digging a bit in the Eigen library, I couldn't find an explic=
it
>> > Point class, are you sure they have implemented such class?
>>
>> Yes and no; see the vector class(es). There's not much=C2=B9 benefit to
>> defining a point class vs. a vector class, and a general vector has more
>> uses. A "point" is just a vector offset from the origin, which is merely
>> a semantic distinction; it's fairly common to treat "points" as a
>> semantic subset of "vectors".
>>
>> (=C2=B9 Actually, offhand I can't think of *any* benefit except maybe ty=
pe
>> distinction, and strong typedefs would make that moot. I feel like
>> *maybe* there is some benefit, but I can't think what.)
>>
>> --
>> Matthew
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>
On Wednesday, 22 July 2015 21:19:24 UTC+2, Christopher Horvath wrote:
>
> This is a very difficult design problem, because there's a question of=20
> semantics and transformations.
>
> A point is transformed differently by a matrix than a vector (the=20
> difference between points), and each of these are transformed differently=
=20
> than a normal.  In the Renderman Shading Language, these correspond to=20
> three different functions, "transform", "vtransform", and "ntransform".
>
> Some C++ geometry libraries have made strong type distinctions -=20
> differentiating "point3" from "vector3" from "normal3", and so on, allowi=
ng=20
> them to overload the arithmetic operators.  Having used several such=20
> libraries, they're generally frustrating to use because the data is usual=
ly=20
> stored simply as "float3" or "double3" or "half3", and the constant=20
> static_cast or reinterpret_casting, or worse, new object creation, is=20
> tedious. =20
>
> A library I've been using recently, built on top of Eigen and a separate=
=20
> math library as an alternative, doesn't overload arthmetic operators at=
=20
> all, but instead uses explicit free functions for readability - so you ca=
n=20
> say, transform_point(float4x4, float3), transform_vector(float4x4, float3=
),=20
> etc.  This also makes it easy to templatize the arguments to these free=
=20
> functions to any type which meets the minimum requirements.  Many users o=
f=20
> such an approach, however, find the lack of arithmetic operator overloads=
=20
> deeply annoying.
>
> Yet another library I've had to work with recently simply disallows=20
> transforming a float3 by a mat44, requiring the user to convert the float=
3=20
> into a homogenous point as a float4.  Then, transform_point becomes=20
> operator*(mat44, float4{float3, 1}), and transform_vector becomes=20
> operator*(mat44, float4{float3, 0}), and transform_normal becomes=20
> operator*(inverse(transpose(mat44)), float4{float3, 0}).  This is tedious=
=20
> in its own way.
>
> Eigen goes to great (and sometimes frustrating) extents to create odd=20
> intermediate types that allow for compile-time removal of unnecessary=20
> temporaries.  For example, if a matrix is orthonormal, then the operation=
=20
> inverse(transpose(matrix)) is a no-op, and this can be detected at compil=
e=20
> time using a traits object on things like rigid transformations.  This is=
=20
> useful with very large dimensions, but has difficulties that the=20
> intermediate types sometimes produce unexpected results when using "auto"=
..
>
> I would imagine a standardization attempt at such a library would be=20
> deeply contentious, but probably valuable if consensus could be reached. =
 I=20
> hope that members of the graphics and games communities would be involved=
..
>
> Chris
>
>
>
> On Wed, Jul 22, 2015 at 10:29 AM, Matthew Woehlke <mwoehlk...@gmail.com=
=20
> <javascript:>> wrote:
>
>> On 2015-07-22 13:19, David Haim wrote:
>> > 2) After digging a bit in the Eigen library, I couldn't find an explic=
it
>> > Point class, are you sure they have implemented such class?
>>
>> Yes and no; see the vector class(es). There's not much=C2=B9 benefit to
>> defining a point class vs. a vector class, and a general vector has more
>> uses. A "point" is just a vector offset from the origin, which is merely
>> a semantic distinction; it's fairly common to treat "points" as a
>> semantic subset of "vectors".
>>
>> (=C2=B9 Actually, offhand I can't think of *any* benefit except maybe ty=
pe
>> distinction, and strong typedefs would make that moot. I feel like
>> *maybe* there is some benefit, but I can't think what.)
>>
>> --
>> Matthew
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>
On Wednesday, 22 July 2015 21:19:24 UTC+2, Christopher Horvath wrote:
>
> This is a very difficult design problem, because there's a question of=20
> semantics and transformations.
>
> A point is transformed differently by a matrix than a vector (the=20
> difference between points), and each of these are transformed differently=
=20
> than a normal.  In the Renderman Shading Language, these correspond to=20
> three different functions, "transform", "vtransform", and "ntransform".
>
> Some C++ geometry libraries have made strong type distinctions -=20
> differentiating "point3" from "vector3" from "normal3", and so on, allowi=
ng=20
> them to overload the arithmetic operators.  Having used several such=20
> libraries, they're generally frustrating to use because the data is usual=
ly=20
> stored simply as "float3" or "double3" or "half3", and the constant=20
> static_cast or reinterpret_casting, or worse, new object creation, is=20
> tedious. =20
>
> A library I've been using recently, built on top of Eigen and a separate=
=20
> math library as an alternative, doesn't overload arthmetic operators at=
=20
> all, but instead uses explicit free functions for readability - so you ca=
n=20
> say, transform_point(float4x4, float3), transform_vector(float4x4, float3=
),=20
> etc.  This also makes it easy to templatize the arguments to these free=
=20
> functions to any type which meets the minimum requirements.  Many users o=
f=20
> such an approach, however, find the lack of arithmetic operator overloads=
=20
> deeply annoying.
>
> Yet another library I've had to work with recently simply disallows=20
> transforming a float3 by a mat44, requiring the user to convert the float=
3=20
> into a homogenous point as a float4.  Then, transform_point becomes=20
> operator*(mat44, float4{float3, 1}), and transform_vector becomes=20
> operator*(mat44, float4{float3, 0}), and transform_normal becomes=20
> operator*(inverse(transpose(mat44)), float4{float3, 0}).  This is tedious=
=20
> in its own way.
>
> Eigen goes to great (and sometimes frustrating) extents to create odd=20
> intermediate types that allow for compile-time removal of unnecessary=20
> temporaries.  For example, if a matrix is orthonormal, then the operation=
=20
> inverse(transpose(matrix)) is a no-op, and this can be detected at compil=
e=20
> time using a traits object on things like rigid transformations.  This is=
=20
> useful with very large dimensions, but has difficulties that the=20
> intermediate types sometimes produce unexpected results when using "auto"=
..
>
> I would imagine a standardization attempt at such a library would be=20
> deeply contentious, but probably valuable if consensus could be reached. =
 I=20
> hope that members of the graphics and games communities would be involved=
..
>
> Chris
>
>
>
> On Wed, Jul 22, 2015 at 10:29 AM, Matthew Woehlke <mwoehlk...@gmail.com=
=20
> <javascript:>> wrote:
>
>> On 2015-07-22 13:19, David Haim wrote:
>> > 2) After digging a bit in the Eigen library, I couldn't find an explic=
it
>> > Point class, are you sure they have implemented such class?
>>
>> Yes and no; see the vector class(es). There's not much=C2=B9 benefit to
>> defining a point class vs. a vector class, and a general vector has more
>> uses. A "point" is just a vector offset from the origin, which is merely
>> a semantic distinction; it's fairly common to treat "points" as a
>> semantic subset of "vectors".
>>
>> (=C2=B9 Actually, offhand I can't think of *any* benefit except maybe ty=
pe
>> distinction, and strong typedefs would make that moot. I feel like
>> *maybe* there is some benefit, but I can't think what.)
>>
>> --
>> Matthew
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>
Now that we are getting concepts (lite), would it be useful to make a Point=
=20
concept instead of (or in addition to) a concrete type? Look at=20
Boost.Geometry for an example of a concepts-based geometry library.=20
Concepts and generics makes it very easy to customise the behaviour, write=
=20
generic algorithms etc. Also, existing libraries would be able to use the=
=20
(standard) point algorithms if they adhere to the concept, and would not=20
need to change their point type(s)...=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

On Wednesday, 22 July 2015 21:19:24 UTC+2, Christopher Horvath  wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">This is a very dif=
ficult design problem, because there&#39;s a question of semantics and tran=
sformations.<div><br></div><div>A point is transformed differently by a mat=
rix than a vector (the difference between points), and each of these are tr=
ansformed differently than a normal.=C2=A0 In the Renderman Shading Languag=
e, these correspond to three different functions, &quot;transform&quot;, &q=
uot;vtransform&quot;, and &quot;ntransform&quot;.</div><div><br></div><div>=
Some C++ geometry libraries have made strong type distinctions - differenti=
ating &quot;point3&quot; from &quot;vector3&quot; from &quot;normal3&quot;,=
 and so on, allowing them to overload the arithmetic operators.=C2=A0 Havin=
g used several such libraries, they&#39;re generally frustrating to use bec=
ause the data is usually stored simply as &quot;float3&quot; or &quot;doubl=
e3&quot; or &quot;half3&quot;, and the constant static_cast or reinterpret_=
casting, or worse, new object creation, is tedious. =C2=A0</div><div><br></=
div><div>A library I&#39;ve been using recently, built on top of Eigen and =
a separate math library as an alternative, doesn&#39;t overload arthmetic o=
perators at all, but instead uses explicit free functions for readability -=
 so you can say, transform_point(float4x4, float3), transform_vector(float4=
x4, float3), etc.=C2=A0 This also makes it easy to templatize the arguments=
 to these free functions to any type which meets the minimum requirements.=
=C2=A0 Many users of such an approach, however, find the lack of arithmetic=
 operator overloads deeply annoying.</div><div><br></div><div>Yet another l=
ibrary I&#39;ve had to work with recently simply disallows transforming a f=
loat3 by a mat44, requiring the user to convert the float3 into a homogenou=
s point as a float4.=C2=A0 Then, transform_point becomes operator*(mat44, f=
loat4{float3, 1}), and transform_vector becomes operator*(mat44, float4{flo=
at3, 0}), and transform_normal becomes operator*(inverse(transpose(mat44)),=
 float4{float3, 0}).=C2=A0 This is tedious in its own way.</div><div><br></=
div><div>Eigen goes to great (and sometimes frustrating) extents to create =
odd intermediate types that allow for compile-time removal of unnecessary t=
emporaries.=C2=A0 For example, if a matrix is orthonormal, then the operati=
on inverse(transpose(matrix)) is a no-op, and this can be detected at compi=
le time using a traits object on things like rigid transformations.=C2=A0 T=
his is useful with very large dimensions, but has difficulties that the int=
ermediate types sometimes produce unexpected results when using &quot;auto&=
quot;.</div><div><br></div><div>I would imagine a standardization attempt a=
t such a library would be deeply contentious, but probably valuable if cons=
ensus could be reached.=C2=A0 I hope that members of the graphics and games=
 communities would be involved.</div><div><br></div><div>Chris</div><div><b=
r></div><div><div><br></div></div></div><div><br><div class=3D"gmail_quote"=
>On Wed, Jul 22, 2015 at 10:29 AM, Matthew Woehlke <span dir=3D"ltr">&lt;<a=
 href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;ja=
vascript:&#39;;return true;">mwoehlk...@gmail.com</a>&gt;</span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><span>On 2015-07-22 13:19, David Haim wrote:=
<br>
&gt; 2) After digging a bit in the Eigen library, I couldn&#39;t find an ex=
plicit<br>
&gt; Point class, are you sure they have implemented such class?<br>
<br>
</span>Yes and no; see the vector class(es). There&#39;s not much=C2=B9 ben=
efit to<br>
defining a point class vs. a vector class, and a general vector has more<br=
>
uses. A &quot;point&quot; is just a vector offset from the origin, which is=
 merely<br>
a semantic distinction; it&#39;s fairly common to treat &quot;points&quot; =
as a<br>
semantic subset of &quot;vectors&quot;.<br>
<br>
(=C2=B9 Actually, offhand I can&#39;t think of *any* benefit except maybe t=
ype<br>
distinction, and strong typedefs would make that moot. I feel like<br>
*maybe* there is some benefit, but I can&#39;t think what.)<br>
<br>
--<br>
Matthew<br>
<br>
--<br>
<br>
---<br>
<span>You received this message because you are subscribed to the Google Gr=
oups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
</span>To unsubscribe from this group and stop receiving emails from it, se=
nd an email to <a href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" o=
nmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"th=
is.href=3D&#39;javascript:&#39;;return true;">std-proposal...@isocpp.org</a=
>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;retur=
n true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">std-pr.=
...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=
=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.or=
g/group/std-proposals/&#39;;return true;">http://groups.google.com/a/isocpp=
..org/group/std-proposals/</a>.<br>
</blockquote></div><br></div>
</blockquote><br>On Wednesday, 22 July 2015 21:19:24 UTC+2, Christopher Hor=
vath  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">T=
his is a very difficult design problem, because there&#39;s a question of s=
emantics and transformations.<div><br></div><div>A point is transformed dif=
ferently by a matrix than a vector (the difference between points), and eac=
h of these are transformed differently than a normal.=C2=A0 In the Renderma=
n Shading Language, these correspond to three different functions, &quot;tr=
ansform&quot;, &quot;vtransform&quot;, and &quot;ntransform&quot;.</div><di=
v><br></div><div>Some C++ geometry libraries have made strong type distinct=
ions - differentiating &quot;point3&quot; from &quot;vector3&quot; from &qu=
ot;normal3&quot;, and so on, allowing them to overload the arithmetic opera=
tors.=C2=A0 Having used several such libraries, they&#39;re generally frust=
rating to use because the data is usually stored simply as &quot;float3&quo=
t; or &quot;double3&quot; or &quot;half3&quot;, and the constant static_cas=
t or reinterpret_casting, or worse, new object creation, is tedious. =C2=A0=
</div><div><br></div><div>A library I&#39;ve been using recently, built on =
top of Eigen and a separate math library as an alternative, doesn&#39;t ove=
rload arthmetic operators at all, but instead uses explicit free functions =
for readability - so you can say, transform_point(float4x4, float3), transf=
orm_vector(float4x4, float3), etc.=C2=A0 This also makes it easy to templat=
ize the arguments to these free functions to any type which meets the minim=
um requirements.=C2=A0 Many users of such an approach, however, find the la=
ck of arithmetic operator overloads deeply annoying.</div><div><br></div><d=
iv>Yet another library I&#39;ve had to work with recently simply disallows =
transforming a float3 by a mat44, requiring the user to convert the float3 =
into a homogenous point as a float4.=C2=A0 Then, transform_point becomes op=
erator*(mat44, float4{float3, 1}), and transform_vector becomes operator*(m=
at44, float4{float3, 0}), and transform_normal becomes operator*(inverse(tr=
anspose(mat44)), float4{float3, 0}).=C2=A0 This is tedious in its own way.<=
/div><div><br></div><div>Eigen goes to great (and sometimes frustrating) ex=
tents to create odd intermediate types that allow for compile-time removal =
of unnecessary temporaries.=C2=A0 For example, if a matrix is orthonormal, =
then the operation inverse(transpose(matrix)) is a no-op, and this can be d=
etected at compile time using a traits object on things like rigid transfor=
mations.=C2=A0 This is useful with very large dimensions, but has difficult=
ies that the intermediate types sometimes produce unexpected results when u=
sing &quot;auto&quot;.</div><div><br></div><div>I would imagine a standardi=
zation attempt at such a library would be deeply contentious, but probably =
valuable if consensus could be reached.=C2=A0 I hope that members of the gr=
aphics and games communities would be involved.</div><div><br></div><div>Ch=
ris</div><div><br></div><div><div><br></div></div></div><div><br><div class=
=3D"gmail_quote">On Wed, Jul 22, 2015 at 10:29 AM, Matthew Woehlke <span di=
r=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" on=
mousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"thi=
s.href=3D&#39;javascript:&#39;;return true;">mwoehlk...@gmail.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><span>On 2015-07-22 13:19, D=
avid Haim wrote:<br>
&gt; 2) After digging a bit in the Eigen library, I couldn&#39;t find an ex=
plicit<br>
&gt; Point class, are you sure they have implemented such class?<br>
<br>
</span>Yes and no; see the vector class(es). There&#39;s not much=C2=B9 ben=
efit to<br>
defining a point class vs. a vector class, and a general vector has more<br=
>
uses. A &quot;point&quot; is just a vector offset from the origin, which is=
 merely<br>
a semantic distinction; it&#39;s fairly common to treat &quot;points&quot; =
as a<br>
semantic subset of &quot;vectors&quot;.<br>
<br>
(=C2=B9 Actually, offhand I can&#39;t think of *any* benefit except maybe t=
ype<br>
distinction, and strong typedefs would make that moot. I feel like<br>
*maybe* there is some benefit, but I can&#39;t think what.)<br>
<br>
--<br>
Matthew<br>
<br>
--<br>
<br>
---<br>
<span>You received this message because you are subscribed to the Google Gr=
oups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
</span>To unsubscribe from this group and stop receiving emails from it, se=
nd an email to <a href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" o=
nmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"th=
is.href=3D&#39;javascript:&#39;;return true;">std-proposal...@isocpp.org</a=
>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;retur=
n true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">std-pr.=
...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=
=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.or=
g/group/std-proposals/&#39;;return true;">http://groups.google.com/a/isocpp=
..org/group/std-proposals/</a>.<br>
</blockquote></div><br></div>
</blockquote><br>On Wednesday, 22 July 2015 21:19:24 UTC+2, Christopher Hor=
vath  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">T=
his is a very difficult design problem, because there&#39;s a question of s=
emantics and transformations.<div><br></div><div>A point is transformed dif=
ferently by a matrix than a vector (the difference between points), and eac=
h of these are transformed differently than a normal.=C2=A0 In the Renderma=
n Shading Language, these correspond to three different functions, &quot;tr=
ansform&quot;, &quot;vtransform&quot;, and &quot;ntransform&quot;.</div><di=
v><br></div><div>Some C++ geometry libraries have made strong type distinct=
ions - differentiating &quot;point3&quot; from &quot;vector3&quot; from &qu=
ot;normal3&quot;, and so on, allowing them to overload the arithmetic opera=
tors.=C2=A0 Having used several such libraries, they&#39;re generally frust=
rating to use because the data is usually stored simply as &quot;float3&quo=
t; or &quot;double3&quot; or &quot;half3&quot;, and the constant static_cas=
t or reinterpret_casting, or worse, new object creation, is tedious. =C2=A0=
</div><div><br></div><div>A library I&#39;ve been using recently, built on =
top of Eigen and a separate math library as an alternative, doesn&#39;t ove=
rload arthmetic operators at all, but instead uses explicit free functions =
for readability - so you can say, transform_point(float4x4, float3), transf=
orm_vector(float4x4, float3), etc.=C2=A0 This also makes it easy to templat=
ize the arguments to these free functions to any type which meets the minim=
um requirements.=C2=A0 Many users of such an approach, however, find the la=
ck of arithmetic operator overloads deeply annoying.</div><div><br></div><d=
iv>Yet another library I&#39;ve had to work with recently simply disallows =
transforming a float3 by a mat44, requiring the user to convert the float3 =
into a homogenous point as a float4.=C2=A0 Then, transform_point becomes op=
erator*(mat44, float4{float3, 1}), and transform_vector becomes operator*(m=
at44, float4{float3, 0}), and transform_normal becomes operator*(inverse(tr=
anspose(mat44)), float4{float3, 0}).=C2=A0 This is tedious in its own way.<=
/div><div><br></div><div>Eigen goes to great (and sometimes frustrating) ex=
tents to create odd intermediate types that allow for compile-time removal =
of unnecessary temporaries.=C2=A0 For example, if a matrix is orthonormal, =
then the operation inverse(transpose(matrix)) is a no-op, and this can be d=
etected at compile time using a traits object on things like rigid transfor=
mations.=C2=A0 This is useful with very large dimensions, but has difficult=
ies that the intermediate types sometimes produce unexpected results when u=
sing &quot;auto&quot;.</div><div><br></div><div>I would imagine a standardi=
zation attempt at such a library would be deeply contentious, but probably =
valuable if consensus could be reached.=C2=A0 I hope that members of the gr=
aphics and games communities would be involved.</div><div><br></div><div>Ch=
ris</div><div><br></div><div><div><br></div></div></div><div><br><div class=
=3D"gmail_quote">On Wed, Jul 22, 2015 at 10:29 AM, Matthew Woehlke <span di=
r=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" on=
mousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"thi=
s.href=3D&#39;javascript:&#39;;return true;">mwoehlk...@gmail.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><span>On 2015-07-22 13:19, D=
avid Haim wrote:<br>
&gt; 2) After digging a bit in the Eigen library, I couldn&#39;t find an ex=
plicit<br>
&gt; Point class, are you sure they have implemented such class?<br>
<br>
</span>Yes and no; see the vector class(es). There&#39;s not much=C2=B9 ben=
efit to<br>
defining a point class vs. a vector class, and a general vector has more<br=
>
uses. A &quot;point&quot; is just a vector offset from the origin, which is=
 merely<br>
a semantic distinction; it&#39;s fairly common to treat &quot;points&quot; =
as a<br>
semantic subset of &quot;vectors&quot;.<br>
<br>
(=C2=B9 Actually, offhand I can&#39;t think of *any* benefit except maybe t=
ype<br>
distinction, and strong typedefs would make that moot. I feel like<br>
*maybe* there is some benefit, but I can&#39;t think what.)<br>
<br>
--<br>
Matthew<br>
<br>
--<br>
<br>
---<br>
<span>You received this message because you are subscribed to the Google Gr=
oups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
</span>To unsubscribe from this group and stop receiving emails from it, se=
nd an email to <a href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" o=
nmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"th=
is.href=3D&#39;javascript:&#39;;return true;">std-proposal...@isocpp.org</a=
>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;retur=
n true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">std-pr.=
...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=
=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.or=
g/group/std-proposals/&#39;;return true;">http://groups.google.com/a/isocpp=
..org/group/std-proposals/</a>.<br>
</blockquote></div><br></div></blockquote><div><br>Now that we are getting =
concepts (lite), would it be useful to make a Point concept instead of (or =
in addition to) a concrete type? Look at Boost.Geometry for an example of a=
 concepts-based geometry library. Concepts and generics makes it very easy =
to customise the behaviour, write generic algorithms etc. Also, existing li=
braries would be able to use the (standard) point algorithms if they adhere=
 to the concept, and would not need to change their point type(s)... <br></=
div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_218_213498592.1437717154592--
------=_Part_217_1199727764.1437717154592--

.