Topic: Lightweight Fixed Point Arithmetic
Author: Matheus Izvekov <mizvekov@gmail.com>
Date: Fri, 7 Mar 2014 20:35:47 -0800 (PST)
Raw View
------=_Part_1302_25785651.1394253347632
Content-Type: text/plain; charset=UTF-8
Hi!
This is my first time posting to this forum. Hope this is the right place
for this!
What I want to propose is a lightweight fixed point arithmetic addition to
some future c++ standard.
I have written an implementation to serve as a basis for discussion, and
it's hosted on github at: https://github.com/mizvekov/fp
The implementation is one header only, contained in the file fp.hpp. There
is also a description in the *README*.
It's written with C++14 in mind, and at the moment only clang can compile
it.
What I want from you is help with ideas, improvements, feature requests and
constructive criticisms. I have never done standards work before so
please bear with me :)
I mainly want to know how much interest there is for this, and what kinds
of functionality people would expect.
What I want is to be able to write code like this:
fp<int,8> a = 1.25;
fp<char,4> b = 0.75;
auto c = a * b;
//c has type fp<int,12>
std::cout << double(c);
//prints 0.9375
but right now I have to write code like this:
int a = 1.25 * 256;
char b = 0.75 * 16;
auto c = a * b;
std::cout << double(c) / 4096;
I want to be able to work with fixed point numbers in a type-safe manner,
and not have to keep track of the binary point in my head.
To keep things uncomplicated, the fixed point type should model the usual
promotion and conversion rules for the base integer type.
Right now, I think it's an issue that there is a lot of fixed point math
code written out there in an ad-hoc manner, and modifying it
can easily be like walking in a minefield.
One important consideration is that you can freely mix different fixed
point types, integers and floats in a single expression and
that sensible implicit conversion rules should apply.
I think that this sets this proposal apart from every other fixed point
library that I have seen out there.
Invariably they only allow you to work within one fixed pointer type, and
every arithmetic operation must at the end cast the result
back to fit in the original type. You can not have something like this:
fp<int,16> c = fp<int,8>(1.5) * fp<int,8>(0.75);
You would necessarily have:
fp<int,8> c = fp<int,8>(1.5) * fp<int,8>(0.75);
and the 8 least significant bits would be shifted out and be discarded.
You could try converting each operand individually to fp<int,16>, but
then you would now have to perform a shift 3 times instead of only once!
One for each operand, and then one more time at the end to convert it back
to fp<int,16>. And also now the result could overflow, and you would need a
bigger integer. Clearly it is not optimal.
Now with the fp class I am proposing, this operation would need no shifts
at all, only one multiplication and the result is already at the right type.
Another important feature is that constexpr operations should be used as
much as possible, although implementation issues arise.
And of course, the resulting generated code should be as good performing as
hand-written fixed point manipulation.
Please also read the README file over the github page for a more complete
description, and also check out static_tests.hpp or runtime_tests.cc
for more examples.
Now, these are two things that I think are missing:
* Overloads or member functions for more complicated operations, like those
available for ints and floats in cmath
* Support for specifying how to perform rounding whenever a floating point
number is converted to an integer inside the implementation
And the main issues with the current implementation that I am aware of:
Using binary shift with signed numbers is complicated right now in
constexpr evaluations.
Clang is very strict here in that it doesn't allow implementation defined
results and will error out.
The shifts could be replaced by multiplications and divisions, but worse
code is generated in that case.
There is no portable mechanism right now to have constexpr and
non-constexpr overloads.
In the same vein as above, rounding is complicated because implementations
are not required to provide constexpr rounding functions.
Now please, comments and suggestions welcome :)
--
---
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_1302_25785651.1394253347632
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi!<br><br>This is my first time posting to this forum. Ho=
pe this is the right place for this!<br><br>What I want to propose is a lig=
htweight fixed point arithmetic addition to some future c++ standard.<br><b=
r>I have written an implementation to serve as a basis for discussion, and =
it's hosted on github at: <a href=3D"https://github.com/mizvekov/fp">https:=
//github.com/mizvekov/fp</a><br>The implementation is one header only, cont=
ained in the file fp.hpp. There is also a description in the <i>README</i>.=
<br>It's written with C++14 in mind, and at the moment only clang can compi=
le it.<br><br>What I want from you is help with ideas, improvements, featur=
e requests and constructive criticisms. I have never done standards work be=
fore so<br>please bear with me :)<br>I mainly want to know how much interes=
t there is for this, and what kinds of functionality people would expect.<b=
r><br><br>What I want is to be able to write code like this:<br><br><div cl=
ass=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-c=
olor: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap=
: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">fp</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #066;" cla=
ss=3D"styled-by-prettify">8</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">></span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> a </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #066;" class=3D"styled-by-prettify">1.25</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br>fp</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">char</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">,</span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">4</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">></span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> b </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #066;" class=3D"styled-by-prettify">0.75</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> c </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> a </span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> b</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><=
span style=3D"color: #800;" class=3D"styled-by-prettify">//c has type fp<=
;int,12></span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br>std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">cout </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify"><<</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">double</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">c</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br></span><span style=3D"color: #800;" class=3D"style=
d-by-prettify">//prints 0.9375</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br></span></div></code></div><br>but right now I have =
to write code like this:<br><br><div class=3D"prettyprint" style=3D"backgro=
und-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-sty=
le: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pretty=
print"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"=
styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> a </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #066;" class=3D"styled-by-prettify">1.25</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066=
;" class=3D"styled-by-prettify">256</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">char</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> b </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #066;" class=3D"styled-by-prettify">0.75</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">16</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> c </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> a </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> b</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>std</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify">cout </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify"><<</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">dou=
ble</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">c</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"co=
lor: #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"> </span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">4096</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span></div></code></div><br>I want to be able to work with fixed poin=
t numbers in a type-safe manner, and not have to keep track of the binary p=
oint in my head.<br>To keep things uncomplicated, the fixed point type shou=
ld model the usual promotion and conversion rules for the base integer type=
..<br><br>Right now, I think it's an issue that there is a lot of fixed poin=
t math code written out there in an ad-hoc manner, and modifying it<br>can =
easily be like walking in a minefield.<br><br>One important consideration i=
s that you can freely mix different fixed point types, integers and floats =
in a single expression and<br>that sensible implicit conversion rules shoul=
d apply.<br><br>I think that this sets this proposal apart from every other=
fixed point library that I have seen out there.<br>Invariably they only al=
low you to work within one fixed pointer type, and every arithmetic operati=
on must at the end cast the result<br>back to fit in the original type. You=
can not have something like this:<br><br><div class=3D"prettyprint" 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 clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;=
" class=3D"styled-by-prettify">fp</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">int</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">,</span><span style=3D"color: #066;" class=3D"styled-by-prettify=
">16</span><span style=3D"color: #660;" class=3D"styled-by-prettify">></=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> c </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> fp</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">,</span><span style=3D"color: #066;" class=3D"=
styled-by-prettify">8</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">>(</span><span style=3D"color: #066;" class=3D"styled-by-pret=
tify">1.5</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><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> fp</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">,</span><span style=3D"color: #066;" class=3D"st=
yled-by-prettify">8</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">>(</span><span style=3D"color: #066;" class=3D"styled-by-pretti=
fy">0.75</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span=
></div></code></div><br>You would necessarily have:<br><br><div class=3D"pr=
ettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb=
(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-w=
ord;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #000;" class=3D"styled-by-prettify">fp</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">,</span><span style=3D"color: #066;" class=3D"sty=
led-by-prettify">8</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">></span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> c </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> fp</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #0=
66;" class=3D"styled-by-prettify">8</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">>(</span><span style=3D"color: #066;" class=3D"=
styled-by-prettify">1.5</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> fp</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #066=
;" class=3D"styled-by-prettify">8</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">>(</span><span style=3D"color: #066;" class=3D"s=
tyled-by-prettify">0.75</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br></span></div></code></div><br>and the 8 least significant bits wou=
ld be shifted out and be discarded.<br>You could try converting each operan=
d individually to fp<int,16>, but<br>then you would now have to perfo=
rm a shift 3 times instead of only once!<br>One for each operand, and then =
one more time at the end to convert it back<br>to fp<int,16>. And als=
o now the result could overflow, and you would need a bigger integer. Clear=
ly it is not optimal.<br><br>Now with the fp class I am proposing, this ope=
ration would need no shifts at all, only one multiplication and the result =
is already at the right type.<br><br>Another important feature is that cons=
texpr operations should be used as much as possible, although implementatio=
n issues arise.<br><br>And of course, the resulting generated code should b=
e as good performing as hand-written fixed point manipulation.<br><br>Pleas=
e also read the README file over the github page for a more complete descri=
ption, and also check out static_tests.hpp or runtime_tests.cc<br>for more =
examples.<br><br><br>Now, these are two things that I think are missing:<br=
><br>* Overloads or member functions for more complicated operations, like =
those available for ints and floats in cmath<br>* Support for specifying ho=
w to perform rounding whenever a floating point number is converted to an i=
nteger inside the implementation<br> <br>And the main issues with the =
current implementation that I am aware of:<br><br>Using binary shift with s=
igned numbers is complicated right now in constexpr evaluations.<br>Clang i=
s very strict here in that it doesn't allow implementation defined results =
and will error out.<br>The shifts could be replaced by multiplications and =
divisions, but worse code is generated in that case.<br>There is no portabl=
e mechanism right now to have constexpr and non-constexpr overloads.<br><br=
>In the same vein as above, rounding is complicated because implementations=
are not required to provide constexpr rounding functions.<br><br><br>Now p=
lease, comments and suggestions welcome :)<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 <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_1302_25785651.1394253347632--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sun, 09 Mar 2014 14:11:01 +0100
Raw View
This is a multi-part message in MIME format.
--------------090006070709060405080807
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 08/03/14 05:35, Matheus Izvekov a =C3=A9crit :
> Hi!
>
> This is my first time posting to this forum. Hope this is the right=20
> place for this!
>
> What I want to propose is a lightweight fixed point arithmetic=20
> addition to some future c++ standard.
>
> I have written an implementation to serve as a basis for discussion,=20
> and it's hosted on github at: https://github.com/mizvekov/fp
> The implementation is one header only, contained in the file fp.hpp.=20
> There is also a description in the /README/.
> It's written with C++14 in mind, and at the moment only clang can=20
> compile it.
>
> What I want from you is help with ideas, improvements, feature=20
> requests and constructive criticisms. I have never done standards work=20
> before so
> please bear with me :)
>
Hi,
how your proposed class makes the things easier than the proposed N3352=20
- C++ Binary Fixed-Point Arithmetic [1]?
Why do you qualify it of lightweight?
Vicente
[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html
--=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/.
--------------090006070709060405080807
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 08/03/14 05:35, Matheus Izvekov a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:698aa041-578d-4f60-a33d-568ef1767f79@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">Hi!<br>
<br>
This is my first time posting to this forum. Hope this is the
right place for this!<br>
<br>
What I want to propose is a lightweight fixed point arithmetic
addition to some future c++ standard.<br>
<br>
I have written an implementation to serve as a basis for
discussion, and it's hosted on github at: <a
moz-do-not-send=3D"true" href=3D"https://github.com/mizvekov/fp">=
https://github.com/mizvekov/fp</a><br>
The implementation is one header only, contained in the file
fp.hpp. There is also a description in the <i>README</i>.<br>
It's written with C++14 in mind, and at the moment only clang
can compile it.<br>
<br>
What I want from you is help with ideas, improvements, feature
requests and constructive criticisms. I have never done
standards work before so<br>
please bear with me :)<br>
</div>
<br>
</blockquote>
Hi, <br>
<br>
how your proposed class makes the things easier than the proposed
N3352 - C++ Binary Fixed-Point Arithmetic [1]?<br>
Why do you qualify it of lightweight?<br>
<br>
Vicente<br>
<br>
[1]
<a class=3D"moz-txt-link-freetext" href=3D"http://www.open-std.org/jtc1=
/sc22/wg21/docs/papers/2012/n3352.html">http://www.open-std.org/jtc1/sc22/w=
g21/docs/papers/2012/n3352.html</a><br>
</body>
</html>
<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 <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 />
--------------090006070709060405080807--
.
Author: Matheus Izvekov <mizvekov@gmail.com>
Date: Sun, 9 Mar 2014 08:39:55 -0700 (PDT)
Raw View
------=_Part_58_9786572.1394379595215
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi Vicente,
Thank you for bringing that proposal to my attention, I was unaware of it.
The main difference is that my proposal just wraps an existing integral=20
type, and the value range is determined by that underlying type.
I hope that you can achieve saturating addition if you use a base integral=
=20
type that supports it as the base type.
For example fp<saturating<int>, 8> would be a fixed point type with=20
saturating arithmetic and whatever range of values that type provides.
If just a pure int is used as base type, then overflow is implementation=20
defined, just like operating directly on an int currently is.
Doing saturating arithmetic in a fast manner is a complicated beast that=20
requires compiler support, and I hope to not have to deal with that in this=
=20
proposal.
Another simplifying characteristic is that I am proposing just one=20
templated type, 'fp', while that paper proposes four such types: cardinal,=
=20
integral, nonnegative, negatable.
My proposal deals with the difference between integral and fractional types=
=20
by relying on the exponent template parameter parameter.
It is my intention that fp<int, 0> would behave just like an ordinary int,=
=20
and that you could substitute one for another,
The default value for that template parameter is 0, so it could just be=20
ommited.
The difference between the nonnegative and negatable types in Lawrence's=20
proposal
would be accounted for by the base type in my proposal, where for example=
=20
fp<unsigned int, 8>
would be an unsigned fractional type, and there overflow would be well=20
defined by the standard.
Also, that paper he says there is already an implementation, but it does=20
not link to it. I would like to see that.
The details on the conversion rules he describes seem right and I think are=
=20
similar to what I am proposing, with the exception of the range parameter,
which of course I left out and am delegating that responsibility on another=
=20
proposal for integral types with user specified ranges (which I am not=20
working on).
On the other hand, I am giving you the source there, and you can test it=20
and see for yourself that it performs just as fast as hand-coded fixed=20
point arithmetic.
Does Lawrence frequent this group and is there a good chance he would see=
=20
this thread?
Thank you.
On Sunday, March 9, 2014 10:11:01 AM UTC-3, Vicente J. Botet Escriba wrote:
>
> Le 08/03/14 05:35, Matheus Izvekov a =C3=A9crit :
> =20
> Hi!
>
> This is my first time posting to this forum. Hope this is the right place=
=20
> for this!
>
> What I want to propose is a lightweight fixed point arithmetic addition t=
o=20
> some future c++ standard.
>
> I have written an implementation to serve as a basis for discussion, and=
=20
> it's hosted on github at: https://github.com/mizvekov/fp
> The implementation is one header only, contained in the file fp.hpp. Ther=
e=20
> is also a description in the *README*.
> It's written with C++14 in mind, and at the moment only clang can compile=
=20
> it.
>
> What I want from you is help with ideas, improvements, feature requests=
=20
> and constructive criticisms. I have never done standards work before so
> please bear with me :)
> =20
> Hi,=20
>
> how your proposed class makes the things easier than the proposed N3352 -=
=20
> C++ Binary Fixed-Point Arithmetic [1]?
> Why do you qualify it of lightweight?
>
> Vicente
>
> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html
> =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_58_9786572.1394379595215
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Vicente,<br><br>Thank you for bringing that proposal to=
my attention, I was unaware of it.<br><br>The main difference is that my p=
roposal just wraps an existing integral type, and the value range is determ=
ined by that underlying type.<br>I hope that you can achieve saturating add=
ition if you use a base integral type that supports it as the base type.<br=
>For example fp<saturating<int>, 8> would be a fixed point type=
with saturating arithmetic and whatever range of values that type provides=
..<br>If just a pure int is used as base type, then overflow is implementati=
on defined, just like operating directly on an int currently is.<br>Doing s=
aturating arithmetic in a fast manner is a complicated beast that requires =
compiler support, and I hope to not have to deal with that in this proposal=
..<br><br>Another simplifying characteristic is that I am proposing just one=
templated type, 'fp', while that paper proposes four such types: cardinal,=
integral, nonnegative, negatable.<br>My proposal deals with the difference=
between integral and fractional types by relying on the exponent template =
parameter parameter.<br>It is my intention that fp<int, 0> would beha=
ve just like an ordinary int, and that you could substitute one for another=
,<br>The default value for that template parameter is 0, so it could just b=
e ommited.<br><br>The difference between the nonnegative and negatable typ=
es in Lawrence's proposal<br>would be accounted for by the base type in my =
proposal, where for example fp<unsigned int, 8><br>would be an unsign=
ed fractional type, and there overflow would be well defined by the standar=
d.<br><br>Also, that paper he says there is already an implementation, but =
it does not link to it. I would like to see that.<br>The details on the con=
version rules he describes seem right and I think are similar to what I am =
proposing, with the exception of the range parameter,<br>which of course I =
left out and am delegating that responsibility on another proposal for inte=
gral types with user specified ranges (which I am not working on).<br><br>O=
n the other hand, I am giving you the source there, and you can test it and=
see for yourself that it performs just as fast as hand-coded fixed point a=
rithmetic.<br><br>Does Lawrence frequent this group and is there a good cha=
nce he would see this thread?<br><br>Thank you.<br><br>On Sunday, March 9, =
2014 10:11:01 AM UTC-3, Vicente J. Botet Escriba wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 08/03/14 05:35, Matheus Izvekov a
=C3=A9crit :<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">Hi!<br>
<br>
This is my first time posting to this forum. Hope this is the
right place for this!<br>
<br>
What I want to propose is a lightweight fixed point arithmetic
addition to some future c++ standard.<br>
<br>
I have written an implementation to serve as a basis for
discussion, and it's hosted on github at: <a href=3D"https://github=
..com/mizvekov/fp" target=3D"_blank" onmousedown=3D"this.href=3D'https://www=
..google.com/url?q\75https%3A%2F%2Fgithub.com%2Fmizvekov%2Ffp\46sa\75D\46snt=
z\0751\46usg\75AFQjCNE9axYk-AM1s_3aq_MwcO6lyc57kQ';return true;" onclick=3D=
"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fmiz=
vekov%2Ffp\46sa\75D\46sntz\0751\46usg\75AFQjCNE9axYk-AM1s_3aq_MwcO6lyc57kQ'=
;return true;">https://github.com/mizvekov/fp</a><br>
The implementation is one header only, contained in the file
fp.hpp. There is also a description in the <i>README</i>.<br>
It's written with C++14 in mind, and at the moment only clang
can compile it.<br>
<br>
What I want from you is help with ideas, improvements, feature
requests and constructive criticisms. I have never done
standards work before so<br>
please bear with me :)<br>
</div>
<br>
</blockquote>
Hi, <br>
<br>
how your proposed class makes the things easier than the proposed
N3352 - C++ Binary Fixed-Point Arithmetic [1]?<br>
Why do you qualify it of lightweight?<br>
<br>
Vicente<br>
<br>
[1]
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n335=
2.html" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com=
/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers=
%2F2012%2Fn3352.html\46sa\75D\46sntz\0751\46usg\75AFQjCNG1eP1baW5Z_631XtdWL=
EmLwBJNog';return true;" onclick=3D"this.href=3D'http://www.google.com/url?=
q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F20=
12%2Fn3352.html\46sa\75D\46sntz\0751\46usg\75AFQjCNG1eP1baW5Z_631XtdWLEmLwB=
JNog';return true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers=
/2012/<wbr>n3352.html</a><br>
</div>
</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 <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_58_9786572.1394379595215--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sun, 09 Mar 2014 18:42:06 +0100
Raw View
This is a multi-part message in MIME format.
--------------030708060900000303060005
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 09/03/14 16:39, Matheus Izvekov a =C3=A9crit :
> Hi Vicente,
>
> Thank you for bringing that proposal to my attention, I was unaware of it=
..
>
> The main difference is that my proposal just wraps an existing=20
> integral type, and the value range is determined by that underlying type.
What are the constraints on this integral type?
> I hope that you can achieve saturating addition if you use a base=20
> integral type that supports it as the base type.
> For example fp<saturating<int>, 8> would be a fixed point type with=20
> saturating arithmetic and whatever range of values that type provides.
> If just a pure int is used as base type, then overflow is=20
> implementation defined, just like operating directly on an int=20
> currently is.
> Doing saturating arithmetic in a fast manner is a complicated beast=20
> that requires compiler support, and I hope to not have to deal with=20
> that in this proposal.
What about rounding?
>
> Another simplifying characteristic is that I am proposing just one=20
> templated type, 'fp', while that paper proposes four such types:=20
> cardinal, integral, nonnegative, negatable.
> My proposal deals with the difference between integral and fractional=20
> types by relying on the exponent template parameter parameter.
> It is my intention that fp<int, 0> would behave just like an ordinary=20
> int, and that you could substitute one for another,
> The default value for that template parameter is 0, so it could just=20
> be ommited.
integer and fractional arithmetic are not the same. In addition there=20
are operation that have a sense only for integer or fractional types.
Maybe you need only fractional arithmetic. Others need integer=20
arithmetic as well. Of course there could be separated proposals but the=20
design should be homogeneous.
>
> The difference between the nonnegative and negatable types in=20
> Lawrence's proposal
> would be accounted for by the base type in my proposal, where for=20
> example fp<unsigned int, 8>
> would be an unsigned fractional type, and there overflow would be well=20
> defined by the standard.
I like the possibility for the user to give the representation, but I=20
like also that the class could choose a default one. This is having=20
signed and unsigned classes helps.
>
> Also, that paper he says there is already an implementation, but it=20
> does not link to it. I would like to see that.
I'm not aware of one. I did a prototype that takes in account even more=20
variation points. I don't think you will be interested in, anyway if you=20
are interested you could take a look at [1]
> The details on the conversion rules he describes seem right and I=20
> think are similar to what I am proposing, with the exception of the=20
> range parameter,
> which of course I left out and am delegating that responsibility on=20
> another proposal for integral types with user specified ranges (which=20
> I am not working on).
>
I really think the Range parameter is a must have.
> On the other hand, I am giving you the source there, and you can test=20
> it and see for yourself that it performs just as fast as hand-coded=20
> fixed point arithmetic.
I believe you about the performances. I'm sure the interface proposed by=20
Laurence could perform as well.
I see some issues with the definition of
template<class A, class B> using conv_type =3D decltype(A() + B()); When=20
multiplying A and B this type could be not big enough. In addition the=20
declaration of
#define DECL template<class A, class B> friend constexpr
DECL auto operator+(const A &a, const B &b) { return=20
bin_op<max,std::plus >(proxy<B>(a), proxy<A>(b)); } would introduce=20
ambiguities as there are no constraints on the template parameters.
>
> Does Lawrence frequent this group and is there a good chance he would=20
> see this thread?
>
Yes, from time to time. He participates more on c++std groups.
Best,
Vicente
[1] https://svn.boost.org/svn/boost/sandbox/fixed_point/
BTW, you didn't answered explicitly to my question
Why do you qualify it of lightweight?
--=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/.
--------------030708060900000303060005
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 09/03/14 16:39, Matheus Izvekov a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:a1abf1d6-a211-4e0a-bae0-ba9d9a47a1f2@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">Hi Vicente,<br>
<br>
Thank you for bringing that proposal to my attention, I was
unaware of it.<br>
<br>
The main difference is that my proposal just wraps an existing
integral type, and the value range is determined by that
underlying type.<br>
</div>
</blockquote>
What are the constraints on this integral type?<br>
<blockquote
cite=3D"mid:a1abf1d6-a211-4e0a-bae0-ba9d9a47a1f2@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">I hope that you can achieve saturating addition if
you use a base integral type that supports it as the base type.<br>
For example fp<saturating<int>, 8> would be a fixed
point type with saturating arithmetic and whatever range of
values that type provides.<br>
If just a pure int is used as base type, then overflow is
implementation defined, just like operating directly on an int
currently is.<br>
Doing saturating arithmetic in a fast manner is a complicated
beast that requires compiler support, and I hope to not have to
deal with that in this proposal.<br>
</div>
</blockquote>
What about rounding?<br>
<blockquote
cite=3D"mid:a1abf1d6-a211-4e0a-bae0-ba9d9a47a1f2@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
Another simplifying characteristic is that I am proposing just
one templated type, 'fp', while that paper proposes four such
types: cardinal, integral, nonnegative, negatable.<br>
My proposal deals with the difference between integral and
fractional types by relying on the exponent template parameter
parameter.<br>
It is my intention that fp<int, 0> would behave just like
an ordinary int, and that you could substitute one for another,<br>
The default value for that template parameter is 0, so it could
just be ommited.<br>
</div>
</blockquote>
integer and fractional arithmetic are not the same. In addition
there are operation that have a sense only for integer or fractional
types.<br>
Maybe you need only fractional arithmetic. Others need integer
arithmetic as well. Of course there could be separated proposals but
the design should be homogeneous.<br>
=C2=A0<br>
<blockquote
cite=3D"mid:a1abf1d6-a211-4e0a-bae0-ba9d9a47a1f2@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
The difference between the nonnegative and negatable types in
Lawrence's proposal<br>
would be accounted for by the base type in my proposal, where
for example fp<unsigned int, 8><br>
would be an unsigned fractional type, and there overflow would
be well defined by the standard.<br>
</div>
</blockquote>
I like the possibility for the user to give the representation, but
I like also that the class could choose a default one. This is
having signed and unsigned classes helps.<br>
<blockquote
cite=3D"mid:a1abf1d6-a211-4e0a-bae0-ba9d9a47a1f2@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
Also, that paper he says there is already an implementation, but
it does not link to it. I would like to see that.<br>
</div>
</blockquote>
I'm not aware of one. I did a prototype that takes in account even
more variation points. I don't think you will be interested in,
anyway if you are interested=C2=A0 you could take a look at [1]<br>
<blockquote
cite=3D"mid:a1abf1d6-a211-4e0a-bae0-ba9d9a47a1f2@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">The details on the conversion rules he describes
seem right and I think are similar to what I am proposing, with
the exception of the range parameter,<br>
which of course I left out and am delegating that responsibility
on another proposal for integral types with user specified
ranges (which I am not working on).<br>
<br>
</div>
</blockquote>
I really think the Range parameter is a must have. <br>
<blockquote
cite=3D"mid:a1abf1d6-a211-4e0a-bae0-ba9d9a47a1f2@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">On the other hand, I am giving you the source
there, and you can test it and see for yourself that it performs
just as fast as hand-coded fixed point arithmetic.<br>
</div>
</blockquote>
I believe you about the performances. I'm sure the interface
proposed by Laurence could perform as well.<br>
I see some issues with the definition of<br>
<br>
<meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8=
">
<pre><div class=3D"line" id=3D"LC100"> <span class=3D"k">template</span=
><span class=3D"o"><</span><span class=3D"k">class</span> <span class=3D=
"nc">A</span><span class=3D"p">,</span> <span class=3D"k">class</span> <spa=
n class=3D"nc">B</span><span class=3D"o">></span> <span class=3D"k">usin=
g</span> <span class=3D"n">conv_type</span> <span class=3D"o">=3D</span> <s=
pan class=3D"n">decltype</span><span class=3D"p">(</span><span class=3D"n">=
A</span><span class=3D"p">()</span> <span class=3D"o">+</span> <span class=
=3D"n">B</span><span class=3D"p">());
</span><span class=3D"p">When multiplying A and B this type could be not bi=
g enough.
In addition the declaration of
</span><meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUT=
F-8"><pre><div class=3D"line" id=3D"LC55"><span class=3D"cp">#define DECL t=
emplate<class A, class B> friend constexpr</span></div><div class=3D"=
line" id=3D"LC56"> <span class=3D"n">DECL</span> <span class=3D"k">auto</sp=
an> <span class=3D"k">operator</span><span class=3D"o">+</span><span class=
=3D"p">(</span><span class=3D"k">const</span> <span class=3D"n">A</span> <s=
pan class=3D"o">&</span><span class=3D"n">a</span><span class=3D"p">,</=
span> <span class=3D"k">const</span> <span class=3D"n">B</span> <span class=
=3D"o">&</span><span class=3D"n">b</span><span class=3D"p">)</span> <sp=
an class=3D"p">{</span> <span class=3D"k">return</span> <span class=3D"n">b=
in_op</span><span class=3D"o"><</span><span class=3D"n">max</span><span =
class=3D"p">,</span><span class=3D"n">std</span><span class=3D"o">::</span>=
<span class=3D"n">plus</span> <span class=3D"o">></span><span class=
=3D"p">(</span><span class=3D"n">proxy</span><span class=3D"o"><</span><=
span class=3D"n">B</span
><span class=3D"o">></span><span class=3D"p">(</span><span class=3D"n">a=
</span><span class=3D"p">),</span> <span class=3D"n">proxy</span><span clas=
s=3D"o"><</span><span class=3D"n">A</span><span class=3D"o">></span><=
span class=3D"p">(</span><span class=3D"n">b</span><span class=3D"p">));</s=
pan> <span class=3D"p">}
would introduce ambiguities as there are no constraints on the template par=
ameters.
</span></div></pre>
</div></pre>
<blockquote
cite=3D"mid:a1abf1d6-a211-4e0a-bae0-ba9d9a47a1f2@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
Does Lawrence frequent this group and is there a good chance he
would see this thread?<br>
<br>
</div>
</blockquote>
Yes, from time to time. He participates more on c++std groups.<br>
<br>
Best,<br>
Vicente<br>
<br>
[1] <a class=3D"moz-txt-link-freetext" href=3D"https://svn.boost.org/sv=
n/boost/sandbox/fixed_point/">https://svn.boost.org/svn/boost/sandbox/fixed=
_point/</a><br>
<br>
BTW, you didn't answered explicitly=C2=A0 to my question<br>
Why do you qualify it of lightweight?<br>
</body>
</html>
<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 <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 />
--------------030708060900000303060005--
.
Author: Matheus Izvekov <mizvekov@gmail.com>
Date: Sun, 9 Mar 2014 12:05:22 -0700 (PDT)
Raw View
------=_Part_2499_30188821.1394391922491
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, March 9, 2014 2:42:06 PM UTC-3, Vicente J. Botet Escriba wrote:
>
> Le 09/03/14 16:39, Matheus Izvekov a =C3=A9crit :
> =20
> What are the constraints on this integral type?
>
It should specialize is_integral to true, support all operators that the=20
fundamental integers do, and it should be default constructible.
>
> What about rounding?
>
Like I said in the original post, that is one thing I want to support there=
..
I am not sure yet on the syntax, probably another template parameter would=
=20
be best.
And I think this rounding should only be supported whenever internally a=20
floating point must be converted to an integer.
I don't think it should apply to conversions between fp types, because=20
there is generally no support for doing this fast in hardware,
and the main uses for this is in high performance code.
If rounding is to be applied between those conversions, I think a separate=
=20
function to do this explicitly (like std::lround) is preferred.
>
> integer and fractional arithmetic are not the same. In addition there are=
=20
> operation that have a sense only for integer or fractional types.
> Maybe you need only fractional arithmetic. Others need integer arithmetic=
=20
> as well. Of course there could be separated proposals but the design shou=
ld=20
> be homogeneous.
> =20
>
But the proposal I submitted is homogeneous, all operations are well=20
defined for integrals (E =3D=3D 0) and non-integrals (E !=3D 0)
What operations do you think should be supported for one kind and not the=
=20
other?
At any rate, if you are thinking of more complicated functions like=20
straight factorial for example,
then this function could easily require that the passed fp type has E =3D=
=3D 0.
> =20
> The difference between the nonnegative and negatable types in Lawrence's=
=20
> proposal
> would be accounted for by the base type in my proposal, where for example=
=20
> fp<unsigned int, 8>
> would be an unsigned fractional type, and there overflow would be well=20
> defined by the standard.
> =20
> I like the possibility for the user to give the representation, but I lik=
e=20
> also that the class could choose a default one. This is having signed and=
=20
> unsigned classes helps.
>
Then maybe what you want could fit here by providing aliases to the fp=20
variants of the existing integral type.
An alias to fp<unsigned int, E> could be provided, as could to other types.
If you want it to support automatically selecting the most appropriate type=
=20
for a given range, then maybe a separate proposal
could specify a type just like that.
For example suppose there exists a type function 'ranged_integer' which=20
given a range as a template parameter returns a type for an appropriate
integer. You could then easily combine this here by doing =20
fp<ranged_integer_t<65536>, 8>.
I'm not aware of one. I did a prototype that takes in account even more=20
> variation points. I don't think you will be interested in, anyway if you=
=20
> are interested you could take a look at [1]
>
Thank you, I will take a look later. I am interested in knowing what=20
features people are interested in.=20
> The details on the conversion rules he describes seem right and I think=
=20
> are similar to what I am proposing, with the exception of the range=20
> parameter,
> which of course I left out and am delegating that responsibility on=20
> another proposal for integral types with user specified ranges (which I a=
m=20
> not working on).
>
> I really think the Range parameter is a must have.
>
Like I said above, I think this could be better combined with another=20
proposal for a ranged integer.=20
I believe you about the performances. I'm sure the interface proposed by=20
> Laurence could perform as well.
> I see some issues with the definition of
>
> template<class A, class B> using conv_type =3D decltype(A() + B());
> When multiplying A and B this type could be not big enough.
>
>
I think I see that you mean. This was intentional, and I think one of the t=
hings that makes this proposal lightweight is that the fp types behave as c=
losely as possible
to the underlying integral types.
But suppose the user provides a special safe_integer which has safer conver=
sion rules, and for those the multiply operation is defined in a way that t=
he resulting type
has a bigger range. Then I would not be taking advantage of that here.
I suppose it would be worth it to support base types with different convers=
ion rules than the fundamental integers, a type in which decltype(T() + T()=
) is not the same as decltype(T() * T())
I could certainly look into this improvement.
>
> In addition the declaration of
>
>
> #define DECL template<class A, class B> friend constexpr
> DECL auto operator+(const A &a, const B &b) { return bin_op<max,std::plu=
s >(proxy<B>(a), proxy<A>(b)); }
>
> would introduce ambiguities as there are no constraints on the template p=
arameters.
>
>
Not actually I think. The fact that this is declared here as friend=20
function would mean that it would only be brought in when one of the=20
parameters is a fp instance, due to ADL.
If any one parameter is a fp type and the other is not, then the call to=20
proxy will select an overload which tries to convert it to the same type as=
=20
the other.
proxy has two overloads. One overload is a template which accepts a=20
reference to any fp instance, and in doing so returns that reference=20
unchanged.
The other overload will perform a conversion to an fp type.
If you think there is a case where this breaks, I would be happy to fix it.=
=20
>
> [1] https://svn.boost.org/svn/boost/sandbox/fixed_point/
>
> BTW, you didn't answered explicitly to my question
> Why do you qualify it of lightweight?
>
I would qualify it as lightweight because I am not trying to introduce many=
=20
features which I think are contentious and would be better served
by different proposals. I think a better approach is to create something=20
which is simpler and in any case composable.
If those features I mentioned like saturating arithmetic, 'ranged integers'=
=20
and such are introduced in the future, then they could be combined here
by using them as base types.
--=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_2499_30188821.1394391922491
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Sunday, March 9, 2014 2:42:06 PM UTC-3, Vicente J. =
Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 09/03/14 16:39, Matheus Izvekov a
=C3=A9crit :<br>
</div>
<br>
What are the constraints on this integral type?<br></div></blockquote><=
div><br>It should specialize is_integral to true, support all operators tha=
t the fundamental integers do, and it should be default constructible.<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" =
text=3D"#000000">
<br>
What about rounding?<br></div></blockquote><div><br>Like I said in the =
original post, that is one thing I want to support there.<br>I am not sure =
yet on the syntax, probably another template parameter would be best.<br>An=
d I think this rounding should only be supported whenever internally a floa=
ting point must be converted to an integer.<br>I don't think it should appl=
y to conversions between fp types, because there is generally no support fo=
r doing this fast in hardware,<br>and the main uses for this is in high per=
formance code.<br>If rounding is to be applied between those conversions, I=
think a separate function to do this explicitly (like std::lround) is pref=
erred.<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=
=3D"#FFFFFF" text=3D"#000000">
<br>
integer and fractional arithmetic are not the same. In addition
there are operation that have a sense only for integer or fractional
types.<br>
Maybe you need only fractional arithmetic. Others need integer
arithmetic as well. Of course there could be separated proposals but
the design should be homogeneous.<br>
<br></div></blockquote><div><br>But the proposal I submitted is h=
omogeneous, all operations are well defined for integrals (E =3D=3D 0) and =
non-integrals (E !=3D 0)<br>What operations do you think should be supporte=
d for one kind and not the other?<br>At any rate, if you are thinking of mo=
re complicated functions like straight factorial for example,<br>then this =
function could easily require that the passed fp type has E =3D=3D 0.<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" t=
ext=3D"#000000">
<blockquote type=3D"cite">
<div dir=3D"ltr"><br>
The difference between the nonnegative and negatable types in
Lawrence's proposal<br>
would be accounted for by the base type in my proposal, where
for example fp<unsigned int, 8><br>
would be an unsigned fractional type, and there overflow would
be well defined by the standard.<br>
</div>
</blockquote>
I like the possibility for the user to give the representation, but
I like also that the class could choose a default one. This is
having signed and unsigned classes helps.<br></div></blockquote><div di=
r=3D"ltr"><br>Then maybe what you want could fit here by providing aliases =
to the fp variants of the existing integral type.<br>An alias to fp<unsi=
gned int, E> could be provided, as could to other types.<br>If you want =
it to support automatically selecting the most appropriate type for a given=
range, then maybe a separate proposal<br>could specify a type just like th=
at.<br>For example suppose there exists a type function 'ranged_integer' wh=
ich given a range as a template parameter returns a type for an appropriate=
<br>integer. You could then easily combine this here by doing fp<r=
anged_integer_t<65536>, 8>.<br><br>
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"=
#FFFFFF" text=3D"#000000">I'm not aware of one. I did a prototype that take=
s in account even
more variation points. I don't think you will be interested in,
anyway if you are interested you could take a look at [1]<br></di=
v></blockquote><div><br>Thank you, I will take a look later. I am intereste=
d in knowing what features people are interested in. <br></div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
<blockquote type=3D"cite">
<div dir=3D"ltr">The details on the conversion rules he describes
seem right and I think are similar to what I am proposing, with
the exception of the range parameter,<br>
which of course I left out and am delegating that responsibility
on another proposal for integral types with user specified
ranges (which I am not working on).<br>
<br>
</div>
</blockquote>
I really think the Range parameter is a must have.<br></div></blockquot=
e><div><br>Like I said above, I think this could be better combined with an=
other proposal for a ranged integer. <br></div><div><br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
#ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">I=
believe you about the performances. I'm sure the interface
proposed by Laurence could perform as well.<br>
I see some issues with the definition of<br>
<br>
=20
<pre><div> <span>template</span><span><</span><span>class</span> <sp=
an>A</span><span>,</span> <span>class</span> <span>B</span><span>></span=
> <span>using</span> <span>conv_type</span> <span>=3D</span> <span>decltype=
</span><span>(</span><span>A</span><span>()</span> <span>+</span> <span>B</=
span><span>());
</span><span>When multiplying A and B this type could be not big enough.</s=
pan></div></pre></div></blockquote><div><br><pre>I think I see that you mea=
n. This was intentional, and I think one of the things that makes this prop=
osal lightweight is that the fp types behave as closely as possible<br>to t=
he underlying integral types.<br>But suppose the user provides a special sa=
fe_integer which has safer conversion rules, and for those the multiply ope=
ration is defined in a way that the resulting type<br>has a bigger range. T=
hen I would not be taking advantage of that here.<br>I suppose it would be =
worth it to support base types with different conversion rules than the fun=
damental integers, a type in which decltype(T() + T()) is not the same as d=
ecltype(T() * T())<br>I could certainly look into this improvement.</pre><b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFF=
F" text=3D"#000000"><pre><div><br><span>
In addition the declaration of
</span><pre><div><span>#define DECL template<class A, class B> friend=
constexpr</span></div><div> <span>DECL</span> <span>auto</span> <span>oper=
ator</span><span>+</span><span>(</span><span>const</span> <span>A</span> <s=
pan>&</span><span>a</span><span>,</span> <span>const</span> <span>B</sp=
an> <span>&</span><span>b</span><span>)</span> <span>{</span> <span>ret=
urn</span> <span>bin_op</span><span><</span><span>max</span><span>,</spa=
n><span>std</span><span>::</span><span>plus</span> <span>></span><s=
pan>(</span><span>proxy</span><span><</span><span>B</span><span>></sp=
an><span>(</span><span>a</span><span>),</span> <span>proxy</span><span><=
</span><span>A</span><span>></span><span>(</span><span>b</span><span>));=
</span> <span>}
would introduce ambiguities as there are no constraints on the template par=
ameters.</span></div></pre></div></pre></div></blockquote><div><br>Not actu=
ally I think. The fact that this is declared here as friend=20
function would mean that it would only be brought in when one of the=20
parameters is a fp instance, due to ADL.<br>If any one parameter is a fp
type and the other is not, then the call to proxy will select an=20
overload which tries to convert it to the same type as the other.<br><br>pr=
oxy
has two overloads. One overload is a template which accepts a reference
to any fp instance, and in doing so returns that reference unchanged.<br>T=
he other overload will perform a conversion to an fp type.<br><br>If you th=
ink there is a case where this breaks, I would be happy to fix it. <br></di=
v><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=
=3D"#FFFFFF" text=3D"#000000"><br>
<br>
[1] <a href=3D"https://svn.boost.org/svn/boost/sandbox/fixed_point/" ta=
rget=3D"_blank" onmousedown=3D"this.href=3D'https://www.google.com/url?q\75=
https%3A%2F%2Fsvn.boost.org%2Fsvn%2Fboost%2Fsandbox%2Ffixed_point%2F\46sa\7=
5D\46sntz\0751\46usg\75AFQjCNEwTh7fYqdBiDygaSDL8L0cLb91CQ';return true;" on=
click=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fsvn.boos=
t.org%2Fsvn%2Fboost%2Fsandbox%2Ffixed_point%2F\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNEwTh7fYqdBiDygaSDL8L0cLb91CQ';return true;">https://svn.boost.org/sv=
n/<wbr>boost/sandbox/fixed_point/</a><br>
<br>
BTW, you didn't answered explicitly to my question<br>
Why do you qualify it of lightweight?<br></div></blockquote><div><br>I =
would qualify it as lightweight because I am not trying to introduce many f=
eatures which I think are contentious and would be better served<br>by diff=
erent proposals. I think a better approach is to create something which is =
simpler and in any case composable.<br>If those features I mentioned like s=
aturating arithmetic, 'ranged integers' and such are introduced in the futu=
re, then they could be combined here<br>by using them as base types.<br></d=
iv></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 <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_2499_30188821.1394391922491--
.
Author: Matheus Izvekov <mizvekov@gmail.com>
Date: Sun, 9 Mar 2014 12:52:09 -0700 (PDT)
Raw View
------=_Part_2487_20505388.1394394729597
Content-Type: text/plain; charset=UTF-8
On Sunday, March 9, 2014 4:05:22 PM UTC-3, Matheus Izvekov wrote:
>
>
> But the proposal I submitted is homogeneous, all operations are well
> defined for integrals (E == 0) and non-integrals (E != 0)
> What operations do you think should be supported for one kind and not the
> other?
> At any rate, if you are thinking of more complicated functions like
> straight factorial for example,
> then this function could easily require that the passed fp type has E == 0.
>
Actually I made a mistake here. I want to clarify that in this proposal,
'integrals' in that sense would be
any fp type which has E <= 0. Fractionals would be the ones in which E > 0.
I was thinking more in the sense of which type most closely models the
fundamental integer, and that would be
the ones where E == 0.
--
---
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_2487_20505388.1394394729597
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, March 9, 2014 4:05:22 PM UTC-3, Matheus Izvekov=
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"><br><d=
iv>But the proposal I submitted is homogeneous, all operations are well def=
ined for integrals (E =3D=3D 0) and non-integrals (E !=3D 0)<br>What operat=
ions do you think should be supported for one kind and not the other?<br>At=
any rate, if you are thinking of more complicated functions like straight =
factorial for example,<br>then this function could easily require that the =
passed fp type has E =3D=3D 0.<br></div></div></blockquote><div><br>Actuall=
y I made a mistake here. I want to clarify that in this proposal, 'integral=
s' in that sense would be<br>any fp type which has E <=3D 0. Fract=
ionals would be the ones in which E > 0.<br>I was thinking more in the s=
ense of which type most closely models the fundamental integer, and that wo=
uld be<br>the ones where E =3D=3D 0.<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 <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_2487_20505388.1394394729597--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 09 Mar 2014 16:46:10 -0700
Raw View
Em dom 09 mar 2014, =E0s 12:05:22, Matheus Izvekov escreveu:
> It should specialize is_integral to true, support all operators that the=
=20
> fundamental integers do, and it should be default constructible.
Please don't specialise the type traits like is_integral, is_unsigned, etc.=
,=20
ever.
--=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/.
.
Author: Matheus Izvekov <mizvekov@gmail.com>
Date: Sun, 9 Mar 2014 17:03:11 -0700 (PDT)
Raw View
------=_Part_543_16484512.1394409791725
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, March 9, 2014 8:46:10 PM UTC-3, Thiago Macieira wrote:
>
> Em dom 09 mar 2014, =C3=A0s 12:05:22, Matheus Izvekov escreveu:=20
> > It should specialize is_integral to true, support all operators that th=
e=20
> > fundamental integers do, and it should be default constructible.=20
>
> Please don't specialise the type traits like is_integral, is_unsigned,=20
> etc.,=20
> ever.=20
>
>
I am stating the requirements on the base type supplied as a parameter.
If there is ever a proposal put forward for another kind of integer, like a=
=20
saturating integer or an infinite precision int, then
it would also specialize these traits, right?
=20
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
> Software Architect - Intel Open Source Technology Center=20
> PGP/GPG: 0x6EF45358; fingerprint:=20
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358=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_543_16484512.1394409791725
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sunday, March 9, 2014 8:46:10 PM UTC-3, Thiago =
Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Em dom 09 mar 2=
014, =C3=A0s 12:05:22, Matheus Izvekov escreveu:
<br>> It should specialize is_integral to true, support all operators th=
at the=20
<br>> fundamental integers do, and it should be default constructible.
<br>
<br>Please don't specialise the type traits like is_integral, is_unsigned, =
etc.,=20
<br>ever.
<br>
<br></blockquote><div><br>I am stating the requirements on the base type su=
pplied as a parameter.<br>If there is ever a proposal put forward for anoth=
er kind of integer, like a saturating integer or an infinite precision int,=
then<br>it would also specialize these traits, right?<br> </div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%=
3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNCNanbu7euhq=
Ln_62FW8ag';return true;" onclick=3D"this.href=3D'http://www.google.com/url=
?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNC=
Nanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - thiago (AT) <a href=
=3D"http://kde.org" target=3D"_blank" onmousedown=3D"this.href=3D'http://ww=
w.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQj=
CNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'http:=
//www.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75=
AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a>
<br> Software Architect - Intel Open Source Technology Center
<br> PGP/GPG: 0x6EF45358; fingerprint:
<br> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4=
5358
<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 <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_543_16484512.1394409791725--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Mon, 10 Mar 2014 01:10:13 +0100
Raw View
This is a multi-part message in MIME format.
--------------030909030301050909010906
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 09/03/14 20:05, Matheus Izvekov a =C3=A9crit :
>
> On Sunday, March 9, 2014 2:42:06 PM UTC-3, Vicente J. Botet Escriba=20
> wrote:
>
> Le 09/03/14 16:39, Matheus Izvekov a =C3=A9crit :
>
> What are the constraints on this integral type?
>
>
> It should specialize is_integral to true, support all operators that=20
> the fundamental integers do, and it should be default constructible.
I'm not sure the user can specialize this trait.
>
>
> What about rounding?
>
>
> Like I said in the original post, that is one thing I want to support=20
> there.
> I am not sure yet on the syntax, probably another template parameter=20
> would be best.
> And I think this rounding should only be supported whenever internally=20
> a floating point must be converted to an integer.
We need rounding whenever we lost in precision.
> I don't think it should apply to conversions between fp types, because=20
> there is generally no support for doing this fast in hardware,
> and the main uses for this is in high performance code.
I disagree here. This operation is quite common in some domains.
> If rounding is to be applied between those conversions, I think a=20
> separate function to do this explicitly (like std::lround) is preferred.
Anytime there is a loss of precision the user must do it explicitly. I=20
believed that N3352 had a cast operation. Anyway, my implementation has=20
one number_cast operation that takes care of this.
>
>
> integer and fractional arithmetic are not the same. In addition
> there are operation that have a sense only for integer or
> fractional types.
> Maybe you need only fractional arithmetic. Others need integer
> arithmetic as well. Of course there could be separated proposals
> but the design should be homogeneous.
>
>
> But the proposal I submitted is homogeneous, all operations are well=20
> defined for integrals (E =3D=3D 0) and non-integrals (E !=3D 0)
> What operations do you think should be supported for one kind and not=20
> the other?
You can take a look at N3352. All the bitwise operations had only a sens=20
on cardinal types. modulo has a sens only for integral and cardinal.=20
division only on fractional types. division on intrgral types would need=20
a rounding policy (truncation could be the default however). Increasing=20
(operators ++ and --) a fractional number is subject to interpretations.
> At any rate, if you are thinking of more complicated functions like=20
> straight factorial for example,
> then this function could easily require that the passed fp type has E=20
> =3D=3D 0.
>
>>
>> The difference between the nonnegative and negatable types in
>> Lawrence's proposal
>> would be accounted for by the base type in my proposal, where for
>> example fp<unsigned int, 8>
>> would be an unsigned fractional type, and there overflow would be
>> well defined by the standard.
> I like the possibility for the user to give the representation,
> but I like also that the class could choose a default one. This is
> having signed and unsigned classes helps.
>
>
> Then maybe what you want could fit here by providing aliases to the fp=20
> variants of the existing integral type.
> An alias to fp<unsigned int, E> could be provided, as could to other=20
> types.
> If you want it to support automatically selecting the most appropriate=20
> type for a given range, then maybe a separate proposal
> could specify a type just like that.
> For example suppose there exists a type function 'ranged_integer'=20
> which given a range as a template parameter returns a type for an=20
> appropriate
> integer. You could then easily combine this here by doing=20
> fp<ranged_integer_t<65536>, 8>.
I'm not against your proposal, but in order to convince me I need to see=20
how do you take care of all the things N3352 provides. IMHO, saying that=20
the type given as parameter could resolve all the issues needs more=20
arguments and probes.
How your library would take care of the range?
What would be the result of fp<ranged_integer_t<256>,=20
8>+fp<ranged_integer_t<256>, 8>?
>
> I'm not aware of one. I did a prototype that takes in account even
> more variation points. I don't think you will be interested in,
> anyway if you are interested you could take a look at [1]
>
>
> Thank you, I will take a look later. I am interested in knowing what=20
> features people are interested in.
There are some domains that don't care if the result of T+T is bigger=20
than T. Others want that T+T->T. This is what I called closed versus=20
open arithmetic.
Others don't want to work with arbitrary size and want to be limited to=20
some builtin type. This is what I called bounded versus unbounded=20
arithmetic.
>
>> The details on the conversion rules he describes seem right and I
>> think are similar to what I am proposing, with the exception of
>> the range parameter,
>> which of course I left out and am delegating that responsibility
>> on another proposal for integral types with user specified ranges
>> (which I am not working on).
>>
> I really think the Range parameter is a must have.
>
>
> Like I said above, I think this could be better combined with another=20
> proposal for a ranged integer.
Sorry, but I need a probe. Once we see that this is possible I will have=20
no problem with your proposal.
>
> I believe you about the performances. I'm sure the interface
> proposed by Laurence could perform as well.
> I see some issues with the definition of
>
> template<class A, class B> using conv_type =3D decltype(A() + B());
> When multiplying A and B this type could be not big enough.
>
>
> I think I see that you mean. This was intentional, and I think one of the=
things that makes this proposal lightweight is that the fp types behave as=
closely as possible
> to the underlying integral types.
> But suppose the user provides a special safe_integer which has safer conv=
ersion rules, and for those the multiply operation is defined in a way that=
the resulting type
> has a bigger range. Then I would not be taking advantage of that here.
> I suppose it would be worth it to support base types with different conve=
rsion rules than the fundamental integers, a type in which decltype(T() + T=
()) is not the same as decltype(T() * T())
> I could certainly look into this improvement.
>
Great.
>
> In addition the declaration of
>
> #define DECL template<class A, class B> friend constexpr
> DECL auto operator+(const A &a, const B &b) { return
> bin_op<max,std::plus >(proxy<B>(a), proxy<A>(b)); } would
> introduce ambiguities as there are no constraints on the template
> parameters.
>
>
> Not actually I think. The fact that this is declared here as friend=20
> function would mean that it would only be brought in when one of the=20
> parameters is a fp instance, due to ADL.
If this is true, you have teach me something important. Could you point=20
me where in the standard this is defined?
> If any one parameter is a fp type and the other is not, then the call=20
> to proxy will select an overload which tries to convert it to the same=20
> type as the other.
>
> proxy has two overloads. One overload is a template which accepts a=20
> reference to any fp instance, and in doing so returns that reference=20
> unchanged.
> The other overload will perform a conversion to an fp type.
>
> If you think there is a case where this breaks, I would be happy to=20
> fix it.
I will give a try to your implementation. I will come back then.
>
>
>
> [1] https://svn.boost.org/svn/boost/sandbox/fixed_point/
> <https://svn.boost.org/svn/boost/sandbox/fixed_point/>
>
> BTW, you didn't answered explicitly to my question
> Why do you qualify it of lightweight?
>
>
> I would qualify it as lightweight because I am not trying to introduce=20
> many features which I think are contentious and would be better served
> by different proposals. I think a better approach is to create=20
> something which is simpler and in any case composable.
I'm always for separation of concerns, but I need to see that I can=20
compose them. When interactions between the different concerns appear we=20
need some entity that manage them.
> If those features I mentioned like saturating arithmetic, 'ranged=20
> integers' and such are introduced in the future, then they could be=20
> combined here
> by using them as base types.
It would be great if you can implement such a type of family of types,=20
aware of overflow and rounding strategies and of the range bounds. IMO,=20
you will end by defining what N3352 and my implementation propose. And=20
IMHO, the exponent would be also part of the underlying type.
But maybe you can probe the opposite, which will be really appreciated.
Best,
Vicente
--=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/.
--------------030909030301050909010906
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 09/03/14 20:05, Matheus Izvekov a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:17f4d473-56f2-4e1a-92a7-b26396256ad6@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
On Sunday, March 9, 2014 2:42:06 PM UTC-3, Vicente J. Botet
Escriba wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 09/03/14 16:39, Matheus Izvekov a =C3=A9crit=C2=A0:<br>
</div>
<br>
What are the constraints on this integral type?<br>
</div>
</blockquote>
<div><br>
It should specialize is_integral to true, support all
operators that the fundamental integers do, and it should be
default constructible.<br>
</div>
</div>
</blockquote>
I'm not sure the user can specialize this trait.<br>
<blockquote
cite=3D"mid:17f4d473-56f2-4e1a-92a7-b26396256ad6@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"> <br>
What about rounding?<br>
</div>
</blockquote>
<div><br>
Like I said in the original post, that is one thing I want to
support there.<br>
I am not sure yet on the syntax, probably another template
parameter would be best.<br>
And I think this rounding should only be supported whenever
internally a floating point must be converted to an integer.<br>
</div>
</div>
</blockquote>
We need rounding whenever we lost in precision.<br>
<blockquote
cite=3D"mid:17f4d473-56f2-4e1a-92a7-b26396256ad6@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>I don't think it should apply to conversions between fp
types, because there is generally no support for doing this
fast in hardware,<br>
and the main uses for this is in high performance code.<br>
</div>
</div>
</blockquote>
I disagree here. This operation is quite common in some domains.<br>
<blockquote
cite=3D"mid:17f4d473-56f2-4e1a-92a7-b26396256ad6@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>If rounding is to be applied between those conversions, I
think a separate function to do this explicitly (like
std::lround) is preferred.<br>
</div>
</div>
</blockquote>
Anytime there is a loss of precision the user must do it explicitly.
I believed that N3352 had a cast operation. Anyway, my
implementation has one number_cast operation that takes care of
this. <br>
<blockquote
cite=3D"mid:17f4d473-56f2-4e1a-92a7-b26396256ad6@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"> <br>
integer and fractional arithmetic are not the same. In
addition there are operation that have a sense only for
integer or fractional types.<br>
Maybe you need only fractional arithmetic. Others need
integer arithmetic as well. Of course there could be
separated proposals but the design should be homogeneous.<br>
=C2=A0<br>
</div>
</blockquote>
<div><br>
But the proposal I submitted is homogeneous, all operations
are well defined for integrals (E =3D=3D 0) and non-integrals (E
!=3D 0)<br>
What operations do you think should be supported for one kind
and not the other?<br>
</div>
</div>
</blockquote>
You can take a look at N3352. All the bitwise operations had only a
sens on cardinal types. modulo has a sens only for integral and
cardinal. division only on fractional types. division on intrgral
types would need a rounding policy (truncation could be the default
however). Increasing (operators ++ and --) a fractional number is
subject to interpretations.<br>
<blockquote
cite=3D"mid:17f4d473-56f2-4e1a-92a7-b26396256ad6@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>At any rate, if you are thinking of more complicated
functions like straight factorial for example,<br>
then this function could easily require that the passed fp
type has E =3D=3D 0.<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<blockquote type=3D"cite">
<div dir=3D"ltr"><br>
The difference between the nonnegative and negatable
types in Lawrence's proposal<br>
would be accounted for by the base type in my proposal,
where for example fp<unsigned int, 8><br>
would be an unsigned fractional type, and there overflow
would be well defined by the standard.<br>
</div>
</blockquote>
I like the possibility for the user to give the
representation, but I like also that the class could choose
a default one. This is having signed and unsigned classes
helps.<br>
</div>
</blockquote>
<div dir=3D"ltr"><br>
Then maybe what you want could fit here by providing aliases
to the fp variants of the existing integral type.<br>
An alias to fp<unsigned int, E> could be provided, as
could to other types.<br>
If you want it to support automatically selecting the most
appropriate type for a given range, then maybe a separate
proposal<br>
could specify a type just like that.<br>
For example suppose there exists a type function
'ranged_integer' which given a range as a template parameter
returns a type for an appropriate<br>
integer. You could then easily combine this here by doing=C2=A0
fp<ranged_integer_t<65536>, 8>.<br>
</div>
</div>
</blockquote>
I'm not against your proposal, but in order to convince me I need to
see how do you take care of all the things N3352 provides. IMHO,
saying that the type given as parameter could resolve all the issues
needs more arguments and probes. <br>
How your library would take care of the range?<br>
What would be the result of fp<ranged_integer_t<256>,
8>+fp<ranged_integer_t<256>, 8>?<br>
<br>
<blockquote
cite=3D"mid:17f4d473-56f2-4e1a-92a7-b26396256ad6@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div dir=3D"ltr"><br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">I'm not aware of one. I
did a prototype that takes in account even more variation
points. I don't think you will be interested in, anyway if
you are interested=C2=A0 you could take a look at [1]<br>
</div>
</blockquote>
<div><br>
Thank you, I will take a look later. I am interested in
knowing what features people are interested in. <br>
</div>
</div>
</blockquote>
There are some domains that don't care if the result of T+T is
bigger than T. Others want that T+T->T.=C2=A0 This is what I called
closed versus open arithmetic.<br>
Others don't want to work with arbitrary size and want to be limited
to some builtin type. This is what I called bounded versus unbounded
arithmetic.<br>
<blockquote
cite=3D"mid:17f4d473-56f2-4e1a-92a7-b26396256ad6@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<blockquote type=3D"cite">
<div dir=3D"ltr">The details on the conversion rules he
describes seem right and I think are similar to what I
am proposing, with the exception of the range parameter,<br=
>
which of course I left out and am delegating that
responsibility on another proposal for integral types
with user specified ranges (which I am not working on).<br>
<br>
</div>
</blockquote>
I really think the Range parameter is a must have.<br>
</div>
</blockquote>
<div><br>
Like I said above, I think this could be better combined with
another proposal for a ranged integer. <br>
</div>
</div>
</blockquote>
Sorry, but I need a probe. Once we see that this is possible I will
have no problem with your proposal.<br>
<blockquote
cite=3D"mid:17f4d473-56f2-4e1a-92a7-b26396256ad6@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div><br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">I believe you about the
performances. I'm sure the interface proposed by Laurence
could perform as well.<br>
I see some issues with the definition of<br>
<br>
<pre><div> <span>template</span><span><</span><span>class</s=
pan> <span>A</span><span>,</span> <span>class</span> <span>B</span><span>&g=
t;</span> <span>using</span> <span>conv_type</span> <span>=3D</span> <span>=
decltype</span><span>(</span><span>A</span><span>()</span> <span>+</span> <=
span>B</span><span>());
</span><span>When multiplying A and B this type could be not big enough.</s=
pan></div></pre>
</div>
</blockquote>
<div><br>
<pre>I think I see that you mean. This was intentional, and I thi=
nk one of the things that makes this proposal lightweight is that the fp ty=
pes behave as closely as possible
to the underlying integral types.
But suppose the user provides a special safe_integer which has safer conver=
sion rules, and for those the multiply operation is defined in a way that t=
he resulting type
has a bigger range. Then I would not be taking advantage of that here.
I suppose it would be worth it to support base types with different convers=
ion rules than the fundamental integers, a type in which decltype(T() + T()=
) is not the same as decltype(T() * T())
I could certainly look into this improvement.</pre>
<br>
</div>
</div>
</blockquote>
Great.<br>
<blockquote
cite=3D"mid:17f4d473-56f2-4e1a-92a7-b26396256ad6@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<pre><div>
<span>
In addition the declaration of
</span><pre><div><span>#define DECL template<class A, class B> friend=
constexpr</span></div><div> <span>DECL</span> <span>auto</span> <span>oper=
ator</span><span>+</span><span>(</span><span>const</span> <span>A</span> <s=
pan>&</span><span>a</span><span>,</span> <span>const</span> <span>B</sp=
an> <span>&</span><span>b</span><span>)</span> <span>{</span> <span>ret=
urn</span> <span>bin_op</span><span><</span><span>max</span><span>,</spa=
n><span>std</span><span>::</span><span>plus</span> <span>></span><s=
pan>(</span><span>proxy</span><span><</span><span>B</span><span>></sp=
an><span>(</span><span>a</span><span>),</span> <span>proxy</span><span><=
</span><span>A</span><span>></span><span>(</span><span>b</span><span>));=
</span> <span>}
would introduce ambiguities as there are no constraints on the template par=
ameters.</span></div></pre></div></pre>
</div>
</blockquote>
<div><br>
Not actually I think. The fact that this is declared here as
friend function would mean that it would only be brought in
when one of the parameters is a fp instance, due to ADL.<br>
</div>
</div>
</blockquote>
If this is true, you have teach me something important. Could you
point me where in the standard this is defined?<br>
<blockquote
cite=3D"mid:17f4d473-56f2-4e1a-92a7-b26396256ad6@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>If any one parameter is a fp type and the other is not,
then the call to proxy will select an overload which tries to
convert it to the same type as the other.<br>
<br>
proxy has two overloads. One overload is a template which
accepts a reference to any fp instance, and in doing so
returns that reference unchanged.<br>
The other overload will perform a conversion to an fp type.<br>
<br>
If you think there is a case where this breaks, I would be
happy to fix it. <br>
</div>
</div>
</blockquote>
I will give a try to your implementation. I will come back then.<br>
<blockquote
cite=3D"mid:17f4d473-56f2-4e1a-92a7-b26396256ad6@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div><br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><br>
<br>
[1] <a moz-do-not-send=3D"true"
href=3D"https://svn.boost.org/svn/boost/sandbox/fixed_point/"
target=3D"_blank"
onmousedown=3D"this.href=3D'https://www.google.com/url?q\75ht=
tps%3A%2F%2Fsvn.boost.org%2Fsvn%2Fboost%2Fsandbox%2Ffixed_point%2F\46sa\75D=
\46sntz\0751\46usg\75AFQjCNEwTh7fYqdBiDygaSDL8L0cLb91CQ';return
true;"
onclick=3D"this.href=3D'https://www.google.com/url?q\75https%=
3A%2F%2Fsvn.boost.org%2Fsvn%2Fboost%2Fsandbox%2Ffixed_point%2F\46sa\75D\46s=
ntz\0751\46usg\75AFQjCNEwTh7fYqdBiDygaSDL8L0cLb91CQ';return
true;">https://svn.boost.org/svn/<wbr>boost/sandbox/fixed_poi=
nt/</a><br>
<br>
BTW, you didn't answered explicitly=C2=A0 to my question<br>
Why do you qualify it of lightweight?<br>
</div>
</blockquote>
<div><br>
I would qualify it as lightweight because I am not trying to
introduce many features which I think are contentious and
would be better served<br>
by different proposals. I think a better approach is to create
something which is simpler and in any case composable.<br>
</div>
</div>
</blockquote>
I'm always for separation of concerns, but I need to see that I can
compose them. When interactions between the different concerns
appear we need some entity that manage them.<br>
<blockquote
cite=3D"mid:17f4d473-56f2-4e1a-92a7-b26396256ad6@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>If those features I mentioned like saturating arithmetic,
'ranged integers' and such are introduced in the future, then
they could be combined here<br>
by using them as base types.<br>
</div>
</div>
</blockquote>
<br>
It would be great if you can implement such a type of family of
types, aware of overflow and rounding strategies and of the range
bounds. IMO, you will end by defining what N3352 and my
implementation propose. And IMHO, the exponent would be also part of
the underlying type.<br>
<br>
But maybe you can probe the opposite, which will be really
appreciated.<br>
<br>
Best,<br>
Vicente<br>
</body>
</html>
<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 <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 />
--------------030909030301050909010906--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 09 Mar 2014 17:26:15 -0700
Raw View
Em dom 09 mar 2014, =E0s 17:03:11, Matheus Izvekov escreveu:
> I am stating the requirements on the base type supplied as a parameter.
> If there is ever a proposal put forward for another kind of integer, like=
a=20
> saturating integer or an infinite precision int, then
> it would also specialize these traits, right?
> =20
You would never specialise those traits. The only specialisations permitted=
=20
are already provided in the standard library.
Imagine you write your own fp<T, int> class and you proceed to specialise=
=20
std::is_integer. How do you suppose std::atomic<fp<int, 8>> will do additio=
ns?
--=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/.
.
Author: Matheus Izvekov <mizvekov@gmail.com>
Date: Sun, 9 Mar 2014 18:23:56 -0700 (PDT)
Raw View
------=_Part_2469_15633490.1394414636399
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, March 9, 2014 9:10:13 PM UTC-3, Vicente J. Botet Escriba wrote:
>
> Le 09/03/14 20:05, Matheus Izvekov a =C3=A9crit :
> =20
>
> On Sunday, March 9, 2014 2:42:06 PM UTC-3, Vicente J. Botet Escriba wrote=
:=20
>>
>> Le 09/03/14 16:39, Matheus Izvekov a =C3=A9crit :
>> =20
>> What are the constraints on this integral type?
>> =20
>
> It should specialize is_integral to true, support all operators that the=
=20
> fundamental integers do, and it should be default constructible.
> =20
> I'm not sure the user can specialize this trait.
>
Yeah I see what you are getting at, I should probably support user types as=
=20
the base type, and yes the user would not be allowed to specialize those=20
traits.
I have to investigate this, but it seems the kind of thing concepts lite=20
would help here.
We need rounding whenever we lost in precision.
>
Then it would need to be treated separately from float to int rounding I=20
think, they should be independent options.
> I disagree here. This operation is quite common in some domains.
>
Okay, I will take a look at how this could happen within this framework.=20
> If rounding is to be applied between those conversions, I think a=20
> separate function to do this explicitly (like std::lround) is preferred.
> =20
> Anytime there is a loss of precision the user must do it explicitly. I=20
> believed that N3352 had a cast operation. Anyway, my implementation has o=
ne=20
> number_cast operation that takes care of this.=20
>
I don't know, there is a case that these losses of precision can be=20
dangerous to the unwary, but in general the language allows lossy implicit=
=20
conversions,
I am thinking doing something like that would make the class feel out of=20
place with the rest of the language.
You can take a look at N3352. All the bitwise operations had only a sens on=
=20
> cardinal types. modulo has a sens only for integral and cardinal. divisio=
n=20
> only on fractional types. division on intrgral types would need a roundin=
g=20
> policy (truncation could be the default however). Increasing (operators +=
+=20
> and --) a fractional number is subject to interpretations.
>
I treat all the bitwise operations and modulo the same as addition and=20
subtraction, and it makes perfect sense.
You could for example use bitwise 'and' to mask and get only the fractional=
=20
bits, and it fits perfectly.
Same for modulo, it captures exactly what modulo means for fractional=20
types, and it's not even handled as a special case,
I think there should be no distinction here wrt to rounding integers and=20
fractionals, they can both be handled in a general way.
Well, for increment / decrement I took the meaning that it should be=20
handled the same as 'x +=3D 1;' 'and x =3D x + 1;'
I think it's the most obvious one and a no-brainer.
I'm not against your proposal, but in order to convince me I need to see=20
> how do you take care of all the things N3352 provides. IMHO, saying that=
=20
> the type given as parameter could resolve all the issues needs more=20
> arguments and probes.=20
> How your library would take care of the range?
> What would be the result of fp<ranged_integer_t<256>,=20
> 8>+fp<ranged_integer_t<256>, 8>?
>
Within my proposal, the resulting type of 'fp<ranged_integer_t<256>,=20
8>+fp<ranged_integer_t<256>, 8>'
would be ''fp<decltype(ranged_integer_t<256>() + ranged_integer_t<256>()),=
=20
8>
And suppose ranged_integer_t is a type which the following holds:
decltype(ranged_integer_t<256>() + ranged_integer_t<256>()) results in the=
=20
type 'ranged_integer_r<512>'
then the resulting type of your original expression would be=20
'fp<ranged_integer_t<512>, 8>'
See how everything can fit together?
I will take a better look N3352 later and see what else there is, thank you=
=20
for bringing it to my attention.
=20
>
> There are some domains that don't care if the result of T+T is bigger tha=
n=20
> T. Others want that T+T->T. This is what I called closed versus open=20
> arithmetic.
> Others don't want to work with arbitrary size and want to be limited to=
=20
> some builtin type. This is what I called bounded versus unbounded=20
> arithmetic.
>
I see, that terminology sounds good to me.
If this is true, you have teach me something important. Could you point me=
=20
> where in the standard this is defined?
>
I can not cite exactly where in the standards text this is right now, I=20
have to get back at you later, but this is similar to the Barton_Nackman=20
trick: http://en.wikipedia.org/wiki/Barton%E2%80%93Nackman_trick
But basically friend functions declared inside a class and which are not=20
declared at namespace scope are only visible thru ADL.
The best answer in this stackoverflow post also corroborates this:=20
http://stackoverflow.com/questions/4777025/visibility-of-friend-functions-w=
hen-creating-functors
>
> I will give a try to your implementation. I will come back then.
>
Thank you.=20
> =20
> =20
>>
>> [1] https://svn.boost.org/svn/boost/sandbox/fixed_point/
>>
>> BTW, you didn't answered explicitly to my question
>> Why do you qualify it of lightweight?
>> =20
>
> I would qualify it as lightweight because I am not trying to introduce=20
> many features which I think are contentious and would be better served
> by different proposals. I think a better approach is to create something=
=20
> which is simpler and in any case composable.
> =20
> I'm always for separation of concerns, but I need to see that I can=20
> compose them. When interactions between the different concerns appear we=
=20
> need some entity that manage them.
>
> If those features I mentioned like saturating arithmetic, 'ranged=20
> integers' and such are introduced in the future, then they could be=20
> combined here
> by using them as base types.
> =20
>
> It would be great if you can implement such a type of family of types,=20
> aware of overflow and rounding strategies and of the range bounds. IMO, y=
ou=20
> will end by defining what N3352 and my implementation propose. And IMHO,=
=20
> the exponent would be also part of the underlying type.
>
> But maybe you can probe the opposite, which will be really appreciated.
>
> Best,
> Vicente
>
Thanks!=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_2469_15633490.1394414636399
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, March 9, 2014 9:10:13 PM UTC-3, Vicente J. Bote=
t Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 09/03/14 20:05, Matheus Izvekov a
=C3=A9crit :<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr"><br>
On Sunday, March 9, 2014 2:42:06 PM UTC-3, Vicente J. Botet
Escriba wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 09/03/14 16:39, Matheus Izvekov a =C3=A9crit :<br>
</div>
<br>
What are the constraints on this integral type?<br>
</div>
</blockquote>
<div><br>
It should specialize is_integral to true, support all
operators that the fundamental integers do, and it should be
default constructible.<br>
</div>
</div>
</blockquote>
I'm not sure the user can specialize this trait.<br></div></blockquote>=
<div><br>Yeah I see what you are getting at, I should probably support user=
types as the base type, and yes the user would not be allowed to specializ=
e those traits.<br>I have to investigate this, but it seems the kind of thi=
ng concepts lite would help here.<br><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
=20
We need rounding whenever we lost in precision.<br></div></blockquote><=
div><br>Then it would need to be treated separately from float to int round=
ing I think, they should be independent options.<br><br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
#ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
<br>
I disagree here. This operation is quite common in some domains.<br></d=
iv></blockquote><div><br>Okay, I will take a look at how this could happen =
within this framework. <br></div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>If rounding is to be applied between those conversions, I
think a separate function to do this explicitly (like
std::lround) is preferred.<br>
</div>
</div>
</blockquote>
Anytime there is a loss of precision the user must do it explicitly.
I believed that N3352 had a cast operation. Anyway, my
implementation has one number_cast operation that takes care of
this. <br></div></blockquote><div><br>I don't know, there is a case tha=
t these losses of precision can be dangerous to the unwary, but in general =
the language allows lossy implicit conversions,<br>I am thinking doing some=
thing like that would make the class feel out of place with the rest of the=
language.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div b=
gcolor=3D"#FFFFFF" text=3D"#000000">
=20
You can take a look at N3352. All the bitwise operations had only a
sens on cardinal types. modulo has a sens only for integral and
cardinal. division only on fractional types. division on intrgral
types would need a rounding policy (truncation could be the default
however). Increasing (operators ++ and --) a fractional number is
subject to interpretations.<br></div></blockquote><div><br>I treat all =
the bitwise operations and modulo the same as addition and subtraction, and=
it makes perfect sense.<br>You could for example use bitwise 'and' to mask=
and get only the fractional bits, and it fits perfectly.<br>Same for modul=
o, it captures exactly what modulo means for fractional types, and it's not=
even handled as a special case,<br><br>I think there should be no distinct=
ion here wrt to rounding integers and fractionals, they can both be handled=
in a general way.<br>Well, for increment / decrement I took the meaning th=
at it should be handled the same as 'x +=3D 1;' 'and x =3D x + 1;'<br>I thi=
nk it's the most obvious one and a no-brainer.<br><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
=20
I'm not against your proposal, but in order to convince me I need to
see how do you take care of all the things N3352 provides. IMHO,
saying that the type given as parameter could resolve all the issues
needs more arguments and probes. <br>
How your library would take care of the range?<br>
What would be the result of fp<ranged_integer_t<256>,
8>+fp<ranged_integer_t<256>, 8>?<br></div></blockquote><=
div><br>Within my proposal, the resulting type of 'fp<ranged_integer_t&l=
t;256>,
8>+fp<ranged_integer_t<256>, 8>'<br>would be ''fp<dec=
ltype(ranged_integer_t<256>() + ranged_integer_t<256>()), 8>=
<br><br>And suppose ranged_integer_t is a type which the following holds:<b=
r>decltype(ranged_integer_t<256>() + ranged_integer_t<256>()) r=
esults in the type 'ranged_integer_r<512>'<br><br>then the resulting =
type of your original expression would be 'fp<ranged_integer_t<512>=
;,
8>'<br>See how everything can fit together?<br><br>I will take a bet=
ter look N3352 later and see what else there is, thank you for bringing it =
to my attention.<br> </div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
<br>
=20
There are some domains that don't care if the result of T+T is
bigger than T. Others want that T+T->T. This is what I called
closed versus open arithmetic.<br>
Others don't want to work with arbitrary size and want to be limited
to some builtin type. This is what I called bounded versus unbounded
arithmetic.<br></div></blockquote><div><br>I see, that terminology soun=
ds good to me.<br><br></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 bgcolor=3D"#FFFFFF" text=3D"#000000">If this is true, you have teach me =
something important. Could you
point me where in the standard this is defined?<br></div></blockquote><=
div><br>I can not cite exactly where in the standards text this is right no=
w, I have to get back at you later, but this is similar to the Barton_Nackm=
an trick: <a href=3D"http://en.wikipedia.org/wiki/Barton%E2%80%93Nackman_tr=
ick">http://en.wikipedia.org/wiki/Barton%E2%80%93Nackman_trick</a><br>But b=
asically friend functions declared inside a class and which are not declare=
d at namespace scope are only visible thru ADL.<br>The best answer in this =
stackoverflow post also corroborates this: <a href=3D"http://stackoverflow.=
com/questions/4777025/visibility-of-friend-functions-when-creating-functors=
">http://stackoverflow.com/questions/4777025/visibility-of-friend-functions=
-when-creating-functors</a><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
<br>
I will give a try to your implementation. I will come back then.<br></d=
iv></blockquote><div><br>Thank you. <br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div><br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><br>
<br>
[1] <a href=3D"https://svn.boost.org/svn/boost/sandbox/fixed_po=
int/" target=3D"_blank" onmousedown=3D"this.href=3D'https://www.google.com/=
url?q\75https%3A%2F%2Fsvn.boost.org%2Fsvn%2Fboost%2Fsandbox%2Ffixed_point%2=
F\46sa\75D\46sntz\0751\46usg\75AFQjCNEwTh7fYqdBiDygaSDL8L0cLb91CQ';return t=
rue;" onclick=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2F=
svn.boost.org%2Fsvn%2Fboost%2Fsandbox%2Ffixed_point%2F\46sa\75D\46sntz\0751=
\46usg\75AFQjCNEwTh7fYqdBiDygaSDL8L0cLb91CQ';return true;">https://svn.boos=
t.org/svn/<wbr>boost/sandbox/fixed_point/</a><br>
<br>
BTW, you didn't answered explicitly to my question<br>
Why do you qualify it of lightweight?<br>
</div>
</blockquote>
<div><br>
I would qualify it as lightweight because I am not trying to
introduce many features which I think are contentious and
would be better served<br>
by different proposals. I think a better approach is to create
something which is simpler and in any case composable.<br>
</div>
</div>
</blockquote>
I'm always for separation of concerns, but I need to see that I can
compose them. When interactions between the different concerns
appear we need some entity that manage them.<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>If those features I mentioned like saturating arithmetic,
'ranged integers' and such are introduced in the future, then
they could be combined here<br>
by using them as base types.<br>
</div>
</div>
</blockquote>
<br>
It would be great if you can implement such a type of family of
types, aware of overflow and rounding strategies and of the range
bounds. IMO, you will end by defining what N3352 and my
implementation propose. And IMHO, the exponent would be also part of
the underlying type.<br>
<br>
But maybe you can probe the opposite, which will be really
appreciated.<br>
<br>
Best,<br>
Vicente<br></div></blockquote><div><br>Thanks! <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 <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_2469_15633490.1394414636399--
.
Author: Matheus Izvekov <mizvekov@gmail.com>
Date: Sun, 9 Mar 2014 18:26:38 -0700 (PDT)
Raw View
------=_Part_104_6449170.1394414798298
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, March 9, 2014 9:26:15 PM UTC-3, Thiago Macieira wrote:
>
> Em dom 09 mar 2014, =C3=A0s 17:03:11, Matheus Izvekov escreveu:=20
> > I am stating the requirements on the base type supplied as a parameter.=
=20
> > If there is ever a proposal put forward for another kind of integer,=20
> like a=20
> > saturating integer or an infinite precision int, then=20
> > it would also specialize these traits, right?=20
> > =20
>
> You would never specialise those traits. The only specialisations=20
> permitted=20
> are already provided in the standard library.=20
>
> Imagine you write your own fp<T, int> class and you proceed to specialise=
=20
> std::is_integer. How do you suppose std::atomic<fp<int, 8>> will do=20
> additions?=20
>
I see what you mean, then maybe is_integer is not appropriate here and I=20
need
some sort of concept 'Integer', or anything which returns true if the=20
underlying type quacks like an int.
=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
> Software Architect - Intel Open Source Technology Center=20
> PGP/GPG: 0x6EF45358; fingerprint:=20
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358=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_104_6449170.1394414798298
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, March 9, 2014 9:26:15 PM UTC-3, Thiago Macieira=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Em dom 09 mar 2014, =C3=
=A0s 17:03:11, Matheus Izvekov escreveu:
<br>> I am stating the requirements on the base type supplied as a param=
eter.
<br>> If there is ever a proposal put forward for another kind of intege=
r, like a=20
<br>> saturating integer or an infinite precision int, then
<br>> it would also specialize these traits, right?
<br>>
<br>
<br>You would never specialise those traits. The only specialisations permi=
tted=20
<br>are already provided in the standard library.
<br>
<br>Imagine you write your own fp<T, int> class and you proceed to sp=
ecialise=20
<br>std::is_integer. How do you suppose std::atomic<fp<int, 8>>=
will do additions?
<br></blockquote><div><br>I see what you mean, then maybe is_integer is not=
appropriate here and I need<br>some sort of concept 'Integer', or anything=
which returns true if the underlying type quacks like an int.<br> </d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%=
3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNCNanbu7euhq=
Ln_62FW8ag';return true;" onclick=3D"this.href=3D'http://www.google.com/url=
?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNC=
Nanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - thiago (AT) <a href=
=3D"http://kde.org" target=3D"_blank" onmousedown=3D"this.href=3D'http://ww=
w.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQj=
CNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'http:=
//www.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75=
AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a>
<br> Software Architect - Intel Open Source Technology Center
<br> PGP/GPG: 0x6EF45358; fingerprint:
<br> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4=
5358
<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 <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_104_6449170.1394414798298--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Mon, 10 Mar 2014 13:00:48 +0100
Raw View
This is a multi-part message in MIME format.
--------------010802080002080405050402
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 10/03/14 02:23, Matheus Izvekov a =C3=A9crit :
> On Sunday, March 9, 2014 9:10:13 PM UTC-3, Vicente J. Botet Escriba=20
> wrote:
>
> Le 09/03/14 20:05, Matheus Izvekov a =C3=A9crit :
>>
>> On Sunday, March 9, 2014 2:42:06 PM UTC-3, Vicente J. Botet
>> Escriba wrote:
>
> We need rounding whenever we lost in precision.
>
>
> Then it would need to be treated separately from float to int rounding=20
> I think, they should be independent options.
Right.
>
>> If rounding is to be applied between those conversions, I think a
>> separate function to do this explicitly (like std::lround) is
>> preferred.
> Anytime there is a loss of precision the user must do it
> explicitly. I believed that N3352 had a cast operation. Anyway, my
> implementation has one number_cast operation that takes care of this.
>
>
> I don't know, there is a case that these losses of precision can be=20
> dangerous to the unwary, but in general the language allows lossy=20
> implicit conversions,
> I am thinking doing something like that would make the class feel out=20
> of place with the rest of the language.
IMO, this class should not emulate the deficiencies of the builtin types=20
arithmetic.
>
> You can take a look at N3352. All the bitwise operations had only
> a sens on cardinal types. modulo has a sens only for integral and
> cardinal. division only on fractional types. division on intrgral
> types would need a rounding policy (truncation could be the
> default however). Increasing (operators ++ and --) a fractional
> number is subject to interpretations.
>
>
> I treat all the bitwise operations and modulo the same as addition and=20
> subtraction, and it makes perfect sense.
Well, I don't see an signed int as a suite of bits. Even less a fractional.
> You could for example use bitwise 'and' to mask and get only the=20
> fractional bits, and it fits perfectly.
> Same for modulo, it captures exactly what modulo means for fractional=20
> types, and it's not even handled as a special case,
Humm, yes modulo could have a sens for fractional numbers. My bad.
>
> I think there should be no distinction here wrt to rounding integers=20
> and fractionals, they can both be handled in a general way.
It depends on the result you expect for i/j. Is the result an integer?=20
for fractional numbers, f/g is always a fractional. if I/j is an integer=20
we need to state what is the rounding policy.
> Well, for increment / decrement I took the meaning that it should be=20
> handled the same as 'x +=3D 1;' 'and x =3D x + 1;'
> I think it's the most obvious one and a no-brainer.
Others ave suggested just to increase/decrease the quantum. If your=20
fractional counts quarters, ++ means adding a quarter.
>
> I'm not against your proposal, but in order to convince me I need
> to see how do you take care of all the things N3352 provides.
> IMHO, saying that the type given as parameter could resolve all
> the issues needs more arguments and probes.
> How your library would take care of the range?
> What would be the result of fp<ranged_integer_t<256>,
> 8>+fp<ranged_integer_t<256>, 8>?
>
>
> Within my proposal, the resulting type of 'fp<ranged_integer_t<256>,=20
> 8>+fp<ranged_integer_t<256>, 8>'
> would be ''fp<decltype(ranged_integer_t<256>() +=20
> ranged_integer_t<256>()), 8>
Yes this make sens.
>
> If this is true, you have teach me something important. Could you
> point me where in the standard this is defined?
>
>
> I can not cite exactly where in the standards text this is right now,=20
> I have to get back at you later, but this is similar to the=20
> Barton_Nackman trick:=20
> http://en.wikipedia.org/wiki/Barton%E2%80%93Nackman_trick
> But basically friend functions declared inside a class and which are=20
> not declared at namespace scope are only visible thru ADL.
> The best answer in this stackoverflow post also corroborates this:=20
> http://stackoverflow.com/questions/4777025/visibility-of-friend-functions=
-when-creating-functors
Yes, but note that these friend function had the class as parameter. I=20
think you are wrong here.
Best,
Vicente
--=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/.
--------------010802080002080405050402
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 10/03/14 02:23, Matheus Izvekov a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:1290f64e-5c75-46a4-9315-5ba0caf06bd6@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">On Sunday, March 9, 2014 9:10:13 PM UTC-3, Vicente
J. Botet Escriba wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 09/03/14 20:05, Matheus Izvekov a =C3=A9crit=C2=A0:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr"><br>
On Sunday, March 9, 2014 2:42:06 PM UTC-3, Vicente J.
Botet Escriba wrote: </div>
</blockquote>
</div>
</blockquote>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"> We need rounding
whenever we lost in precision.<br>
</div>
</blockquote>
<div><br>
Then it would need to be treated separately from float to int
rounding I think, they should be independent options.<br>
</div>
</div>
</blockquote>
Right.<br>
<blockquote
cite=3D"mid:1290f64e-5c75-46a4-9315-5ba0caf06bd6@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>If rounding is to be applied between those
conversions, I think a separate function to do this
explicitly (like std::lround) is preferred.<br>
</div>
</div>
</blockquote>
Anytime there is a loss of precision the user must do it
explicitly. I believed that N3352 had a cast operation.
Anyway, my implementation has one number_cast operation that
takes care of this. <br>
</div>
</blockquote>
<div><br>
I don't know, there is a case that these losses of precision
can be dangerous to the unwary, but in general the language
allows lossy implicit conversions,<br>
I am thinking doing something like that would make the class
feel out of place with the rest of the language.<br>
</div>
</div>
</blockquote>
IMO, this class should not emulate the deficiencies of the builtin
types arithmetic.<br>
<blockquote
cite=3D"mid:1290f64e-5c75-46a4-9315-5ba0caf06bd6@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div><br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"> You can take a look at
N3352. All the bitwise operations had only a sens on
cardinal types. modulo has a sens only for integral and
cardinal. division only on fractional types. division on
intrgral types would need a rounding policy (truncation
could be the default however). Increasing (operators ++ and
--) a fractional number is subject to interpretations.<br>
</div>
</blockquote>
<div><br>
I treat all the bitwise operations and modulo the same as
addition and subtraction, and it makes perfect sense.<br>
</div>
</div>
</blockquote>
Well, I don't see an signed int as a suite of bits. Even less a
fractional.<br>
<blockquote
cite=3D"mid:1290f64e-5c75-46a4-9315-5ba0caf06bd6@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>You could for example use bitwise 'and' to mask and get
only the fractional bits, and it fits perfectly.<br>
Same for modulo, it captures exactly what modulo means for
fractional types, and it's not even handled as a special case,<br=
>
</div>
</div>
</blockquote>
Humm, yes modulo could have a sens for fractional numbers. My bad.<br>
<blockquote
cite=3D"mid:1290f64e-5c75-46a4-9315-5ba0caf06bd6@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div><br>
I think there should be no distinction here wrt to rounding
integers and fractionals, they can both be handled in a
general way.<br>
</div>
</div>
</blockquote>
It depends on the result you expect for i/j. Is the result an
integer? for fractional numbers, f/g is always a fractional. if I/j
is an integer we need to state what is the rounding policy.<br>
<blockquote
cite=3D"mid:1290f64e-5c75-46a4-9315-5ba0caf06bd6@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>Well, for increment / decrement I took the meaning that it
should be handled the same as 'x +=3D 1;' 'and x =3D x + 1;'<br>
I think it's the most obvious one and a no-brainer.<br>
</div>
</div>
</blockquote>
Others ave suggested just to increase/decrease the quantum. If your
fractional counts quarters, ++ means adding a quarter.<br>
<blockquote
cite=3D"mid:1290f64e-5c75-46a4-9315-5ba0caf06bd6@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div><br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"> I'm not against your
proposal, but in order to convince me I need to see how do
you take care of all the things N3352 provides. IMHO, saying
that the type given as parameter could resolve all the
issues needs more arguments and probes. <br>
How your library would take care of the range?<br>
What would be the result of
fp<ranged_integer_t<256>,
8>+fp<ranged_integer_t<256>, 8>?<br>
</div>
</blockquote>
<div><br>
Within my proposal, the resulting type of
'fp<ranged_integer_t<256>,
8>+fp<ranged_integer_t<256>, 8>'<br>
would be ''fp<decltype(ranged_integer_t<256>() +
ranged_integer_t<256>()), 8><br>
</div>
</div>
</blockquote>
Yes this make sens.<br>
<blockquote
cite=3D"mid:1290f64e-5c75-46a4-9315-5ba0caf06bd6@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div><br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">If this is true, you
have teach me something important. Could you point me where
in the standard this is defined?<br>
</div>
</blockquote>
<div><br>
I can not cite exactly where in the standards text this is
right now, I have to get back at you later, but this is
similar to the Barton_Nackman trick: <a
moz-do-not-send=3D"true"
href=3D"http://en.wikipedia.org/wiki/Barton%E2%80%93Nackman_tri=
ck">http://en.wikipedia.org/wiki/Barton%E2%80%93Nackman_trick</a><br>
But basically friend functions declared inside a class and
which are not declared at namespace scope are only visible
thru ADL.<br>
The best answer in this stackoverflow post also corroborates
this: <a moz-do-not-send=3D"true"
href=3D"http://stackoverflow.com/questions/4777025/visibility-of-friend-fun=
ctions-when-creating-functors">http://stackoverflow.com/questions/4777025/v=
isibility-of-friend-functions-when-creating-functors</a><br>
</div>
</div>
</blockquote>
Yes, but note that these friend function had the class as parameter.
I think you are wrong here.<br>
<br>
Best,<br>
Vicente<br>
</body>
</html>
<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 <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 />
--------------010802080002080405050402--
.
Author: Matheus Izvekov <mizvekov@gmail.com>
Date: Tue, 11 Mar 2014 02:28:14 -0700 (PDT)
Raw View
------=_Part_1387_21643298.1394530094874
Content-Type: text/plain; charset=UTF-8
On Monday, March 10, 2014 9:00:48 AM UTC-3, Vicente J. Botet Escriba wrote:
> IMO, this class should not emulate the deficiencies of the builtin
types arithmetic.
Right, but I am trying here to create a class which just adds fixed point
arithmetic on top of another type.
If you use a builtin type as a base, then it seems fair that these
characteristics you call deficiencies persist.
Maybe there is a way to preserve this if the base type has more stringent
conversion rules,
but I haven't yet thought through this part of the problem, I'll give it
more consideration.
> It depends on the result you expect for i/j. Is the result an integer?
for fractional numbers, f/g is always a fractional. if I/j is an integer we
need to state what is the rounding policy.
I think I see what you mean.
Currently I am treating division in a straightforward way.
'fp<int,10>(x) / fp<int,10>(y)' would result in 'fp<int,0>', an 'integer'.
If you wanted your result to be a fraction, you could always increase the
exponent of the numerator by how many bits it would take to make the
fraction you want.
Like for example 'fp<int,18>(x) / fp<int,10>(y)' would result in 'fp<int,8>'
Problem is of course that you could overflow in your numerator doing that.
The other way which does not overflow but is a lot slower is to use the
modulus of the first division in a second division,
and get your extra bits from there.
I see two ways to integrate this in my proposal
One would be a function which does this operation explicitly.
The other would be to make that division create a proxy object, and then
when this proxy object is assigned to some other fp variable, then it
performs this operation
in case the type of the fp number being assigned to would leave room for
extra bits.
> Others ave suggested just to increase/decrease the quantum. If your
fractional counts quarters, ++ means adding a quarter.
I dislike this approach because in most cases you are using a fp number as
a way to get more precision out of an integer,
and it's desirable to be free to change the exponent at will, to change the
trade-off between precision and range.
When you have an operator++ like that, then when you change the exponent
you are also changing the value being accumulated,
and it gives a lot more trouble I think.
I am not against though in principle adding a method to increment the
quantum.
> Yes, but note that these friend function had the class as parameter. I
think you are wrong here.
I think the main difference between what I am doing and what those links I
originally sent you describe is that I am using a
templated operator.
I am thinking there is a piece somewhere in the standards that special
cases templated friend operators, but I have not found it yet.
In any case, I am using this code in a big project and I have not yet seen
an ambiguity come into play.
This could be a clang quirk, but this is so useful that if it's not in the
standard, it ought to be!
--
---
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_1387_21643298.1394530094874
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, March 10, 2014 9:00:48 AM UTC-3, Vicente J. Bot=
et Escriba wrote:<br>> IMO, this class should not emul=
ate the deficiencies of the builtin types arithmetic.<br><br>Right, but I a=
m trying here to create a class which just adds fixed point arithmetic on t=
op of another type.<br>If you use a builtin type as a base, then it seems f=
air that these characteristics you call deficiencies persist.<br>Maybe ther=
e is a way to preserve this if the base type has more stringent conversion =
rules,<br>but I haven't yet thought through this part of the problem, I'll =
give it more consideration.<br><br>> It depends on the=
result you expect for i/j. Is the result an integer? for fractional number=
s, f/g is always a fractional. if I/j is an integer we need to state what i=
s the rounding policy.<br><br>I think I see what you mean.<br>Currently I a=
m treating division in a straightforward way.<br>'fp<int,10>(x) / fp&=
lt;int,10>(y)' would result in 'fp<int,0>', an 'integer'.<br>If yo=
u wanted your result to be a fraction, you could always increase the expone=
nt of the numerator by how many bits it would take to make the fraction you=
want.<br>Like for example 'fp<int,18>(x) / fp<int,10>(y)' woul=
d result in 'fp<int,8>'<br>Problem is of course that you could overfl=
ow in your numerator doing that.<br>The other way which does not overflow b=
ut is a lot slower is to use the modulus of the first division in a second =
division,<br>and get your extra bits from there.<br><br>I see two ways to i=
ntegrate this in my proposal<br>One would be a function which does this ope=
ration explicitly.<br>The other would be to make that division create a pro=
xy object, and then<br>when this proxy object is assigned to some other fp =
variable, then it performs this operation<br>in case the type of the fp num=
ber being assigned to would leave room for extra bits.<br><br>> &nb=
sp; Others ave suggested just to increase/decrease the quantum. If yo=
ur fractional counts quarters, ++ means adding a quarter.<br><br>I dislike =
this approach because in most cases you are using a fp number as a way to g=
et more precision out of an integer,<br>and it's desirable to be free to ch=
ange the exponent at will, to change the trade-off between precision and ra=
nge.<br>When you have an operator++ like that, then when you change the exp=
onent you are also changing the value being accumulated,<br>and it gives a =
lot more trouble I think.<br><br>I am not against though in principle addin=
g a method to increment the quantum.<br><br><br>> Yes,=
but note that these friend function had the class as parameter. I think yo=
u are wrong here.<br><br>I think the main difference between what I am doin=
g and what those links I originally sent you describe is that I am using a<=
br>templated operator.<br>I am thinking there is a piece somewhere in the s=
tandards that special cases templated friend operators, but I have not foun=
d it yet.<br>In any case, I am using this code in a big project and I have =
not yet seen an ambiguity come into play.<br><br>This could be a clang quir=
k, but this is so useful that if it's not in the standard, it ought to be!<=
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 <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_1387_21643298.1394530094874--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 11 Mar 2014 18:08:31 +0800
Raw View
--Apple-Mail=_7292B0CE-7981-44A2-A024-0BFE623685B6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-03-11, at 5:28 PM, Matheus Izvekov <mizvekov@gmail.com> wrote:
> I see two ways to integrate this in my proposal
> One would be a function which does this operation explicitly.
> The other would be to make that division create a proxy object, and then
> when this proxy object is assigned to some other fp variable, then it per=
forms this operation
> in case the type of the fp number being assigned to would leave room for =
extra bits.
This sounds nontrivial. It would be cool to see it work in practice. If it =
proves too much for rapid standardization, at least it could gain popularit=
y in Boost. A quick Google search indicates a vacuum in this solution space=
..
> > Others ave suggested just to increase/decrease the quantum. If your =
fractional counts quarters, ++ means adding a quarter.
>=20
> I dislike this approach because in most cases you are using a fp number a=
s a way to get more precision out of an integer,
> and it's desirable to be free to change the exponent at will, to change t=
he trade-off between precision and range.
> When you have an operator++ like that, then when you change the exponent =
you are also changing the value being accumulated,
> and it gives a lot more trouble I think.
>=20
> I am not against though in principle adding a method to increment the qua=
ntum.
Overload the names nextafter and nexttoward from C99.
> > Yes, but note that these friend function had the class as parameter.=
I think you are wrong here.
>=20
> I think the main difference between what I am doing and what those links =
I originally sent you describe is that I am using a
> templated operator.
> I am thinking there is a piece somewhere in the standards that special ca=
ses templated friend operators, but I have not found it yet.
> In any case, I am using this code in a big project and I have not yet see=
n an ambiguity come into play.
>=20
> This could be a clang quirk, but this is so useful that if it's not in th=
e standard, it ought to be!
Have no fear. Or at least, a little less. All friend declarations in the cl=
asses associated with arguments to an overloaded operator (or any function)=
are visible, no matter whether the declaration names the class or accepts =
it as a generically deduced argument.
However, the friend declarations are not members, so the class in no way qu=
alifies or modifies the function signature. If you had a second class in th=
e same namespace with a similar generic friend operator, that operator woul=
d be the same function and it would generate a link error despite having pe=
rhaps completely unrelated functionality.
What I'm not sure about is whether friend function templates defined by two=
specializations of the same class template are distinct templates. I suspe=
ct that they are. Even if they aren't, they could specialize differently fo=
r the same function arguments and cause self-interference. It's not good pr=
actice.
To avoid all kinds of headaches, you should probably define the "primary" o=
perators as friend non-templates, and keep the "secondary" relational opera=
tors outside the class entirely.
--=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/.
--Apple-Mail=_7292B0CE-7981-44A2-A024-0BFE623685B6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;03–11, at 5:28 PM, Matheus Izvekov <<a href=3D"mailto:mizvek=
ov@gmail.com">mizvekov@gmail.com</a>> wrote:</div><br class=3D"Apple-int=
erchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">I see two ways=
to integrate this in my proposal<br>One would be a function which does thi=
s operation explicitly.<br>The other would be to make that division create =
a proxy object, and then<br>when this proxy object is assigned to some othe=
r fp variable, then it performs this operation<br>in case the type of the f=
p number being assigned to would leave room for extra bits.<br></div></bloc=
kquote><div><br></div><div>This sounds nontrivial. It would be cool to see =
it work in practice. If it proves too much for rapid standardization, at le=
ast it could gain popularity in Boost. A quick Google search indicates a va=
cuum in this solution space.</div><br><blockquote type=3D"cite"><div dir=3D=
"ltr">> Others ave suggested just to increase/decrease=
the quantum. If your fractional counts quarters, ++ means adding a quarter=
..<br><br>I dislike this approach because in most cases you are using a fp n=
umber as a way to get more precision out of an integer,<br>and it's desirab=
le to be free to change the exponent at will, to change the trade-off betwe=
en precision and range.<br>When you have an operator++ like that, then when=
you change the exponent you are also changing the value being accumulated,=
<br>and it gives a lot more trouble I think.<br><br>I am not against though=
in principle adding a method to increment the quantum.<br></div></blockquo=
te><div><br></div><div>Overload the names <font face=3D"Courier">nextafter<=
/font> and <font face=3D"Courier">nexttoward</font> from C99.</div><br><blo=
ckquote type=3D"cite"><div dir=3D"ltr">> Yes, but note=
that these friend function had the class as parameter. I think you are wro=
ng here.<br><br>I think the main difference between what I am doing and wha=
t those links I originally sent you describe is that I am using a<br>templa=
ted operator.<br>I am thinking there is a piece somewhere in the standards =
that special cases templated friend operators, but I have not found it yet.=
<br>In any case, I am using this code in a big project and I have not yet s=
een an ambiguity come into play.<br><br>This could be a clang quirk, but th=
is is so useful that if it's not in the standard, it ought to be!<br></div>=
</blockquote><div><br></div></div><div>Have no fear. Or at least, a little =
less. All friend declarations in the classes associated with arguments to a=
n overloaded operator (or any function) are visible, no matter whether the =
declaration names the class or accepts it as a generically deduced argument=
..</div><div><br></div><div><i>However</i>, the friend declarations are not =
members, so the class in no way qualifies or modifies the function signatur=
e. If you had a second class in the same namespace with a similar generic f=
riend operator, that operator would be the same function and it would gener=
ate a link error despite having perhaps completely unrelated functionality.=
</div><div><br></div><div>What I’m not sure about is whether friend f=
unction templates defined by two specializations of the same class template=
are distinct templates. I suspect that they are. Even if they aren’t=
, they could specialize differently for the same function arguments and cau=
se self-interference. It’s not good practice.</div><div><br></div><di=
v>To avoid all kinds of headaches, you should probably define the “pr=
imary” operators as friend non-templates, and keep the “seconda=
ry” relational operators outside the class entirely.</div><div><br></=
div></body></html>
<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 <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 />
--Apple-Mail=_7292B0CE-7981-44A2-A024-0BFE623685B6--
.
Author: Matheus Izvekov <mizvekov@gmail.com>
Date: Tue, 11 Mar 2014 03:58:25 -0700 (PDT)
Raw View
------=_Part_7_13738991.1394535505138
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, March 11, 2014 7:08:31 AM UTC-3, David Krauss wrote:
>
>
> This sounds nontrivial. It would be cool to see it work in practice. If i=
t=20
> proves too much for rapid standardization, at least it could gain=20
> popularity in Boost. A quick Google search indicates a vacuum in this=20
> solution space.
>
>
Yeah, have to think of all them corner cases.
I thought about boost, though right now I am not trying to limit anything=
=20
to the boost baseline.
If in the end I get something cool and yet it's still possible to port it=
=20
over to the boost world without losing too much, then sure why not.
> Overload the names nextafter and nexttoward from C99.
>
>
Great idea, thanks!
> Have no fear. Or at least, a little less. All friend declarations in the=
=20
> classes associated with arguments to an overloaded operator (or any=20
> function) are visible, no matter whether the declaration names the class =
or=20
> accepts it as a generically deduced argument.
>
> *However*, the friend declarations are not members, so the class in no=20
> way qualifies or modifies the function signature. If you had a second cla=
ss=20
> in the same namespace with a similar generic friend operator, that operat=
or=20
> would be the same function and it would generate a link error despite=20
> having perhaps completely unrelated functionality.
>
I understand now, well I have no problem putting this class inside a=20
separate namespace, I just did not do it now because I didn't need to.
But yeah, I begin to picture how an ambiguity could arise.
> What I=E2=80=99m not sure about is whether friend function templates defi=
ned by=20
> two specializations of the same class template are distinct templates. I=
=20
> suspect that they are. Even if they aren=E2=80=99t, they could specialize=
=20
> differently for the same function arguments and cause self-interference.=
=20
> It=E2=80=99s not good practice.
>
I see, well I did not intend to specialize them, but anyway, as I noted=20
above, I can see now how there could be a problem here.
=20
>
> To avoid all kinds of headaches, you should probably define the =E2=80=9C=
primary=E2=80=9D=20
> operators as friend non-templates, and keep the =E2=80=9Csecondary=E2=80=
=9D relational=20
> operators outside the class entirely.
>
>
I'll try to see if that's possible here, thank you!
=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_7_13738991.1394535505138
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, March 11, 2014 7:08:31 AM UTC-3, David Krauss =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:=
break-word"><div><br><div>This sounds nontrivial. It would be cool to see i=
t work in practice. If it proves too much for rapid standardization, at lea=
st it could gain popularity in Boost. A quick Google search indicates a vac=
uum in this solution space.</div><br></div></div></blockquote><div><br>Yeah=
, have to think of all them corner cases.<br>I thought about boost, though =
right now I am not trying to limit anything to the boost baseline.<br>If in=
the end I get something cool and yet it's still possible to port it over t=
o the boost world without losing too much, then sure why not.<br><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-=
word"><div><br><div>Overload the names <font face=3D"Courier">nextafter</fo=
nt> and <font face=3D"Courier">nexttoward</font> from C99.</div><br></div><=
/div></blockquote><div><br>Great idea, thanks!<br><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><div><br>=
</div><div>Have no fear. Or at least, a little less. All friend declaration=
s in the classes associated with arguments to an overloaded operator (or an=
y function) are visible, no matter whether the declaration names the class =
or accepts it as a generically deduced argument.</div><div><br></div><div><=
i>However</i>, the friend declarations are not members, so the class in no =
way qualifies or modifies the function signature. If you had a second class=
in the same namespace with a similar generic friend operator, that operato=
r would be the same function and it would generate a link error despite hav=
ing perhaps completely unrelated functionality.</div></div></blockquote><di=
v><br>I understand now, well I have no problem putting this class inside a =
separate namespace, I just did not do it now because I didn't need to.<br>B=
ut yeah, I begin to picture how an ambiguity could arise.<br><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word=
"><div><br></div><div>What I=E2=80=99m not sure about is whether friend fun=
ction templates defined by two specializations of the same class template a=
re distinct templates. I suspect that they are. Even if they aren=E2=80=99t=
, they could specialize differently for the same function arguments and cau=
se self-interference. It=E2=80=99s not good practice.</div></div></blockquo=
te><div><br>I see, well I did not intend to specialize them, but anyway, as=
I noted above, I can see now how there could be a problem here.<br> <=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:b=
reak-word"><div><br></div><div>To avoid all kinds of headaches, you should =
probably define the =E2=80=9Cprimary=E2=80=9D operators as friend non-templ=
ates, and keep the =E2=80=9Csecondary=E2=80=9D relational operators outside=
the class entirely.</div><div><br></div></div></blockquote><div><br>I'll t=
ry to see if that's possible here, thank you!<br></div><div> </div></d=
iv>
<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 <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_7_13738991.1394535505138--
.
Author: Matheus Izvekov <mizvekov@gmail.com>
Date: Tue, 11 Mar 2014 04:13:50 -0700 (PDT)
Raw View
------=_Part_1606_28352377.1394536430589
Content-Type: text/plain; charset=UTF-8
I just pushed an update into the github repo where, among other things, I
added support for using a floating point type as a base type, so you can
have a fixed point floating point number.
Now before you think I am insane, the main reason I was looking to support
this is because of an opportunity for optimization in mixed fixed point /
floating point code.
Suppose you are implementing a mixed filter like that, and your
coefficients are stored in an array of floats, but that coefficient is
multiplied by a fixed-point number inside your innermost loop,
and the result of that needs to be a float in the range [0...1]
Then the underlying operation that needs to be executed is something like
[0.0 ... 1.0] * [0 ... 65535], but that obviously is missing a scaling
factor.
What would happen is that the coefficient value would need to be scaled to
the fixed point exponent, and this would result in a floating point
multiplication by a constant, problem is this
multiplication would be happening in the inner loop, and a lot of processor
cycles go to waste. The obvious thing to do here would be to do that
multiplication when building the coefficient table
in the program initialization, which happens only once. If you try to do
this in a naive way, you would have to break the abstraction a little and
its a lot cumbersome.
Now if instead of using a float to store the coefficient, you use a
'fp<float, E>', where E is the same exponent as the number you would be
multiplying this with in the inner loop,
then this scaling happens when the coefficient is constructed, during
initialization, and then everything just works afterwards.
What is great though that I added this support by simplifying things and
removing the restriction imposed by the static_assert.
I had to do this though, because I am moving in the direction of supporting
user defined arithmetic types, and it just shows how little requirements
the class has on the
base type.
Now one issue though is that if the user tries to use an operator which is
not defined for floats, like bitwise and, then an ugly compilation error
arises.
This I think could be neatly fixed by adding a requirement on each
operator, that the operation is also supported on the base type, and
Concepts Lite would help here.
Right now, only builtin floats and integers are supported, because the
scaling helpers are quite limited yet.
--
---
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_1606_28352377.1394536430589
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I just pushed an update into the github repo where, among =
other things, I added support for using a floating point type as a base typ=
e, so you can<br>have a fixed point floating point number.<br><br>Now befor=
e you think I am insane, the main reason I was looking to support this is b=
ecause of an opportunity for optimization in mixed fixed point / floating p=
oint code.<br><br>Suppose you are implementing a mixed filter like that, an=
d your coefficients are stored in an array of floats, but that coefficient =
is multiplied by a fixed-point number inside your innermost loop,<br>and th=
e result of that needs to be a float in the range [0...1]<br>Then the under=
lying operation that needs to be executed is something like [0.0 ... 1.0] *=
[0 ... 65535], but that obviously is missing a scaling factor.<br><br>What=
would happen is that the coefficient value would need to be scaled to the =
fixed point exponent, and this would result in a floating point multiplicat=
ion by a constant, problem is this<br>multiplication would be happening in =
the inner loop, and a lot of processor cycles go to waste. The obvious thin=
g to do here would be to do that multiplication when building the coefficie=
nt table<br>in the program initialization, which happens only once. If you =
try to do this in a naive way, you would have to break the abstraction a li=
ttle and its a lot cumbersome.<br><br>Now if instead of using a float to st=
ore the coefficient, you use a 'fp<float, E>', where E is the same ex=
ponent as the number you would be multiplying this with in the inner loop,<=
br>then this scaling happens when the coefficient is constructed, during in=
itialization, and then everything just works afterwards.<br><br>What is gre=
at though that I added this support by simplifying things and removing the =
restriction imposed by the static_assert.<br>I had to do this though, becau=
se I am moving in the direction of supporting user defined arithmetic types=
, and it just shows how little requirements the class has on the<br>base ty=
pe.<br><br>Now one issue though is that if the user tries to use an operato=
r which is not defined for floats, like bitwise and, then an ugly compilati=
on error arises.<br>This I think could be neatly fixed by adding a requirem=
ent on each operator, that the operation is also supported on the base type=
, and Concepts Lite would help here.<br><br>Right now, only builtin floats =
and integers are supported, because the scaling helpers are quite limited y=
et.<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 <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_1606_28352377.1394536430589--
.
Author: "Daniel Gutson" <danielgutson@gmail.com>
Date: Tue, 11 Mar 2014 11:42:13 +0000
Raw View
--part2505-boundary-1575377516-1669466862
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Use case suggestion: implement an FFT or a second-order digital filter. I c=
ould provide a real world case if you want, it was implemented in C and req=
uired some cpp machinery, it would be nice to show how by using your propos=
al we end up in a very clean and elegant C++ code and yet generates the sam=
e (optimum) asm.
Enviado desde mi BlackBerry de Movistar (http://www.movistar.com.ar)
-----Original Message-----
From: Matheus Izvekov <mizvekov@gmail.com>
Date: Tue, 11 Mar 2014 04:13:50=20
To: <std-proposals@isocpp.org>
Reply-To: std-proposals@isocpp.org
Subject: [std-proposals] Re: Lightweight Fixed Point Arithmetic
I just pushed an update into the github repo where, among other things, I=
=20
added support for using a floating point type as a base type, so you can
have a fixed point floating point number.
Now before you think I am insane, the main reason I was looking to support=
=20
this is because of an opportunity for optimization in mixed fixed point /=
=20
floating point code.
Suppose you are implementing a mixed filter like that, and your=20
coefficients are stored in an array of floats, but that coefficient is=20
multiplied by a fixed-point number inside your innermost loop,
and the result of that needs to be a float in the range [0...1]
Then the underlying operation that needs to be executed is something like=
=20
[0.0 ... 1.0] * [0 ... 65535], but that obviously is missing a scaling=20
factor.
What would happen is that the coefficient value would need to be scaled to=
=20
the fixed point exponent, and this would result in a floating point=20
multiplication by a constant, problem is this
multiplication would be happening in the inner loop, and a lot of processor=
=20
cycles go to waste. The obvious thing to do here would be to do that=20
multiplication when building the coefficient table
in the program initialization, which happens only once. If you try to do=20
this in a naive way, you would have to break the abstraction a little and=
=20
its a lot cumbersome.
Now if instead of using a float to store the coefficient, you use a=20
'fp<float, E>', where E is the same exponent as the number you would be=20
multiplying this with in the inner loop,
then this scaling happens when the coefficient is constructed, during=20
initialization, and then everything just works afterwards.
What is great though that I added this support by simplifying things and=20
removing the restriction imposed by the static_assert.
I had to do this though, because I am moving in the direction of supporting=
=20
user defined arithmetic types, and it just shows how little requirements=20
the class has on the
base type.
Now one issue though is that if the user tries to use an operator which is=
=20
not defined for floats, like bitwise and, then an ugly compilation error=20
arises.
This I think could be neatly fixed by adding a requirement on each=20
operator, that the operation is also supported on the base type, and=20
Concepts Lite would help here.
Right now, only builtin floats and integers are supported, because the=20
scaling helpers are quite limited yet.
--=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/.
--=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/.
--part2505-boundary-1575377516-1669466862
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><html><head><=
meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type"></h=
ead><body>Use case suggestion: implement an FFT or a second-order digital f=
ilter. I could provide a real world case if you want, it was implemented in=
C and required some cpp machinery, it would be nice to show how by using y=
our proposal we end up in a very clean and elegant C++ code and yet generat=
es the same (optimum) asm.<div>Enviado desde mi BlackBerry de Movistar (htt=
p://www.movistar.com.ar)</div><hr/><div><b>From: </b> Matheus Izvekov <m=
izvekov@gmail.com>
</div><div><b>Date: </b>Tue, 11 Mar 2014 04:13:50 -0700 (PDT)</div><div><b>=
To: </b><std-proposals@isocpp.org></div><div><b>ReplyTo: </b> std-pro=
posals@isocpp.org
</div><div><b>Subject: </b>[std-proposals] Re: Lightweight Fixed Point Arit=
hmetic</div><div><br/></div><div dir=3D"ltr">I just pushed an update into t=
he github repo where, among other things, I added support for using a float=
ing point type as a base type, so you can<br>have a fixed point floating po=
int number.<br><br>Now before you think I am insane, the main reason I was =
looking to support this is because of an opportunity for optimization in mi=
xed fixed point / floating point code.<br><br>Suppose you are implementing =
a mixed filter like that, and your coefficients are stored in an array of f=
loats, but that coefficient is multiplied by a fixed-point number inside yo=
ur innermost loop,<br>and the result of that needs to be a float in the ran=
ge [0...1]<br>Then the underlying operation that needs to be executed is so=
mething like [0.0 ... 1.0] * [0 ... 65535], but that obviously is missing a=
scaling factor.<br><br>What would happen is that the coefficient value wou=
ld need to be scaled to the fixed point exponent, and this would result in =
a floating point multiplication by a constant, problem is this<br>multiplic=
ation would be happening in the inner loop, and a lot of processor cycles g=
o to waste. The obvious thing to do here would be to do that multiplication=
when building the coefficient table<br>in the program initialization, whic=
h happens only once. If you try to do this in a naive way, you would have t=
o break the abstraction a little and its a lot cumbersome.<br><br>Now if in=
stead of using a float to store the coefficient, you use a 'fp<float, E&=
gt;', where E is the same exponent as the number you would be multiplying t=
his with in the inner loop,<br>then this scaling happens when the coefficie=
nt is constructed, during initialization, and then everything just works af=
terwards.<br><br>What is great though that I added this support by simplify=
ing things and removing the restriction imposed by the static_assert.<br>I =
had to do this though, because I am moving in the direction of supporting u=
ser defined arithmetic types, and it just shows how little requirements the=
class has on the<br>base type.<br><br>Now one issue though is that if the =
user tries to use an operator which is not defined for floats, like bitwise=
and, then an ugly compilation error arises.<br>This I think could be neatl=
y fixed by adding a requirement on each operator, that the operation is als=
o supported on the base type, and Concepts Lite would help here.<br><br>Rig=
ht now, only builtin floats and integers are supported, because the scaling=
helpers are quite limited yet.<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 <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 />
</body></html>
<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 <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 />
--part2505-boundary-1575377516-1669466862--
.
Author: Matheus Izvekov <mizvekov@gmail.com>
Date: Tue, 11 Mar 2014 05:04:46 -0700 (PDT)
Raw View
------=_Part_328_13249479.1394539487066
Content-Type: text/plain; charset=UTF-8
On Tuesday, March 11, 2014 8:42:13 AM UTC-3, dgutson . wrote:
>
> Use case suggestion: implement an FFT or a second-order digital filter. I
> could provide a real world case if you want, it was implemented in C and
> required some cpp machinery, it would be nice to show how by using your
> proposal we end up in a very clean and elegant C++ code and yet generates
> the same (optimum) asm.
>
Could be, I have a few use cases myself, but I don't have much time to work
on both things at the same time right now...
--
---
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_328_13249479.1394539487066
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, March 11, 2014 8:42:13 AM UTC-3, dgutson . wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div>Use case suggestion: i=
mplement an FFT or a second-order digital filter. I could provide a real wo=
rld case if you want, it was implemented in C and required some cpp machine=
ry, it would be nice to show how by using your proposal we end up in a very=
clean and elegant C++ code and yet generates the same (optimum) asm.</div>=
</blockquote><div><br>Could be, I have a few use cases myself, but I don't =
have much time to work on both things at the same time right now...<br></di=
v></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 <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_328_13249479.1394539487066--
.
Author: "Daniel Gutson" <danielgutson@gmail.com>
Date: Tue, 11 Mar 2014 12:28:36 +0000
Raw View
--part2461-boundary-1049739322-1982533416
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
It's just to increase the plausibility that your proposal cover a wide enou=
gh audience.
BTW, I also suggest to accept a rounding policy as a template argument.
Another policy that the user could be able to provide is about multiplicati=
on in saturation arithmetic: either use a doubled size integer and then shi=
ft, or check the position of the MSB and see if the resulting MSB would fit=
in the underlying type. I know this sounds like QoI, but this might be a u=
ser decision.
Enviado desde mi BlackBerry de Movistar (http://www.movistar.com.ar)
-----Original Message-----
From: Matheus Izvekov <mizvekov@gmail.com>
Date: Tue, 11 Mar 2014 05:04:46=20
To: <std-proposals@isocpp.org>
Cc: <danielgutson@gmail.com>
Subject: Re: [std-proposals] Re: Lightweight Fixed Point Arithmetic
On Tuesday, March 11, 2014 8:42:13 AM UTC-3, dgutson . wrote:
>
> Use case suggestion: implement an FFT or a second-order digital filter. I=
=20
> could provide a real world case if you want, it was implemented in C and=
=20
> required some cpp machinery, it would be nice to show how by using your=
=20
> proposal we end up in a very clean and elegant C++ code and yet generates=
=20
> the same (optimum) asm.
>
Could be, I have a few use cases myself, but I don't have much time to work=
=20
on both things at the same time right now...
--=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/.
--part2461-boundary-1049739322-1982533416
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><html><head><=
meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type"></h=
ead><body>It's just to increase the plausibility that your proposal cover a=
wide enough audience.<br/><br/>BTW, I also suggest to accept a rounding po=
licy as a template argument.<br/>Another policy that the user could be able=
to provide is about multiplication in saturation arithmetic: either use a =
doubled size integer and then shift, or check the position of the MSB and s=
ee if the resulting MSB would fit in the underlying type. I know this sound=
s like QoI, but this might be a user decision.<div>Enviado desde mi BlackBe=
rry de Movistar (http://www.movistar.com.ar)</div><hr/><div><b>From: </b> M=
atheus Izvekov <mizvekov@gmail.com>
</div><div><b>Date: </b>Tue, 11 Mar 2014 05:04:46 -0700 (PDT)</div><div><b>=
To: </b><std-proposals@isocpp.org></div><div><b>Cc: </b><danielgut=
son@gmail.com></div><div><b>Subject: </b>Re: [std-proposals] Re: Lightwe=
ight Fixed Point Arithmetic</div><div><br/></div><div dir=3D"ltr">On Tuesda=
y, March 11, 2014 8:42:13 AM UTC-3, dgutson . wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div>Use case suggestion: implement an FFT or a secon=
d-order digital filter. I could provide a real world case if you want, it w=
as implemented in C and required some cpp machinery, it would be nice to sh=
ow how by using your proposal we end up in a very clean and elegant C++ cod=
e and yet generates the same (optimum) asm.</div></blockquote><div><br>Coul=
d be, I have a few use cases myself, but I don't have much time to work on =
both things at the same time right now...<br></div></div>
</body></html>
<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 <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 />
--part2461-boundary-1049739322-1982533416--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 11 Mar 2014 14:40:24 +0200
Raw View
On 11 March 2014 14:04, Matheus Izvekov <mizvekov@gmail.com> wrote:
> On Tuesday, March 11, 2014 8:42:13 AM UTC-3, dgutson . wrote:
>>
>> Use case suggestion: implement an FFT or a second-order digital filter. I
>> could provide a real world case if you want, it was implemented in C and
>> required some cpp machinery, it would be nice to show how by using your
>> proposal we end up in a very clean and elegant C++ code and yet generates
>> the same (optimum) asm.
>
>
> Could be, I have a few use cases myself, but I don't have much time to work
> on both things at the same time right now...
I suppose it would be a good idea to get early feedback from the Numerics
Study Group. For that, you need to contact Lawrence Crowl.
--
---
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: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Tue, 11 Mar 2014 13:45:11 +0100
Raw View
This is a multi-part message in MIME format.
--------------080806040000060604000300
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 11/03/14 12:42, Daniel Gutson a =C3=A9crit :
> Use case suggestion: implement an FFT or a second-order digital=20
> filter. I could provide a real world case if you want, it was=20
> implemented in C and required some cpp machinery, it would be nice to=20
> show how by using your proposal we end up in a very clean and elegant=20
> C++ code and yet generates the same (optimum) asm.
>
Hi,
I'm interested. Please could you send me more information?
Vicente
--=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/.
--------------080806040000060604000300
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 11/03/14 12:42, Daniel Gutson a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:771679066-1394538130-cardhu_decombobulator_blackberry.rim.net-1=
841272189-@b28.c15.bise6.blackberry"
type=3D"cite">
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Ty=
pe">
Use case suggestion: implement an FFT or a second-order digital
filter. I could provide a real world case if you want, it was
implemented in C and required some cpp machinery, it would be nice
to show how by using your proposal we end up in a very clean and
elegant C++ code and yet generates the same (optimum) asm.
<div><br>
</div>
</blockquote>
Hi,<br>
<br>
I'm interested. Please could you send me more information?<br>
<br>
Vicente<br>
</body>
</html>
<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 <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 />
--------------080806040000060604000300--
.
Author: Matheus Izvekov <mizvekov@gmail.com>
Date: Wed, 12 Mar 2014 06:43:50 -0700 (PDT)
Raw View
------=_Part_288_21928933.1394631830226
Content-Type: text/plain; charset=UTF-8
On Tuesday, March 11, 2014 9:28:36 AM UTC-3, dgutson . wrote:
>
> It's just to increase the plausibility that your proposal cover a wide
> enough audience.
>
>
Sure, send me anything, but I can't promise I'll have free time to port it
soon, unless it's a really straightforward example.
If you can send me an example that contains test cases including a
performance measurement test, it would be great.
>
> Another policy that the user could be able to provide is about
> multiplication in saturation arithmetic: either use a doubled size integer
> and then shift, or check the position of the MSB and see if the resulting
> MSB would fit in the underlying type. I know this sounds like QoI, but this
> might be a user decision.
>
I don't know if I understand what you are asking, but to perform that shift
after the multiplication, that would need to be known at compile time
because it would affect the type of the result,
but I could only know if the result saturated during runtime, unless
everything was a constexpr computation.
On Tuesday, March 11, 2014 9:40:24 AM UTC-3, Ville Voutilainen wrote:
>
>
> I suppose it would be a good idea to get early feedback from the Numerics
> Study Group. For that, you need to contact Lawrence Crowl.
>
Sure, I was expecting him to show up, but I guess it would be better to
contact him directly in case he missed this thread.
--
---
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_288_21928933.1394631830226
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, March 11, 2014 9:28:36 AM UTC-3, dgutson . wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div>It's just to increase =
the plausibility that your proposal cover a wide enough audience.<br><br></=
div></blockquote><div><br>Sure, send me anything, but I can't promise I'll =
have free time to port it soon, unless it's a really straightforward exampl=
e.<br>If you can send me an example that contains test cases including a pe=
rformance measurement test, it would be great.<br> </div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
#ccc solid;padding-left: 1ex;"><div><br>Another
policy that the user could be able to provide is about multiplication=20
in saturation arithmetic: either use a doubled size integer and then=20
shift, or check the position of the MSB and see if the resulting MSB=20
would fit in the underlying type. I know this sounds like QoI, but this=20
might be a user decision.</div></blockquote><br>I don't know if I=20
understand what you are asking, but to perform that shift after the=20
multiplication, that would need to be known at compile time because it=20
would affect the type of the result,<br>but I could only know if the result=
saturated during runtime, unless everything was a constexpr computation. <=
br><br>On Tuesday, March 11, 2014 9:40:24 AM UTC-3, Ville Voutilainen wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><br>I suppose it would be a g=
ood idea to get early feedback from the Numerics
<br>Study Group. For that, you need to contact Lawrence Crowl.
<br></blockquote><div><br>Sure, I was expecting him to show up, but I guess=
it would be better to contact him directly in case he missed this thread. =
<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 <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_288_21928933.1394631830226--
.
Author: Lawrence Crowl <lawrence.crowl@gmail.com>
Date: Wed, 12 Mar 2014 15:45:40 -0700 (PDT)
Raw View
------=_Part_135_26652160.1394664340821
Content-Type: text/plain; charset=UTF-8
On Wednesday, March 12, 2014 6:43:50 AM UTC-7, Matheus Izvekov wrote:
>
> On Tuesday, March 11, 2014 9:28:36 AM UTC-3, dgutson . wrote:
>
>> I suppose it would be a good idea to get early feedback from the Numerics
>> Study Group. For that, you need to contact Lawrence Crowl.
>>
>
> Sure, I was expecting him to show up, but I guess it would be better to
> contact him directly in case he missed this thread.
>
So, my email subscription got lost. I've missed things. Anyway, I think
I need to give a bit more background.
When I first started doing fixed-point computation, it was with integers
and explicit shifts. It was very painful.
Then I took an approach much like what Matheus Izvekov has done. It was
a template class parameterized by base type and number of bits below the
radix.
The problem was that it lost bits left and right. Overflows were hard to
avoid without writing in the style of a two-address assembler. Excessive
truncation/rounding was likewise hard to avoid. The result was either
extreme overkill in the representation size (a performance problem) or
code that quickly became either unreadable or unreliable.
The problem is that the approach tends preserve the type and the number
fractional bits through the expressions. You do not want that. You want
the expressions to preserve the information content of the numbers.
The reason that floating-point computation displaced fixed-point
computation in early computers is precisely because it does a better job
of preserving information through expresssions.
Still, fixed-point computation is better than floating-point computation
for some purposes. The problem is in expressing it in a way that is both
efficient and effectively programmable. I concluded that normal
operations needed to preserve the information and assignment and
conversion needed to manage information loss.
Normal operations preserve information by producing a result with a range
and resolution that is generally larger than its arguments. For most
operations, all information is preserved. For division, preserving all
of the information requires an infinite number of bits. So, I chose to
limit the representation to that which is roughly the within the error
range implied by the arguments.
When the result of an expression is assigned to a variable, or converted
to another type, there could be information loss. The first information
loss is overflow. The present C++ standard defines overflow for unsigned
integers to be modular, and leaves signed integer undefined. The problem
is that if you do not want the defined behavior, avoiding it is painful.
I chose to ask the user to state explicitly what they wanted. I also
chose to do that through a type parameter, which is less invasive than
other possible approaches. The default overflow handing is the most
conservative, throw an exception. The second information loss is
rounding. Again, there are many ways to round, and I take the same
approach. The default is also instructive, it rounds towards nearest
odd, which preserves the most information of any of the rounding modes.
The default mechanisms for handling information loss are those that are
most conservative. These have a performance cost, which programmers can
avoid by being more explicit.
My proposal does not expose or preserve the representation type. This
choice was very deliberate. First, the C++ primitive types are different
sizes on different platforms, leading to portability problems. Second,
the sign promotion rules among primitive types are wrong. Third, the
width promotion rules among primitive types are inconsistent with the
need to preserve information. Fourth, the representation type is not
important. What is important is that the implementation choose a
representation that is efficient. For that, it needs both range an
resolution.
Another effect of the keeping both range and resolution is that the range
and resolution need not straddle zero. For example, nonnegative<8,4>
represents values in the range [0,256) by increments of 16. This feature
enables programmers to be very precise about the information in their
variables.
Consider the implications of the above discussion on division. Suppose
we divide a negatable<8,0> by a negatable<6,0>. The approach of
preserving information produces a result of negatable<8-0,0-6>. Nearly
all the information is preserved. However, in producing bits below the
radix, the operation is definitely not integer division.
Finally, there was a concern about implementability. Let me assure you
that no compiler changes are required. My implementation is a pure
library. There are places where expanded primitives (like a rounding
right shift) would help, but they are not necessary. Though I have not
verified recently, GCC produces efficient code with my library. It is
true that the my library relies on a compiler that does a decent job of
inlining. My library is not the only one that does so. The down side
is that my implementation uses lots of template magic, which has a
compile-time cost.
The template magic also has a cost in developing the library. I am in
the middle of a restructuring the implementation based on requests from
the numerics study group. I intend to open source it when I have it in
a usable shape.
--
---
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_135_26652160.1394664340821
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, March 12, 2014 6:43:50 AM UTC-7, Matheus Izv=
ekov 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">On=
Tuesday, March 11, 2014 9:28:36 AM UTC-3, dgutson . wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex">I suppose it would be a good idea to get early =
feedback from the Numerics
<br>Study Group. For that, you need to contact Lawrence Crowl.
<br></blockquote><div><br>Sure, I was expecting him to show up, but I guess=
it would be better to contact him directly in case he missed this thread. =
<br></div></div></blockquote><div><br>So, my email subscription got lost.&n=
bsp; I've missed things. Anyway, I think<br>I need to give a bit more=
background.<br><br>When I first started doing fixed-point computation, it =
was with integers<br>and explicit shifts. It was very painful.<br><br=
>Then I took an approach much like what Matheus Izvekov has done. It =
was <br>a template class parameterized by base type and number of bits belo=
w the<br>radix.<br><br>The problem was that it lost bits left and right.&nb=
sp; Overflows were hard to<br>avoid without writing in the style of a two-a=
ddress assembler. Excessive<br>truncation/rounding was likewise hard =
to avoid. The result was either<br>extreme overkill in the representa=
tion size (a performance problem) or<br>code that quickly became either unr=
eadable or unreliable.<br><br>The problem is that the approach tends preser=
ve the type and the number<br>fractional bits through the expressions. =
; You do not want that. You want<br>the expressions to preserve the i=
nformation content of the numbers.<br><br>The reason that floating-point co=
mputation displaced fixed-point<br>computation in early computers is precis=
ely because it does a better job<br>of preserving information through expre=
sssions.<br><br>Still, fixed-point computation is better than floating-poin=
t computation<br>for some purposes. The problem is in expressing it i=
n a way that is both<br>efficient and effectively programmable. I con=
cluded that normal<br>operations needed to preserve the information and ass=
ignment and<br>conversion needed to manage information loss.<br><br>Normal =
operations preserve information by producing a result with a range<br>and r=
esolution that is generally larger than its arguments. For most<br>op=
erations, all information is preserved. For division, preserving all<=
br>of the information requires an infinite number of bits. So, I chos=
e to<br>limit the representation to that which is roughly the within the er=
ror<br>range implied by the arguments.<br><br>When the result of an express=
ion is assigned to a variable, or converted<br>to another type, there could=
be information loss. The first information<br>loss is overflow. =
; The present C++ standard defines overflow for unsigned<br>integers to be =
modular, and leaves signed integer undefined. The problem<br>is that =
if you do not want the defined behavior, avoiding it is painful.<br>I chose=
to ask the user to state explicitly what they wanted. I also<br>chos=
e to do that through a type parameter, which is less invasive than<br>other=
possible approaches. The default overflow handing is the most<br>con=
servative, throw an exception. The second information loss is<br>roun=
ding. Again, there are many ways to round, and I take the same<br>app=
roach. The default is also instructive, it rounds towards nearest<br>=
odd, which preserves the most information of any of the rounding modes.<br>=
<br>The default mechanisms for handling information loss are those that are=
<br>most conservative. These have a performance cost, which programme=
rs can<br>avoid by being more explicit.<br><br>My proposal does not expose =
or preserve the representation type. This<br>choice was very delibera=
te. First, the C++ primitive types are different<br>sizes on differen=
t platforms, leading to portability problems. Second,<br>the sign pro=
motion rules among primitive types are wrong. Third, the<br>width pro=
motion rules among primitive types are inconsistent with the<br>need to pre=
serve information. Fourth, the representation type is not<br>importan=
t. What is important is that the implementation choose a<br>represent=
ation that is efficient. For that, it needs both range an<br>resoluti=
on.<br><br>Another effect of the keeping both range and resolution is that =
the range<br>and resolution need not straddle zero. For example, nonn=
egative<8,4><br>represents values in the range [0,256) by increments =
of 16. This feature<br>enables programmers to be very precise about t=
he information in their<br>variables.<br><br>Consider the implications of t=
he above discussion on division. Suppose<br>we divide a negatable<=
8,0> by a negatable<6,0>. The approach of<br>preserving info=
rmation produces a result of negatable<8-0,0-6>. Nearly<br>all =
the information is preserved. However, in producing bits below the<br=
>radix, the operation is definitely not integer division.<br><br>Finally, t=
here was a concern about implementability. Let me assure you<br>that =
no compiler changes are required. My implementation is a pure<br>libr=
ary. There are places where expanded primitives (like a rounding<br>r=
ight shift) would help, but they are not necessary. Though I have not=
<br>verified recently, GCC produces efficient code with my library. I=
t is<br>true that the my library relies on a compiler that does a decent jo=
b of<br>inlining. My library is not the only one that does so. =
The down side<br>is that my implementation uses lots of template magic, whi=
ch has a<br>compile-time cost.<br><br>The template magic also has a cost in=
developing the library. I am in<br>the middle of a restructuring the=
implementation based on requests from<br>the numerics study group. I=
intend to open source it when I have it in<br>a usable shape.<br></div></d=
iv>
<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 <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_135_26652160.1394664340821--
.
Author: Matheus Izvekov <mizvekov@gmail.com>
Date: Thu, 13 Mar 2014 11:52:05 -0700 (PDT)
Raw View
------=_Part_2149_29720980.1394736725892
Content-Type: text/plain; charset=UTF-8
On Wednesday, March 12, 2014 7:45:40 PM UTC-3, Lawrence Crowl wrote:
My proposal does not expose or preserve the representation type. This
choice was very deliberate. First, the C++ primitive types are
different
sizes on different platforms, leading to portability problems. Second,
the sign promotion rules among primitive types are wrong. Third, the
width promotion rules among primitive types are inconsistent with the
need to preserve information. Fourth, the representation type is not
important. What is important is that the implementation choose a
representation that is efficient. For that, it needs both range an
resolution.
I understand that. I was going for a different approach where the operations
propagate to the underlying type of the operands and the resulting type is
then
used as the underlying type of the final result.
Like I said a couple of pages up, an operation like 'declspec(fp<A>() /
fp<B>())'
would result in a type like 'fp<declspec(A() / B())>'
My design goal would be to be able to add fixed point arithmetic on top of
any
arithmetic type that could be conceived in the future.
For example, I hope that with my proposal it would be possible to use your
'cardinal' and 'integral' types as base types, and then with other
modifications
it would be possible to have all those semantics that we agree are the most
desirable.
The advantage would that, if in the future another proposal like infinite
range integers
get accepted, then it would be possible to add fixed point on top of it
using this class.
And it would be even possible, it's even possible today, to add fixed point
on top of a
fundamental floating point type. Suppose for example that in some
computation the ranges
being worked are very outside the float/double ranges, it could be useful,
although the
the use I found for it today is when mixing floating point and fixed point
integral operations,
like I cited a couple of posts up.
Basically I think that all those issues of promotion, conversion rules,
range, rounding mode,
overflow, saturation and whatnot could be handled in a 'integral'-like
class and then a
fixed point class could be composed on top of it.
However, I am still not convinced that just adding new integer types as a
library solution
is that satisfactory, because that still leaves out template value
parameters only accepting
the built-in types. Just the other day I was bitten by a bug where I was
comparing signed and
unsigned in a template metaprogram, and of course it overflowed without any
warnings from clang.
So, if your types cardinal and integral get accepted, would there be any
hope of using them as
template value parameters?
Another effect of the keeping both range and resolution is that the
range
and resolution need not straddle zero. For example, nonnegative<8,4>
represents values in the range [0,256) by increments of 16. This
feature
enables programmers to be very precise about the information in their
variables.
I understand. I was also planing to support that, but instead of
integrating it
into the fp class, it would sit in another class which could be composed
with it.
Consider the implications of the above discussion on division. Suppose
we divide a negatable<8,0> by a negatable<6,0>. The approach of
preserving information produces a result of negatable<8-0,0-6>. Nearly
all the information is preserved. However, in producing bits below the
radix, the operation is definitely not integer division.
I agree that is nice, and the code I posted on github currently does not do
that,
but the default behaviour of the division could be changed so that it takes
into account the range of the underlying type.
Finally, there was a concern about implementability. Let me assure you
that no compiler changes are required. My implementation is a pure
library. There are places where expanded primitives (like a rounding
right shift) would help, but they are not necessary. Though I have not
verified recently, GCC produces efficient code with my library. It is
true that the my library relies on a compiler that does a decent job of
inlining. My library is not the only one that does so. The down side
is that my implementation uses lots of template magic, which has a
compile-time cost.
I believe you, and I am only hoping that c++ has a feature like that sooner,
and I'm sure you are doing everything you can.
Anyway, I think this post was very constructive because now I understand
what is considered important to support, thank you very much for it.
The template magic also has a cost in developing the library. I am in
the middle of a restructuring the implementation based on requests from
the numerics study group. I intend to open source it when I have it in
a usable shape.
Looking forward to 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/.
------=_Part_2149_29720980.1394736725892
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, March 12, 2014 7:45:40 PM UTC-3, Lawrence Cr=
owl wrote:<br><br> My proposal does not expose or preserv=
e the representation type. This<br> choice was very=
deliberate. First, the C++ primitive types are different<br> &n=
bsp; sizes on different platforms, leading to portability problems.&n=
bsp; Second,<br> the sign promotion rules among primitive=
types are wrong. Third, the<br> width promotion ru=
les among primitive types are inconsistent with the<br> n=
eed to preserve information. Fourth, the representation type is not<b=
r> important. What is important is that the impleme=
ntation choose a<br> representation that is efficient.&nb=
sp; For that, it needs both range an<br> resolution.<br><=
br>I understand that. I was going for a different approach where the operat=
ions<br>propagate to the underlying type of the operands and the resulting =
type is then<br>used as the underlying type of the final result.<br>Like I =
said a couple of pages up, an operation like 'declspec(fp<A>() / fp&l=
t;B>())'<br>would result in a type like 'fp<declspec(A() / B())>'<=
br>My design goal would be to be able to add fixed point arithmetic on top =
of any<br>arithmetic type that could be conceived in the future.<br>For exa=
mple, I hope that with my proposal it would be possible to use your<br>'car=
dinal' and 'integral' types as base types, and then with other modification=
s<br>it would be possible to have all those semantics that we agree are the=
most desirable.<br>The advantage would that, if in the future another prop=
osal like infinite range integers<br>get accepted, then it would be possibl=
e to add fixed point on top of it using this class.<br>And it would be even=
possible, it's even possible today, to add fixed point on top of a<br>fund=
amental floating point type. Suppose for example that in some computation t=
he ranges<br>being worked are very outside the float/double ranges, it coul=
d be useful, although the<br>the use I found for it today is when mixing fl=
oating point and fixed point integral operations,<br>like I cited a couple =
of posts up.<br><br>Basically I think that all those issues of promotion, c=
onversion rules, range, rounding mode,<br>overflow, saturation and whatnot =
could be handled in a 'integral'-like class and then a<br>fixed point class=
could be composed on top of it.<br><br>However, I am still not convinced t=
hat just adding new integer types as a library solution<br>is that satisfac=
tory, because that still leaves out template value parameters only acceptin=
g<br>the built-in types. Just the other day I was bitten by a bug where I w=
as comparing signed and<br>unsigned in a template metaprogram, and of cours=
e it overflowed without any warnings from clang.<br>So, if your types cardi=
nal and integral get accepted, would there be any hope of using them as<br>=
template value parameters?<br><br> Another effect of the =
keeping both range and resolution is that the range<br> a=
nd resolution need not straddle zero. For example, nonnegative<8,4=
><br> represents values in the range [0,256) by increm=
ents of 16. This feature<br> enables programmers to=
be very precise about the information in their<br> varia=
bles.<br><br>I understand. I was also planing to support that, but instead =
of integrating it<br>into the fp class, it would sit in another class which=
could be composed with it.<br><br> Consider the implicat=
ions of the above discussion on division. Suppose<br> &nbs=
p; we divide a negatable<8,0> by a negatable<6,0>. The ap=
proach of<br> preserving information produces a result of=
negatable<8-0,0-6>. Nearly<br> all the infor=
mation is preserved. However, in producing bits below the<br> &n=
bsp; radix, the operation is definitely not integer division.<br><br>=
I agree that is nice, and the code I posted on github currently does not do=
that,<br>but the default behaviour of the division could be changed so tha=
t it takes<br>into account the range of the underlying type.<br><br> &=
nbsp; Finally, there was a concern about implementability. Let =
me assure you<br> that no compiler changes are required.&=
nbsp; My implementation is a pure<br> library. Ther=
e are places where expanded primitives (like a rounding<br> &nbs=
p; right shift) would help, but they are not necessary. Though I have=
not<br> verified recently, GCC produces efficient code w=
ith my library. It is<br> true that the my library =
relies on a compiler that does a decent job of<br> inlini=
ng. My library is not the only one that does so. The down side<=
br> is that my implementation uses lots of template magic=
, which has a<br> compile-time cost.<br><br>I believe you=
, and I am only hoping that c++ has a feature like that sooner,<br>and I'm =
sure you are doing everything you can.<br>Anyway, I think this post was ver=
y constructive because now I understand<br>what is considered important to =
support, thank you very much for it.<br><br> The template=
magic also has a cost in developing the library. I am in<br> &n=
bsp; the middle of a restructuring the implementation based on reques=
ts from<br> the numerics study group. I intend to o=
pen source it when I have it in<br> a usable shape.<br><b=
r>Looking forward to it!<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 <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_2149_29720980.1394736725892--
.
Author: Lawrence Crowl <Lawrence@Crowl.org>
Date: Thu, 13 Mar 2014 14:48:07 -0700
Raw View
On 3/13/14, Matheus Izvekov <mizvekov@gmail.com> wrote:
> On Wednesday, March 12, 2014 7:45:40 PM UTC-3, Lawrence Crowl wrote:
> My proposal does not expose or preserve the representation type.
> This choice was very deliberate. First, the C++ primitive types
> are different sizes on different platforms, leading to portability
> problems. Second, the sign promotion rules among primitive types
> are wrong. Third, the width promotion rules among primitive types
> are inconsistent with the need to preserve information. Fourth,
> the representation type is not important. What is important is
> that the implementation choose a representation that is efficient.
> For that, it needs both range an resolution.
>
> I understand that. I was going for a different approach where the
> operations propagate to the underlying type of the operands and the
> resulting type is then used as the underlying type of the final
> result. Like I said a couple of pages up, an operation like
> 'declspec(fp<A>() / fp<B>())' would result in a type like
> 'fp<declspec(A() / B())>'
I understand your goal here. I am suggesting that the approach breaks
down because of the interaction of the semantics of the fp template and
the parameter types.
> My design goal would be to be able to add fixed point arithmetic on
> top of any arithmetic type that could be conceived in the future.
> For example, I hope that with my proposal it would be possible to use
> your 'cardinal' and 'integral' types as base types, and then with
> other modifications it would be possible to have all those semantics
> that we agree are the most desirable.
In fact, my library is implemented that way. It does not, however,
expose that relationship in the interface contract. Doing so, is a
debatable point. However, what makes it feasible is that the cardinal
and integral types meet the needs of fixed-point types. Not all
numeric types would.
> The advantage would that, if in the future another proposal like
> infinite range integers get accepted, then it would be possible to
> add fixed point on top of it using this class.
But what would happen to division? Theoretically, a single division
could consume all of memory. There is a significant difference
between fixed and unbounded representations. Given an unbounded
representation, rational numbers probably make more sense than
fixed-point numbers. The numerics study group had a discussion about
a template for rational numbers. We ended up concluding that rational
numbers based on fixed representations necessarily had different
semantics from those with unbounded representations, and so necessarily
had to be different types.
> And it would be even possible, it's even possible today, to add fixed
> point on top of a fundamental floating point type. Suppose for example
> that in some computation the ranges being worked are very outside the
> float/double ranges, it could be useful, although the the use I found
> for it today is when mixing floating point and fixed point integral
> operations, like I cited a couple of posts up.
I saw that, though I think for most purposes you are better off with
a floating-point type with an extended range. It would be nice to
have a floating-point template type that took exponent and fraction
size as parameters.
> Basically I think that all those issues of promotion, conversion
> rules, range, rounding mode, overflow, saturation and whatnot could
> be handled in a 'integral'-like class and then a fixed point class
> could be composed on top of it.
Well, what I have does essentially that, by design, though I do not
expose it. Exposing it is a discussion worth having.
> However, I am still not convinced that just adding new integer types
> as a library solution is that satisfactory, because that still leaves
> out template value parameters only accepting the built-in types. Just
> the other day I was bitten by a bug where I was comparing signed and
> unsigned in a template metaprogram, and of course it overflowed
> without any warnings from clang. So, if your types cardinal and
> integral get accepted, would there be any hope of using them as
> template value parameters?
They are literal types, and N3413 "Allowing arbitrary literal types
for non-type template parameters" sets us on the path towards getting
them as non-type template parameters. I think there are lots of good
reasons to make the proposal happen.
> Another effect of the keeping both range and resolution is that
> the range and resolution need not straddle zero. For example,
> nonnegative<8,4> represents values in the range [0,256) by
> increments of 16. This feature enables programmers to be very
> precise about the information in their variables.
>
> I understand. I was also planing to support that, but instead of
> integrating it into the fp class, it would sit in another class
> which could be composed with it.
Can you clarify the value that composition brings?
> Consider the implications of the above discussion on division.
> Suppose we divide a negatable<8,0> by a negatable<6,0>. The
> approach of preserving information produces a result of
> negatable<8-0,0-6>. Nearly all the information is preserved.
> However, in producing bits below the radix, the operation is
> definitely not integer division.
>
> I agree that is nice, and the code I posted on github currently
> does not do that, but the default behaviour of the division could
> be changed so that it takes into account the range of the
> underlying type.
I am more concerned about the range of values than the range of the
underlying type because the representations needed to avoid overflow
in expressions grow faster if you use the range of the representation.
> Finally, there was a concern about implementability. Let me
> assure you that no compiler changes are required. My
> implementation is a pure library. There are places where
> expanded primitives (like a rounding right shift) would help,
> but they are not necessary. Though I have not verified recently,
> GCC produces efficient code with my library. It is true that the
> my library relies on a compiler that does a decent job of
> inlining. My library is not the only one that does so. The down
> side is that my implementation uses lots of template magic, which
> has a compile-time cost.
>
> I believe you, and I am only hoping that c++ has a feature like that
> sooner, and I'm sure you are doing everything you can. Anyway, I
> think this post was very constructive because now I understand what
> is considered important to support, thank you very much for it.
>
> The template magic also has a cost in developing the library.
> I am in the middle of a restructuring the implementation based
> on requests from the numerics study group. I intend to open
> source it when I have it in a usable shape.
>
> Looking forward to it!
--
Lawrence Crowl
--
---
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: Matheus Izvekov <mizvekov@gmail.com>
Date: Thu, 13 Mar 2014 15:39:07 -0700 (PDT)
Raw View
------=_Part_2260_15430769.1394750347932
Content-Type: text/plain; charset=UTF-8
On Thursday, March 13, 2014 6:48:07 PM UTC-3, Lawrence Crowl wrote:
In fact, my library is implemented that way. It does not, however,
expose that relationship in the interface contract. Doing so, is a
debatable point. However, what makes it feasible is that the cardinal
and integral types meet the needs of fixed-point types. Not all
numeric types would.
I see, very good, although I would prefer if this relationship was somehow
exposed in the interface, and each part could be used with different types.
But what would happen to division? Theoretically, a single division
could consume all of memory. There is a significant difference
between fixed and unbounded representations. Given an unbounded
representation, rational numbers probably make more sense than
fixed-point numbers. The numerics study group had a discussion about
a template for rational numbers. We ended up concluding that rational
numbers based on fixed representations necessarily had different
semantics from those with unbounded representations, and so necessarily
had to be different types.
Yeah, I was having a different semantics for division in mind.
It would behave like an integer division if you did:
auto z = x / y;
But would be able to produce bits below the radix if you assigned it to a
fp class with radix point above the result.
This could be implemented with a proxy object and with overloading operator
auto.
I saw that, though I think for most purposes you are better off with
a floating-point type with an extended range. It would be nice to
have a floating-point template type that took exponent and fraction
size as parameters.
But how do you propose to handle that optimization case I cited, would it be
fine by you to just ask the user to break the abstraction a bit?
Well, what I have does essentially that, by design, though I do not
expose it. Exposing it is a discussion worth having.
Yeah, I see now, though that was not clear in N3352.
They are literal types, and N3413 "Allowing arbitrary literal types
for non-type template parameters" sets us on the path towards getting
them as non-type template parameters. I think there are lots of good
reasons to make the proposal happen.
If the committee votes for that, would be great, I also have other uses for
it.
Can you clarify the value that composition brings?
Basically the value I saw was that you could have something way simpler that
could be fast tracked to adoption, by avoiding lots of contentious issues,
and it would be much better to use it with the built-in types than the
current situation
of having no birds in hand.
I designed the semantics of the operations differently from your proposal,
so it could be
more generic and work well with more diverse underlying types, just as a
way to
have it flexible and future-proofed.
I am more concerned about the range of values than the range of the
underlying type because the representations needed to avoid overflow
in expressions grow faster if you use the range of the representation.
Yeah, but if the underlying type is a ranged type just like your integral
and cardinal types, then it works just the same.
I of course have not tried, but I think that if I could make fp work on top
of your integral, then most operations would have identical semantics, clear
exception would be division.
By the way, how is the development of your proposal being discussed and
coordinated? Is it in any public forum or is there a way anyone else
could participate?
--
---
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_2260_15430769.1394750347932
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, March 13, 2014 6:48:07 PM UTC-3, Lawrence Cro=
wl wrote:<br> In fact, my library is implemented that way=
.. It does not, however,<br> expose that relationshi=
p in the interface contract. Doing so, is a<br> deb=
atable point. However, what makes it feasible is that the cardinal<br=
> and integral types meet the needs of fixed-point types.=
Not all<br> numeric types would.<br><br>I see, ver=
y good, although I would prefer if this relationship was somehow<br>exposed=
in the interface, and each part could be used with different types.<br><br=
> But what would happen to division? Theoretically,=
a single division<br> could consume all of memory. =
There is a significant difference<br> between fixed and =
unbounded representations. Given an unbounded<br> r=
epresentation, rational numbers probably make more sense than<br> &nbs=
p; fixed-point numbers. The numerics study group had a discussi=
on about<br> a template for rational numbers. We en=
ded up concluding that rational<br> numbers based on fixe=
d representations necessarily had different<br> semantics=
from those with unbounded representations, and so necessarily<br> &nb=
sp; had to be different types.<br><br>Yeah, I was having a different =
semantics for division in mind.<br>It would behave like an integer division=
if you did:<br><br> auto z =3D x / y;<br><br>But would b=
e able to produce bits below the radix if you assigned it to a<br>fp class =
with radix point above the result.<br>This could be implemented with a prox=
y object and with overloading operator auto.<br><br> I sa=
w that, though I think for most purposes you are better off with<br> &=
nbsp; a floating-point type with an extended range. It would be=
nice to<br> have a floating-point template type that too=
k exponent and fraction<br> size as parameters.<br><br>Bu=
t how do you propose to handle that optimization case I cited, would it be<=
br>fine by you to just ask the user to break the abstraction a bit?<br><br>=
Well, what I have does essentially that, by design, thou=
gh I do not<br> expose it. Exposing it is a discuss=
ion worth having.<br><br>Yeah, I see now, though that was not clear in N335=
2.<br><br> They are literal types, and N3413 "Allowing ar=
bitrary literal types<br> for non-type template parameter=
s" sets us on the path towards getting<br> them as non-ty=
pe template parameters. I think there are lots of good<br>  =
; reasons to make the proposal happen.<br><br>If the committee votes =
for that, would be great, I also have other uses for it.<br><br>  =
; Can you clarify the value that composition brings?<br><br>Basically=
the value I saw was that you could have something way simpler that<br>coul=
d be fast tracked to adoption, by avoiding lots of contentious issues,<br>a=
nd it would be much better to use it with the built-in types than the curre=
nt situation<br>of having no birds in hand.<br><br>I designed the semantics=
of the operations differently from your proposal, so it could be<br>more g=
eneric and work well with more diverse underlying types, just as a way to<b=
r>have it flexible and future-proofed.<br><br> I am more =
concerned about the range of values than the range of the<br> &n=
bsp; underlying type because the representations needed to avoid overflow<b=
r> in expressions grow faster if you use the range of the=
representation.<br><br>Yeah, but if the underlying type is a ranged type j=
ust like your integral<br>and cardinal types, then it works just the same.<=
br>I of course have not tried, but I think that if I could make fp work on =
top<br>of your integral, then most operations would have identical semantic=
s, clear<br>exception would be division.<br><br>By the way, how is the deve=
lopment of your proposal being discussed and<br>coordinated? Is it in any p=
ublic forum or is there a way anyone else<br>could participate?<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 <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_2260_15430769.1394750347932--
.
Author: Lawrence Crowl <Lawrence@Crowl.org>
Date: Thu, 13 Mar 2014 19:31:40 -0700
Raw View
On 3/13/14, Matheus Izvekov <mizvekov@gmail.com> wrote:
> On Thursday, March 13, 2014 6:48:07 PM UTC-3, Lawrence Crowl wrote:
> In fact, my library is implemented that way. It does not, however,
> expose that relationship in the interface contract. Doing so, is a
> debatable point. However, what makes it feasible is that the cardinal
> and integral types meet the needs of fixed-point types. Not all
> numeric types would.
>
> I see, very good, although I would prefer if this relationship was somehow
> exposed in the interface, and each part could be used with different types.
I will add the issue to the next paper.
> But what would happen to division? Theoretically, a single division
> could consume all of memory. There is a significant difference
> between fixed and unbounded representations. Given an unbounded
> representation, rational numbers probably make more sense than
> fixed-point numbers. The numerics study group had a discussion about
> a template for rational numbers. We ended up concluding that rational
> numbers based on fixed representations necessarily had different
> semantics from those with unbounded representations, and so necessarily
> had to be different types.
>
> Yeah, I was having a different semantics for division in mind.
> It would behave like an integer division if you did:
>
> auto z = x / y;
>
> But would be able to produce bits below the radix if you assigned it to a
> fp class with radix point above the result.
> This could be implemented with a proxy object and with overloading
> operator auto.
I'd need to be convinced that you could do it in general. The C++ type
system generally bubbles up, not down.
> I saw that, though I think for most purposes you are better off with
> a floating-point type with an extended range. It would be nice to
> have a floating-point template type that took exponent and fraction
> size as parameters.
>
> But how do you propose to handle that optimization case I cited, would
> it be fine by you to just ask the user to break the abstraction a bit?
I think this example is one that needs a more clearly explained use case.
In particular, showing the written code and generated code with both
approaches.
> Well, what I have does essentially that, by design, though I do not
> expose it. Exposing it is a discussion worth having.
>
> Yeah, I see now, though that was not clear in N3352.
Yes, it was not clear.
> They are literal types, and N3413 "Allowing arbitrary literal types
> for non-type template parameters" sets us on the path towards getting
> them as non-type template parameters. I think there are lots of good
> reasons to make the proposal happen.
>
> If the committee votes for that, would be great, I also have other uses for
> it.
>
> Can you clarify the value that composition brings?
>
> Basically the value I saw was that you could have something way simpler
> that could be fast tracked to adoption, by avoiding lots of contentious
> issues, and it would be much better to use it with the built-in types than
> the current situation of having no birds in hand.
You end up getting different contentious issues, as you've seen from my
response. :-)
>
> I designed the semantics of the operations differently from your proposal,
> so it could be more generic and work well with more diverse underlying
> types, just as a way to have it flexible and future-proofed.
>
> I am more concerned about the range of values than the range of the
> underlying type because the representations needed to avoid overflow
> in expressions grow faster if you use the range of the representation.
>
> Yeah, but if the underlying type is a ranged type just like your integral
> and cardinal types, then it works just the same.
> I of course have not tried, but I think that if I could make fp work on top
> of your integral, then most operations would have identical semantics,
> clear exception would be division.
You would need to add rounding as well.
> By the way, how is the development of your proposal being discussed
> and coordinated? Is it in any public forum or is there a way anyone else
> could participate?
Right now, it is just on my computer. It'll probably end up on github,
with all the opportunities for interaction that implies.
--
Lawrence Crowl
--
---
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: Matheus Izvekov <mizvekov@gmail.com>
Date: Fri, 14 Mar 2014 07:22:53 -0700 (PDT)
Raw View
------=_Part_63_29196693.1394806973164
Content-Type: text/plain; charset=UTF-8
On Thursday, March 13, 2014 11:31:40 PM UTC-3, Lawrence Crowl wrote:
I'd need to be convinced that you could do it in general. The C++ type
system generally bubbles up, not down.
I'll give it a try and report later.
I think this example is one that needs a more clearly explained use
case.
In particular, showing the written code and generated code with both
approaches.
Sure, here follows. Since I don't have access to your implementation, here
is example code
and assembly with mine.
First I present the bad (sub-optimal) example:
#include "fp.hpp"
#include <array>
#include <cmath>
static volatile double garbage;
int main() {
std::array<double, 32> a;
for(int i = 0; i < a.size(); ++i) a[i] = std::sin(i);
std::array<fp<int16_t, 14>, a.size()> b;
for(int i = 0; i < b.size(); ++i) b[i] = std::cos(i);
//above here is initialization
for(int i = 0; ; i = (i + 1) & 31) { //here is the inner loop
auto x = a[i];
auto y = double(b[i]); // b has radix pos = 14, gets scaled back to
0 here
double res = x * y;
garbage = res;
}
return 0;
}
Now the good, optimized example showing the technique of using 'fixed-point
floating-point numbers':
#include "fp.hpp"
#include <array>
#include <cmath>
static volatile double garbage;
int main() {
std::array<fp<double,-14>, 32> a; // now the value is scaled here
for(int i = 0; i < a.size(); ++i) a[i] = std::sin(i);
std::array<fp<int16_t, 14>, a.size()> b;
for(int i = 0; i < b.size(); ++i) b[i] = std::cos(i);
//above here is initialization
for(int i = 0; ; i = (i + 1) & 31) { //here is the inner loop
auto x = a[i];
auto y = b[i];
// since x has radix point at -14 and y has radix point at 14,
// when they get multiplied, the result is already at radix point 0
// thus no scaling happens here in the innerloop
auto res = double(x * y); // no scaling here, yay!
garbage = res;
}
return 0;
}
They each get generated into the following asm
Bad code:
0000000000000000 <main>:
0: push r14
12: (bad)
13: cvtsi2sd xmm0,ebx
17: call 1c <main+0xc>
1c: movsd QWORD PTR [rsp+rbx*8+0x48],xmm0
22: inc rbx
25: cmp rbx,0x20
29: jne 10 <main>
2b: xor ebx,ebx
2d: xor r14d,r14d
30: xorps xmm0,xmm0
33: cvtsi2sd xmm0,r14d
38: call 3d <main+0x2d>
3d: mulsd xmm0,QWORD PTR [rip+0x0] # 45 <main+0x35>
45: cvttsd2si eax,xmm0
49: mov WORD PTR [rsp+r14*2+0x8],ax
4f: inc r14
52: cmp r14,0x20
56: jne 30 <main+0x20>
58: movsd xmm0,QWORD PTR [rip+0x0] # here is the scaling
factor being moved into register xmm0
60: mov eax,ebx
62: movsx ecx,WORD PTR [rsp+rax*2+0x8]
67: xorps xmm1,xmm1
6a: cvtsi2sd xmm1,ecx
6e: mulsd xmm1,xmm0 # here is the scaling
multiplication, happens in the inner loop
72: mulsd xmm1,QWORD PTR [rsp+rax*8+0x48]
78: movsd QWORD PTR [rip+0x0],xmm1 # 80 <main+0x70>
80: inc ebx
82: and ebx,0x1f
85: jmp 60 <main+0x50>
And for the good example:
0000000000000000 <main>:
0: push r14
12: (bad)
13: cvtsi2sd xmm0,ebx
17: call 1c <main+0xc>
1c: mulsd xmm0,QWORD PTR [rip+0x0] # <- here is the scaling
multiplication,
24: movsd QWORD PTR [rsp+rbx*8+0x48],xmm0 # happens during
initialization of the array
2a: inc rbx
2d: cmp rbx,0x20
31: jne 10 <main>
33: xor ebx,ebx
35: xor r14d,r14d
38: nop DWORD PTR [rax+rax*1+0x0]
40: xorps xmm0,xmm0
43: cvtsi2sd xmm0,r14d
48: call 4d <main+0x3d>
4d: mulsd xmm0,QWORD PTR [rip+0x0] # 55 <main+0x45>
55: cvttsd2si eax,xmm0
59: mov WORD PTR [rsp+r14*2+0x8],ax
5f: inc r14
62: cmp r14,0x20
66: jne 40 <main+0x30>
68: nop DWORD PTR [rax+rax*1+0x0]
70: mov eax,ebx
72: movsx ecx,WORD PTR [rsp+rax*2+0x8]
77: xorps xmm0,xmm0
7a: cvtsi2sd xmm0,ecx
7e: mulsd xmm0,QWORD PTR [rsp+rax*8+0x48]
84: movsd QWORD PTR [rip+0x0],xmm0 # 8c <main+0x7c>
8c: inc ebx
8e: and ebx,0x1f
91: jmp 70 <main+0x60>
You end up getting different contentious issues, as you've seen from my
response. :-)
I suppose, but when I started this, I had no idea someone was actively
working on this problem.
And tackling the integer mess is a big undertaking, and you are doing
something
there which if it succeeds, will probably lead to the obsolescence of the
fundamental
integers at some point. I was not trying to be that ambitious on my first
try on
contributing back to the c++ community :)
You would need to add rounding as well.
Yeah, I suppose, but why not add rounding as an option to the integral
types?
Like rounding shifts and rounding division. Make it default to no rounding
for
cardinal and integral, and default enabled for the fractional types.
What's the problem with that?
Right now, it is just on my computer. It'll probably end up on github,
with all the opportunities for interaction that implies.
Great, looking forward to 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/.
------=_Part_63_29196693.1394806973164
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, March 13, 2014 11:31:40 PM UTC-3, Lawrence Cr=
owl wrote:<br> I'd need to be convinced that you could do=
it in general. The C++ type<br> system generally b=
ubbles up, not down.<br><br>I'll give it a try and report later.<br><br>&nb=
sp; I think this example is one that needs a more clearly expla=
ined use case.<br> In particular, showing the written cod=
e and generated code with both<br> approaches.<br><br>Sur=
e, here follows. Since I don't have access to your implementation, here is =
example code<br>and assembly with mine.<br><br>First I present the bad (sub=
-optimal) example:<br><br><div class=3D"prettyprint" style=3D"background-co=
lor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: so=
lid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"=
><div class=3D"subprettyprint"><span style=3D"color: #800;" class=3D"styled=
-by-prettify">#include</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-prettif=
y">"fp.hpp"</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">#=
include</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #080;" class=3D"styled-by-prettify"><array>=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #800;" class=3D"styled-by-prettify">#include</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #080;" class=3D"styled-by-prettify"><cmath></span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">static</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">volatile</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">double</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> garbage</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> main</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br> std</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">array</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">double</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"=
styled-by-prettify">32</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">></span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>&nb=
sp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>for</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> i </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;=
" class=3D"styled-by-prettify">0</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> i </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify"><</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">size</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">++</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify">i</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> a</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">[</span><span style=3D"color: #000;" class=3D"styled-by-prettify">i</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">]</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">sin</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">i</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>&=
nbsp; std</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">ar=
ray</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">fp</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">int16_t</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" =
class=3D"styled-by-prettify">14</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">>,</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> a</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">s=
ize</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()><=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> b</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br><br> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">for</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> i </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> i =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> b</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">size</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">++</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">i</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> b</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">i</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">]</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">cos</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">i</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br><br> </span=
><span style=3D"color: #800;" class=3D"styled-by-prettify">//above here is =
initialization</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br><br> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">for</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> i </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> i </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">i </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">+</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" =
class=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #066;" class=3D"styled-by-prettify">31</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"=
styled-by-prettify">//here is the inner loop</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br> </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> x </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> a</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">[</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">i</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">];</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> y </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">doubl=
e</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">b</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">[</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">i</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">]);</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"style=
d-by-prettify">// b has radix pos =3D 14, gets scaled back to 0 here</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
</span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">double</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> res </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D<=
/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 styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> y</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br> garbage </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> res</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br><br> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">0</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br></span></div></code></div><br><br>Now the good, optimized example =
showing the technique of using 'fixed-point floating-point numbers':<br><br=
><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 25=
0); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1p=
x; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpre=
ttyprint"><span style=3D"color: #800;" class=3D"styled-by-prettify">#includ=
e</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #080;" class=3D"styled-by-prettify">"fp.hpp"</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span=
style=3D"color: #800;" class=3D"styled-by-prettify">#include</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #080;" class=3D"styled-by-prettify"><array></span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #800;" class=3D"styled-by-prettify">#include</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;"=
class=3D"styled-by-prettify"><cmath></span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">static</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">volatile</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">double</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> garbage</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> main</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=
=3D"color: #000;" class=3D"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"><br> std</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">array</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify"><</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">fp</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify"><</span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">double</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">,-</span><span style=3D"color: #066;" class=3D"styled-by-prettify">14</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">>,</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #066;" class=3D"styled-by-prettify">32</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">></span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> a</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pr=
ettify">// now the value is scaled here</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br><br> </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">for</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> i </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> i </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> a</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">size</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">();</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">i</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> a</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">[</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">i</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">]</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">sin</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">i</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"><br><br> std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">array</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify"><</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">fp</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify"><</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify">int16_t</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">14</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">>,</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> a</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">size</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">()></span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> b</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br><br> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">for</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> i </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> i </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify"><</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> b</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">size</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>();</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">++</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">i</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> b</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">[</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">i</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">]</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">cos</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">i</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br><br> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">//above here is initialization</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br><br> </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">for</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> i </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-=
prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> i </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">i </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">+</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #066;" class=3D"styled-by-prettify">1</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" clas=
s=3D"styled-by-prettify">31</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </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: #800;" class=3D"styled-by-prettify">//here is the inner=
loop</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&=
nbsp; </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> x </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> a<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">i</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">];</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br> </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> y </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> b</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">[</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">i</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">];</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br> </span><span style=3D"color: #800;" =
class=3D"styled-by-prettify">// since x has radix point at -14 and y has ra=
dix point at 14,</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br> </span><span style=3D"color: #800;" c=
lass=3D"styled-by-prettify">// when they get multiplied, the result is alre=
ady at radix point 0</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br> </span><span style=3D"color: #800=
;" class=3D"styled-by-prettify">// thus no scaling happens here in the inne=
rloop</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&=
nbsp; </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> res </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">double</sp=
an><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"color: #=
000;" class=3D"styled-by-prettify"> y</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-=
prettify">// no scaling here, yay!</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br> garbage </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> res</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br><br> </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">return</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;"=
class=3D"styled-by-prettify">0</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">}</span></div></code></div><br>They each get generated into the follo=
wing asm<br><br>Bad code:<br><br><div class=3D"prettyprint" style=3D"backgr=
ound-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-st=
yle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prett=
yprint"><div class=3D"subprettyprint"><span style=3D"color: #066;" class=3D=
"styled-by-prettify">0000000000000000</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"st=
yled-by-prettify"><main></span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br> </span><span style=3D"color: #066;" class=3D"st=
yled-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
push r14<br> </span><span style=3D"color: #066;"=
class=3D"styled-by-prettify">12</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">bad</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify">  =
;<br> </span><span style=3D"color: #066;" class=3D"styled-by-prettify=
">13</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> c=
vtsi2sd xmm0</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify">ebx<br>=
</span><span style=3D"color: #066;" class=3D"styled-by-prettify">17<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> call &=
nbsp; </span><span style=3D"color: #066;" class=3D"styled-by-prettify">1c</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">main</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">+</span><span style=3D"color: #06=
6;" class=3D"styled-by-prettify">0xc</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br> </span><span style=3D"color: #066;" class=3D=
"styled-by-prettify">1c</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> movsd QWORD PTR </span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">[</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">rsp</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">+</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">rbx</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*<=
/span><span style=3D"color: #066;" class=3D"styled-by-prettify">8</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">+</span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">0x48</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">],</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">xmm0<br> </span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">22</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> inc rbx<br> </span><s=
pan style=3D"color: #066;" class=3D"styled-by-prettify">25</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> cmp rbx</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><spa=
n style=3D"color: #066;" class=3D"styled-by-prettify">0x20</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><span sty=
le=3D"color: #066;" class=3D"styled-by-prettify">29</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> jne </span><span=
style=3D"color: #066;" class=3D"styled-by-prettify">10</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #080;" class=3D"styled-by-prettify"><main></span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br> </span><span style=3D"co=
lor: #066;" class=3D"styled-by-prettify">2b</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> xor ebx</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">ebx<br> </span><span style=3D"=
color: #066;" class=3D"styled-by-prettify">2d</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> xor r14d</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">r14d<br> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">30</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> xorps xmm0</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">xmm0<br> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">33</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> cvtsi2sd xmm0</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">r14d<br> </span><span style=3D"=
color: #066;" class=3D"styled-by-prettify">38</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> call </span><span style=3D"c=
olor: #066;" class=3D"styled-by-prettify">3d</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify"><</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">main</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">+</span><span style=3D"color: #066;" class=3D"styled-by-pretti=
fy">0x2d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&g=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbs=
p; </span><span style=3D"color: #066;" class=3D"styled-by-prettify">3d</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> mulsd &nbs=
p;xmm0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">QWORD PTR </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">rip</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">+</span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">0x0</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">]</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #800;" class=3D"styled-by-prettify"># 45 <main+0x35></span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><sp=
an style=3D"color: #066;" class=3D"styled-by-prettify">45</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> cvttsd2si eax</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">xmm0<br> </span><span =
style=3D"color: #066;" class=3D"styled-by-prettify">49</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> mov WORD PTR =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">rsp</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">+</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">r14</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">*</span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">2</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">+</span><span style=3D"color: #066;" class=3D"styled-by-pret=
tify">0x8</span><span style=3D"color: #660;" class=3D"styled-by-prettify">]=
,</span><span style=3D"color: #000;" class=3D"styled-by-prettify">ax<br>&nb=
sp; </span><span style=3D"color: #066;" class=3D"styled-by-prettify">4f</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> inc  =
; r14<br> </span><span style=3D"color: #066;" class=3D"styled-b=
y-prettify">52</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> &nbs=
p; cmp r14</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">,</span><span style=3D"color: #066;" class=3D"styled-by-=
prettify">0x20</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br> </span><span style=3D"color: #066;" class=3D"styled-by-prett=
ify">56</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> &nbs=
p;jne </span><span style=3D"color: #066;" class=3D"styled-by-p=
rettify">30</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">main</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">+</span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">0x20</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">></span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br> </span><span style=3D"color: =
#066;" class=3D"styled-by-prettify">58</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> movsd xmm0</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify">QWORD PTR </span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">[</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">rip</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">+</span><span style=3D"color: #066;" class=3D"styled-by-prett=
ify">0x0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">]<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> &nb=
sp; </span><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify"># here is the scaling factor being moved into register xmm0</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><=
span style=3D"color: #066;" class=3D"styled-by-prettify">60</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> mov eax<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">ebx<br> </span=
><span style=3D"color: #066;" class=3D"styled-by-prettify">62</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> movsx ecx</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">WORD PTR </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">[</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">rsp</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">+</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">rax</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">*</span><span style=3D"color: #066;" class=3D"styled-by-=
prettify">2</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>+</span><span style=3D"color: #066;" class=3D"styled-by-prettify">0x8</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">]</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><span =
style=3D"color: #066;" class=3D"styled-by-prettify">67</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> xorps xmm1</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">xmm1<br> </span><span =
style=3D"color: #066;" class=3D"styled-by-prettify">6a</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> cvtsi2sd xmm1</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">ecx<br> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">6e</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> mulsd xmm1</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">xmm0 &=
nbsp; </span><span style=3D"color=
: #800;" class=3D"styled-by-prettify"># here is the scaling multiplication,=
happens in the inner loop</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br> </span><span style=3D"color: #066;" class=3D"sty=
led-by-prettify">72</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
mulsd xmm1</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">QWORD PTR </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">[</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">rsp</span><span style=3D"color: #660;" class=3D"styled-by-prettify">+</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">rax</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">8</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">+</span><span style=3D"color: #066;" =
class=3D"styled-by-prettify">0x48</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">]</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br> </span><span style=3D"color: #066;" class=3D"styl=
ed-by-prettify">78</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
movsd QWORD PTR </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">[</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">rip</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">+</span><span style=3D"color: #066;" class=3D"styled-by-prettify">=
0x0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">],</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">xmm1 &nb=
sp; </span><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify"># 80 <main+0x70></span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br> </span><span style=3D"color: #066;" class=3D"=
styled-by-prettify">80</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> inc ebx<br> </span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">82</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">and</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> ebx</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">,</span><span style=3D"color: #066;" class=3D"styl=
ed-by-prettify">0x1f</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br> </span><span style=3D"color: #066;" class=3D"styled-by=
-prettify">85</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify">  =
; jmp </span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">60</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&l=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">main</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">+</span><span =
style=3D"color: #066;" class=3D"styled-by-prettify">0x50</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">></span></div></code></di=
v><br><br>And for the good example:<br><br><div class=3D"prettyprint" 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 clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #066;=
" class=3D"styled-by-prettify">0000000000000000</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" c=
lass=3D"styled-by-prettify"><main></span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br> </span><span style=3D"color: #066;" c=
lass=3D"styled-by-prettify">0</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> push r14<br> </span><span style=3D"col=
or: #066;" class=3D"styled-by-prettify">12</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">bad</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> <br> </span><span style=3D"color: #066;" class=3D"styled-by=
-prettify">13</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify">  =
; cvtsi2sd xmm0</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">ebx<br> </span><span style=3D"color: #066;" class=3D"styled-by-pret=
tify">17</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> &nb=
sp;call </span><span style=3D"color: #066;" class=3D"styled-by-prett=
ify">1c</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">main</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">+</span><span style=3D"c=
olor: #066;" class=3D"styled-by-prettify">0xc</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">></span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br> </span><span style=3D"color: #066;"=
class=3D"styled-by-prettify">1c</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> mulsd xmm0</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">QWORD PTR </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">[</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">rip</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">+</span><span style=3D"color: #066;" class=3D"styled-by-prettify"=
>0x0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">]</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #800;" class=3D"styled-by-prettif=
y"># <- here is the scaling multiplication, </span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"><br> </span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">24</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> movsd QWORD PTR </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">[</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">rsp</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">+</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">rbx</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">*</span><span style=3D"color: #066;" class=3D"styled-by-pr=
ettify">8</span><span style=3D"color: #660;" class=3D"styled-by-prettify">+=
</span><span style=3D"color: #066;" class=3D"styled-by-prettify">0x48</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">],</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">xmm0 </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify"># happens durin=
g initialization of the array</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br> </span><span style=3D"color: #066;" class=3D"=
styled-by-prettify">2a</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> inc rbx<br> </span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">2d</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> cmp rbx</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">0x20</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br> </span><span style=3D"color: #06=
6;" class=3D"styled-by-prettify">31</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> jne </span><span style=3D"color:=
#066;" class=3D"styled-by-prettify">10</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"=
styled-by-prettify"><main></span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br> </span><span style=3D"color: #066;" clas=
s=3D"styled-by-prettify">33</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> xor ebx</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">ebx<br> </span><span style=3D"color: #066;" c=
lass=3D"styled-by-prettify">35</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> xor r14d</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">r14d<br> </span><span style=3D"color: #066=
;" class=3D"styled-by-prettify">38</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> nop DWORD PTR </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">[</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">rax</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">+</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">rax</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">*</span><span style=3D"color: #066;" class=3D"styled-by-pr=
ettify">1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">+=
</span><span style=3D"color: #066;" class=3D"styled-by-prettify">0x0</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">]</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><span st=
yle=3D"color: #066;" class=3D"styled-by-prettify">40</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> xorps xmm0</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">xmm0<br> </span><span sty=
le=3D"color: #066;" class=3D"styled-by-prettify">43</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> cvtsi2sd xmm0</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">r14d<br> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">48</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> call </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">4d</span><span style=3D"colo=
r: #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">main</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">+</span><span style=3D"color: #066;" class=3D"styled-by-p=
rettify">0x3d</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">></span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">4d=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> mulsd=
xmm0</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>,</span><span style=3D"color: #000;" class=3D"styled-by-prettify">QWORD PT=
R </span><span style=3D"color: #660;" class=3D"styled-by-prettify">[</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">rip</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">+</span><span style=3D"c=
olor: #066;" class=3D"styled-by-prettify">0x0</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">]</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D=
"color: #800;" class=3D"styled-by-prettify"># 55 <main+0x45></span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><=
span style=3D"color: #066;" class=3D"styled-by-prettify">55</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> cvttsd2si eax</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">xmm0<br> </span><span=
style=3D"color: #066;" class=3D"styled-by-prettify">59</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> mov WORD P=
TR </span><span style=3D"color: #660;" class=3D"styled-by-prettify">[</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">rsp</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">+</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">r14</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #066;" cl=
ass=3D"styled-by-prettify">2</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">+</span><span style=3D"color: #066;" class=3D"styled-by-p=
rettify">0x8</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">],</span><span style=3D"color: #000;" class=3D"styled-by-prettify">ax<br>=
</span><span style=3D"color: #066;" class=3D"styled-by-prettify">5f<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> inc &n=
bsp; r14<br> </span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">62</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> &=
nbsp; cmp r14</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">0x20</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br> </span><span style=3D"color: #066;" class=3D"styled-by-=
prettify">66</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
jne </span><span style=3D"color: #066;" class=3D"styled=
-by-prettify">40</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"><=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">main</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">+</span><span s=
tyle=3D"color: #066;" class=3D"styled-by-prettify">0x30</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br> </span><span style=3D"c=
olor: #066;" class=3D"styled-by-prettify">68</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> nop DWORD PTR </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">rax</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">+</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">rax</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">*</span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">1</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">+</span><span style=3D"color: #066;" class=3D"styled-by-prettify">0x0=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">]</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><=
span style=3D"color: #066;" class=3D"styled-by-prettify">70</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> mov eax<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">ebx<br> </span=
><span style=3D"color: #066;" class=3D"styled-by-prettify">72</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> movsx ecx</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">WORD PTR </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">[</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">rsp</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">+</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">rax</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">*</span><span style=3D"color: #066;" class=3D"styled-by-=
prettify">2</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>+</span><span style=3D"color: #066;" class=3D"styled-by-prettify">0x8</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">]</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><span =
style=3D"color: #066;" class=3D"styled-by-prettify">77</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> xorps xmm0</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">xmm0<br> </span><span =
style=3D"color: #066;" class=3D"styled-by-prettify">7a</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> cvtsi2sd xmm0</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">ecx<br> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">7e</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> mulsd xmm0</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">QWORD PTR </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">[</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">rsp</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">+</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">rax</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">*</span><span style=3D"color: #066;" class=3D"styled-by-prettify">=
8</span><span style=3D"color: #660;" class=3D"styled-by-prettify">+</span><=
span style=3D"color: #066;" class=3D"styled-by-prettify">0x48</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">]</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br> </span><span style=3D"=
color: #066;" class=3D"styled-by-prettify">84</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> movsd QWORD PTR </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">rip</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">+</span><span style=3D"color: #066;" cl=
ass=3D"styled-by-prettify">0x0</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">],</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">xmm0 </span><span style=3D"color: #8=
00;" class=3D"styled-by-prettify"># 8c <main+0x7c></span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><span styl=
e=3D"color: #066;" class=3D"styled-by-prettify">8c</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> inc ebx<br> =
</span><span style=3D"color: #066;" class=3D"styled-by-prettify">8e</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #008;" class=3D"styled-by-prettify">and</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> ebx</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">0x1f</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br> </span><span style=3D"c=
olor: #066;" class=3D"styled-by-prettify">91</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> jmp </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">70</span><span style=3D"colo=
r: #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">main</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">+</span><span style=3D"color: #066;" class=3D"styled-by-p=
rettify">0x60</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">></span></div></code></div><br><br><br> You end up =
getting different contentious issues, as you've seen from my<br>  =
; response. :-)<br><br>I suppose, but when I started this, I ha=
d no idea someone was actively working on this problem.<br>And tackling the=
integer mess is a big undertaking, and you are doing something<br>there wh=
ich if it succeeds, will probably lead to the obsolescence of the fundament=
al<br>integers at some point. I was not trying to be that ambitious on my f=
irst try on<br>contributing back to the c++ community :)<br><br>  =
; You would need to add rounding as well.<br><br>Yeah, I suppose, but=
why not add rounding as an option to the integral types?<br>Like rounding =
shifts and rounding division. Make it default to no rounding for<br>cardina=
l and integral, and default enabled for the fractional types.<br>What's the=
problem with that?<br><br> Right now, it is just on my c=
omputer. It'll probably end up on github,<br> with =
all the opportunities for interaction that implies.<br><br>Great, looking f=
orward to it.<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 <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_63_29196693.1394806973164--
.
Author: Lawrence Crowl <Lawrence@Crowl.org>
Date: Fri, 14 Mar 2014 14:25:36 -0700
Raw View
On 3/14/14, Matheus Izvekov <mizvekov@gmail.com> wrote:
> On Thursday, March 13, 2014 11:31:40 PM UTC-3, Lawrence Crowl wrote:
> I think this example is one that needs a more clearly explained use
> case. In particular, showing the written code and generated code
> with both approaches.
>
> Sure, here follows. Since I don't have access to your implementation,
> here is example code and assembly with mine.
>
> First I present the bad (sub-optimal) example:
>
> #include "fp.hpp"
>
> #include <array>
> #include <cmath>
>
> static volatile double garbage;
>
> int main() {
> std::array<double, 32> a;
>
> for(int i = 0; i < a.size(); ++i) a[i] = std::sin(i);
>
> std::array<fp<int16_t, 14>, a.size()> b;
>
> for(int i = 0; i < b.size(); ++i) b[i] = std::cos(i);
>
> //above here is initialization
>
> for(int i = 0; ; i = (i + 1) & 31) { //here is the inner loop
> auto x = a[i];
> auto y = double(b[i]); // b has radix pos = 14,
> // gets scaled back to 0 here
> double res = x * y;
> garbage = res;
> }
>
> return 0;
> }
As a matter of presentation, the committee prefers examples from real
code. It is unlikely that the above code will occur in production.
I know it seems like a burden, but it helps the committee understand
your problem, rather than just your solution.
>
> Now the good, optimized example showing the technique of using
> 'fixed-point floating-point numbers':
>
> #include "fp.hpp"
>
> #include <array>
> #include <cmath>
>
> static volatile double garbage;
>
> int main() {
> std::array<fp<double,-14>, 32> a; // now the value is scaled here
>
> for(int i = 0; i < a.size(); ++i) a[i] = std::sin(i);
>
> std::array<fp<int16_t, 14>, a.size()> b;
>
> for(int i = 0; i < b.size(); ++i) b[i] = std::cos(i);
>
> //above here is initialization
>
> for(int i = 0; ; i = (i + 1) & 31) { //here is the inner loop
> auto x = a[i];
> auto y = b[i];
> // since x has radix point at -14 and y has radix point at 14,
> // when they get multiplied, the result is already at radix point 0
> // thus no scaling happens here in the innerloop
> auto res = double(x * y); // no scaling here, yay!
> garbage = res;
> }
>
> return 0;
> }
>
> They each get generated into the following asm
>
> Bad code:
>
> 0000000000000000 <main>:
> 0: push r14
> 12: (bad)
> 13: cvtsi2sd xmm0,ebx
> 17: call 1c <main+0xc>
> 1c: movsd QWORD PTR [rsp+rbx*8+0x48],xmm0
> 22: inc rbx
> 25: cmp rbx,0x20
> 29: jne 10 <main>
> 2b: xor ebx,ebx
> 2d: xor r14d,r14d
> 30: xorps xmm0,xmm0
> 33: cvtsi2sd xmm0,r14d
> 38: call 3d <main+0x2d>
> 3d: mulsd xmm0,QWORD PTR [rip+0x0] # 45 <main+0x35>
> 45: cvttsd2si eax,xmm0
> 49: mov WORD PTR [rsp+r14*2+0x8],ax
> 4f: inc r14
> 52: cmp r14,0x20
> 56: jne 30 <main+0x20>
> 58: movsd xmm0,QWORD PTR [rip+0x0] # here is the scaling
> factor being moved into register xmm0
> 60: mov eax,ebx
> 62: movsx ecx,WORD PTR [rsp+rax*2+0x8]
> 67: xorps xmm1,xmm1
> 6a: cvtsi2sd xmm1,ecx
> 6e: mulsd xmm1,xmm0 # here is the scaling
> multiplication, happens in the inner loop
> 72: mulsd xmm1,QWORD PTR [rsp+rax*8+0x48]
> 78: movsd QWORD PTR [rip+0x0],xmm1 # 80 <main+0x70>
> 80: inc ebx
> 82: and ebx,0x1f
> 85: jmp 60 <main+0x50>
>
>
> And for the good example:
>
> 0000000000000000 <main>:
> 0: push r14
> 12: (bad)
> 13: cvtsi2sd xmm0,ebx
> 17: call 1c <main+0xc>
> 1c: mulsd xmm0,QWORD PTR [rip+0x0] # <- here is the scaling
> multiplication,
> 24: movsd QWORD PTR [rsp+rbx*8+0x48],xmm0 # happens during
> initialization of the array
> 2a: inc rbx
> 2d: cmp rbx,0x20
> 31: jne 10 <main>
> 33: xor ebx,ebx
> 35: xor r14d,r14d
> 38: nop DWORD PTR [rax+rax*1+0x0]
> 40: xorps xmm0,xmm0
> 43: cvtsi2sd xmm0,r14d
> 48: call 4d <main+0x3d>
> 4d: mulsd xmm0,QWORD PTR [rip+0x0] # 55 <main+0x45>
> 55: cvttsd2si eax,xmm0
> 59: mov WORD PTR [rsp+r14*2+0x8],ax
> 5f: inc r14
> 62: cmp r14,0x20
> 66: jne 40 <main+0x30>
> 68: nop DWORD PTR [rax+rax*1+0x0]
> 70: mov eax,ebx
> 72: movsx ecx,WORD PTR [rsp+rax*2+0x8]
> 77: xorps xmm0,xmm0
> 7a: cvtsi2sd xmm0,ecx
> 7e: mulsd xmm0,QWORD PTR [rsp+rax*8+0x48]
> 84: movsd QWORD PTR [rip+0x0],xmm0 # 8c <main+0x7c>
> 8c: inc ebx
> 8e: and ebx,0x1f
> 91: jmp 70 <main+0x60>
Ah, I see what you are doing here. Basically you are manually moving
a common sub expression on the exponent out of the loop. You need to
do it manually here because the hardware does not separate out the
exponent computation from the fraction computation.
> You end up getting different contentious issues, as you've seen
> from my response. :-)
>
> I suppose, but when I started this, I had no idea someone was actively
> working on this problem.
It's not just your proposal. Nearly every proposal, including all of
mine, go through a process of objections to issues unknown or forgotten
to the author. In short, there are no simple proposals.
> And tackling the integer mess is a big undertaking, and you are doing
> something there which if it succeeds, will probably lead to the
> obsolescence of the fundamental integers at some point.
I don't think the work will go that far, because things like index
variables still work fine with the fundamental types.
> I was not trying to be that ambitious on my first try on contributing
> back to the c++ community :)
Don't worry! Just remember that any proposal takes persistence.
>
> You would need to add rounding as well.
>
> Yeah, I suppose, but why not add rounding as an option to the integral
> types? Like rounding shifts and rounding division. Make it default to
> no rounding for cardinal and integral, and default enabled for the
> fractional types. What's the problem with that?
Actually, I do have them. But they are functions, not operators.
The numerics study group wanted me to separate out the overflow and
rounding primitives. It was a good request, because it has forced
me to generalize the facility. It's in testing now.
--
Lawrence Crowl
--
---
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: Marc <marc.glisse@gmail.com>
Date: Fri, 14 Mar 2014 15:44:08 -0700 (PDT)
Raw View
------=_Part_751_20060647.1394837048966
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Le vendredi 14 mars 2014 03:31:40 UTC+1, Lawrence Crowl a =C3=A9crit :
>
> On 3/13/14, Matheus Izvekov <mizv...@gmail.com <javascript:>> wrote:=20
> > But what would happen to division? Theoretically, a single divisio=
n=20
> > could consume all of memory. There is a significant difference=20
> > between fixed and unbounded representations. Given an unbounded=20
> > representation, rational numbers probably make more sense than=20
> > fixed-point numbers. The numerics study group had a discussion=20
> about=20
> > a template for rational numbers. We ended up concluding that=20
> rational=20
> > numbers based on fixed representations necessarily had different=20
> > semantics from those with unbounded representations, and so=20
> necessarily=20
> > had to be different types.=20
> >=20
> > Yeah, I was having a different semantics for division in mind.=20
> > It would behave like an integer division if you did:=20
> >=20
> > auto z =3D x / y;=20
> >=20
> > But would be able to produce bits below the radix if you assigned it to=
=20
> a=20
> > fp class with radix point above the result.=20
> > This could be implemented with a proxy object and with overloading=20
> > operator auto.=20
>
> I'd need to be convinced that you could do it in general. The C++ type=
=20
> system generally bubbles up, not down.=20
>
=20
With expression templates, it seems that similar things are done regularly.=
=20
In GMP, with mpf_class, when computing a=3Db+c+d, I think b+c is computed=
=20
with the precision of a, and similarly for the second addition. Some=20
wrappers of MPFR do more fancy things trying to estimate the required=20
precision on the intermediate results. And you can do the virtual / dynamic=
=20
equivalent.
--=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_751_20060647.1394837048966
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Le vendredi 14 mars 2014 03:31:40 UTC+1, Lawrence Crowl a =
=C3=A9crit :<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 3/13/14, M=
atheus Izvekov <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated=
-mailto=3D"8hGxX3z6aBEJ" onmousedown=3D"this.href=3D'javascript:';return tr=
ue;" onclick=3D"this.href=3D'javascript:';return true;">mizv...@gmail.com</=
a>> wrote:
<br>> But what would happen to division? Theoretical=
ly, a single division
<br>> could consume all of memory. There is a signif=
icant difference
<br>> between fixed and unbounded representations. G=
iven an unbounded
<br>> representation, rational numbers probably make more =
sense than
<br>> fixed-point numbers. The numerics study group =
had a discussion about
<br>> a template for rational numbers. We ended up c=
oncluding that rational
<br>> numbers based on fixed representations necessarily h=
ad different
<br>> semantics from those with unbounded representations,=
and so necessarily
<br>> had to be different types.
<br>>
<br>> Yeah, I was having a different semantics for division in mind.
<br>> It would behave like an integer division if you did:
<br>>
<br>> auto z =3D x / y;
<br>>
<br>> But would be able to produce bits below the radix if you assigned =
it to a
<br>> fp class with radix point above the result.
<br>> This could be implemented with a proxy object and with overloading
<br>> operator auto.
<br>
<br>I'd need to be convinced that you could do it in general. The C++=
type
<br>system generally bubbles up, not down.
<br></blockquote><div> <br>With expression templates, it seems that si=
milar things are done regularly. In GMP, with mpf_class, when computing a=
=3Db+c+d, I think b+c is computed with the precision of a, and similarly fo=
r the second addition. Some wrappers of MPFR do more fancy things trying to=
estimate the required precision on the intermediate results. And you can d=
o the virtual / dynamic equivalent.<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 <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_751_20060647.1394837048966--
.
Author: Matheus Izvekov <mizvekov@gmail.com>
Date: Fri, 14 Mar 2014 16:54:00 -0700 (PDT)
Raw View
------=_Part_878_26979101.1394841240174
Content-Type: text/plain; charset=UTF-8
On Friday, March 14, 2014 6:25:36 PM UTC-3, Lawrence Crowl wrote:
>
>
> As a matter of presentation, the committee prefers examples from real
> code. It is unlikely that the above code will occur in production.
> I know it seems like a burden, but it helps the committee understand
> your problem, rather than just your solution.
>
>
I see, thanks for the advice. I have a real world example of this, but the
code is
a lot more complicated and I hoped with that example I could show the
problem in
general. In case this needs to go forward with the committee, then I can
provide
a more real-world-like example.
> Ah, I see what you are doing here. Basically you are manually moving
> a common sub expression on the exponent out of the loop. You need to
> do it manually here because the hardware does not separate out the
> exponent computation from the fraction computation.
>
>
By hardware I think you mean the compiler, and yeah, that would be a pretty
difficult optimization even for clang.
> It's not just your proposal. Nearly every proposal, including all of
> mine, go through a process of objections to issues unknown or forgotten
> to the author. In short, there are no simple proposals.
>
>
I see, well but even then I think limiting the scope helps :)
> I don't think the work will go that far, because things like index
> variables still work fine with the fundamental types.
>
>
I see, but the big public figures on c++ such as H. Sutter tend to give
advice in the direction of deprecating elements of the language which
can be completely substituted by a safer alternative, even if the 'unsafe'
elements can be used fine on a more limited context. I guess that if
anything,
it helps reduce the perceived complexity by the newcomers, and it results
in less
stuff to learn / remember.
So I can see a future advice being something like 'never use ints!'
>
> Don't worry! Just remember that any proposal takes persistence.
>
>
Sure :)
>
> Actually, I do have them. But they are functions, not operators.
>
> The numerics study group wanted me to separate out the overflow and
> rounding primitives. It was a good request, because it has forced
> me to generalize the facility. It's in testing now.
>
>
Yeah I see, but it would work better with my idea if these classes also had
a template
parameter to select rounding, and if it was enabled, then it would work on
the operators.
Maybe a case could be made that it would be a cool feature in general to
have.
--
---
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_878_26979101.1394841240174
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, March 14, 2014 6:25:36 PM UTC-3, Lawrence Crowl=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>As a matter of pres=
entation, the committee prefers examples from real
<br>code. It is unlikely that the above code will occur in production=
..
<br>I know it seems like a burden, but it helps the committee understand
<br>your problem, rather than just your solution.
<br>
<br></blockquote><div><br>I see, thanks for the advice. I have a real world=
example of this, but the code is<br>a lot more complicated and I hoped wit=
h that example I could show the problem in<br>general. In case this needs t=
o go forward with the committee, then I can provide<br>a more real-world-li=
ke example.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>Ah, I see what you are doing here. Basically you are manually mov=
ing
<br>a common sub expression on the exponent out of the loop. You need=
to
<br>do it manually here because the hardware does not separate out the
<br>exponent computation from the fraction computation.
<br>
<br></blockquote><div><br>By hardware I think you mean the compiler, and ye=
ah, that would be a pretty<br>difficult optimization even for clang. <br><b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>It's not just your proposal. Nearly every proposal, including all=
of
<br>mine, go through a process of objections to issues unknown or forgotten
<br>to the author. In short, there are no simple proposals.
<br>
<br></blockquote><div><br>I see, well but even then I think limiting the sc=
ope helps :) <br><br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>I don't think the work will go that far, because things like index
<br>variables still work fine with the fundamental types.
<br>
<br></blockquote><div><br>I see, but the big public figures on c++ such as =
H. Sutter tend to give<br>advice in the direction of deprecating elements o=
f the language which<br>can be completely substituted by a safer alternativ=
e, even if the 'unsafe'<br>elements can be used fine on a more limited cont=
ext. I guess that if anything,<br>it helps reduce the perceived complexity =
by the newcomers, and it results in less<br>stuff to learn / remember.<br><=
br>So I can see a future advice being something like 'never use ints!'<br>&=
nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>Don't worry! &n=
bsp;Just remember that any proposal takes persistence.
<br>
<br></blockquote><div><br>Sure :)<br> </div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><br>Actually, I do have them. But they are functio=
ns, not operators.
<br>
<br>The numerics study group wanted me to separate out the overflow and
<br>rounding primitives. It was a good request, because it has forced
<br>me to generalize the facility. It's in testing now.
<br>
<br></blockquote><div><br>Yeah I see, but it would work better with my idea=
if these classes also had a template<br>parameter to select rounding, and =
if it was enabled, then it would work on the operators.<br>Maybe a case cou=
ld be made that it would be a cool feature in general to have.</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 <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_878_26979101.1394841240174--
.
Author: Matheus Izvekov <mizvekov@gmail.com>
Date: Fri, 14 Mar 2014 22:01:48 -0300
Raw View
--047d7b6d7fb458f69304f49abce6
Content-Type: text/plain; charset=UTF-8
So I just pushed a big update on the github repo.
So, basically I removed the implicit conversions on the advice of Vicente
J. Botet Escriba and
David Krauss, on the arguments that the previous implementation would
result in ambiguity.
These can be added back later if needed, I don't think they are that
important right now.
I also reworked the fp class implementation so it can now accept user types
as the base type, rather
than just built-in arithmetic types.
Just to demonstrate how composition with other types can work, I
implemented a 'ranged' class.
This class basically has the form ranged<T, LOW, MAX> where LOW and MAX are
template parameter values
which define the closed range of values that are admissible. When operators
are applied to objects of this type,
it will perform interval arithmetic and propagate the range into the
resulting type.
The idea here is to trigger compilation error if any range violations occur.
These violations can be constructing a ranged type where LOW or MAX are
outside the ranges of the underlying type, or
assigning a ranged variable to another one where the range of the first
does not completely contain the range of the second.
It will also short circuit the relational operations to always return true
/ false if you try to make a comparison that would
never succeed if the program is consistent.
Examples are if two variables have ranges completely disjoint, then
equality could never
succeed and then it always returns false. Another is that if one variable
has a range completely below the range of another, then 'less'
comparison will always succeed, and it will always return true.
This ranged class is not fully fleshed and is intended only as a
demonstration. It relies on the underlying type having undefined overflow
so that the compiler will error out during template instantiation. Also,
since it needs LOW and MAX as value parameters, then only the builtin
integers can be used as the underlying type.
Here are examples of it in action:
auto test1 = ranged<int32_t, -20, 50>{ 10 };
auto test2 = ranged<int32_t, 1000, 10000>{ 2000 };
auto test3 = ranged<int32_t, -3000, 8000>{ 100 };
// will trip a compile error because the result can be as big as
4'000'000'000, which is above MAX_INT
auto test4 = test1 * test2 * test3;
auto test1 = ranged<int, -20, 50>{ 10 };
// will trip a compile error because test1 could have a value up to 50, but
test2 only accepts values up to 49
ranged<int, -20, 49> test2 = test1;
This class can be composed with 'fp' like this:
auto test1 = fp<ranged<int, -20, 50>,1>{8};
auto test2 = -test1;
static_assert(test2.lowest() == fp<ranged<int>>(-25), "");
static_assert(test2.max() == fp<ranged<int>>(10), "");
static_assert(int(test2) == -8, "");
Since 'fp' is composed on top of 'ranged' instead of below it, then the
range values are referenced with respect
to the 'int' values, instead of the 'fp' values, so it is a bit awkward
that 'fp<ranged<int,-20,50>,1>().lowest() == -25'
instead of 50.
This would be straightforward to fix if literal types were accepted as
template value parameters, since
then you could do ranged<fp<int,1>, -10, 25> instead.
A crazy useless thing that can be done now, which I tried because it stress
tests the implementation and demonstrates that it is sound,
is that you can also compose an fp type on top of another fp type and so on.
Example of valid (but pointless) code right now:
static constexpr auto test1 = fp<fp<fp<int,1>,2>,3>{ 7.640625 };
static constexpr auto test2 = fp<fp<fp<int,3>,2>,1>{ 3.203125 };
static constexpr auto test3 = test1 * test2;
// now test3 has type 'fp<fp<fp<int,4>,4,4>'
// and in general it will behave the same as fp<int,12>
static_assert(double(test3) == 24.473876953125, "");
There are more examples / tests being included of all this new
functionality as well.
Oh, and I am also including specializations of numeric_limits for all these
classes as well.
--
---
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/.
--047d7b6d7fb458f69304f49abce6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">So I just pushed a big update on the github repo.<br><br>S=
o, basically I removed the implicit conversions on the advice of Vicente J.=
Botet Escriba and<br>David Krauss<span class=3D""><span style=3D"color:rgb=
(34,34,34)" class=3D""></span></span>, on the arguments that the previous i=
mplementation would result in ambiguity.<br>
These can be added back later if needed, I don't think they are that im=
portant right now.<br><br>I also reworked the fp class implementation so it=
can now accept user types as the base type, rather<br>than just built-in a=
rithmetic types.<br>
<br>Just to demonstrate how composition with other types can work, I implem=
ented a 'ranged' class.<br><br>This class basically has the form ra=
nged<T, LOW, MAX> where LOW and MAX are template parameter values<br>
which define the closed range of values that are admissible. When operators=
are applied to objects of this type,<br>it will perform interval arithmeti=
c and propagate the range into the resulting type.<br><br>The idea here is =
to trigger compilation error if any range violations occur.<br>
These violations can be constructing a ranged type where LOW or MAX are out=
side the ranges of the underlying type, or<br>assigning a ranged variable t=
o another one where the range of the first does not completely contain the =
range of the second.<br>
<br>It will also short circuit the relational operations to always return t=
rue / false if you try to make a comparison that would<br>never succeed if =
the program is consistent.<br>Examples are if two variables have ranges com=
pletely disjoint, then equality could never<br>
succeed
and then it always returns false. Another is that if one variable has a
range completely below the range of another, then 'less'<br>compar=
ison will always succeed, and it will always return true.<br><br>This
ranged class is not fully fleshed and is intended only as a=20
demonstration. It relies on the underlying type having undefined=20
overflow<br>so that the compiler will error out during template=20
instantiation. Also, since it needs LOW and MAX as value parameters,=20
then only the builtin<br>integers can be used as the underlying type.<br><b=
r>Here are examples of it in action:<br><br><div class=3D"" style=3D"backgr=
ound-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:soli=
d;border-width:1px;word-wrap:break-word">
<code class=3D""><div class=3D""><span style=3D"color:rgb(0,0,136)" class=
=3D"">auto</span><span style=3D"color:rgb(0,0,0)" class=3D""> test1 </span>=
<span style=3D"color:rgb(102,102,0)" class=3D"">=3D</span><span style=3D"co=
lor:rgb(0,0,0)" class=3D""> ranged</span><span style=3D"color:rgb(102,102,0=
)" class=3D""><</span><span style=3D"color:rgb(0,0,0)" class=3D"">int32_=
t</span><span style=3D"color:rgb(102,102,0)" class=3D"">,</span><span style=
=3D"color:rgb(0,0,0)" class=3D""> </span><span style=3D"color:rgb(102,102,0=
)" class=3D"">-</span><span style=3D"color:rgb(0,102,102)" class=3D"">20</s=
pan><span style=3D"color:rgb(102,102,0)" class=3D"">,</span><span style=3D"=
color:rgb(0,0,0)" class=3D""> </span><span style=3D"color:rgb(0,102,102)" c=
lass=3D"">50</span><span style=3D"color:rgb(102,102,0)" class=3D"">>{</s=
pan><span style=3D"color:rgb(0,0,0)" class=3D""> </span><span style=3D"colo=
r:rgb(0,102,102)" class=3D"">10</span><span style=3D"color:rgb(0,0,0)" clas=
s=3D""> </span><span style=3D"color:rgb(102,102,0)" class=3D"">};</span><sp=
an style=3D"color:rgb(0,0,0)" class=3D""><br>
</span><span style=3D"color:rgb(0,0,136)" class=3D"">auto</span><span style=
=3D"color:rgb(0,0,0)" class=3D""> test2 </span><span style=3D"color:rgb(102=
,102,0)" class=3D"">=3D</span><span style=3D"color:rgb(0,0,0)" class=3D""> =
ranged</span><span style=3D"color:rgb(102,102,0)" class=3D""><</span><sp=
an style=3D"color:rgb(0,0,0)" class=3D"">int32_t</span><span style=3D"color=
:rgb(102,102,0)" class=3D"">,</span><span style=3D"color:rgb(0,0,0)" class=
=3D""> </span><span style=3D"color:rgb(0,102,102)" class=3D"">1000</span><s=
pan style=3D"color:rgb(102,102,0)" class=3D"">,</span><span style=3D"color:=
rgb(0,0,0)" class=3D""> </span><span style=3D"color:rgb(0,102,102)" class=
=3D"">10000</span><span style=3D"color:rgb(102,102,0)" class=3D"">>{</sp=
an><span style=3D"color:rgb(0,0,0)" class=3D""> </span><span style=3D"color=
:rgb(0,102,102)" class=3D"">2000</span><span style=3D"color:rgb(0,0,0)" cla=
ss=3D""> </span><span style=3D"color:rgb(102,102,0)" class=3D"">};</span><s=
pan style=3D"color:rgb(0,0,0)" class=3D""><br>
</span><span style=3D"color:rgb(0,0,136)" class=3D"">auto</span><span style=
=3D"color:rgb(0,0,0)" class=3D""> test3 </span><span style=3D"color:rgb(102=
,102,0)" class=3D"">=3D</span><span style=3D"color:rgb(0,0,0)" class=3D""> =
ranged</span><span style=3D"color:rgb(102,102,0)" class=3D""><</span><sp=
an style=3D"color:rgb(0,0,0)" class=3D"">int32_t</span><span style=3D"color=
:rgb(102,102,0)" class=3D"">,</span><span style=3D"color:rgb(0,0,0)" class=
=3D""> </span><span style=3D"color:rgb(102,102,0)" class=3D"">-</span><span=
style=3D"color:rgb(0,102,102)" class=3D"">3000</span><span style=3D"color:=
rgb(102,102,0)" class=3D"">,</span><span style=3D"color:rgb(0,0,0)" class=
=3D""> </span><span style=3D"color:rgb(0,102,102)" class=3D"">8000</span><s=
pan style=3D"color:rgb(102,102,0)" class=3D"">>{</span><span style=3D"co=
lor:rgb(0,0,0)" class=3D""> </span><span style=3D"color:rgb(0,102,102)" cla=
ss=3D"">100</span><span style=3D"color:rgb(0,0,0)" class=3D""> </span><span=
style=3D"color:rgb(102,102,0)" class=3D"">};</span><span style=3D"color:rg=
b(0,0,0)" class=3D""><br>
</span><span style=3D"color:rgb(136,0,0)" class=3D"">// will trip a compile=
error because the result can be as big as 4'000'000'000, which=
is above MAX_INT</span><span style=3D"color:rgb(0,0,0)" class=3D""><br></s=
pan><span style=3D"color:rgb(0,0,136)" class=3D"">auto</span><span style=3D=
"color:rgb(0,0,0)" class=3D""> test4 </span><span style=3D"color:rgb(102,10=
2,0)" class=3D"">=3D</span><span style=3D"color:rgb(0,0,0)" class=3D""> tes=
t1 </span><span style=3D"color:rgb(102,102,0)" class=3D"">*</span><span sty=
le=3D"color:rgb(0,0,0)" class=3D""> test2 </span><span style=3D"color:rgb(1=
02,102,0)" class=3D"">*</span><span style=3D"color:rgb(0,0,0)" class=3D""> =
test3</span><span style=3D"color:rgb(102,102,0)" class=3D"">;</span></div>
</code></div><br><br><div class=3D"" 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""><div class=3D""><span style=3D"color:rgb=
(0,0,136)" class=3D"">auto</span><span style=3D"color:rgb(0,0,0)" class=3D"=
"> test1 </span><span style=3D"color:rgb(102,102,0)" class=3D"">=3D</span><=
span style=3D"color:rgb(0,0,0)" class=3D""> ranged</span><span style=3D"col=
or:rgb(102,102,0)" class=3D""><</span><span style=3D"color:rgb(0,0,136)"=
class=3D"">int</span><span style=3D"color:rgb(102,102,0)" class=3D"">,</sp=
an><span style=3D"color:rgb(0,0,0)" class=3D""> </span><span style=3D"color=
:rgb(102,102,0)" class=3D"">-</span><span style=3D"color:rgb(0,102,102)" cl=
ass=3D"">20</span><span style=3D"color:rgb(102,102,0)" class=3D"">,</span><=
span style=3D"color:rgb(0,0,0)" class=3D""> </span><span style=3D"color:rgb=
(0,102,102)" class=3D"">50</span><span style=3D"color:rgb(102,102,0)" class=
=3D"">>{</span><span style=3D"color:rgb(0,0,0)" class=3D""> </span><span=
style=3D"color:rgb(0,102,102)" class=3D"">10</span><span style=3D"color:rg=
b(0,0,0)" class=3D""> </span><span style=3D"color:rgb(102,102,0)" class=3D"=
">};</span><span style=3D"color:rgb(0,0,0)" class=3D""><br>
</span><span style=3D"color:rgb(136,0,0)" class=3D"">// will trip a compile=
error because test1 could have a value up to 50, but test2 only accepts va=
lues up to 49</span><span style=3D"color:rgb(0,0,0)" class=3D""><br>ranged<=
/span><span style=3D"color:rgb(102,102,0)" class=3D""><</span><span styl=
e=3D"color:rgb(0,0,136)" class=3D"">int</span><span style=3D"color:rgb(102,=
102,0)" class=3D"">,</span><span style=3D"color:rgb(0,0,0)" class=3D""> </s=
pan><span style=3D"color:rgb(102,102,0)" class=3D"">-</span><span style=3D"=
color:rgb(0,102,102)" class=3D"">20</span><span style=3D"color:rgb(102,102,=
0)" class=3D"">,</span><span style=3D"color:rgb(0,0,0)" class=3D""> </span>=
<span style=3D"color:rgb(0,102,102)" class=3D"">49</span><span style=3D"col=
or:rgb(102,102,0)" class=3D"">></span><span style=3D"color:rgb(0,0,0)" c=
lass=3D""> test2 </span><span style=3D"color:rgb(102,102,0)" class=3D"">=3D=
</span><span style=3D"color:rgb(0,0,0)" class=3D""> test1</span><span style=
=3D"color:rgb(102,102,0)" class=3D"">;</span></div>
</code></div><br>This class can be composed with 'fp' like this:<br=
><br><div class=3D"" style=3D"background-color:rgb(250,250,250);border-colo=
r:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word=
">
<code class=3D""><div class=3D""><span style=3D"color:rgb(0,0,136)" class=
=3D"">auto</span><span style=3D"color:rgb(0,0,0)" class=3D""> test1 </span>=
<span style=3D"color:rgb(102,102,0)" class=3D"">=3D</span><span style=3D"co=
lor:rgb(0,0,0)" class=3D""> fp</span><span style=3D"color:rgb(102,102,0)" c=
lass=3D""><</span><span style=3D"color:rgb(0,0,0)" class=3D"">ranged</sp=
an><span style=3D"color:rgb(102,102,0)" class=3D""><</span><span style=
=3D"color:rgb(0,0,136)" class=3D"">int</span><span style=3D"color:rgb(102,1=
02,0)" class=3D"">,</span><span style=3D"color:rgb(0,0,0)" class=3D""> </sp=
an><span style=3D"color:rgb(102,102,0)" class=3D"">-</span><span style=3D"c=
olor:rgb(0,102,102)" class=3D"">20</span><span style=3D"color:rgb(102,102,0=
)" class=3D"">,</span><span style=3D"color:rgb(0,0,0)" class=3D""> </span><=
span style=3D"color:rgb(0,102,102)" class=3D"">50</span><span style=3D"colo=
r:rgb(102,102,0)" class=3D"">>,</span><span style=3D"color:rgb(0,102,102=
)" class=3D"">1</span><span style=3D"color:rgb(102,102,0)" class=3D"">>{=
</span><span style=3D"color:rgb(0,102,102)" class=3D"">8</span><span style=
=3D"color:rgb(102,102,0)" class=3D"">};</span><span style=3D"color:rgb(0,0,=
0)" class=3D""><br>
</span><span style=3D"color:rgb(0,0,136)" class=3D"">auto</span><span style=
=3D"color:rgb(0,0,0)" class=3D""> test2 </span><span style=3D"color:rgb(102=
,102,0)" class=3D"">=3D</span><span style=3D"color:rgb(0,0,0)" class=3D""> =
</span><span style=3D"color:rgb(102,102,0)" class=3D"">-</span><span style=
=3D"color:rgb(0,0,0)" class=3D"">test1</span><span style=3D"color:rgb(102,1=
02,0)" class=3D"">;</span><span style=3D"color:rgb(0,0,0)" class=3D""><br>
</span><span style=3D"color:rgb(0,0,136)" class=3D"">static_assert</span><s=
pan style=3D"color:rgb(102,102,0)" class=3D"">(</span><span style=3D"color:=
rgb(0,0,0)" class=3D"">test2</span><span style=3D"color:rgb(102,102,0)" cla=
ss=3D"">.</span><span style=3D"color:rgb(0,0,0)" class=3D"">lowest</span><s=
pan style=3D"color:rgb(102,102,0)" class=3D"">()</span><span style=3D"color=
:rgb(0,0,0)" class=3D""> </span><span style=3D"color:rgb(102,102,0)" class=
=3D"">=3D=3D</span><span style=3D"color:rgb(0,0,0)" class=3D""> fp</span><s=
pan style=3D"color:rgb(102,102,0)" class=3D""><</span><span style=3D"col=
or:rgb(0,0,0)" class=3D"">ranged</span><span style=3D"color:rgb(0,136,0)" c=
lass=3D""><int></span><span style=3D"color:rgb(102,102,0)" class=3D""=
>>(-</span><span style=3D"color:rgb(0,102,102)" class=3D"">25</span><spa=
n style=3D"color:rgb(102,102,0)" class=3D"">),</span><span style=3D"color:r=
gb(0,0,0)" class=3D""> </span><span style=3D"color:rgb(0,136,0)" class=3D""=
>""</span><span style=3D"color:rgb(102,102,0)" class=3D"">);</spa=
n><span style=3D"color:rgb(0,0,0)" class=3D""><br>
</span><span style=3D"color:rgb(0,0,136)" class=3D"">static_assert</span><s=
pan style=3D"color:rgb(102,102,0)" class=3D"">(</span><span style=3D"color:=
rgb(0,0,0)" class=3D"">test2</span><span style=3D"color:rgb(102,102,0)" cla=
ss=3D"">.</span><span style=3D"color:rgb(0,0,0)" class=3D"">max</span><span=
style=3D"color:rgb(102,102,0)" class=3D"">()</span><span style=3D"color:rg=
b(0,0,0)" class=3D""> </span><span style=3D"color:rgb(102,102,0)" class=3D"=
">=3D=3D</span><span style=3D"color:rgb(0,0,0)" class=3D""> fp</span><span =
style=3D"color:rgb(102,102,0)" class=3D""><</span><span style=3D"color:r=
gb(0,0,0)" class=3D"">ranged</span><span style=3D"color:rgb(0,136,0)" class=
=3D""><int></span><span style=3D"color:rgb(102,102,0)" class=3D"">>=
;(</span><span style=3D"color:rgb(0,102,102)" class=3D"">10</span><span sty=
le=3D"color:rgb(102,102,0)" class=3D"">),</span><span style=3D"color:rgb(0,=
0,0)" class=3D""> </span><span style=3D"color:rgb(0,136,0)" class=3D"">&quo=
t;"</span><span style=3D"color:rgb(102,102,0)" class=3D"">);</span><sp=
an style=3D"color:rgb(0,0,0)" class=3D""><br>
</span><span style=3D"color:rgb(0,0,136)" class=3D"">static_assert</span><s=
pan style=3D"color:rgb(102,102,0)" class=3D"">(</span><span style=3D"color:=
rgb(0,0,136)" class=3D"">int</span><span style=3D"color:rgb(102,102,0)" cla=
ss=3D"">(</span><span style=3D"color:rgb(0,0,0)" class=3D"">test2</span><sp=
an style=3D"color:rgb(102,102,0)" class=3D"">)</span><span style=3D"color:r=
gb(0,0,0)" class=3D""> </span><span style=3D"color:rgb(102,102,0)" class=3D=
"">=3D=3D</span><span style=3D"color:rgb(0,0,0)" class=3D""> </span><span s=
tyle=3D"color:rgb(102,102,0)" class=3D"">-</span><span style=3D"color:rgb(0=
,102,102)" class=3D"">8</span><span style=3D"color:rgb(102,102,0)" class=3D=
"">,</span><span style=3D"color:rgb(0,0,0)" class=3D""> </span><span style=
=3D"color:rgb(0,136,0)" class=3D"">""</span><span style=3D"color:=
rgb(102,102,0)" class=3D"">);</span></div>
</code></div><br><br><span style=3D"color:rgb(0,0,0)">Since 'fp' is=
composed on top of 'ranged' instead of below it, then the range va=
lues are referenced with respect<br>to the 'int' values, instead of=
the 'fp' values, so it is a bit awkward that </span>'fp<ran=
ged<int,-20,50>,1>().lowest() =3D=3D -25'<br>
instead of 50.<br><br>This would be straightforward to fix if literal types=
were accepted as template value parameters, since<br>then you could do ran=
ged<fp<int,1>, -10, 25> instead.<br><br>A crazy useless thing t=
hat can be done now, which I tried because it stress tests the implementati=
on and demonstrates that it is sound,<br>
is that you can also compose an fp type on top of another fp type and so on=
..<br><br>Example of valid (but pointless) code right now:<code class=3D""><=
span style=3D"color:rgb(102,102,0)" class=3D""><font color=3D"#000000"><br>=
<br>
<div class=3D"" style=3D"background-color:rgb(250,250,250);border-color:rgb=
(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><co=
de class=3D""><div class=3D""><span style=3D"color:rgb(0,0,136)" class=3D""=
>static</span><span style=3D"color:rgb(0,0,0)" class=3D""> </span><span sty=
le=3D"color:rgb(0,0,136)" class=3D"">constexpr</span><span style=3D"color:r=
gb(0,0,0)" class=3D""> </span><span style=3D"color:rgb(0,0,136)" class=3D""=
>auto</span><span style=3D"color:rgb(0,0,0)" class=3D""> test1 </span><span=
style=3D"color:rgb(102,102,0)" class=3D"">=3D</span><span style=3D"color:r=
gb(0,0,0)" class=3D""> fp</span><span style=3D"color:rgb(102,102,0)" class=
=3D""><</span><span style=3D"color:rgb(0,0,0)" class=3D"">fp</span><span=
style=3D"color:rgb(102,102,0)" class=3D""><</span><span style=3D"color:=
rgb(0,0,0)" class=3D"">fp</span><span style=3D"color:rgb(102,102,0)" class=
=3D""><</span><span style=3D"color:rgb(0,0,136)" class=3D"">int</span><s=
pan style=3D"color:rgb(102,102,0)" class=3D"">,</span><span style=3D"color:=
rgb(0,102,102)" class=3D"">1</span><span style=3D"color:rgb(102,102,0)" cla=
ss=3D"">>,</span><span style=3D"color:rgb(0,102,102)" class=3D"">2</span=
><span style=3D"color:rgb(102,102,0)" class=3D"">>,</span><span style=3D=
"color:rgb(0,102,102)" class=3D"">3</span><span style=3D"color:rgb(102,102,=
0)" class=3D"">>{</span><span style=3D"color:rgb(0,0,0)" class=3D""> </s=
pan><span style=3D"color:rgb(0,102,102)" class=3D"">7.640625</span><span st=
yle=3D"color:rgb(0,0,0)" class=3D""> </span><span style=3D"color:rgb(102,10=
2,0)" class=3D"">};</span><span style=3D"color:rgb(0,0,0)" class=3D""><br>
</span><span style=3D"color:rgb(0,0,136)" class=3D""><code class=3D""><span=
style=3D"color:rgb(102,102,0)" class=3D""><font color=3D"#000000"><code cl=
ass=3D""><span style=3D"color:rgb(0,0,136)" class=3D"">static</span><span s=
tyle=3D"color:rgb(0,0,0)" class=3D""> </span><span style=3D"color:rgb(0,0,1=
36)" class=3D"">constexpr</span><span style=3D"color:rgb(0,0,0)" class=3D""=
> </span><span style=3D"color:rgb(0,0,136)" class=3D""></span></code></font=
></span></code>auto</span><span style=3D"color:rgb(0,0,0)" class=3D""> test=
2 </span><span style=3D"color:rgb(102,102,0)" class=3D"">=3D</span><span st=
yle=3D"color:rgb(0,0,0)" class=3D""> fp</span><span style=3D"color:rgb(102,=
102,0)" class=3D""><</span><span style=3D"color:rgb(0,0,0)" class=3D"">f=
p</span><span style=3D"color:rgb(102,102,0)" class=3D""><</span><span st=
yle=3D"color:rgb(0,0,0)" class=3D"">fp</span><span style=3D"color:rgb(102,1=
02,0)" class=3D""><</span><span style=3D"color:rgb(0,0,136)" class=3D"">=
int</span><span style=3D"color:rgb(102,102,0)" class=3D"">,</span><span sty=
le=3D"color:rgb(0,102,102)" class=3D"">3</span><span style=3D"color:rgb(102=
,102,0)" class=3D"">>,</span><span style=3D"color:rgb(0,102,102)" class=
=3D"">2</span><span style=3D"color:rgb(102,102,0)" class=3D"">>,</span><=
span style=3D"color:rgb(0,102,102)" class=3D"">1</span><span style=3D"color=
:rgb(102,102,0)" class=3D"">>{</span><span style=3D"color:rgb(0,0,0)" cl=
ass=3D""> </span><span style=3D"color:rgb(0,102,102)" class=3D"">3.203125</=
span><span style=3D"color:rgb(0,0,0)" class=3D""> </span><span style=3D"col=
or:rgb(102,102,0)" class=3D"">};</span><span style=3D"color:rgb(0,0,0)" cla=
ss=3D""><br>
</span><span style=3D"color:rgb(0,0,136)" class=3D""><code class=3D""><span=
style=3D"color:rgb(102,102,0)" class=3D""><font color=3D"#000000"><code cl=
ass=3D""><span style=3D"color:rgb(0,0,136)" class=3D"">static</span><span s=
tyle=3D"color:rgb(0,0,0)" class=3D""> </span><span style=3D"color:rgb(0,0,1=
36)" class=3D"">constexpr</span><span style=3D"color:rgb(0,0,0)" class=3D""=
> </span><span style=3D"color:rgb(0,0,136)" class=3D""></span></code></font=
></span></code>auto</span><span style=3D"color:rgb(0,0,0)" class=3D""> test=
3 </span><span style=3D"color:rgb(102,102,0)" class=3D"">=3D</span><span st=
yle=3D"color:rgb(0,0,0)" class=3D""> test1 </span><span style=3D"color:rgb(=
102,102,0)" class=3D"">*</span><span style=3D"color:rgb(0,0,0)" class=3D"">=
test2</span><span style=3D"color:rgb(102,102,0)" class=3D"">;</span><span =
style=3D"color:rgb(0,0,0)" class=3D""><br>
</span><span style=3D"color:rgb(136,0,0)" class=3D"">// now test</span><fon=
t color=3D"#000000"><span style=3D"color:rgb(136,0,0)" class=3D"">3 has typ=
e 'fp<fp<fp<int,4>,4,4>'</span><span style=3D"color:=
rgb(0,0,0)" class=3D""><br>
</span><span style=3D"color:rgb(136,0,0)" class=3D"">// and in general it w=
ill behave the same as fp<int,12></span><span style=3D"color:rgb(0,0,=
0)" class=3D""><br></span><span style=3D"color:rgb(0,0,136)" class=3D"">sta=
tic_assert</span><span style=3D"color:rgb(102,102,0)" class=3D"">(</span><s=
pan style=3D"color:rgb(0,0,136)" class=3D"">double</span><span style=3D"col=
or:rgb(102,102,0)" class=3D"">(</span><span style=3D"color:rgb(0,0,0)" clas=
s=3D"">test3</span><span style=3D"color:rgb(102,102,0)" class=3D"">)</span>=
<span style=3D"color:rgb(0,0,0)" class=3D""> </span><span style=3D"color:rg=
b(102,102,0)" class=3D"">=3D=3D</span><span style=3D"color:rgb(0,0,0)" clas=
s=3D""> </span><span style=3D"color:rgb(0,102,102)" class=3D"">24.473876953=
125</span><span style=3D"color:rgb(102,102,0)" class=3D"">,</span><span sty=
le=3D"color:rgb(0,0,0)" class=3D""> </span><span style=3D"color:rgb(0,136,0=
)" class=3D"">""</span><span style=3D"color:rgb(102,102,0)" class=
=3D"">);</span><span style=3D"color:rgb(0,0,0)" class=3D""></span></font><s=
pan style=3D"color:rgb(0,0,0)" class=3D""><br>
</span></div></code></div><br>There are more examples / tests being include=
d of all this new functionality as well.<br><br>Oh, and I am also including=
specializations of numeric_limits for all these classes as well.</font><br=
>
</span><span style=3D"color:rgb(102,102,0)" class=3D""></span></code></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 <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 />
--047d7b6d7fb458f69304f49abce6--
.
Author: Lawrence Crowl <Lawrence@Crowl.org>
Date: Sun, 16 Mar 2014 16:47:32 -0700
Raw View
On 3/14/14, Marc <marc.glisse@gmail.com> wrote:
> Le vendredi 14 mars 2014 03:31:40 UTC+1, Lawrence Crowl a =E9crit :
>> On 3/13/14, Matheus Izvekov <mizv...@gmail.com <javascript:>> wrote:
>> > But what would happen to division? Theoretically, a single divisi=
on
>> > could consume all of memory. There is a significant difference
>> > between fixed and unbounded representations. Given an unbounded
>> > representation, rational numbers probably make more sense than
>> > fixed-point numbers. The numerics study group had a discussion
>> > about a template for rational numbers. We ended up concluding tha=
t
>> > rational numbers based on fixed representations necessarily had
>> > different semantics from those with unbounded representations, and
>> > so necessarily had to be different types.
>> >
>> > Yeah, I was having a different semantics for division in mind.
>> > It would behave like an integer division if you did:
>> >
>> > auto z =3D x / y;
>> >
>> > But would be able to produce bits below the radix if you assigned it t=
o
>> > a fp class with radix point above the result.
>> > This could be implemented with a proxy object and with overloading
>> > operator auto.
>>
>> I'd need to be convinced that you could do it in general. The C++ type
>> system generally bubbles up, not down.
>
> With expression templates, it seems that similar things are done regularl=
y.
>
> In GMP, with mpf_class, when computing a=3Db+c+d, I think b+c is computed
> with the precision of a, and similarly for the second addition. Some
> wrappers of MPFR do more fancy things trying to estimate the required
> precision on the intermediate results. And you can do the virtual / dynam=
ic
> equivalent.
While that is true, expression templates are generally only cost-effective
when the amount of computation embodied in an operator is significant.
Fixed-point operations do not seem to be in that class.
--=20
Lawrence Crowl
--=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/.
.
Author: Lawrence Crowl <Lawrence@Crowl.org>
Date: Sun, 16 Mar 2014 16:53:46 -0700
Raw View
On 3/14/14, Matheus Izvekov <mizvekov@gmail.com> wrote:
> On Friday, March 14, 2014 6:25:36 PM UTC-3, Lawrence Crowl wrote:
>> I don't think the work will go that far, because things like index
>> variables still work fine with the fundamental types.
>
> I see, but the big public figures on c++ such as H. Sutter tend to give
> advice in the direction of deprecating elements of the language which
> can be completely substituted by a safer alternative, even if the
> 'unsafe' elements can be used fine on a more limited context. I guess
> that if anything, it helps reduce the perceived complexity by the
> newcomers, and it results in less stuff to learn / remember.
That is true so long as the substitution is complete. The advantage
to int (at least as originally incarnated in C) was that they
represented what the machine could handle. Today we call the type
size_t or ssize_t. In some sense, we can call these control types.
In contrast, the types we've been discussing are good for representing
the data.
> So I can see a future advice being something like 'never use ints!'
I see a useful distinction between the two categories of types, but
you may be right.
--
Lawrence Crowl
--
---
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, 17 Mar 2014 09:12:26 +0800
Raw View
--Apple-Mail=_6D1201BF-BBC4-4321-B678-DBFF43AD1A43
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-03-17, at 7:47 AM, Lawrence Crowl <Lawrence@Crowl.org> wrote:
> On 3/14/14, Marc <marc.glisse@gmail.com> wrote:
>> With expression templates, it seems that similar things are done regular=
ly.
>>=20
>> In GMP, with mpf_class, when computing a=3Db+c+d, I think b+c is compute=
d
>> with the precision of a, and similarly for the second addition. Some
>> wrappers of MPFR do more fancy things trying to estimate the required
>> precision on the intermediate results. And you can do the virtual / dyna=
mic
>> equivalent.
>=20
> While that is true, expression templates are generally only cost-effectiv=
e
> when the amount of computation embodied in an operator is significant.
> Fixed-point operations do not seem to be in that class.
ETs are also only applicable when splitting or splicing lines is allowed to=
change behavior, i.e. the programmer expects a certain degree of nondeterm=
inism or at least pseudo-randomness of interpretation. I think fixed-point =
programmers mainly want to deal in exact values with no wiggle room.
A fixed-point library could be more deterministic by using something like a=
user-visible intermediate result class which can instantiate a persistent =
local variable. But that's not exactly the same thing as ETs.
GMP says:
> All calculations are performed to the precision of the destination variab=
le. Each function is defined to calculate with "infinite precision" followe=
d by a truncation to the destination precision, but of course the work done=
is only what's needed to determine a result under that definition.
>=20
Without delving into the C++ wrapper implementation, it sounds like they us=
e ETs and back-propagate the intermediate result precisions from the final =
result precision. You can use auto because precision is a runtime variable,=
but yet you can expect different results when splitting an expression acro=
ss lines, unless the intermediate destination is pre-initialized with corre=
ct precision.
Maybe I'm wrong about what fixed-point programmers want. Just want to point=
out the issue.
--=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/.
--Apple-Mail=_6D1201BF-BBC4-4321-B678-DBFF43AD1A43
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;03–17, at 7:47 AM, Lawrence Crowl <<a href=3D"mailto:Lawrenc=
e@Crowl.org">Lawrence@Crowl.org</a>> wrote:</div><br class=3D"Apple-inte=
rchange-newline"><blockquote type=3D"cite"><div style=3D"font-size: 12px; f=
ont-style: normal; font-variant: normal; font-weight: normal; letter-spacin=
g: normal; line-height: normal; orphans: auto; text-align: start; text-inde=
nt: 0px; text-transform: none; white-space: normal; widows: auto; word-spac=
ing: 0px; -webkit-text-stroke-width: 0px;">On 3/14/14, Marc <<a href=3D"=
mailto:marc.glisse@gmail.com">marc.glisse@gmail.com</a>> wrote:<br><bloc=
kquote type=3D"cite">With expression templates, it seems that similar thing=
s are done regularly.<br><br>In GMP, with mpf_class, when computing a=3Db+c=
+d, I think b+c is computed<br>with the precision of a, and similarly for t=
he second addition. Some<br>wrappers of MPFR do more fancy things trying to=
estimate the required<br>precision on the intermediate results. And you ca=
n do the virtual / dynamic<br>equivalent.<br></blockquote><br>While that is=
true, expression templates are generally only cost-effective<br>when the a=
mount of computation embodied in an operator is significant.<br>Fixed-point=
operations do not seem to be in that class.<br></div></blockquote><div><br=
></div>ETs are also only applicable when splitting or splicing lines is all=
owed to change behavior, i.e. the programmer expects a certain degree of no=
ndeterminism or at least pseudo-randomness of interpretation. I think fixed=
-point programmers mainly want to deal in exact values with no wiggle room.=
</div><div><br></div><div>A fixed-point library could be more deterministic=
by using something like a user-visible intermediate result class which can=
instantiate a persistent local variable. But that’s not exactly the =
same thing as ETs.</div><div><br></div><div>GMP says:</div><div><p></p><blo=
ckquote type=3D"cite"><p>All calculations are performed to the precision of=
the destination variable.=20
Each function is defined to calculate with “infinite precision”=
followed by
a truncation to the destination precision, but of course the work done is o=
nly
what's needed to determine a result under that definition.</p></blockquote>=
<div>Without delving into the C++ wrapper implementation, it sounds like th=
ey use ETs and back-propagate the intermediate result precisions from the f=
inal result precision. You can use auto because precision is a runtime vari=
able, but yet you can expect different results when splitting an expression=
across lines, unless the intermediate destination is pre-initialized with =
correct precision.</div><div><br></div><div>Maybe I’m wrong about wha=
t fixed-point programmers want. Just want to point out the issue.</div><div=
><br></div></div></body></html>
<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 <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 />
--Apple-Mail=_6D1201BF-BBC4-4321-B678-DBFF43AD1A43--
.
Author: Matheus Izvekov <mizvekov@gmail.com>
Date: Sun, 16 Mar 2014 20:40:59 -0700 (PDT)
Raw View
------=_Part_2372_11042671.1395027659206
Content-Type: text/plain; charset=UTF-8
On Sunday, March 16, 2014 8:47:32 PM UTC-3, Lawrence Crowl wrote:
>
>
> While that is true, expression templates are generally only cost-effective
> when the amount of computation embodied in an operator is significant.
> Fixed-point operations do not seem to be in that class.
>
> --
> Lawrence Crowl
>
I only realize now that there is another issue that makes the solution with
ET not as simple as I had hoped.
With the simple syntax I was considering earlier, which would look
something like this:
fp<int, 8> a = fp<int, 0>(1) / fp<int, 0>(3);
That would produce 8 bits below the radix point, but at the same time, we
are forced to specify
the base type of the result, and that only works okay in the simple cases.
If we were using more complex types like the 'ranged' wrapper, then we most
likely would want to
automatically deduce the base type while still specifying the radix point.
If some syntax in C++ like this were valid:
fp<auto, 8> a = fp<ranged<int, -10, 10>, 0>(1) / fp<ranged<int, 1, 100>, 0>(
3);
And if doing this would make it deduce the base type from the construction
of the base member, then it would be alright,
although I am afraid some feature like this would never get approved.
With the fractional types in N3352 there is the same kind of issue, at the
same time
you specify the radix point parameter, you would be forced to also specify
the range parameter,
while the most useful would be to have range automatically deduced in any
case.
ET could still be a solution, but there would need to be another syntactic
element.
One possibility is something like this:
auto a = (fp<ranged<int, -10, 10>, 0>(1) / fp<ranged<int, 1, 100>, 0>(3
)).shift<8>();
Or something else similar.
Suggestions are welcome.
--
---
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_2372_11042671.1395027659206
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, March 16, 2014 8:47:32 PM UTC-3, Lawrence Crowl=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>While that is true,=
expression templates are generally only cost-effective
<br>when the amount of computation embodied in an operator is significant.
<br>Fixed-point operations do not seem to be in that class.
<br>
<br>--=20
<br>Lawrence Crowl
<br></blockquote><div><br>I only realize now that there is another issue th=
at makes the solution with ET not as simple as I had hoped.<br><br>With the=
simple syntax I was considering earlier, which would look something like t=
his:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, =
250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wi=
dth: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D=
"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">=
fp</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">8</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> a </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> fp</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y"><</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">>(</span><span style=3D"color: #06=
6;" class=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">/</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> fp=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
66;" class=3D"styled-by-prettify">0</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">>(</span><span style=3D"color: #066;" class=3D"=
styled-by-prettify">3</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">);</span></div></code></div><br>That would produce 8 bits below =
the radix point, but at the same time, we are forced to specify<br>the base=
type of the result, and that only works okay in the simple cases.<br>If we=
were using more complex types like the 'ranged' wrapper, then we most like=
ly would want to<br>automatically deduce the base type while still specifyi=
ng the radix point.<br><br>If some syntax in C++ like this were valid:<br><=
br><div class=3D"prettyprint" 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"subprett=
yprint"><div class=3D"prettyprint" 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"sub=
prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">fp</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #06=
6;" class=3D"styled-by-prettify">8</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> a </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> fp</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><=
;ranged<int, -10, 10></span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify"></span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">>(</span><span st=
yle=3D"color: #066;" class=3D"styled-by-prettify">1</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">)</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"style=
d-by-prettify"> fp</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify"><</span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">ranged<int, 1, 100></span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">0=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">>(</spa=
n><span style=3D"color: #066;" class=3D"styled-by-prettify">3</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">);</span></div></code></=
div><span style=3D"color: #660;" class=3D"styled-by-prettify"></span></div>=
</code></div><br>And if doing this would make it deduce the base type from =
the construction of the base member, then it would be alright,<br>although =
I am afraid some feature like this would never get approved.<br><br>With th=
e fractional types in N3352 there is the same kind of issue, at the same ti=
me<br>you specify the radix point parameter, you would be forced to also sp=
ecify the range parameter,<br>while the most useful would be to have range =
automatically deduced in any case.<br><br>ET could still be a solution, but=
there would need to be another syntactic element.<br>One possibility is so=
mething like this:<br><br><div class=3D"prettyprint" style=3D"background-co=
lor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: so=
lid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"=
><div class=3D"subprettyprint"><span style=3D"color: #606;" class=3D"styled=
-by-prettify">auto a =3D (fp<</span><code class=3D"prettyprint"><code cl=
ass=3D"prettyprint"><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">ranged<int, -10, 10></span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify"></span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">>(</span><span =
style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">/</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> fp</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify"><</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">ranged<int, 1, 100></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">=
0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">>(</sp=
an><span style=3D"color: #066;" class=3D"styled-by-prettify">3</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">)).shift<8>();</s=
pan></code></code><span style=3D"color: #660;" class=3D"styled-by-prettify"=
></span></div></code></div><br>Or something else similar.<br><br>Suggestion=
s are welcome.<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 <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_2372_11042671.1395027659206--
.
Author: Lawrence Crowl <Lawrence@Crowl.org>
Date: Sun, 16 Mar 2014 23:54:10 -0700
Raw View
On 3/16/14, Matheus Izvekov <mizvekov@gmail.com> wrote:
> If some syntax in C++ like this were valid:
>
> fp<auto, 8> a = fp<ranged<int, -10, 10>, 0>(1)
> / fp<ranged<int, 1, 100>, 0>( 3);
>
> And if doing this would make it deduce the base type from the construction
> of the base member, then it would be alright, although I am afraid some
> feature like this would never get approved.
There has been similar work in polymorphic lambdas,
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3559.pdf,
so it is not beyond the realm of possibility. However, it might be
prudent to not rely on the feature in the short term. :-)
> With the fractional types in N3352 there is the same kind of issue, at the
> same time you specify the radix point parameter, you would be forced to
> also specify the range parameter, while the most useful would be to have
> range automatically deduced in any case.
Specifying the range is actually useful, because it gives more room to
compute without overflowing a word. Consider the case of a 12-bit A/D
converter. On most machines, the densest reasonable storage is 16 bits.
You can do 4 additions on the converted values while still remaining
within a 16-bit word. That matters to embedded processors doing signal
processing.
> ET could still be a solution, but there would need to be another syntactic
> element. One possibility is something like this:
>
> auto a = (fp<ranged<int, -10, 10>, 0>(1)
> / fp<ranged<int, 1, 100>, 0>(3)).shift<8>();
>
> Or something else similar.
N3352 relies on a model in which programmers precisely characterize their
input data, both range and resolution. They can then use expressions and
auto declarations in straight-line code, knowing their intermediate results
will be accurate. Output and loops will require converting the
intermediate results to variables with defined range and resolution.
Performance optimization may also require that conversion. The intent is
that programmers only need to be specific when it really matters, and
when it really matters, they need to be specific.
--
Lawrence Crowl
--
---
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: Matheus Izvekov <mizvekov@gmail.com>
Date: Mon, 17 Mar 2014 00:37:24 -0700 (PDT)
Raw View
------=_Part_5223_5747939.1395041844298
Content-Type: text/plain; charset=UTF-8
On Monday, March 17, 2014 3:54:10 AM UTC-3, Lawrence Crowl wrote:
>
>
> There has been similar work in polymorphic lambdas,
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3559.pdf,
> so it is not beyond the realm of possibility. However, it might be
> prudent to not rely on the feature in the short term. :-)
>
Yeah, I was also thinking of a series of proposals that planned to add
'auto' non-static member variables, but then it seems the idea was discussed
a lot and shot down. There was even a more recent paper that documented
all the issues with supporting this feature, for future reference.
Unfortunately I can't find it thru an internet search.
I don't know an easy way to search the proposals database.
But yeah, not going to wait for this feature :)
>
> Specifying the range is actually useful, because it gives more room to
> compute without overflowing a word. Consider the case of a 12-bit A/D
> converter. On most machines, the densest reasonable storage is 16 bits.
> You can do 4 additions on the converted values while still remaining
> within a 16-bit word. That matters to embedded processors doing signal
> processing.
>
>
Yes but what I mean is, it would be beneficial to be able to specify either
range
or radix position, and have the other deduced, but currently you can only
have either both deduced or both specified.
What are your thoughts on this? Do you plan to support it, don't want to,
or want to, but think it's too complex to do it with current language rules?
>
> N3352 relies on a model in which programmers precisely characterize their
> input data, both range and resolution. They can then use expressions and
> auto declarations in straight-line code, knowing their intermediate
> results
> will be accurate. Output and loops will require converting the
> intermediate results to variables with defined range and resolution.
> Performance optimization may also require that conversion. The intent is
> that programmers only need to be specific when it really matters, and
> when it really matters, they need to be specific.
>
>
Yes I see, I agree with all that, although for the specific issue of
division, I am still leaning on the side of doing 'integer'
division unless the user specifies otherwise.
> --
> Lawrence Crowl
>
--
---
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_5223_5747939.1395041844298
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, March 17, 2014 3:54:10 AM UTC-3, Lawrence Crowl=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>There has been similar work in polymorphic lambdas,
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n355=
9.pdf" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/=
url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%=
2F2013%2Fn3559.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNERI2Ob-mhqWWHQPfjUn0B=
9sR0mbQ';return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\=
75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013=
%2Fn3559.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNERI2Ob-mhqWWHQPfjUn0B9sR0mb=
Q';return true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/20=
13/<wbr>n3559.pdf</a>,
<br>so it is not beyond the realm of possibility. However, it might b=
e
<br>prudent to not rely on the feature in the short term. :-)
<br></blockquote><div><br>Yeah, I was also thinking of a series of proposal=
s that planned to add<br>'auto' non-static member variables, but then it se=
ems the idea was discussed<br>a lot and shot down. There was even a more re=
cent paper that documented<br>all the issues with supporting this feature, =
for future reference.<br>Unfortunately I can't find it thru an internet sea=
rch.<br>I don't know an easy way to search the proposals database.<br><br>B=
ut yeah, not going to wait for this feature :)<br> </div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
#ccc solid;padding-left: 1ex;">
<br>Specifying the range is actually useful, because it gives more room to
<br>compute without overflowing a word. Consider the case of a 12-bit=
A/D
<br>converter. On most machines, the densest reasonable storage is 16=
bits.
<br>You can do 4 additions on the converted values while still remaining
<br>within a 16-bit word. That matters to embedded processors doing s=
ignal
<br>processing.
<br>
<br></blockquote><div><br>Yes but what I mean is, it would be beneficial to=
be able to specify either range<br>or radix position, and have the other d=
educed, but currently you can only<br>have either both deduced or both spec=
ified.<br><br>What are your thoughts on this? Do you plan to support it, do=
n't want to,<br>or want to, but think it's too complex to do it with curren=
t language rules?<br> </div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><br>N3352 relies on a model in which programmers precisely characterize =
their
<br>input data, both range and resolution. They can then use expressi=
ons and
<br>auto declarations in straight-line code, knowing their intermediate res=
ults
<br>will be accurate. Output and loops will require converting the
<br>intermediate results to variables with defined range and resolution.
<br>Performance optimization may also require that conversion. The in=
tent is
<br>that programmers only need to be specific when it really matters, and
<br>when it really matters, they need to be specific.
<br>
<br></blockquote><div><br>Yes I see, I agree with all that, although for th=
e specific issue of division, I am still leaning on the side of doing 'inte=
ger'<br>division unless the user specifies otherwise.<br> </div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">--=20
<br>Lawrence Crowl
<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 <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_5223_5747939.1395041844298--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 17 Mar 2014 09:57:34 +0200
Raw View
On 17 March 2014 09:37, Matheus Izvekov <mizvekov@gmail.com> wrote:
> Yeah, I was also thinking of a series of proposals that planned to add
> 'auto' non-static member variables, but then it seems the idea was discussed
> a lot and shot down. There was even a more recent paper that documented
> all the issues with supporting this feature, for future reference.
> Unfortunately I can't find it thru an internet search.
> I don't know an easy way to search the proposals database.
That would be http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3897.html
--
---
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: Matheus Izvekov <mizvekov@gmail.com>
Date: Mon, 17 Mar 2014 13:19:43 -0700 (PDT)
Raw View
------=_Part_458_8584938.1395087583543
Content-Type: text/plain; charset=UTF-8
On Monday, March 17, 2014 4:57:34 AM UTC-3, Ville Voutilainen wrote:
>
>
> That would be
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3897.html
>
Yes, straight from the horse's mouth, thank you :-)
--
---
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_458_8584938.1395087583543
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, March 17, 2014 4:57:34 AM UTC-3, Ville Voutilai=
nen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>That would be <a=
href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3897.html" ta=
rget=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75h=
ttp%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2014%2Fn389=
7.html\46sa\75D\46sntz\0751\46usg\75AFQjCNE93tuQmcRVqAup74EnVuW7ajKEZg';ret=
urn true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F=
%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2014%2Fn3897.html\46=
sa\75D\46sntz\0751\46usg\75AFQjCNE93tuQmcRVqAup74EnVuW7ajKEZg';return true;=
">http://open-std.org/JTC1/SC22/<wbr>WG21/docs/papers/2014/n3897.<wbr>html<=
/a>
<br></blockquote><div><br>Yes, straight from the horse's mouth, thank you :=
-) <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 <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_458_8584938.1395087583543--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 17 Mar 2014 22:30:51 +0200
Raw View
On 17 March 2014 22:19, Matheus Izvekov <mizvekov@gmail.com> wrote:
> On Monday, March 17, 2014 4:57:34 AM UTC-3, Ville Voutilainen wrote:
>> That would be
>> http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3897.html
> Yes, straight from the horse's mouth, thank you :-)
Well, I'd like to point out that I merely jotted down the discussion -
Faisal did the
hard part. I wish more people did that when coming up with 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/.
.