Topic: How about *^ for a exponentiation operator
Author: Francis Smit <grizzlysmit@gmail.com>
Date: Fri, 19 Jul 2013 20:38:53 +1000
Raw View
many of us I think would like an exponentiation operator and obviously
** is not viable in C++ as that could be confused with a * (*b) where b
is is a pointer but a *^ b should not compile at the moment unless I am
very much mistaken, so it should be fine for this use.
--
.~. In my life God comes first....
/V\ but Linux is pretty high after that :-D
/( )\ Francis (Grizzly) Smit
^^-^^ http://www.smit.id.au/
--
---
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/.
.
Author: Maurice Bos <m-ou.se@m-ou.se>
Date: Fri, 19 Jul 2013 04:06:54 -0700 (PDT)
Raw View
------=_Part_434_27147117.1374232014792
Content-Type: text/plain; charset=ISO-8859-1
Something very similar has been discussed before:
https://groups.google.com/d/msg/comp.lang.c++/g8BxAFmNykc/TDwgWgDenqEJ
Op vrijdag 19 juli 2013 12:38:53 UTC+2 schreef Francis Grizzly Smit het
volgende:
>
> many of us I think would like an exponentiation operator and obviously
> ** is not viable in C++ as that could be confused with a * (*b) where b
> is is a pointer but a *^ b should not compile at the moment unless I am
> very much mistaken, so it should be fine for this use.
>
>
>
> --
>
>
> .~. In my life God comes first....
> /V\ but Linux is pretty high after that :-D
> /( )\ Francis (Grizzly) Smit
> ^^-^^ http://www.smit.id.au/
>
>
--
---
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_434_27147117.1374232014792
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Something very similar has been discussed before: https://groups.google.com=
/d/msg/comp.lang.c++/g8BxAFmNykc/TDwgWgDenqEJ<br><br>Op vrijdag 19 juli 201=
3 12:38:53 UTC+2 schreef Francis Grizzly Smit het volgende:<blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;">many of us I think would like an exponentiatio=
n operator and obviously=20
<br>** is not viable in C++ as that could be confused with a * (*b) where b=
=20
<br>is is a pointer but a *^ b should not compile at the moment unless I am=
=20
<br>very much mistaken, so it should be fine for this use.
<br>
<br>
<br>
<br>--=20
<br>
<br>
<br> .~. In my life God comes first....
<br> /V\ but Linux is pretty high a=
fter that :-D
<br> /( )\ Francis (Grizzly) Smit
<br> ^^-^^ <a href=3D"http://www.smit.id.au/" target=3D"=
_blank">http://www.smit.id.au/</a>
<br>
<br></blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
<br />
<br />
------=_Part_434_27147117.1374232014792--
.
Author: Francis Smit <grizzlysmit@gmail.com>
Date: Sat, 20 Jul 2013 00:22:33 +1000
Raw View
This is a multi-part message in MIME format.
--------------080500050102010200020702
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 19/07/13 21:06, Maurice Bos wrote:
> Something very similar has been discussed before:
> https://groups.google.com/d/msg/comp.lang.c++/g8BxAFmNykc/TDwgWgDenqEJ
sorta similar but my proposal doesn't involve the same sort of confusing
looking syntax ! is already not so it's not a good choice for
exponentiation if we where to give ! another task I would suggest
making it a a postfix factorial operator certainly not a a binary operator.
>
> Op vrijdag 19 juli 2013 12:38:53 UTC+2 schreef Francis Grizzly Smit
> het volgende:
>
> many of us I think would like an exponentiation operator and
> obviously
> ** is not viable in C++ as that could be confused with a * (*b)
> where b
> is is a pointer but a *^ b should not compile at the moment unless
> I am
> very much mistaken, so it should be fine for this use.
>
>
--
.~. In my life God comes first....
/V\ but Linux is pretty high after that :-D
/( )\ Francis (Grizzly) Smit
^^-^^ http://www.smit.id.au/
--
---
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/.
--------------080500050102010200020702
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 19/07/13 21:06, Maurice Bos wrote:<br>
</div>
<blockquote
cite="mid:9bebe8bc-05f9-4432-abf8-6ba0bcf00d85@isocpp.org"
type="cite">Something very similar has been discussed before:
<a class="moz-txt-link-freetext" href="https://groups.google.com/d/msg/comp.lang.c++/g8BxAFmNykc/TDwgWgDenqEJ">https://groups.google.com/d/msg/comp.lang.c++/g8BxAFmNykc/TDwgWgDenqEJ</a><br>
</blockquote>
sorta similar but my proposal doesn't involve the same sort of
confusing looking syntax ! is already not so it's not a good choice
for exponentiation if we where to give ! another task I would
suggest making it a a postfix factorial operator certainly not a a
binary operator. <br>
<blockquote
cite="mid:9bebe8bc-05f9-4432-abf8-6ba0bcf00d85@isocpp.org"
type="cite"><br>
Op vrijdag 19 juli 2013 12:38:53 UTC+2 schreef Francis Grizzly
Smit het volgende:
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">many of us
I think would like an exponentiation operator and obviously <br>
** is not viable in C++ as that could be confused with a * (*b)
where b <br>
is is a pointer but a *^ b should not compile at the moment
unless I am <br>
very much mistaken, so it should be fine for this use.
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
<pre><tt>
.~. In my life God comes first....
/V\ but Linux is pretty high after that :-D
/( )\ Francis (Grizzly) Smit
^^-^^ <a class="moz-txt-link-freetext" href="http://www.smit.id.au/">http://www.smit.id.au/</a>
</tt><pre>
</pre></pre>
</div>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
<br />
<br />
--------------080500050102010200020702--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 19 Jul 2013 17:39:05 +0300
Raw View
--047d7b6dcf52e6484e04e1de49fe
Content-Type: text/plain; charset=ISO-8859-1
On 19 July 2013 17:22, Francis Smit <grizzlysmit@gmail.com> wrote:
> On 19/07/13 21:06, Maurice Bos wrote:
>
> Something very similar has been discussed before:
> https://groups.google.com/d/msg/comp.lang.c++/g8BxAFmNykc/TDwgWgDenqEJ
>
> sorta similar but my proposal doesn't involve the same sort of confusing
> looking syntax ! is already not so it's not a good choice for
> exponentiation if we where to give ! another task I would suggest making
> it a a postfix factorial operator certainly not a a binary operator.
>
I don't consider exponentiation important enough that we should try to add
it as an afterthought.
--
---
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/.
--047d7b6dcf52e6484e04e1de49fe
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 19 July 2013 17:22, Francis Smit <span dir=3D"ltr"><<a href=
=3D"mailto:grizzlysmit@gmail.com" target=3D"_blank">grizzlysmit@gmail.com</=
a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><div class=3D"im">
<div>On 19/07/13 21:06, Maurice Bos wrote:<br>
</div>
<blockquote type=3D"cite">Something very similar has been discussed bef=
ore:
<a href=3D"https://groups.google.com/d/msg/comp.lang.c++/g8BxAFmNykc/=
TDwgWgDenqEJ" target=3D"_blank">https://groups.google.com/d/msg/comp.lang.c=
++/g8BxAFmNykc/TDwgWgDenqEJ</a><br>
</blockquote></div>
sorta similar but my proposal doesn't involve the same sort of
confusing looking syntax ! is already not so it's not a good choice
for exponentiation if we where to give ! another task I would
suggest =A0 making it a a postfix factorial operator certainly not a a
binary operator. <br></div></blockquote><div><br></div><div>I don't=
consider exponentiation important enough that we should try to add it as a=
n afterthought. <br></div><div>=A0</div></div><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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
<br />
<br />
--047d7b6dcf52e6484e04e1de49fe--
.
Author: Mikhail Semenov <mikhailsemenov1957@gmail.com>
Date: Fri, 19 Jul 2013 19:25:50 +0100
Raw View
--f46d043be228c930d704e1e1746c
Content-Type: text/plain; charset=ISO-8859-1
How about using ^^ ?
For example:
2^^5
x^^y
f(x)^^g(z)
On 19 July 2013 11:38, Francis Smit <grizzlysmit@gmail.com> wrote:
> many of us I think would like an exponentiation operator and obviously **
> is not viable in C++ as that could be confused with a * (*b) where b is is
> a pointer but a *^ b should not compile at the moment unless I am very much
> mistaken, so it should be fine for this use.
>
>
>
> --
>
>
> .~. In my life God comes first....
> /V\ but Linux is pretty high after that :-D
> /( )\ Francis (Grizzly) Smit
> ^^-^^ http://www.smit.id.au/
>
> --
>
> --- 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<std-proposals%2Bunsubscribe@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/ <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/.
--f46d043be228c930d704e1e1746c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>How about using ^^=A0 ?</div><div>For example: </div>=
<div>2^^5 </div><div>x^^y</div><div>f(x)^^g(z)</div><div>=A0</div><div>=A0<=
/div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On=
19 July 2013 11:38, Francis Smit <span dir=3D"ltr"><<a href=3D"mailto:g=
rizzlysmit@gmail.com" target=3D"_blank">grizzlysmit@gmail.com</a>></span=
> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">many of us I think would like an exponentiat=
ion operator and obviously ** is not viable in C++ as that could be confuse=
d with a * (*b) where b is is a pointer but a *^ b should not compile at th=
e moment unless I am very much mistaken, so it should be fine for this use.=
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
<br>
<br>
-- <br>
<br>
<br>
=A0 .~. =A0 =A0 In my life God comes first....<br>
=A0 /V\ =A0 =A0 =A0 =A0 but Linux is pretty high after that :-D<br>
=A0/( )\ =A0 =A0Francis (Grizzly) Smit<br>
=A0^^-^^ =A0 =A0<a href=3D"http://www.smit.id.au/" target=3D"_blank">http:/=
/www.smit.id.au/</a><br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@<u></u>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/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
<br>
<br>
</font></span></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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
<br />
<br />
--f46d043be228c930d704e1e1746c--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 19 Jul 2013 13:31:24 -0500
Raw View
--047d7b67302416b44004e1e18b65
Content-Type: text/plain; charset=ISO-8859-1
On 19 July 2013 09:39, Ville Voutilainen <ville.voutilainen@gmail.com>wrote:
>
> I don't consider exponentiation important enough that we should try to add
> it as an afterthought.
>
+1.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
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/.
--047d7b67302416b44004e1e18b65
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 19 July 2013 09:39, Ville Voutilainen <span dir=3D"ltr"><<a href=3D"m=
ailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmai=
l.com</a>></span> wrote:<br><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<div>I don't consider exponentiation important enough that we should tr=
y to add it as an afterthought. <br></div></div></div></div></blockquote><d=
iv>
<br>+1. <br></div></div><br clear=3D"all"><br>-- <br>=A0Nevin ":-)&quo=
t; Liber=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"=
_blank">nevin@eviloverlord.com</a>>=A0 (847) 691-1404
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
<br />
<br />
--047d7b67302416b44004e1e18b65--
.
Author: Francis Smit <grizzlysmit@gmail.com>
Date: Sat, 20 Jul 2013 08:02:39 +1000
Raw View
This is a multi-part message in MIME format.
--------------020606040800020201020209
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 20/07/13 04:25, Mikhail Semenov wrote:
> How about using ^^ ?
> For example:
> 2^^5
> x^^y
> f(x)^^g(z)
to me ^^ looks like it should be logical xor should we ever choose to
add that I was looking for something completely free and *^ fit's that
bill nicely, further the * in it suggests multiplication and the whole
thing *^ looks like it denotes something beyond multiplication which is
exactly what exponentiation is.
>
>
> On 19 July 2013 11:38, Francis Smit <grizzlysmit@gmail.com
> <mailto:grizzlysmit@gmail.com>> wrote:
>
> many of us I think would like an exponentiation operator and
> obviously ** is not viable in C++ as that could be confused with a
> * (*b) where b is is a pointer but a *^ b should not compile at
> the moment unless I am very much mistaken, so it should be fine
> for this use.
>
--
.~. In my life God comes first....
/V\ but Linux is pretty high after that :-D
/( )\ Francis (Grizzly) Smit
^^-^^ http://www.smit.id.au/
--
---
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/.
--------------020606040800020201020209
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 20/07/13 04:25, Mikhail Semenov
wrote:<br>
</div>
<blockquote
cite="mid:CAMeU-s3Xuig61x_UtQ34175UYmBBkr4oqvQO_CJ22BymOLMzOg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>How about using ^^ ?</div>
<div>For example: </div>
<div>2^^5 </div>
<div>x^^y</div>
<div>f(x)^^g(z)</div>
<div> </div>
<div> </div>
</div>
</blockquote>
to me ^^ looks like it should be logical xor should we ever choose
to add that I was looking for something completely free and *^ fit's
that bill nicely, further the * in it suggests multiplication and
the whole thing *^ looks like it denotes something beyond
multiplication which is exactly what exponentiation is.<br>
<blockquote
cite="mid:CAMeU-s3Xuig61x_UtQ34175UYmBBkr4oqvQO_CJ22BymOLMzOg@mail.gmail.com"
type="cite">
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On 19 July 2013 11:38, Francis Smit <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:grizzlysmit@gmail.com" target="_blank">grizzlysmit@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">many of us
I think would like an exponentiation operator and obviously
** is not viable in C++ as that could be confused with a *
(*b) where b is is a pointer but a *^ b should not compile
at the moment unless I am very much mistaken, so it should
be fine for this use.<span class="HOEnZb"><font
color="#888888"><br>
</font></span>
<br>
</blockquote>
</div>
</div>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
<pre><tt>
.~. In my life God comes first....
/V\ but Linux is pretty high after that :-D
/( )\ Francis (Grizzly) Smit
^^-^^ <a class="moz-txt-link-freetext" href="http://www.smit.id.au/">http://www.smit.id.au/</a>
</tt><pre>
</pre></pre>
</div>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
<br />
<br />
--------------020606040800020201020209--
.
Author: Maurice Bos <m-ou.se@m-ou.se>
Date: Sat, 20 Jul 2013 00:03:34 +0200
Raw View
--089e0111bcfaab6d2404e1e480e1
Content-Type: text/plain; charset=ISO-8859-1
We already have logical xor: operator !=
2013/7/20 Francis Smit <grizzlysmit@gmail.com>
> On 20/07/13 04:25, Mikhail Semenov wrote:
>
> How about using ^^ ?
> For example:
> 2^^5
> x^^y
> f(x)^^g(z)
>
>
>
> to me ^^ looks like it should be logical xor should we ever choose to add
> that I was looking for something completely free and *^ fit's that bill
> nicely, further the * in it suggests multiplication and the whole thing *^
> looks like it denotes something beyond multiplication which is exactly
> what exponentiation is.
>
>
>
> On 19 July 2013 11:38, Francis Smit <grizzlysmit@gmail.com> wrote:
>
>> many of us I think would like an exponentiation operator and obviously **
>> is not viable in C++ as that could be confused with a * (*b) where b is is
>> a pointer but a *^ b should not compile at the moment unless I am very much
>> mistaken, so it should be fine for this use.
>>
>>
>
>
> --
>
>
> .~. In my life God comes first....
> /V\ but Linux is pretty high after that :-D
> /( )\ Francis (Grizzly) Smit
> ^^-^^ http://www.smit.id.au/
>
> --
>
> ---
> 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/.
--089e0111bcfaab6d2404e1e480e1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
We already have logical xor: operator !=3D<br><br><div class=3D"gmail_quote=
">2013/7/20 Francis Smit <span dir=3D"ltr"><<a href=3D"mailto:grizzlysmi=
t@gmail.com" target=3D"_blank">grizzlysmit@gmail.com</a>></span><br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><div class=3D"im">
<div>On 20/07/13 04:25, Mikhail Semenov
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>How about using ^^=A0 ?</div>
<div>For example: </div>
<div>2^^5 </div>
<div>x^^y</div>
<div>f(x)^^g(z)</div>
<div>=A0</div>
<div>=A0</div>
</div>
</blockquote></div>
to me ^^ looks like it should be logical xor should we ever choose
to add that I was looking for something completely free and *^ fit'=
s
that bill nicely, further the * in it suggests multiplication and
the whole thing *^ looks like it denotes something beyond=A0
multiplication which is exactly what exponentiation is.<div class=3D"im=
"><br>
<blockquote type=3D"cite">
<div class=3D"gmail_extra"><br>
<br>
<div class=3D"gmail_quote">On 19 July 2013 11:38, Francis Smit <spa=
n dir=3D"ltr"><<a href=3D"mailto:grizzlysmit@gmail.com" target=3D"_blank=
">grizzlysmit@gmail.com</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">many of us
I think would like an exponentiation operator and obviously
** is not viable in C++ as that could be confused with a *
(*b) where b is is a pointer but a *^ b should not compile
at the moment unless I am very much mistaken, so it should
be fine for this use.<span><font color=3D"#888888"><br>
</font></span>=A0
<br>
</blockquote>
</div>
</div>
</blockquote>
<br>
<br>
<div>-- <br>
<pre><tt>
.~. In my life God comes first....=20
/V\ but Linux is pretty high after that :-D
/( )\ Francis (Grizzly) Smit
^^-^^ <a href=3D"http://www.smit.id.au/" target=3D"_blank">http://www.s=
mit.id.au/</a>
</tt><pre></pre></pre>
</div>
</div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@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>
=A0<br>
=A0<br>
</div></div></blockquote></div><br>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
<br />
<br />
--089e0111bcfaab6d2404e1e480e1--
.
Author: Jesse Perla <jesseperla@gmail.com>
Date: Mon, 22 Jul 2013 10:00:31 -0700 (PDT)
Raw View
------=_Part_660_32002643.1374512431249
Content-Type: text/plain; charset=ISO-8859-1
On Friday, July 19, 2013 7:39:05 AM UTC-7, Ville Voutilainen wrote:
>
>
> I don't consider exponentiation important enough that we should try to add
> it as an afterthought.
>
>
Besides the general goal of making C++ a good language for scientific
computing (and finally putting a nail in Fortran for general purpose
scientific computing), this can be extremely useful if it is over-loadable.
The basic problem is that there are a large number of new types these days
where you take powers, but can't (or shouldn't) use std::pow(). With an
operator and ADL, this makes life far easier, generic, and avoids namespace
issues.
For example, including variations of scalars, and many other types.
- *built in arithmetic types: *std::pow()
- *GPU: *thrust::pow()
https://github.com/jtravs/cuda_complex/blob/master/cuda_complex.hpp
- *eign matrices*: eigen::pow() or eigen::pow() with
- *boost matrices: *
http://stackoverflow.com/questions/10676856/regarding-element-by-element-operations-in-boostublas
- *autodifferentiation*: CppAD::pow()
- *multiprecision*:
http://www.boost.org/doc/libs/1_53_0_beta1/boost/multiprecision/detail/functions/pow.hpp
.... add in DSL's for polynomials, etc. and the list goes on.
One of the big places this is useful is for generic functions to be used in
with optimizers, etc. For example, in Matlab the following works
vectorized or for a unary value. So the optimizer can use the function to
evaluate at a vectorized set of values, apply autodifferentiation, etc.
without changing the function interface.
f = @(x) x.^2;
And here, assuming the appropriate concepts-lite constraint in C++:
auto f = [](const Multiplicative& x)(return x *^ 2};
For this, an optimizer could now use it to record an auto-differentiated
gradient and then calculate the minimum.
And there are plenty of algorithms that can be written more generally for
the same reasons. For example, with the appropriate concepts to constrain:
<Range R> requires Ring<Value_type<R>()
auto sum_squares(R r, Value_type<R> init = Value_type<R>())
{
return std::accumulate(begin(r), end(r), init, [](auto& sum, auto x&)(sum
+= x^*2));
}
--
---
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_660_32002643.1374512431249
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div><br></div><br>On Friday, July 19, 2013 7:39:05 AM UTC-7, Ville Voutila=
inen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><d=
iv><div class=3D"gmail_quote"><div><br></div><div>I don't consider exponent=
iation important enough that we should try to add it as an afterthought. <b=
r></div><div><br></div></div></div></div></blockquote><div><br></div><div><=
div>Besides the general goal of making C++ a good language for scientific c=
omputing (and finally putting a nail in Fortran for general purpose scienti=
fic computing), this can be extremely useful if it is over-loadable. =
The basic problem is that there are a large number of new types these days =
where you take powers, but can't (or shouldn't) use std::pow(). With =
an operator and ADL, this makes life far easier, generic, and avoids namesp=
ace issues.</div><div><br></div><div>For example, including variations of s=
calars, and many other types.</div><div><ul><li><b>built in arithmetic type=
s: </b>std::pow()<br></li><li><b>GPU: </b>thrust::pow() https://=
github.com/jtravs/cuda_complex/blob/master/cuda_complex.hpp<br></li><li><b>=
eign matrices</b>: eigen::pow() or eigen::pow() with <br></li><l=
i><b>boost matrices: </b><a href=3D"http://stackoverflow.com/questions=
/10676856/regarding-element-by-element-operations-in-boostublas">http://sta=
ckoverflow.com/questions/10676856/regarding-element-by-element-operations-i=
n-boostublas</a></li><li><b>autodifferentiation</b>: CppAD::pow()<br></li><=
li><b>multiprecision</b>: <a href=3D"http://www.boost.org/doc/libs/1_5=
3_0_beta1/boost/multiprecision/detail/functions/pow.hpp">http://www.boost.o=
rg/doc/libs/1_53_0_beta1/boost/multiprecision/detail/functions/pow.hpp</a><=
/li></ul></div><div>... add in DSL's for polynomials, etc. and the list goe=
s on.</div><div><br></div><div>One of the big places this is useful is for =
generic functions to be used in with optimizers, etc. For example, in=
Matlab the following works vectorized or for a unary value. So the o=
ptimizer can use the function to evaluate at a vectorized set of valu=
es, apply autodifferentiation, etc. without changing the function int=
erface.</div><div>f =3D @(x) x.^2;</div><div><br></div><div>And here, assum=
ing the appropriate concepts-lite constraint in C++:</div><div>auto f =3D [=
](const Multiplicative& x)(return x *^ 2};</div><div><br></div><div>For=
this, an optimizer could now use it to record an auto-differentiated gradi=
ent and then calculate the minimum.</div><div><br></div><div>And there are =
plenty of algorithms that can be written more generally for the same reason=
s. For example, with the appropriate concepts to constrain:</div><div=
><Range R> requires Ring<Value_type<R>()</div><div>auto sum_=
squares(R r, Value_type<R> init =3D Value_type<R>())</div><div>=
{</div><div> return std::accumulate(begin(r), end(r), init, [](auto&a=
mp; sum, auto x&)(sum +=3D x^*2));</div><div>}</div><div><br></div></di=
v>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
<br />
<br />
------=_Part_660_32002643.1374512431249--
.
Author: notayakk@gmail.com
Date: Fri, 23 Aug 2013 08:19:49 -0700 (PDT)
Raw View
------=_Part_1724_25821424.1377271189750
Content-Type: text/plain; charset=ISO-8859-1
A named *power* operator would also solve many of these problems, rather
than *^, would it not?
And a named *power* operator can be implemented as a pure library feature.
Stick it in std somewhere, and have it invoke the free function
operator_power(lhs, rhs).
- Adam
On Friday, July 19, 2013 6:38:53 AM UTC-4, Francis Grizzly Smit wrote:
>
> many of us I think would like an exponentiation operator and obviously
> ** is not viable in C++ as that could be confused with a * (*b) where b
> is is a pointer but a *^ b should not compile at the moment unless I am
> very much mistaken, so it should be fine for this use.
>
>
>
> --
>
>
> .~. In my life God comes first....
> /V\ but Linux is pretty high after that :-D
> /( )\ Francis (Grizzly) Smit
> ^^-^^ http://www.smit.id.au/
>
>
--
---
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_1724_25821424.1377271189750
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">A named *power* operator would also solve many of these pr=
oblems, rather than *^, would it not?<br><br>And a named *power* operator c=
an be implemented as a pure library feature.<br><br>Stick it in std somewhe=
re, and have it invoke the free function operator_power(lhs, rhs).<br><br>-=
Adam<br><br>On Friday, July 19, 2013 6:38:53 AM UTC-4, Francis Grizzly Smi=
t wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">many of us I think wou=
ld like an exponentiation operator and obviously=20
<br>** is not viable in C++ as that could be confused with a * (*b) where b=
=20
<br>is is a pointer but a *^ b should not compile at the moment unless I am=
=20
<br>very much mistaken, so it should be fine for this use.
<br>
<br>
<br>
<br>--=20
<br>
<br>
<br> .~. In my life God comes first....
<br> /V\ but Linux is pretty high a=
fter that :-D
<br> /( )\ Francis (Grizzly) Smit
<br> ^^-^^ <a href=3D"http://www.smit.id.au/" target=3D"=
_blank">http://www.smit.id.au/</a>
<br>
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1724_25821424.1377271189750--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 26 Aug 2013 16:04:20 -0700
Raw View
--nextPart1848267.XLPLnVVCuy
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
On sexta-feira, 23 de agosto de 2013 08:19:49, notayakk@gmail.com wrote:
> A named *power* operator would also solve many of these problems, rather
> than *^, would it not?
>
> And a named *power* operator can be implemented as a pure library feature.
>
> Stick it in std somewhere, and have it invoke the free function
> operator_power(lhs, rhs).
That's std::pow, from <cmath>.
--
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
--nextPart1848267.XLPLnVVCuy
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iD8DBQBSG970M/XwBW70U1gRAi9KAJ9KBcyGoKx4v5/buxWx7M/SHw3tEwCfebAz
6z/m0FcYsjF3o2lW+Xk5nw4=
=iYtr
-----END PGP SIGNATURE-----
--nextPart1848267.XLPLnVVCuy--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 26 Aug 2013 16:17:59 -0700 (PDT)
Raw View
------=_Part_3_13357562.1377559079501
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, August 27, 2013 7:04:20 AM UTC+8, Thiago Macieira wrote:
>
> On sexta-feira, 23 de agosto de 2013 08:19:49, nota...@gmail.com<javascript:>wrote:
> > A named *power* operator would also solve many of these problems, rather
> > than *^, would it not?
> >
> > And a named *power* operator can be implemented as a pure library
> feature.
> >
> > Stick it in std somewhere, and have it invoke the free function
> > operator_power(lhs, rhs).
>
> That's std::pow, from <cmath>.
>
To do it properly, the operator should fall back on recursive
multiplication and/or functional composition.
All this could be added after C++ gets user-defined, named infix operators.
Since making the parse tree of every expression to depend on name lookup is
a great idea. Especially when operator name lookup itself depends on
declarations in faraway places.
By the way, those of us reading on groups.google.com don't see your
signature but instead get a big goofy graphic; please set your email client
to substitute it inline rather than attaching as multi-part.
--
---
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_3_13357562.1377559079501
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, August 27, 2013 7:04:20 AM UTC+8, Thia=
go Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On sexta-fei=
ra, 23 de agosto de 2013 08:19:49, <a href=3D"javascript:" target=3D"_blank=
" gdf-obfuscated-mailto=3D"6GftEeU0k_sJ">nota...@gmail.com</a> wrote:
<br>> A named *power* operator would also solve many of these problems, =
rather=20
<br>> than *^, would it not?
<br>>=20
<br>> And a named *power* operator can be implemented as a pure library =
feature.
<br>>=20
<br>> Stick it in std somewhere, and have it invoke the free function=20
<br>> operator_power(lhs, rhs).
<br>
<br>That's std::pow, from <cmath>.
<br>
</blockquote><div><br>To do it properly, the operator should fall back on r=
ecursive multiplication and/or functional composition.<br><br>All this coul=
d be added after C++ gets user-defined, named infix operators. Since making=
the parse tree of every expression to depend on name lookup is a great ide=
a. Especially when operator name lookup itself depends on declarations in f=
araway places.<br><br>By the way, those of us reading on groups.google.com =
don't see your signature but instead get a big goofy graphic; please set yo=
ur email client to substitute it inline rather than attaching as multi-part=
..<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_3_13357562.1377559079501--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 26 Aug 2013 19:19:37 -0700
Raw View
On segunda-feira, 26 de agosto de 2013 16:17:59, David Krauss wrote:
> > That's std::pow, from <cmath>.
>
> To do it properly, the operator should fall back on recursive
> multiplication and/or functional composition.
That sounds like a bad idea for me. Suddenly we have an automatic operator
with O(n) behaviour -- with n being the right-hand side argument.
If we add a real operator, then such an operator should behave like all other
operators for non-primitive types: if you don't define it explicitly, it
doesn't exist. I strongly disagree on a fallback.
> All this could be added after C++ gets user-defined, named infix operators.
> Since making the parse tree of every expression to depend on name lookup is
> a great idea. Especially when operator name lookup itself depends on
> declarations in faraway places.
Has there been a proposal for this?
> By the way, those of us reading on groups.google.com don't see your
> signature but instead get a big goofy graphic; please set your email client
> to substitute it inline rather than attaching as multi-part.
OpenPGP/MIME is over a decade old (RFC 3156 is from 2001), it's the only way
to sign attachments. I've been using it automatically for 8 years or more. It
looks like the Google Groups interface shows it as an unknown attachment.
I'll try to remember to disable signing before posting to this list.
--
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
--
---
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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 26 Aug 2013 22:41:12 -0700 (PDT)
Raw View
------=_Part_226_32775960.1377582073075
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, July 23, 2013 1:00:31 AM UTC+8, Jesse Perla wrote:
>
>
> Besides the general goal of making C++ a good language for scientific
> computing (and finally putting a nail in Fortran for general purpose
> scientific computing), this can be extremely useful if it is over-loadable.
> The basic problem is that there are a large number of new types these days
> where you take powers, but can't (or shouldn't) use std::pow(). With an
> operator and ADL, this makes life far easier, generic, and avoids namespace
> issues.
Fortran programmers will probably continue using Fortran. It's a different
paradigm.
ADL works just the same without an operator. Namespace issues would be *
exacerbated*.
> ... add in DSL's for polynomials, etc. and the list goes on.
>
If ADL doesn't work in a particular case, then a "using blah_lib::pow" will
make it visible, but presumably the library author would have had a good
reason for specifically disabling ADL.
For the case of primitive types, the relevant declaration is "using
std::pow;".
Combining many numeric libraries in the same function is just masochism
(unless you're doing it to someone else).
> One of the big places this is useful is for generic functions to be used
> in with optimizers, etc. For example, in Matlab the following works
> vectorized or for a unary value. So the optimizer can use the function to
> evaluate at a vectorized set of values, apply autodifferentiation, etc.
> without changing the function interface.
> f = @(x) x.^2;
>
> And here, assuming the appropriate concepts-lite constraint in C++:
> auto f = [](const Multiplicative& x)(return x *^ 2};
>
Is Multiplicative an apt term for being closed over multiplication? I'm not
even sure that's necessary or sufficient for exponentiation.
auto squared = [](auto const & x){ using std::pow; return pow( x, 2 ); };
If you want to apply a concept, just check that such a call to pow is
defined. No need to make all those libraries catch up.
The fundamental problem is that C operators, which C++ inherits, refer to
the functions most microprocessors can perform, without reference to
mathematical ideals. If you're going to work with matrices, why not also
work with all kinds of abstract algebra entities?
As for exponentiation in hardware, we have left shift, which raises two to
the power of the RHS and then multiplies it by the LHS. It happens to be
more popular to interpret that visually as "push the RHS into the LHS,"
i.e. stream insertion or sequence initialization pre-std::initializer_list.
But you might have better luck fighting to take back the *original*exponentiation operator than to define a new one.
--
---
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_226_32775960.1377582073075
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, July 23, 2013 1:00:31 AM UTC+8, Jesse Perla wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div><br></div>Besides the=
general goal of making C++ a good language for scientific computing (and f=
inally putting a nail in Fortran for general purpose scientific computing),=
this can be extremely useful if it is over-loadable. The basic probl=
em is that there are a large number of new types these days where you take =
powers, but can't (or shouldn't) use std::pow(). With an operator and=
ADL, this makes life far easier, generic, and avoids namespace issues.</bl=
ockquote><div><br>Fortran programmers will probably continue using Fortran.=
It's a different paradigm.<br></div><div><br>ADL works just the same witho=
ut an operator. Namespace issues would be <i>exacerbated</i>.<br> </di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div>... add in DSL's for po=
lynomials, etc. and the list goes on.</div></blockquote><div><br>If ADL doe=
sn't work in a particular case, then a "using blah_lib::pow" will make it v=
isible, but presumably the library author would have had a good reason for =
specifically disabling ADL.<br><br>For the case of primitive types, the rel=
evant declaration is "using std::pow;".<br><br>Combining many numeric libra=
ries in the same function is just masochism (unless you're doing it to some=
one else).<br> <br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div><div>One of the big places this is useful is for generic functions to =
be used in with optimizers, etc. For example, in Matlab the following=
works vectorized or for a unary value. So the optimizer can use the =
function to evaluate at a vectorized set of values, apply autodiffere=
ntiation, etc. without changing the function interface.</div><div>f =
=3D @(x) x.^2;</div><div><br></div><div>And here, assuming the appropriate =
concepts-lite constraint in C++:</div><div>auto f =3D [](const Multiplicati=
ve& x)(return x *^ 2};</div></div></blockquote><div><br>Is Multiplicati=
ve an apt term for being closed over multiplication? I'm not even sure that=
's necessary or sufficient for exponentiation.<br><br><div class=3D"prettyp=
rint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187,=
187, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"=
><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> squared </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">[](</span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">con=
st</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">&</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">){</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;"=
class=3D"styled-by-prettify">using</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">pow</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">return</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> pow</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> x</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styl=
ed-by-prettify">2</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">);=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">};</span></div></co=
de></div><br>If you want to apply a concept, just check that such a call to=
pow is defined. No need to make all those libraries catch up.<br><br> The =
fundamental problem is that C operators, which C++ inherits, refer to the f=
unctions most
microprocessors can perform, without reference to mathematical ideals.=20
If you're going to work with matrices, why not also work with all kinds=20
of abstract algebra entities?<br><br>As for exponentiation in hardware, we =
have left shift, which raises two to the power of the RHS and then multipli=
es it by the LHS. It happens to be more popular to interpret that visually =
as "push the RHS into the LHS," i.e. stream insertion or sequence initializ=
ation pre-std::initializer_list.<br><br>But you might have better luck figh=
ting to take back the <b>original</b> exponentiation operator than to defin=
e a new one.<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_226_32775960.1377582073075--
.
Author: Jesse Perla <jesseperla@gmail.com>
Date: Tue, 27 Aug 2013 09:36:01 -0700 (PDT)
Raw View
------=_Part_654_2890242.1377621361249
Content-Type: text/plain; charset=ISO-8859-1
On Monday, August 26, 2013 10:41:12 PM UTC-7, David Krauss wrote:
Thank you for your comments. The key here is that a^*b (or whatever the
operator might be) is completely unnecessary if we were only taking about
intrinsic scalar types. std::pow(a,b) is perfectly fine in the C-style
world, before people started writing fancy numerical libraries. This is
about the transition from C to modern, generic C++.
> Fortran programmers will probably continue using Fortran. It's a different
> paradigm.
>
For old guys, fluid dynamics, and implementing LAPACK, they probably should
continue to Fortran. My issue is for *new* programmers. In my field
(economics) people have many complicated models to write that combine all
sorts of algorithms. They start learning matlab, but when it is no longer
sufficient they go to Fortran with few exceptions. It isn't that Fortran
is the right language for them or that they have the discipline to use it
correctly, it is that they don't see C++ as a real numerical alternative
because they can't figure out how to do simple operations they take for
granted in other languages, and even when they figure out they have to use
libraries, these rarely have consistent notation.
> ADL works just the same without an operator. Namespace issues would be *
> exacerbated*.
>
>
>> ... add in DSL's for polynomials, etc. and the list goes on.
>>
>
> If ADL doesn't work in a particular case, then a "using blah_lib::pow"
> will make it visible, but presumably the library author would have had a
> good reason for specifically disabling ADL.
>
I will defer to you as an expert on this stuff, but the standardization on
the "+" and "*" operators sure seems universal for both EDSL and intrinsic
types. If there is an easy way to do what they have with std::pow right
now, the library vendors don't know it and will probably never implement it
(the list of examples I give above has some pretty savvy library
developers). But with a power operator they would be forced to as you don't
specify std::+ in practice
>
> Combining many numeric libraries in the same function is just masochism
> (unless you're doing it to someone else).
>
Sadly true, and that is what needs to change for C++ to be a viable
language for scientific computing.
The issue is that numerical libraries are rarely written as generic when it
comes to their vectors, matrices, multi-arrays, (and occasionally scalars
for AutoDiff). Exponentiation is only part of the problem, as the real
issue seems to be that people are simply not writing generic code. Of
course, it is a lot easier to write general code with implicit concepts
akin to iterators and ranges have been established. And iterators are a lot
easier to specify when you allow "++" and "*" operators. Hence the value
in getting the core operators down for numerical analysis to make generic
code easier. The bigger issue is what to do about making vector, matrix,
and multidimensional arrays inter-operable in one form or another, which
this doesn't immediately address.
>
>> One of the big places this is useful is for generic functions to be used
>> in with optimizers, etc. For example, in Matlab the following works
>> vectorized or for a unary value. So the optimizer can use the function to
>> evaluate at a vectorized set of values, apply autodifferentiation, etc.
>> without changing the function interface.
>>
>
> Is Multiplicative an apt term for being closed over multiplication? I'm
> not even sure that's necessary or sufficient for exponentiation.
>
> auto squared = [](auto const & x){ using std::pow; return pow( x, 2 ); };
>
> Sure, I was trying to put in a placeholder concept (Although I am not sure
that the requirement for non-communitive multiplicative all that
overspecified, and this sort of stuff belongs in a well thought out
concepts design), but what you have written simply doesn't work for
squaring a matrix, whereas x `POWEROPERATOR` 2 does if the library
implements it. None of them seem to do anything with having std::pow
revert to their own implementation, and probably never will.
> The fundamental problem is that C operators, which C++ inherits, refer to
> the functions most microprocessors can perform, without reference to
> mathematical ideals. If you're going to work with matrices, why not also
> work with all kinds of abstract algebra entities?
>
Why doesn't this also apply to "+", "*", etc. which are commonly
implemented for abstract types? Why not enable it for abstract algebra
entities? Exponentiation and powers come up all the time. More operators
means the libraries can implement the natural mathematics for the type.
> But you might have better luck fighting to take back the *original*exponentiation operator than to define a new one.
>
I don't have a strong prior on what the operator should look like, I am
just sure that it makes C++ much more powerful for making numerical
libraries. I guess I don't understand the technical reasons why it can't
carefully added in the future, and all EDSL made all the more powerful and
consistent for generic algorithms.
--
---
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_654_2890242.1377621361249
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><br></div>On Monday, August 26, 2013 10:41:12 PM UTC-=
7, David Krauss wrote:<div><br></div><div>Thank you for your comments. &nbs=
p;The key here is that a^*b (or whatever the operator might be) is complete=
ly unnecessary if we were only taking about intrinsic scalar types. s=
td::pow(a,b) is perfectly fine in the C-style world, before people started =
writing fancy numerical libraries. This is about the transition from =
C to modern, generic C++.<br></div><div><br><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div><br>Fortran programmers will probably c=
ontinue using Fortran. It's a different paradigm.<br></div></div></blockquo=
te><div><br></div><div>For old guys, fluid dynamics, and implementing LAPAC=
K, they probably should continue to Fortran. My issue is for *new* pr=
ogrammers. In my field (economics) people have many complicated model=
s to write that combine all sorts of algorithms. They start learning =
matlab, but when it is no longer sufficient they go to Fortran with few exc=
eptions. It isn't that Fortran is the right language for them or that=
they have the discipline to use it correctly, it is that they don't see C+=
+ as a real numerical alternative because they can't figure out how to do s=
imple operations they take for granted in other languages, and even when th=
ey figure out they have to use libraries, these rarely have consistent nota=
tion.</div><div> </div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><div>ADL works just the same without an operator. Namespace =
issues would be <i>exacerbated</i>.<br> </div><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div>... add in DSL's for polynomials, etc. and the list go=
es on.</div></blockquote><div><br>If ADL doesn't work in a particular case,=
then a "using blah_lib::pow" will make it visible, but presumably the libr=
ary author would have had a good reason for specifically disabling ADL.</di=
v></div></blockquote><div><br></div><div>I will defer to you as an expert o=
n this stuff, but the standardization on the "+" and "*" operators sure see=
ms universal for both EDSL and intrinsic types. If there is an easy w=
ay to do what they have with std::pow right now, the library vendors don't =
know it and will probably never implement it (the list of examples I give a=
bove has some pretty savvy library developers). But with a power operator t=
hey would be forced to as you don't specify std::+ in practice</div><div>&n=
bsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v><br>Combining many numeric libraries in the same function is just masochi=
sm (unless you're doing it to someone else).<br></div></div></blockquote><d=
iv><br></div><div>Sadly true, and that is what needs to change for C++ to b=
e a viable language for scientific computing.</div><div><br></div><div>The =
issue is that numerical libraries are rarely written as generic when it com=
es to their vectors, matrices, multi-arrays, (and occasionally scalars for =
AutoDiff). Exponentiation is only part of the problem, as the real is=
sue seems to be that people are simply not writing generic code. Of c=
ourse, it is a lot easier to write general code with implicit concepts akin=
to iterators and ranges have been established. And iterators are a lot eas=
ier to specify when you allow "++" and "*" operators. Hence the valu=
e in getting the core operators down for numerical analysis to make generic=
code easier. The bigger issue is what to do about making vector, mat=
rix, and multidimensional arrays inter-operable in one form or another, whi=
ch this doesn't immediately address.</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div> <br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>One of the big places this is useful is=
for generic functions to be used in with optimizers, etc. For exampl=
e, in Matlab the following works vectorized or for a unary value. So =
the optimizer can use the function to evaluate at a vectorized set of=
values, apply autodifferentiation, etc. without changing the functio=
n interface.</div></blockquote><div><br>Is Multiplicative an apt term for b=
eing closed over multiplication? I'm not even sure that's necessary or suff=
icient for exponentiation.<br><br><div style=3D"background-color:rgb(250,25=
0,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px;wo=
rd-wrap:break-word"><code><div><span style=3D"color:#008">auto</span><span =
style=3D"color:#000"> squared </span><span style=3D"color:#660">=3D</span><=
span style=3D"color:#000"> </span><span style=3D"color:#660">[](</span><spa=
n style=3D"color:#008">auto</span><span style=3D"color:#000"> </span><span =
style=3D"color:#008">const</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#660">&</span><span style=3D"color:#000"> x</span><span s=
tyle=3D"color:#660">){</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">using</span><span style=3D"color:#000"> std</span><span sty=
le=3D"color:#660">::</span><span style=3D"color:#000">pow</span><span style=
=3D"color:#660">;</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#008">return</span><span style=3D"color:#000"> pow</span><span style=
=3D"color:#660">(</span><span style=3D"color:#000"> x</span><span style=3D"=
color:#660">,</span><span style=3D"color:#000"> </span><span style=3D"color=
:#066">2</span><span style=3D"color:#000"> </span><span style=3D"color:#660=
">);</span><span style=3D"color:#000"> </span><span style=3D"color:#660">};=
</span></div></code></div><br></div></div></blockquote><div>Sure, I was try=
ing to put in a placeholder concept (Although I am not sure that the requir=
ement for non-communitive multiplicative all that overspecified, and this s=
ort of stuff belongs in a well thought out concepts design), but what you h=
ave written simply doesn't work for squaring a matrix, whereas x `POWEROPER=
ATOR` 2 does if the library implements it. None of them seem to do an=
ything with having std::pow revert to their own implementation, and probabl=
y never will.</div><div><br></div><div> </div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div dir=3D"ltr"><div> The fundamental problem is that=
C operators, which C++ inherits, refer to the functions most
microprocessors can perform, without reference to mathematical ideals.=20
If you're going to work with matrices, why not also work with all kinds=20
of abstract algebra entities?</div></div></blockquote><div>Why doesn't this=
also apply to "+", "*", etc. which are commonly implemented for abstract t=
ypes? Why not enable it for abstract algebra entities? Exponent=
iation and powers come up all the time. More operators means the libr=
aries can implement the natural mathematics for the type.</div><div><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br>B=
ut you might have better luck fighting to take back the <b>original</b> exp=
onentiation operator than to define a new one.<br></div></div></blockquote>=
<div><br></div><div>I don't have a strong prior on what the operator =
should look like, I am just sure that it makes C++ much more powerful for m=
aking numerical libraries. I guess I don't understand the technical r=
easons why it can't carefully added in the future, and all EDSL made all th=
e more powerful and consistent for generic algorithms.</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_654_2890242.1377621361249--
.
Author: Jesse Perla <jesseperla@gmail.com>
Date: Tue, 27 Aug 2013 10:02:04 -0700 (PDT)
Raw View
------=_Part_192_33123163.1377622924842
Content-Type: text/plain; charset=ISO-8859-1
On Monday, August 26, 2013 4:17:59 PM UTC-7, David Krauss wrote:
>
> All this could be added after C++ gets user-defined, named infix
> operators. Since making the parse tree of every expression to depend on
> name lookup is a great idea. Especially when operator name lookup itself
> depends on declarations in faraway places.
>
If this was done, it probably should be done all at once (and right) as you
say). One great test suite for the operators needed is to look at domain
specific languages for matrices and vectors. To give a list of the
operators to consider, let me give the relevant operators in Matlab that
could be implemented in an expression template library for
matrices/vectors. Let A, B be some 2x2 square matrix.
- A * B -> matrix power
- A .* B -> componentwise power (i.{1 x 1, 2x2},{1x1, 2x2}};
- A^2 -> Matrix power, i.e. A * A for non-commutative * operator. Note
that the library could have a specialization for the inverse A^(-1) if it
wanted.
- A.^2 -> Elementwise power -> {{1^2, 2^2}, {1^2, 2^2}};
- e^A -> Matrix exponential , libraries could have a specialization for
this if there was an "e" as a constexp variable, for example. which could
have a special overload that calls std::exp() for the intrinsic scalars.
- e.^A -> elementwise exponential
- A / B -> A * B^{-1} , There is also B \ A which solves it
efficiently as a linear system, but we can live without that for obvious
reasons.
- A /. B -> elementwise division
- A' -> unary complex conjugate transpose operator on A. I think we
could easily live without this in C++
Right now, the librarires use: "+, *, +=, *=, /"
None of the existing libraries have an elegant solution for the elementwise
operations, division, powers, or exponentiation. For example, in eigen
"m*n" works for matrix multiplication, but you need "m.cwiseProduct(n)" for
matrix/scalar componentwise product. Or you call "(m.array() + 4).matrix()
* m" to do coefficientwise addition then matrix multiplication. They could
implement "m .+ 4 * m " if the operators existed
If some of these new operators were there, I am not saying it should be
".+, .+=,", etc. as we would likely have a problem at least with .* But
perhaps there is some notation that would work and not break anything.
General Haskell-style infix operators would be overkill but nice.
However, if we are constrained to alphanumeric names, I think that A
`power` b is too verbose
--
---
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_192_33123163.1377622924842
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Monday, August 26, 2013 4:17:59 PM UTC-7, David Kra=
uss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">All=
this could be added after C++ gets user-defined, named infix operators. Si=
nce making the parse tree of every expression to depend on name lookup is a=
great idea. Especially when operator name lookup itself depends on declara=
tions in faraway places.</div></blockquote><div><br></div><div>If this was =
done, it probably should be done all at once (and right) as you say).  =
;One great test suite for the operators needed is to look at domain specifi=
c languages for matrices and vectors. To give a list of the operators=
to consider, let me give the relevant operators in Matlab that could be im=
plemented in an expression template library for matrices/vectors. Let=
A, B be some 2x2 square matrix.<br></div><div><ul><li>A * B -> matrix p=
ower<br></li><li>A .* B -> componentwise power (i.{1 x 1, 2x2},{1x1, 2x2=
}};</li><li><span style=3D"line-height: normal;">A^2 -> Matrix po=
wer, i.e. A * A for non-commutative * operator. </span>Note that the =
library could have a specialization for the inverse A^(-1) if it wanted.</l=
i><li><span style=3D"line-height: normal;">A.^2 -> Elementwise power -&g=
t; {{1^2, 2^2}, {1^2, 2^2}};</span></li><li><span style=3D"line-heigh=
t: normal;">e^A -> Matrix exponential , libraries could have a specializ=
ation for this if there was an "e" as a constexp variable, for example. whi=
ch could have a special overload that calls std::exp() for the intrinsic sc=
alars.</span></li><li><span style=3D"line-height: normal;">e.^A -> eleme=
ntwise exponential </span></li><li>A / B -> A * B^{-1} , The=
re is also B \ A which solves it efficiently as a linear system, but we can=
live without that for obvious reasons.</li><li>A /. B -> elementwise di=
vision</li><li>A' -> unary complex conjugate transpose operator on A. &n=
bsp;I think we could easily live without this in C++</li></ul><div><span st=
yle=3D"line-height: 17px;">Right now, the librarires use: "+, *, +=3D, *=3D=
, /"</span></div><div><span style=3D"line-height: 17px;">None of the existi=
ng libraries have an elegant solution for the elementwise operations, divis=
ion, powers, or exponentiation. For example, in eigen "m*n" works for=
matrix multiplication, but you need "</span><span style=3D"background-colo=
r: rgb(251, 252, 253); color: rgb(0, 0, 0); font-family: monospace, fixed; =
line-height: 13px; text-indent: -53px; white-space: pre-wrap;">m.cwiseProdu=
ct(n)" for matrix/scalar componentwise product. Or you call "</span><span =
style=3D"background-color: rgb(251, 252, 253); color: rgb(0, 0, 0); font-fa=
mily: monospace, fixed; line-height: 13px; text-indent: -53px; white-space:=
pre-wrap;">(m.array() + 4).matrix() * m" to do coefficientwise addition th=
en matrix multiplication. They could implement "m .+ 4 * m " if the operat=
ors existed</span></div></div><div><span style=3D"background-color: rgb(251=
, 252, 253); color: rgb(0, 0, 0); font-family: monospace, fixed; line-heigh=
t: 13px; text-indent: -53px; white-space: pre-wrap;"><br></span></div><div>=
<span style=3D"line-height: 17px;">If some of these new operators were ther=
e, I am not saying it should be ".+, .+=3D,", etc. as we would likely have =
a problem at least with .* But perhaps there is some notation that w=
ould work and not break anything. General Haskell-style infix operato=
rs would be overkill but nice. However, if we are constrained to alph=
anumeric names, I think that A `power` b is too verbose</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_192_33123163.1377622924842--
.
Author: Joel Falcou <joel.falcou@gmail.com>
Date: Tue, 27 Aug 2013 19:04:01 +0200
Raw View
This is a multi-part message in MIME format.
--------------050100080103080908060800
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 27/08/2013 19:02, Jesse Perla wrote:
> Right now, the librarires use: "+, *, +=, *=, /"
> None of the existing libraries have an elegant solution for the
> elementwise operations, division, powers, or exponentiation. For
> example, in eigen "m*n" works for matrix multiplication, but you need
> "m.cwiseProduct(n)" for matrix/scalar componentwise product. Or you
> call "(m.array() + 4).matrix() * m" to do coefficientwise addition
> then matrix multiplication. They could implement "m .+ 4 * m " if the
> operators existed
>
The choice we made in oru library (NT2) is to derive semantic of
operators based on the container types and
have manual fallback in case you really want to perform operations in
another way. This have been rather OK for user as the mapping to Matlab
is direct. Not sure any new operator is really needed, make the type be
semantically rich.
--
---
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/.
--------------050100080103080908060800
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 27/08/2013 19:02, Jesse Perla wrote:<br>
</div>
<blockquote
cite="mid:42f8445e-a152-4987-a879-f3e572356cde@isocpp.org"
type="cite">
<div dir="ltr"><span style="line-height: 17px;">Right now, the
librarires use: "+, *, +=, *=, /"</span>
<div>
<div><span style="line-height: 17px;">None of the existing
libraries have an elegant solution for the elementwise
operations, division, powers, or exponentiation. For
example, in eigen "m*n" works for matrix multiplication,
but you need "</span><span style="background-color:
rgb(251, 252, 253); color: rgb(0, 0, 0); font-family:
monospace, fixed; line-height: 13px; text-indent: -53px;
white-space: pre-wrap;">m.cwiseProduct(n)" for
matrix/scalar componentwise product. Or you call "</span><span
style="background-color: rgb(251, 252, 253); color: rgb(0,
0, 0); font-family: monospace, fixed; line-height: 13px;
text-indent: -53px; white-space: pre-wrap;">(m.array() +
4).matrix() * m" to do coefficientwise addition then
matrix multiplication. They could implement "m .+ 4 * m "
if the operators existed</span></div>
</div>
<br>
</div>
</blockquote>
<br>
The choice we made in oru library (NT2) is to derive semantic of
operators based on the container types and<br>
have manual fallback in case you really want to perform operations
in another way. This have been rather OK for user as the mapping to
Matlab is direct. Not sure any new operator is really needed, make
the type be semantically rich.<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--------------050100080103080908060800--
.