------=_Part_7058_538452009.1509393260810
Content-Type: multipart/alternative;
 boundary="----=_Part_7059_794845817.1509393260810"

------=_Part_7059_794845817.1509393260810
Content-Type: text/plain; charset="UTF-8"

I wonder if it would be a good idea to add to the language a new (or news)
types of floating-point numbers where the implementation already manages
the precission problems and do correct comparations, for certain well-known
context situations at least, and where the user don't need a full control
of the performance of the operations, but still needs a "pseudo-optional
performance" favouring an exact precission.

For example, for floating-point comparisions, there's a lot of ways of
comparing them, like the Qt's fuzzy comparation, the simplest `fabs(a - b)
== precission`, epsilon/relative comparisions, the "almost equal method",
etc, etc, and the user could be confused about what method is the best to
use for his specific case (where "best" means usually a ratio between
accuracy and performance). So a bit of help from the language for
well-known contexts will be very appreciated I think.

In particular, I was thinking for example in situation where you always
want to work with floating point numbers with a fixed precission in all of
the operations, which can be seen as a degenerated kind of integral
numbers, where a floating-division *a/b* must be equivalent, from a user
point of view, for example to:

((int)(a/precission) / (int)(b/precission)) * precission // where
precission could be, for example, 1e-5.

but still working with them as if they were floating-points number saving
all of this intermediary scalings and roundings or truncations (similar to
MySQL `decimal` data types). You could say that it will be more efficient
to just pass your *fixed-precision* data to integer (dividing it by
precission), at the beginning of the calculation, do the corresponding
operations, and then come back to floating when you are done; but if the
precission must be high, for example, 1e-8, passing to integer could cause
overflow problems.

You can of course have a collection of functions that implement all of
these operations, or a class wrapping a floating-point number with the
suitable overloaded operators, but if these types and operations are
implemented natively by the compiler they could implement them in clever
ways directly written in assembly code according to the most efficient
operations in the underlying architecture. Besides, it is still
user-responsability to know what is the "best implementation" (whetever it
means for him) for each operation.

Besides, precission limits could deliver accumulative errors under certain
operations with certain values (for example, some chainined divisions),
while other operations had not that problem (just a couple of additions).
Since your invariant is to get, at the end of the computation, the same
exact value with that fixed precission that you would get if the machine
had infinite precission, the compiler could just apply the required
adjustments only when needed.

For example, this type could be a templated class called *discrete_float*,
with three template parameters, the floating-point type that you are
wrapping (*float*, *double*, *long double*), the required fixed precission,
and the rounding policy, for example, *std::floor_rounding *or
*std::truncate*, *std::ceil_rounding* and *std::rounding*.

Since the idea is to be a replacement of real floating-point types, I was
thinking in that *discrete_float* type as a degenerated-primitive type with
built-in implementation of its operations (the template class name is a
type keyword, it cannot be specialized, you cannot inherit from them, it
doesn't belong to the `std` namespace, etc, etc, as a built-in float).
Maybe the type could have some "member functions" to change any required
property (like temporarily changing the required precission).

Additionally, although maybe more controversial, for cases where you don't
need to transport a fixed precission, I like too the thinking of having
another degenerated primitive-type called *safe_float<builting-floating-point-type,
precission-hint>* that works as a floating-point number again, but manages
and fixes natively possible error accumulations, and implements efficient
comparisions using the best suitable comparision method, everything
according to the current value and maybe previous operations, to the extent
possible.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/79abb657-d727-4562-84cb-c94ac8e1ece5%40isocpp.org.

------=_Part_7059_794845817.1509393260810
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I wonder if it would be a good idea to add to the language=
 a new (or news) types of floating-point numbers where the implementation a=
lready manages the precission problems and do correct comparations, for cer=
tain well-known context situations at least, and where the user don&#39;t n=
eed a full control of the performance of the operations, but still needs a =
&quot;pseudo-optional performance&quot; favouring an exact precission.<div>=
<br></div><div>For example, for floating-point comparisions, there&#39;s a =
lot of ways of comparing them, like the Qt&#39;s fuzzy comparation, the sim=
plest `fabs(a - b) =3D=3D precission`, epsilon/relative comparisions, the &=
quot;almost equal method&quot;, etc, etc, and the user could be confused ab=
out what method is the best to use for his specific case (where &quot;best&=
quot; means usually a ratio between accuracy and performance). So a bit of =
help from the language for well-known contexts will be very appreciated I t=
hink.<br></div><div><br></div><div>In particular, I was thinking for exampl=
e in situation where you always want to work with floating point numbers wi=
th a fixed precission in all of the operations, which can be seen as a dege=
nerated kind of integral numbers, where a floating-division <i>a/b</i><span=
 style=3D"background-color: white; font-family: Arial, Helvetica, sans-seri=
f;">=C2=A0must be equivalent, from a user point of view, for example to:</s=
pan></div><div><br></div><div><div class=3D"prettyprint" style=3D"backgroun=
d-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style=
: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettypr=
int"><div class=3D"subprettyprint"><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">((</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">int</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">)(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">a</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">/</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">precission</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: #6=
60;" class=3D"styled-by-prettify">/</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">int</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
)(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">b</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">/</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">precission</span><span sty=
le=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"> precission </span><span style=3D"color: #800;" cla=
ss=3D"styled-by-prettify">// where precission could be, for example, 1e-5.<=
/span></div></code></div><br></div><div>but still working with them as if t=
hey were floating-points number saving all of this intermediary scalings an=
d roundings or truncations (similar to MySQL `decimal` data types). You cou=
ld say that it will be more efficient to just pass your <i>fixed-precision<=
/i> data to integer (dividing it by precission), at the beginning of the ca=
lculation, do the corresponding operations, and then come back to floating =
when you are done; but if the precission must be high, for example, 1e-8, p=
assing to integer could cause overflow problems.</div><div><br></div><div>Y=
ou can of course have a collection of functions that implement all of these=
 operations, or a class wrapping a floating-point number with the suitable =
overloaded operators, but if these types and operations are implemented nat=
ively by the compiler they could implement them in clever ways directly wri=
tten in assembly code according to the most efficient operations in the und=
erlying architecture. Besides, it is still user-responsability to know what=
 is the &quot;best implementation&quot; (whetever it means for him) for eac=
h operation.<br></div><div><br></div><div>Besides, precission limits could =
deliver accumulative errors under certain operations with certain values (f=
or example, some chainined divisions), while other operations had not that =
problem (just a couple of additions). Since your invariant is to get, at th=
e end of the computation, the same exact value with that fixed precission t=
hat you would get if the machine had infinite precission, the compiler coul=
d just apply the required adjustments only when needed.</div><div><br></div=
><div>For example, this type could be a templated class called <i>discrete_=
float</i>, with three template parameters, the floating-point type that you=
 are wrapping (<i>float</i>, <i>double</i>, <i>long double</i>), the requir=
ed fixed precission, and the rounding policy, for example, <i>std::floor_ro=
unding=C2=A0</i>or <i>std::truncate</i>,=C2=A0<i>std::ceil_rounding</i>=C2=
=A0and=C2=A0<i>std::rounding</i>.=C2=A0</div><div><br></div><div>Since the =
idea is to be a replacement of real floating-point types, I was thinking in=
 that <i>discrete_float</i> type as a degenerated-primitive type with built=
-in implementation of its operations (the template class name is a type key=
word, it cannot be specialized, you cannot inherit from them, it doesn&#39;=
t belong to the `std` namespace, etc, etc, as a built-in float). Maybe the =
type could have some &quot;member functions&quot; to change any required pr=
operty (like temporarily changing the required precission).</div><div><br><=
/div><div>Additionally, although maybe more controversial, for cases where =
you don&#39;t need to transport a fixed precission, I like too the thinking=
 of having another degenerated primitive-type called <i>safe_float&lt;built=
ing-floating-point-type, precission-hint&gt;</i>=C2=A0that works as a float=
ing-point number again, but manages and fixes natively possible error accum=
ulations, and implements efficient comparisions using the best suitable com=
parision method, everything according to the current value and maybe previo=
us operations, to the extent possible.<br></div></div>

<p></p>

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

------=_Part_7059_794845817.1509393260810--

------=_Part_7058_538452009.1509393260810--

.

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

We probably need to see an implementation of this idea, with tests and some
use experience, before we can reasonably discuss it.


On Mon, Oct 30, 2017 at 12:54 PM Aar=C3=B3n Bueno Villares <abv150ci@gmail.=
com>
wrote:

> I wonder if it would be a good idea to add to the language a new (or news=
)
> types of floating-point numbers where the implementation already manages
> the precission problems and do correct comparations, for certain well-kno=
wn
> context situations at least, and where the user don't need a full control
> of the performance of the operations, but still needs a "pseudo-optional
> performance" favouring an exact precission.
>
> For example, for floating-point comparisions, there's a lot of ways of
> comparing them, like the Qt's fuzzy comparation, the simplest `fabs(a - b=
)
> =3D=3D precission`, epsilon/relative comparisions, the "almost equal meth=
od",
> etc, etc, and the user could be confused about what method is the best to
> use for his specific case (where "best" means usually a ratio between
> accuracy and performance). So a bit of help from the language for
> well-known contexts will be very appreciated I think.
>
> In particular, I was thinking for example in situation where you always
> want to work with floating point numbers with a fixed precission in all o=
f
> the operations, which can be seen as a degenerated kind of integral
> numbers, where a floating-division *a/b* must be equivalent, from a user
> point of view, for example to:
>
> ((int)(a/precission) / (int)(b/precission)) * precission // where
> precission could be, for example, 1e-5.
>
> but still working with them as if they were floating-points number saving
> all of this intermediary scalings and roundings or truncations (similar t=
o
> MySQL `decimal` data types). You could say that it will be more efficient
> to just pass your *fixed-precision* data to integer (dividing it by
> precission), at the beginning of the calculation, do the corresponding
> operations, and then come back to floating when you are done; but if the
> precission must be high, for example, 1e-8, passing to integer could caus=
e
> overflow problems.
>
> You can of course have a collection of functions that implement all of
> these operations, or a class wrapping a floating-point number with the
> suitable overloaded operators, but if these types and operations are
> implemented natively by the compiler they could implement them in clever
> ways directly written in assembly code according to the most efficient
> operations in the underlying architecture. Besides, it is still
> user-responsability to know what is the "best implementation" (whetever i=
t
> means for him) for each operation.
>
> Besides, precission limits could deliver accumulative errors under certai=
n
> operations with certain values (for example, some chainined divisions),
> while other operations had not that problem (just a couple of additions).
> Since your invariant is to get, at the end of the computation, the same
> exact value with that fixed precission that you would get if the machine
> had infinite precission, the compiler could just apply the required
> adjustments only when needed.
>
> For example, this type could be a templated class called *discrete_float*=
,
> with three template parameters, the floating-point type that you are
> wrapping (*float*, *double*, *long double*), the required fixed
> precission, and the rounding policy, for example, *std::floor_rounding *o=
r
> *std::truncate*, *std::ceil_rounding* and *std::rounding*.
>
> Since the idea is to be a replacement of real floating-point types, I was
> thinking in that *discrete_float* type as a degenerated-primitive type
> with built-in implementation of its operations (the template class name i=
s
> a type keyword, it cannot be specialized, you cannot inherit from them, i=
t
> doesn't belong to the `std` namespace, etc, etc, as a built-in float).
> Maybe the type could have some "member functions" to change any required
> property (like temporarily changing the required precission).
>
> Additionally, although maybe more controversial, for cases where you don'=
t
> need to transport a fixed precission, I like too the thinking of having
> another degenerated primitive-type called *safe_float<builting-floating-p=
oint-type,
> precission-hint>* that works as a floating-point number again, but
> manages and fixes natively possible error accumulations, and implements
> efficient comparisions using the best suitable comparision method,
> everything according to the current value and maybe previous operations, =
to
> the extent possible.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/79abb657-d72=
7-4562-84cb-c94ac8e1ece5%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/79abb657-d7=
27-4562-84cb-c94ac8e1ece5%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CANh-dX%3DyKXnK-mUtp02LkTMXAMUtmYPiZGjVe9x__Ng3O=
K%3DPDg%40mail.gmail.com.

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

<div dir=3D"ltr">We probably need to see an implementation of this idea, wi=
th tests and some use experience, before we can reasonably discuss it.</div=
><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Oct 30, 2017 a=
t 12:54 PM Aar=C3=B3n Bueno Villares &lt;<a href=3D"mailto:abv150ci@gmail.c=
om">abv150ci@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr">I wonder if it would be a good idea to add to the langu=
age a new (or news) types of floating-point numbers where the implementatio=
n already manages the precission problems and do correct comparations, for =
certain well-known context situations at least, and where the user don&#39;=
t need a full control of the performance of the operations, but still needs=
 a &quot;pseudo-optional performance&quot; favouring an exact precission.<d=
iv><br></div><div>For example, for floating-point comparisions, there&#39;s=
 a lot of ways of comparing them, like the Qt&#39;s fuzzy comparation, the =
simplest `fabs(a - b) =3D=3D precission`, epsilon/relative comparisions, th=
e &quot;almost equal method&quot;, etc, etc, and the user could be confused=
 about what method is the best to use for his specific case (where &quot;be=
st&quot; means usually a ratio between accuracy and performance). So a bit =
of help from the language for well-known contexts will be very appreciated =
I think.<br></div><div><br></div><div>In particular, I was thinking for exa=
mple in situation where you always want to work with floating point numbers=
 with a fixed precission in all of the operations, which can be seen as a d=
egenerated kind of integral numbers, where a floating-division <i>a/b</i><s=
pan style=3D"background-color:white;font-family:Arial,Helvetica,sans-serif"=
>=C2=A0must be equivalent, from a user point of view, for example to:</span=
></div><div><br></div><div><div class=3D"m_8547611791095455830prettyprint" =
style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);bo=
rder-style:solid;border-width:1px;word-wrap:break-word"><code class=3D"m_85=
47611791095455830prettyprint"><div class=3D"m_8547611791095455830subprettyp=
rint"><span style=3D"color:#660" class=3D"m_8547611791095455830styled-by-pr=
ettify">((</span><span style=3D"color:#008" class=3D"m_8547611791095455830s=
tyled-by-prettify">int</span><span style=3D"color:#660" class=3D"m_85476117=
91095455830styled-by-prettify">)(</span><span style=3D"color:#000" class=3D=
"m_8547611791095455830styled-by-prettify">a</span><span style=3D"color:#660=
" class=3D"m_8547611791095455830styled-by-prettify">/</span><span style=3D"=
color:#000" class=3D"m_8547611791095455830styled-by-prettify">precission</s=
pan><span style=3D"color:#660" class=3D"m_8547611791095455830styled-by-pret=
tify">)</span><span style=3D"color:#000" class=3D"m_8547611791095455830styl=
ed-by-prettify"> </span><span style=3D"color:#660" class=3D"m_8547611791095=
455830styled-by-prettify">/</span><span style=3D"color:#000" class=3D"m_854=
7611791095455830styled-by-prettify"> </span><span style=3D"color:#660" clas=
s=3D"m_8547611791095455830styled-by-prettify">(</span><span style=3D"color:=
#008" class=3D"m_8547611791095455830styled-by-prettify">int</span><span sty=
le=3D"color:#660" class=3D"m_8547611791095455830styled-by-prettify">)(</spa=
n><span style=3D"color:#000" class=3D"m_8547611791095455830styled-by-pretti=
fy">b</span><span style=3D"color:#660" class=3D"m_8547611791095455830styled=
-by-prettify">/</span><span style=3D"color:#000" class=3D"m_854761179109545=
5830styled-by-prettify">precission</span><span style=3D"color:#660" class=
=3D"m_8547611791095455830styled-by-prettify">))</span><span style=3D"color:=
#000" class=3D"m_8547611791095455830styled-by-prettify"> </span><span style=
=3D"color:#660" class=3D"m_8547611791095455830styled-by-prettify">*</span><=
span style=3D"color:#000" class=3D"m_8547611791095455830styled-by-prettify"=
> precission </span><span style=3D"color:#800" class=3D"m_85476117910954558=
30styled-by-prettify">// where precission could be, for example, 1e-5.</spa=
n></div></code></div><br></div><div>but still working with them as if they =
were floating-points number saving all of this intermediary scalings and ro=
undings or truncations (similar to MySQL `decimal` data types). You could s=
ay that it will be more efficient to just pass your <i>fixed-precision</i> =
data to integer (dividing it by precission), at the beginning of the calcul=
ation, do the corresponding operations, and then come back to floating when=
 you are done; but if the precission must be high, for example, 1e-8, passi=
ng to integer could cause overflow problems.</div><div><br></div><div>You c=
an of course have a collection of functions that implement all of these ope=
rations, or a class wrapping a floating-point number with the suitable over=
loaded operators, but if these types and operations are implemented nativel=
y by the compiler they could implement them in clever ways directly written=
 in assembly code according to the most efficient operations in the underly=
ing architecture. Besides, it is still user-responsability to know what is =
the &quot;best implementation&quot; (whetever it means for him) for each op=
eration.<br></div><div><br></div><div>Besides, precission limits could deli=
ver accumulative errors under certain operations with certain values (for e=
xample, some chainined divisions), while other operations had not that prob=
lem (just a couple of additions). Since your invariant is to get, at the en=
d of the computation, the same exact value with that fixed precission that =
you would get if the machine had infinite precission, the compiler could ju=
st apply the required adjustments only when needed.</div><div><br></div><di=
v>For example, this type could be a templated class called <i>discrete_floa=
t</i>, with three template parameters, the floating-point type that you are=
 wrapping (<i>float</i>, <i>double</i>, <i>long double</i>), the required f=
ixed precission, and the rounding policy, for example, <i>std::floor_roundi=
ng=C2=A0</i>or <i>std::truncate</i>,=C2=A0<i>std::ceil_rounding</i>=C2=A0an=
d=C2=A0<i>std::rounding</i>.=C2=A0</div><div><br></div><div>Since the idea =
is to be a replacement of real floating-point types, I was thinking in that=
 <i>discrete_float</i> type as a degenerated-primitive type with built-in i=
mplementation of its operations (the template class name is a type keyword,=
 it cannot be specialized, you cannot inherit from them, it doesn&#39;t bel=
ong to the `std` namespace, etc, etc, as a built-in float). Maybe the type =
could have some &quot;member functions&quot; to change any required propert=
y (like temporarily changing the required precission).</div><div><br></div>=
<div>Additionally, although maybe more controversial, for cases where you d=
on&#39;t need to transport a fixed precission, I like too the thinking of h=
aving another degenerated primitive-type called <i>safe_float&lt;builting-f=
loating-point-type, precission-hint&gt;</i>=C2=A0that works as a floating-p=
oint number again, but manages and fixes natively possible error accumulati=
ons, and implements efficient comparisions using the best suitable comparis=
ion method, everything according to the current value and maybe previous op=
erations, to the extent possible.<br></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/79abb657-d727-4562-84cb-c94ac8e1ece5%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/79abb657-d727-=
4562-84cb-c94ac8e1ece5%40isocpp.org</a>.<br>
</blockquote></div>

<p></p>

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

--001a1143f534c805a0055cc9dc5c--

.

--089e0826730c0b6c4a055ccbeb5f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

You might be interested in John McFarlane's work on the SG14 reflector for
this one. I took the liberty of adding them to this list.



2017-10-30 16:55 GMT-04:00 'Jeffrey Yasskin' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org>:

> We probably need to see an implementation of this idea, with tests and
> some use experience, before we can reasonably discuss it.
>
>
> On Mon, Oct 30, 2017 at 12:54 PM Aar=C3=B3n Bueno Villares <abv150ci@gmai=
l.com>
> wrote:
>
>> I wonder if it would be a good idea to add to the language a new (or
>> news) types of floating-point numbers where the implementation already
>> manages the precission problems and do correct comparations, for certain
>> well-known context situations at least, and where the user don't need a
>> full control of the performance of the operations, but still needs a
>> "pseudo-optional performance" favouring an exact precission.
>>
>> For example, for floating-point comparisions, there's a lot of ways of
>> comparing them, like the Qt's fuzzy comparation, the simplest `fabs(a - =
b)
>> =3D=3D precission`, epsilon/relative comparisions, the "almost equal met=
hod",
>> etc, etc, and the user could be confused about what method is the best t=
o
>> use for his specific case (where "best" means usually a ratio between
>> accuracy and performance). So a bit of help from the language for
>> well-known contexts will be very appreciated I think.
>>
>> In particular, I was thinking for example in situation where you always
>> want to work with floating point numbers with a fixed precission in all =
of
>> the operations, which can be seen as a degenerated kind of integral
>> numbers, where a floating-division *a/b* must be equivalent, from a user
>> point of view, for example to:
>>
>> ((int)(a/precission) / (int)(b/precission)) * precission // where
>> precission could be, for example, 1e-5.
>>
>> but still working with them as if they were floating-points number savin=
g
>> all of this intermediary scalings and roundings or truncations (similar =
to
>> MySQL `decimal` data types). You could say that it will be more efficien=
t
>> to just pass your *fixed-precision* data to integer (dividing it by
>> precission), at the beginning of the calculation, do the corresponding
>> operations, and then come back to floating when you are done; but if the
>> precission must be high, for example, 1e-8, passing to integer could cau=
se
>> overflow problems.
>>
>> You can of course have a collection of functions that implement all of
>> these operations, or a class wrapping a floating-point number with the
>> suitable overloaded operators, but if these types and operations are
>> implemented natively by the compiler they could implement them in clever
>> ways directly written in assembly code according to the most efficient
>> operations in the underlying architecture. Besides, it is still
>> user-responsability to know what is the "best implementation" (whetever =
it
>> means for him) for each operation.
>>
>> Besides, precission limits could deliver accumulative errors under
>> certain operations with certain values (for example, some chainined
>> divisions), while other operations had not that problem (just a couple o=
f
>> additions). Since your invariant is to get, at the end of the computatio=
n,
>> the same exact value with that fixed precission that you would get if th=
e
>> machine had infinite precission, the compiler could just apply the requi=
red
>> adjustments only when needed.
>>
>> For example, this type could be a templated class called *discrete_float=
*,
>> with three template parameters, the floating-point type that you are
>> wrapping (*float*, *double*, *long double*), the required fixed
>> precission, and the rounding policy, for example, *std::floor_rounding *=
or
>> *std::truncate*, *std::ceil_rounding* and *std::rounding*.
>>
>> Since the idea is to be a replacement of real floating-point types, I wa=
s
>> thinking in that *discrete_float* type as a degenerated-primitive type
>> with built-in implementation of its operations (the template class name =
is
>> a type keyword, it cannot be specialized, you cannot inherit from them, =
it
>> doesn't belong to the `std` namespace, etc, etc, as a built-in float).
>> Maybe the type could have some "member functions" to change any required
>> property (like temporarily changing the required precission).
>>
>> Additionally, although maybe more controversial, for cases where you
>> don't need to transport a fixed precission, I like too the thinking of
>> having another degenerated primitive-type called *safe_float<builting-fl=
oating-point-type,
>> precission-hint>* that works as a floating-point number again, but
>> manages and fixes natively possible error accumulations, and implements
>> efficient comparisions using the best suitable comparision method,
>> everything according to the current value and maybe previous operations,=
 to
>> the extent possible.
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/
>> isocpp.org/d/msgid/std-proposals/79abb657-d727-4562-
>> 84cb-c94ac8e1ece5%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/79abb657-d=
727-4562-84cb-c94ac8e1ece5%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CANh-dX%3DyKXnK-
> mUtp02LkTMXAMUtmYPiZGjVe9x__Ng3OK%3DPDg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dX%3Dy=
KXnK-mUtp02LkTMXAMUtmYPiZGjVe9x__Ng3OK%3DPDg%40mail.gmail.com?utm_medium=3D=
email&utm_source=3Dfooter>
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAKiZDp39ib_gF8iF2Pj4AGFQiV8r746GcUSkSdDhx1rmAzF=
t9A%40mail.gmail.com.

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

<div dir=3D"ltr">You might be interested in John McFarlane&#39;s work on th=
e SG14 reflector for this one. I took the liberty of adding them to this li=
st.<br><br><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">20=
17-10-30 16:55 GMT-04:00 &#39;Jeffrey Yasskin&#39; via ISO C++ Standard - F=
uture Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocp=
p.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span>:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr">We probably need to see an implem=
entation of this idea, with tests and some use experience, before we can re=
asonably discuss it.</div><div><div class=3D"h5"><br><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr">On Mon, Oct 30, 2017 at 12:54 PM Aar=C3=B3n Bueno=
 Villares &lt;<a href=3D"mailto:abv150ci@gmail.com" target=3D"_blank">abv15=
0ci@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">I wonder if it would be a good idea to add to the language a new=
 (or news) types of floating-point numbers where the implementation already=
 manages the precission problems and do correct comparations, for certain w=
ell-known context situations at least, and where the user don&#39;t need a =
full control of the performance of the operations, but still needs a &quot;=
pseudo-optional performance&quot; favouring an exact precission.<div><br></=
div><div>For example, for floating-point comparisions, there&#39;s a lot of=
 ways of comparing them, like the Qt&#39;s fuzzy comparation, the simplest =
`fabs(a - b) =3D=3D precission`, epsilon/relative comparisions, the &quot;a=
lmost equal method&quot;, etc, etc, and the user could be confused about wh=
at method is the best to use for his specific case (where &quot;best&quot; =
means usually a ratio between accuracy and performance). So a bit of help f=
rom the language for well-known contexts will be very appreciated I think.<=
br></div><div><br></div><div>In particular, I was thinking for example in s=
ituation where you always want to work with floating point numbers with a f=
ixed precission in all of the operations, which can be seen as a degenerate=
d kind of integral numbers, where a floating-division <i>a/b</i><span style=
=3D"background-color:white;font-family:Arial,Helvetica,sans-serif">=C2=A0mu=
st be equivalent, from a user point of view, for example to:</span></div><d=
iv><br></div><div><div class=3D"m_1626575480564083367m_8547611791095455830p=
rettyprint" 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 c=
lass=3D"m_1626575480564083367m_8547611791095455830prettyprint"><div class=
=3D"m_1626575480564083367m_8547611791095455830subprettyprint"><span style=
=3D"color:#660" class=3D"m_1626575480564083367m_8547611791095455830styled-b=
y-prettify">((</span><span style=3D"color:#008" class=3D"m_1626575480564083=
367m_8547611791095455830styled-by-prettify">int</span><span style=3D"color:=
#660" class=3D"m_1626575480564083367m_8547611791095455830styled-by-prettify=
">)(</span><span style=3D"color:#000" class=3D"m_1626575480564083367m_85476=
11791095455830styled-by-prettify">a</span><span style=3D"color:#660" class=
=3D"m_1626575480564083367m_8547611791095455830styled-by-prettify">/</span><=
span style=3D"color:#000" class=3D"m_1626575480564083367m_85476117910954558=
30styled-by-prettify">precission</span><span style=3D"color:#660" class=3D"=
m_1626575480564083367m_8547611791095455830styled-by-prettify">)</span><span=
 style=3D"color:#000" class=3D"m_1626575480564083367m_8547611791095455830st=
yled-by-prettify"> </span><span style=3D"color:#660" class=3D"m_16265754805=
64083367m_8547611791095455830styled-by-prettify">/</span><span style=3D"col=
or:#000" class=3D"m_1626575480564083367m_8547611791095455830styled-by-prett=
ify"> </span><span style=3D"color:#660" class=3D"m_1626575480564083367m_854=
7611791095455830styled-by-prettify">(</span><span style=3D"color:#008" clas=
s=3D"m_1626575480564083367m_8547611791095455830styled-by-prettify">int</spa=
n><span style=3D"color:#660" class=3D"m_1626575480564083367m_85476117910954=
55830styled-by-prettify">)(</span><span style=3D"color:#000" class=3D"m_162=
6575480564083367m_8547611791095455830styled-by-prettify">b</span><span styl=
e=3D"color:#660" class=3D"m_1626575480564083367m_8547611791095455830styled-=
by-prettify">/</span><span style=3D"color:#000" class=3D"m_1626575480564083=
367m_8547611791095455830styled-by-prettify">precission</span><span style=3D=
"color:#660" class=3D"m_1626575480564083367m_8547611791095455830styled-by-p=
rettify">))</span><span style=3D"color:#000" class=3D"m_1626575480564083367=
m_8547611791095455830styled-by-prettify"> </span><span style=3D"color:#660"=
 class=3D"m_1626575480564083367m_8547611791095455830styled-by-prettify">*</=
span><span style=3D"color:#000" class=3D"m_1626575480564083367m_85476117910=
95455830styled-by-prettify"> precission </span><span style=3D"color:#800" c=
lass=3D"m_1626575480564083367m_8547611791095455830styled-by-prettify">// wh=
ere precission could be, for example, 1e-5.</span></div></code></div><br></=
div><div>but still working with them as if they were floating-points number=
 saving all of this intermediary scalings and roundings or truncations (sim=
ilar to MySQL `decimal` data types). You could say that it will be more eff=
icient to just pass your <i>fixed-precision</i> data to integer (dividing i=
t by precission), at the beginning of the calculation, do the corresponding=
 operations, and then come back to floating when you are done; but if the p=
recission must be high, for example, 1e-8, passing to integer could cause o=
verflow problems.</div><div><br></div><div>You can of course have a collect=
ion of functions that implement all of these operations, or a class wrappin=
g a floating-point number with the suitable overloaded operators, but if th=
ese types and operations are implemented natively by the compiler they coul=
d implement them in clever ways directly written in assembly code according=
 to the most efficient operations in the underlying architecture. Besides, =
it is still user-responsability to know what is the &quot;best implementati=
on&quot; (whetever it means for him) for each operation.<br></div><div><br>=
</div><div>Besides, precission limits could deliver accumulative errors und=
er certain operations with certain values (for example, some chainined divi=
sions), while other operations had not that problem (just a couple of addit=
ions). Since your invariant is to get, at the end of the computation, the s=
ame exact value with that fixed precission that you would get if the machin=
e had infinite precission, the compiler could just apply the required adjus=
tments only when needed.</div><div><br></div><div>For example, this type co=
uld be a templated class called <i>discrete_float</i>, with three template =
parameters, the floating-point type that you are wrapping (<i>float</i>, <i=
>double</i>, <i>long double</i>), the required fixed precission, and the ro=
unding policy, for example, <i>std::floor_rounding=C2=A0</i>or <i>std::trun=
cate</i>,=C2=A0<i>std::ceil_<wbr>rounding</i>=C2=A0and=C2=A0<i>std::roundin=
g</i>.=C2=A0</div><div><br></div><div>Since the idea is to be a replacement=
 of real floating-point types, I was thinking in that <i>discrete_float</i>=
 type as a degenerated-primitive type with built-in implementation of its o=
perations (the template class name is a type keyword, it cannot be speciali=
zed, you cannot inherit from them, it doesn&#39;t belong to the `std` names=
pace, etc, etc, as a built-in float). Maybe the type could have some &quot;=
member functions&quot; to change any required property (like temporarily ch=
anging the required precission).</div><div><br></div><div>Additionally, alt=
hough maybe more controversial, for cases where you don&#39;t need to trans=
port a fixed precission, I like too the thinking of having another degenera=
ted primitive-type called <i>safe_float&lt;builting-floating-<wbr>point-typ=
e, precission-hint&gt;</i>=C2=A0that works as a floating-point number again=
, but manages and fixes natively possible error accumulations, and implemen=
ts efficient comparisions using the best suitable comparision method, every=
thing according to the current value and maybe previous operations, to the =
extent possible.<br></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/79abb657-d727-4562-84cb-c94ac8e1ece5%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/79ab=
b657-d727-4562-<wbr>84cb-c94ac8e1ece5%40isocpp.org</a><wbr>.<br>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh-dX%3DyKXnK-mUtp02LkTMXAMUtmYPiZG=
jVe9x__Ng3OK%3DPDg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/=
std-<wbr>proposals/CANh-dX%3DyKXnK-<wbr>mUtp02LkTMXAMUtmYPiZGjVe9x__<wbr>Ng=
3OK%3DPDg%40mail.gmail.com</a>.<br>
</blockquote></div><br></div></div>

<p></p>

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

--089e0826730c0b6c4a055ccbeb5f--

.

On 10/30/17 1:55 PM, 'Jeffrey Yasskin' via ISO C++ Standard - Future
Proposals wrote:
> We probably need to see an implementation of this idea, with tests and
> some use experience, before we can reasonably discuss it.
>

You can see an implementation of something very similar in the Boost
Safe Numerics Library.  It was the subject of an article in ACCU
magazine and also of a standards proposal. It was reviewed and accepted
by Boost some months ago and is currently being worked on to meet
conditions of acceptance.  Efforts regarding the standards proposal have
taken the back seat to getting the library implementation up to boost
standards.

Robert Ramey

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/bcca9db6-fc39-a1e5-bf81-72cf421f8b0d%40rrsd.com.

.

On segunda-feira, 30 de outubro de 2017 18:41:11 PDT Robert Ramey wrote:
>  It was reviewed and accepted
> by Boost some months ago

Then it looks like we should allow it to mature for a few years before
proposing into the standard.

Mind you, I'm not saying give up. This may be important functionality. But if
it's just been accepted into Boost, it means it's not mature yet.

Are there other, pre-existing examples whose usage we can study and have at
least a couple of years of use?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1610160.1ckeThBg0k%40tjmaciei-mobl1.

.

------=_Part_7847_279537512.1509438426442
Content-Type: multipart/alternative;
 boundary="----=_Part_7848_244211390.1509438426442"

------=_Part_7848_244211390.1509438426442
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Il giorno luned=C3=AC 30 ottobre 2017 20:54:20 UTC+1, Aar=C3=B3n Bueno Vill=
ares ha=20
scritto:
>
> In particular, I was thinking for example in situation where you always=
=20
> want to work with floating point numbers with a fixed precission in all o=
f=20
> the operations, which can be seen as a degenerated kind of integral=20
> numbers, where a floating-division *a/b* must be equivalent, from a user=
=20
> point of view, for example to:
>
> ((int)(a/precission) / (int)(b/precission)) * precission // where=20
> precission could be, for example, 1e-5.
>
>
Isn't that already achieved to some extent by the Fixed Point Real Numbers=
=20
<http://wg21.link/p0037> proposal? What else are you suggesting?

Alberto

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5c1a5538-781c-49a8-90d3-c408ac62a15b%40isocpp.or=
g.

------=_Part_7848_244211390.1509438426442
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Il giorno luned=C3=AC 30 ottobre 2017 20:54:20 UTC+1, Aar=
=C3=B3n Bueno Villares ha scritto:<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">In particular, I was thinking for example in situati=
on where you always want to work with floating point numbers with a fixed p=
recission in all of the operations, which can be seen as a degenerated kind=
 of integral numbers, where a floating-division <i>a/b</i><span style=3D"ba=
ckground-color:white;font-family:Arial,Helvetica,sans-serif">=C2=A0must be =
equivalent, from a user point of view, for example to:</span><div><br></div=
><div><div 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><d=
iv><span style=3D"color:#660">((</span><span style=3D"color:#008">int</span=
><span style=3D"color:#660">)(</span><span style=3D"color:#000">a</span><sp=
an style=3D"color:#660">/</span><span style=3D"color:#000">precission</span=
><span style=3D"color:#660">)</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#660">/</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#660">(</span><span style=3D"color:#008">int</span><span style=
=3D"color:#660">)(</span><span style=3D"color:#000">b</span><span style=3D"=
color:#660">/</span><span style=3D"color:#000">precission</span><span style=
=3D"color:#660">))</span><span style=3D"color:#000"> </span><span style=3D"=
color:#660">*</span><span style=3D"color:#000"> precission </span><span sty=
le=3D"color:#800">// where precission could be, for example, 1e-5.</span></=
div></code></div><br></div></div></blockquote><div><br></div><div>Isn&#39;t=
 that already achieved to some extent by the <a href=3D"http://wg21.link/p0=
037">Fixed Point Real Numbers</a> proposal? What else are you suggesting?<b=
r><br>Alberto<br></div></div>

<p></p>

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

------=_Part_7848_244211390.1509438426442--

------=_Part_7847_279537512.1509438426442--

.

On ter=C3=A7a-feira, 31 de outubro de 2017 09:01:39 PDT you wrote:
 > Hmmm - so if it had not been accepted by boost, it would be appropriate
 > for consideration in the standard now?

See the second part of my answer, about other, non-Boost existing=20
practice and
experience.

 >> Are there other, pre-existing examples whose usage we can study and hav=
e
 >> at
 >> least a couple of years of use?
 >
 > There are numerous such examples.  But they all entail a run time
 > penalty that reviewers find objectionable.  This current effort strives
 > to reduce/eliminate this penalty using cutting edge C++14 facilities.
 > So the package is complex.  (I'm working to simplify it).
 >
 > Although reviewers and users cite a runtime penalty as a basis for not
 > using this or other libraries, I don't think that this is really the
 > real motivation. But I confess I don't know what the real motivation
 > might be.  It's amazing to me that in all the history of C/C++ there has
 > been no real effort to address the fact that these languages will
 > produce code which is not arithmetically correct.  The only serious
 > efforts have been in other other languages (Ada, Modula) which have been
 > cast aside.
 >
 > Robert Ramey


--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
    Software Architect - Intel Open Source Technology Center


--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/otaa4s%2453u%241%40blaine.gmane.org.

.

On 10/30/17 9:28 PM, Thiago Macieira wrote:> On segunda-feira, 30 de
outubro de 2017 18:41:11 PDT Robert Ramey wrote:
 >>   It was reviewed and accepted
 >> by Boost some months ago
 >
 > Then it looks like we should allow it to mature for a few years before
 > proposing into the standard.

Hmmm - so if it had not been accepted by boost, it would be appropriate
for consideration in the standard now?  This is the case with the
proposal for Ranges which is winding through the standards process
without stopping at Boost for a shake down.  When asked about this, the
author asserted (I'm paraphrasing) that the Boost process created a lot
of extra work and time so it seemed better to go for standards inclusion
directly.  So far, he seems to be right about this.

 > Mind you, I'm not saying give up. This may be important
functionality. But if
 > it's just been accepted into Boost, it means it's not mature yet.

Though I think your phrasing is unfortunate, I agree with your
underlying concern.  Is the standard a good place to develop/approve
very complex libraries which don't have a lot of user experience.  That
is, the committee is designing libraries rather than standardizing
accepted practices.  We've done this in the past (iostreams) and we're
doing it now (ranges) and I don't think it's worked out all that well.
After making a skype presentation at the SG-6 working group some time
ago, I decided to focus my efforts on getting this idea more "mature"
and in wider use - hence the boost review and acceptance.

Bjarn has stated that he thinks boost libraries are overly complicated.
That may be true, but it doesn't seem to have prevented the
standardization committee from incorporating a large number of them into
the standard.  The model of using boost to review, develop, disseminate,
and refine proposed libraries has worked well.  I think with the advent
of more powerful C++, this model is more important than ever.

In short, I think we're in agree ment here.

 > Are there other, pre-existing examples whose usage we can study and
have at
 > least a couple of years of use?
There are numerous such examples.  But they all entail a run time
penalty that reviewers find objectionable.  This current effort strives
to reduce/eliminate this penalty using cutting edge C++14 facilities. So
the package is complex.  (I'm working to simplify it).

Although reviewers and users cite a runtime penalty as a basis for not
using this or other libraries, I don't think that this is really the
real motivation. But I confess I don't know what the real motivation
might be.  It's amazing to me that in all the history of C/C++ there has
been no real effort to address the fact that these languages will
produce code which is not arithmetically correct.  The only serious
efforts have been in other other languages (Ada, Modula) which have been
cast aside.

Robert Ramey


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/otabej%24hje%241%40blaine.gmane.org.

.

--089e0829d21452aa11055cdb0c39
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Oct 31, 2017 at 12:59 PM, Robert Ramey <ramey@rrsd.com> wrote:
>
> > It's amazing to me that in all the history of C/C++ there has
> > been no real effort to address the fact that these languages will
> > produce code which is not arithmetically correct.
>

What do you mean by arithmetically correct?  Do you expect to be able to
divide by 1 by 3 and get exactly 1/3?  If so, you'll need a rational
arithmetic
package.  Do you expect to be able to get exact values for =CF=80 and =E2=
=88=9A2?  Then
you'll need a symbolic algebra package.

Binary floating-point is a well-defined and standardized system of
computation.
Arithmetic in binary floating-point produces the closest representable
number
to the result of an operation.  Many people don't understand what they're
doing
when they use it, and then flail around with rounding and adding halves and
all
sorts of stuff to get rid of "the extra 9999 at the end" but that's not the
fault of
the arithmetic.


> > The only serious efforts have been in other other languages (Ada, Modul=
a)


Ada has ordinary floating-point, and it also has fixed-point types, which
are
just scaled integers. <
https://en.wikibooks.org/wiki/Ada_Programming/Types/delta>

People who are processing lots of decimal values are probably better off
with
decimal floating-point.  GCC can be built to support it:
<https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Decimal-Float.html>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAHSYqdYviHDHD0YwGEpDgfTJjRNdcESdiUNaJVBRvdO-Vav=
ibA%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Oct 31, 2017 at 12:59 PM, Robert Ramey <span dir=3D"ltr">&lt;<a href=3D=
"mailto:ramey@rrsd.com" target=3D"_blank">ramey@rrsd.com</a>&gt;</span> wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; It&#39;s amazing to me that in all the history of C/C++ there has<br>
&gt; been no real effort to address the fact that these languages will<br>&=
gt; produce code which is not arithmetically correct.<br></blockquote><div>=
<br>What do you mean by arithmetically correct?=C2=A0 Do you expect to be a=
ble to<br>divide by 1 by 3 and get exactly 1/3?=C2=A0 If so, you&#39;ll nee=
d a rational arithmetic<br>package.=C2=A0 Do you expect to be able to get e=
xact values for=C2=A0=CF=80 and=C2=A0=E2=88=9A2?=C2=A0 Then<br>you&#39;ll n=
eed a symbolic algebra package.<br><br>Binary floating-point is a well-defi=
ned and standardized system of computation.<br>Arithmetic in binary floatin=
g-point produces the closest representable number<br>to the result of an op=
eration.=C2=A0 Many people don&#39;t understand what they&#39;re doing<br>w=
hen they use it, and then flail around with rounding and adding halves and =
all<br>sorts of stuff to get rid of &quot;the extra 9999 at the end&quot; b=
ut that&#39;s not the fault of<br>the arithmetic.<br></div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; The only serious=C2=A0efforts have been in other other languages (Ada,=
 Modula)</blockquote><div><br>Ada has ordinary floating-point, and it also =
has fixed-point types, which are<br>just scaled integers. &lt;<a href=3D"ht=
tps://en.wikibooks.org/wiki/Ada_Programming/Types/delta">https://en.wikiboo=
ks.org/wiki/Ada_Programming/Types/delta</a>&gt;=C2=A0<br><br>People who are=
 processing lots of decimal values are probably better off with<br>decimal =
floating-point.=C2=A0 GCC can be built to support it:<br>&lt;<a href=3D"htt=
ps://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Decimal-Float.html">https://gcc.g=
nu.org/onlinedocs/gcc-7.2.0/gcc/Decimal-Float.html</a>&gt;<br></div></div><=
/div></div>

<p></p>

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

--089e0829d21452aa11055cdb0c39--

.

On ter=C3=A7a-feira, 31 de outubro de 2017 10:25:37 PDT Hyman Rosen wrote:
> People who are processing lots of decimal values are probably better off
> with
> decimal floating-point.  GCC can be built to support it:
> <https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Decimal-Float.html>

And if you need an arbitrary-precision library, Wikipedia has a list:
https://en.wikipedia.org/wiki/List_of_arbitrary-precision_arithmetic_softwa=
re

GMP is probably the most famous in the Unix world.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/58059258.rNAa3hITAz%40tjmaciei-mobl1.

.

On 10/31/17 10:25 AM, Hyman Rosen wrote:
> On Tue, Oct 31, 2017 at 12:59 PM, Robert Ramey <ramey@rrsd.com=20
> <mailto:ramey@rrsd.com>> wrote:
>=20
>      > It's amazing to me that in all the history of C/C++ there has
>      > been no real effort to address the fact that these languages will
>      > produce code which is not arithmetically correct.
>=20
>=20
> What do you mean by arithmetically correct?=C2=A0 Do you expect to be abl=
e to
> divide by 1 by 3 and get exactly 1/3?=C2=A0 If so, you'll need a rational=
=20
> arithmetic
> package.=C2=A0 Do you expect to be able to get exact values for=C2=A0=CF=
=80 and=C2=A0=E2=88=9A2?=C2=A0 Then
> you'll need a symbolic algebra package.

Given the following code

int f(int x, int y){
 return x + y;
}

for some values of x and y, the value returned will not equal x + y.

Note that the original post referred to just floating point numbers.=20
I'm saying the issue is much broader and has been explicitly addressed=20
for integers.  The Safe Numerics Library currently only addresses=20
related to integers, but will likely be eventually extended to floats.=20
Hence it is relevant to the discussion.  Note that it doesn't require=20
any change in the language - it's purely a library solution.  But it=20
does depend on C++ 14.

> Ada has ordinary floating-point, and it also has fixed-point types,=20
> which are
> just scaled integers.=20
> <https://en.wikibooks.org/wiki/Ada_Programming/Types/delta>

I was referring to the fact that these are examples of very few=20
languages which can (I believe) avoid the problems of the above example.

>=20
> People who are processing lots of decimal values are probably better off=
=20
> with
> decimal floating-point.=C2=A0 GCC can be built to support it:
> <https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Decimal-Float.html>

a whole n'other subject.

Robert Ramey

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/otacqf%24dkl%241%40blaine.gmane.org.

.

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

On Tue, Oct 31, 2017 at 1:44 PM, Robert Ramey <ramey@rrsd.com> wrote:
>
> Given the following code
>
> int f(int x, int y){
>         return x + y;
> }
>
> for some values of x and y, the value returned will not equal x + y.


Back in the day, when Ada implemented overflow checking on by default,
the optimizationists of that time yelled bloody murder about how it was
going
to slow down programs.

In any case, gcc supports the -ftrapv option which will catch signed integer
overflow.  (As well as -fwrapv, which defines signed integer overflow to
wrap
around, as God intended.)
<https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbTKYMp7Kai0jgJY2oW6nooKHy-Nw27_%2Bye%2BFNntPXU1w%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Oct 31, 2017 at 1:44 PM, Robert Ramey <span dir=3D"ltr">&lt;<a href=3D"=
mailto:ramey@rrsd.com" target=3D"_blank">ramey@rrsd.com</a>&gt;</span> wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex">
Given the following code<br>
<br>
int f(int x, int y){<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return x + y;<br>
}<br>
<br>
for some values of x and y, the value returned will not equal x + y.</block=
quote><div><br>Back in the day, when Ada implemented overflow checking on b=
y default,<br>the optimizationists of that time yelled bloody murder about =
how it was going<br>to slow down programs.<br><br>In any case, gcc supports=
 the -ftrapv option which will catch signed integer<br>overflow.=C2=A0 (As =
well as -fwrapv, which defines signed integer overflow to wrap<br>around, a=
s God intended.)<br>&lt;<a href=3D"https://gcc.gnu.org/onlinedocs/gcc/Code-=
Gen-Options.html">https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html<=
/a>&gt;</div></div></div></div>

<p></p>

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

--f40304388a08a5bd19055cdb99a4--

.

On ter=C3=A7a-feira, 31 de outubro de 2017 11:05:08 PDT Hyman Rosen wrote:
> In any case, gcc supports the -ftrapv option which will catch signed inte=
ger
> overflow.  (As well as -fwrapv, which defines signed integer overflow to
> wrap
> around, as God intended.)

https://gcc.gnu.org/gcc-8/changes.html
"-fno-strict-overflow is now mapped to -fwrapv and signed integer overflow =
is=20
now undefined by default at all optimization levels. Using -fsanitize=3Dsig=
ned-
integer-overflow is now the preferred way to audit code, -Wstrict-overflow =
is=20
deprecated."

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/11101756.QHqbr4m4Bj%40tjmaciei-mobl1.

.