## digitalmars.D - std.math.TAU

- James Fisher <jameshfisher gmail.com> Jul 05 2011
- "Steven Schveighoffer" <schveiguy yahoo.com> Jul 05 2011
- Don <nospam nospam.com> Jul 05 2011
- Don <nospam nospam.com> Jul 05 2011
- Walter Bright <newshound2 digitalmars.com> Jul 05 2011
- KennyTM~ <kennytm gmail.com> Jul 05 2011
- Walter Bright <newshound2 digitalmars.com> Jul 05 2011
- James Fisher <jameshfisher gmail.com> Jul 05 2011
- James Fisher <jameshfisher gmail.com> Jul 05 2011
- "Nick Sabalausky" <a a.a> Jul 05 2011
- James Fisher <jameshfisher gmail.com> Jul 05 2011
- James Fisher <jameshfisher gmail.com> Jul 05 2011

--90e6ba613b2445365e04a74e4eba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hopefully this won't be taken as frivolous. I (and possibly some of you) have been convinced by the argument at http://tauday.com/. It's very convincing, and I won't rehash it here. The use of =CF=84 instead of =CF=80 will only become really convenient when= one does not have to preface everything with "let =CF=84 =3D 2=CF=80". For example, in D, in order to think in terms of =CF=84 instead of =CF=80, = one must define `enum real TAU =3D std.math.PI * 2;`, and possibly also TAU_2, TAU_4= , etc. As well as being a typing inconvenience, I also think things are not that easy due to loss of precision (though I'm far from an expert on intricacies of floating point). There is an initiative to add TAU to the Python standard library: http://www.python.org/dev/peps/pep-0628/ To this end, I suggest adding the constant TAU to std.math, and possibly also TAU_2 as an alias for PI, TAU_4 as an alias for PI_2, TAU_8 as PI_4. In any case, I'd like to know what's necessary in order for me to define these constants without loss of precision. d --90e6ba613b2445365e04a74e4eba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hopefully this won't be taken as frivolous. =C2=A0I (and possibly some = of you) have been convinced by the argument at=C2=A0<meta http-equiv=3D"con= tent-type" content=3D"text/html; charset=3Dutf-8"><a href=3D"http://tauday.= com/">http://tauday.com/</a>. =C2=A0It's very convincing, and I won'= ;t rehash it here.<div> <br></div>The use of =CF=84 instead of=C2=A0=CF=80 will only become really = convenient when one does not have to preface everything with "let=C2= =A0<meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8"==CF=84 =3D 2<meta http-equiv=3D"content-type" content=3D"text/html; charse=

<br></div><div>For example, in D, in order to think in terms of=C2=A0<meta = http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8">=CF=84 i= nstead of=C2=A0<meta http-equiv=3D"content-type" content=3D"text/html; char= set=3Dutf-8">=CF=80, one must define `enum real TAU =3D std.math.PI * 2;`, = and possibly also TAU_2, TAU_4, etc.<div> <br></div><div>As well as being a typing inconvenience, I also think things= are not that easy due to loss of precision (though I'm far from an exp= ert on intricacies of floating point).<br><div><div><br></div><div>There is= an initiative to add TAU to the Python standard library:=C2=A0<a href=3D"h= ttp://www.python.org/dev/peps/pep-0628/">http://www.python.org/dev/peps/pep= -0628/</a></div> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8"><d= iv><br></div><div>To this end, I suggest adding the constant TAU to std.mat= h, and possibly also TAU_2 as an alias for PI, TAU_4 as an alias for PI_2, = TAU_8 as PI_4.</div> <div><br></div><div>In any case, I'd like to know what's necessary = in order for me to define these constants without loss of precision.</div><= div><div><span class=3D"Apple-style-span" style=3D"color: rgb(7, 7, 7); lin= e-height: 24px; "><span class=3D"MathJax" style=3D"margin-top: 0px; margin-= right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding= -right: 0px; padding-bottom: 0px; padding-left: 0px; border-top-width: 0px;= border-right-width: 0px; border-bottom-width: 0px; border-left-width: 0px;= border-style: initial; border-color: initial; font-weight: normal; vertica= l-align: baseline; display: inline; line-height: normal; text-indent: 0px; = text-align: left; text-transform: none; letter-spacing: normal; word-spacin= g: normal; word-wrap: normal; white-space: nowrap; float: none; direction: = ltr; border-style: initial; border-color: initial; "><span class=3D"math" i= d=3D"MathJax-Span-85" style=3D"margin-top: 0px; margin-right: 0px; margin-b= ottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding= -bottom: 0px; padding-left: 0px; border-top-width: 0px; border-right-width:= 0px; border-bottom-width: 0px; border-left-width: 0px; border-style: initi= al; border-color: initial; font-weight: inherit; vertical-align: 0px; displ= ay: inline; position: static; border-style: initial; border-color: initial;= line-height: normal; text-decoration: none; "><span style=3D"margin-top: 0= px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0= px; padding-right: 0px; padding-bottom: 0px; padding-left: 0px; border-top-= width: 0px; border-right-width: 0px; border-bottom-width: 0px; border-left-= width: 0em; border-style: initial; border-color: initial; font-weight: inhe= rit; font-style: inherit; font-size: 16px; font-family: MathJax_Main, MathJ= ax_Size1, MathJax_AMS; vertical-align: -0.012em; display: inline-block; pos= ition: static; border-style: initial; border-color: initial; line-height: n= ormal; text-decoration: none; border-left-style: solid; border-left-color: = initial; overflow-x: hidden; overflow-y: hidden; width: 0px; height: 0.468e= m; ">d</span></span></span></span><meta http-equiv=3D"content-type" content= =3D"text/html; charset=3Dutf-8"></div> </div></div></div></div> --90e6ba613b2445365e04a74e4eba--

Jul 05 2011

On Tue, 05 Jul 2011 04:31:09 -0400, James Fisher <jameshfisher gmail.com==

wrote:Hopefully this won't be taken as frivolous. I (and possibly some of y=

have been convinced by the argument at http://tauday.com/. It's very convincing, and I won't rehash it here. The use of =CF=84 instead of =CF=80 will only become really convenient=

does not have to preface everything with "let =CF=84 =3D 2=CF=80". For example, in D, in order to think in terms of =CF=84 instead of =CF=

define `enum real TAU =3D std.math.PI * 2;`, and possibly also TAU_2, =

TAU_4, etc. As well as being a typing inconvenience, I also think things are not t=

easy due to loss of precision (though I'm far from an expert on =

intricacies of floating point). There is an initiative to add TAU to the Python standard library: http://www.python.org/dev/peps/pep-0628/ To this end, I suggest adding the constant TAU to std.math, and possib=

also TAU_2 as an alias for PI, TAU_4 as an alias for PI_2, TAU_8 as PI=

In any case, I'd like to know what's necessary in order for me to defi=

these constants without loss of precision. d

I read an article about this recently, it's definitely interesting. The= = one place where I haven't seen it mentioned is what happens when you wan= t = the area of a circle, since that necessarily involves the radius. I'd = guess you'd have to use =CF=84/2 * r^2, but even then, that's one formul= a vs. = the rest. It's probably a good tradeoff. I can definitely see the = advantage when using radians. Never thought I'd have to re-learn trig = again... One thing I like about Pi vs Tau is that it cannot be mistaken for a = normal character. I'm not a floating point expert, but I would expect since floating point= = is stored in binary, dividing or multiplying by 2 loses no precision at = = all. But I could be wrong... -Steve

Jul 05 2011

James Fisher wrote:On Tue, Jul 5, 2011 at 12:31 PM, James Fisher <jameshfisher gmail.com <mailto:jameshfisher gmail.com>> wrote: Sorry, I didn't state this very clearly. Multiplying the approximation of PI in std.math should yield the exact double of that approximation, as it should just involve increasing the exponent by 1. However, [double the approximation of the constant] is not necessarily equal to [the approximation of double the constant]. Does that make sense?

I understand what you're getting at, but actually multiplication by powers of 2 is always exact for binary floating point numbers. The reason is that the rounding is based on the values after the lowest bit of the _significand_. The exponent plays no role. Multiplication or division by two doesn't change the significand at all, only the exponent, so if the rounding was correct before, it is still correct after the multiplication. Or to put it another way: PI in binary is a infinitely long string of 1s and zeros. Multiplying it by two only shifts the string left and right, it doesn't change any of the 1s to 0s, etc, so the approximation doesn't change either.(I think this is why the constants in math.d <https://github.com/D-Programming-Language/phobos/blob/master/std/math.d#L206> are each defined separately rather than in terms of each other.)

Hmm. I'm not sure why PI_2 and PI_4 are there. They should be defined in terms of PI. Probably should fix that.

Jul 05 2011

James Fisher wrote:On Tue, Jul 5, 2011 at 8:49 PM, Don <nospam nospam.com <mailto:nospam nospam.com>> wrote: James Fisher wrote: On Tue, Jul 5, 2011 at 12:31 PM, James Fisher <jameshfisher gmail.com <mailto:jameshfisher gmail.com> <mailto:jameshfisher gmail.com <mailto:jameshfisher gmail.com>__>> wrote: Sorry, I didn't state this very clearly. Multiplying the approximation of PI in std.math should yield the exact double of that approximation, as it should just involve increasing the exponent by 1. However, [double the approximation of the constant] is not necessarily equal to [the approximation of double the constant]. Does that make sense? I understand what you're getting at, but actually multiplication by powers of 2 is always exact for binary floating point numbers. The reason is that the rounding is based on the values after the lowest bit of the _significand_. The exponent plays no role. Multiplication or division by two doesn't change the significand at all, only the exponent, so if the rounding was correct before, it is still correct after the multiplication. Or to put it another way: PI in binary is a infinitely long string of 1s and zeros. Multiplying it by two only shifts the string left and right, it doesn't change any of the 1s to 0s, etc, so the approximation doesn't change either. Great explanation, thanks. (I think this is why the constants in math.d <https://github.com/D-__Programming-Language/phobos/__blob/master/std/math.d#L206 <https://github.com/D-Programming-Language/phobos/blob/master/std/math.d#L206>> are each defined separately rather than in terms of each other.) Hmm. I'm not sure why PI_2 and PI_4 are there. They should be defined in terms of PI. Probably should fix that. Another thing -- why are some constants defined in decimal, others in hex, and one (E) with the long 'L' suffix?

The ones defined in decimal are obsolete, they haven't had a conversion to hex yet.And is there a significance to the number of decimal/hexadecimal places -- e.g., is this the minimum places required to ensure the closest floating point value for all common hardware accuracies?

Yes, it's 80 bit. Currently there's a problem with DMC's floating-point parser, all those numbers should really be 128 bit (we should be ready for 128 bit quads).

Jul 05 2011

On 7/5/2011 3:45 PM, Don wrote:Another thing -- why are some constants defined in decimal, others in hex, and one (E) with the long 'L' suffix?

The ones defined in decimal are obsolete, they haven't had a conversion to hex yet.

The ones in hex I got out of a book that helpfully printed them as octal values. I wanted exact bit patterns, not decimal conversions that might suffer if there's a flaw in the lexer. It's hard to come by textbook values for some of these that are high precision. It's definitely not good enough to just write some simple fp program to generate them.

Jul 05 2011

On Jul 6, 11 06:59, Walter Bright wrote:On 7/5/2011 3:45 PM, Don wrote:Another thing -- why are some constants defined in decimal, others in hex, and one (E) with the long 'L' suffix?

The ones defined in decimal are obsolete, they haven't had a conversion to hex yet.

The ones in hex I got out of a book that helpfully printed them as octal values. I wanted exact bit patterns, not decimal conversions that might suffer if there's a flaw in the lexer. It's hard to come by textbook values for some of these that are high precision. It's definitely not good enough to just write some simple fp program to generate them.

http://www.wolframalpha.com/input/?i=pi+in+hexadecimal

Jul 05 2011

On 7/5/2011 11:12 PM, KennyTM~ wrote:On Jul 6, 11 06:59, Walter Bright wrote:It's definitely not good enough to just write some simple fp program to generate them.

http://www.wolframalpha.com/input/?i=pi+in+hexadecimal

sweet!

Jul 05 2011

--90e6ba6e8c0ca9a00704a750d43d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 5, 2011 at 12:15 PM, Steven Schveighoffer <schveiguy yahoo.com>wrote:On Tue, 05 Jul 2011 04:31:09 -0400, James Fisher <jameshfisher gmail.com> wrote: Hopefully this won't be taken as frivolous. I (and possibly some of you=

have been convinced by the argument at http://tauday.com/. It's very convincing, and I won't rehash it here. The use of =CF=84 instead of =CF=80 will only become really convenient w=

not have to preface everything with "let =CF=84 =3D 2=CF=80". For example, in D, in order to think in terms of =CF=84 instead of =CF=

define `enum real TAU =3D std.math.PI * 2;`, and possibly also TAU_2, TA=

etc. As well as being a typing inconvenience, I also think things are not tha=

easy due to loss of precision (though I'm far from an expert on intricacies of floating point). There is an initiative to add TAU to the Python standard library: http://www.python.org/dev/**peps/pep-0628/<http://www.python.org/dev/pep=

To this end, I suggest adding the constant TAU to std.math, and possibly also TAU_2 as an alias for PI, TAU_4 as an alias for PI_2, TAU_8 as PI_4=

In any case, I'd like to know what's necessary in order for me to define these constants without loss of precision. d

I read an article about this recently, it's definitely interesting. The one place where I haven't seen it mentioned is what happens when you want the area of a circle, since that necessarily involves the radius. I'd gu=

you'd have to use =CF=84/2 * r^2, but even then, that's one formula vs. t=

It's probably a good tradeoff. I can definitely see the advantage when using radians. Never thought I'd have to re-learn trig again... One thing I like about Pi vs Tau is that it cannot be mistaken for a norm=

character. I'm not a floating point expert, but I would expect since floating point =

stored in binary, dividing or multiplying by 2 loses no precision at all. But I could be wrong...

Sorry, I didn't state this very clearly. Multiplying the approximation of PI in std.math should yield the exact double of that approximation, as it should just involve increasing the exponent by 1. However, [double the approximation of the constant] is not necessarily equal to [the approximation of double the constant]. Does that make sense? --90e6ba6e8c0ca9a00704a750d43d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Tue, Jul 5, 2011 at 12:15 PM, Steven Schveigh= offer <span dir=3D"ltr"><<a href=3D"mailto:schveiguy yahoo.com">schveigu= y yahoo.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" styl= e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div><div></div><div class=3D"h5">On Tue, 05 Jul 2011 04:31:09 -0400, James= Fisher <<a href=3D"mailto:jameshfisher gmail.com" target=3D"_blank">jam= eshfisher gmail.com</a>> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Hopefully this won't be taken as frivolous. =C2=A0I (and possibly some = of you)<br> have been convinced by the argument at <a href=3D"http://tauday.com/" targe= t=3D"_blank">http://tauday.com/</a>. =C2=A0It's very<br> convincing, and I won't rehash it here.<br> <br> The use of =CF=84 instead of =CF=80 will only become really convenient when= one does<br> not have to preface everything with "let =CF=84 =3D 2=CF=80".<br> <br> For example, in D, in order to think in terms of =CF=84 instead of =CF=80, = one must<br> define `enum real TAU =3D std.math.PI * 2;`, and possibly also TAU_2, TAU_4= ,<br> etc.<br> <br> As well as being a typing inconvenience, I also think things are not that<b= r> easy due to loss of precision (though I'm far from an expert on intrica= cies<br> of floating point).<br> <br> There is an initiative to add TAU to the Python standard library:<br> <a href=3D"http://www.python.org/dev/peps/pep-0628/" target=3D"_blank">http= ://www.python.org/dev/<u></u>peps/pep-0628/</a><br> <br> To this end, I suggest adding the constant TAU to std.math, and possibly<br=

r> <br> In any case, I'd like to know what's necessary in order for me to d= efine<br> these constants without loss of precision.<br> d<br> </blockquote> <br></div></div> I read an article about this recently, it's definitely interesting. =C2= =A0The one place where I haven't seen it mentioned is what happens when= you want the area of a circle, since that necessarily involves the radius.= =C2=A0I'd guess you'd have to use =CF=84/2 * r^2, but even then, t= hat's one formula vs. the rest. =C2=A0It's probably a good tradeoff= . =C2=A0I can definitely see the advantage when using radians. =C2=A0Never = thought I'd have to re-learn trig again...<br> <br> One thing I like about Pi vs Tau is that it cannot be mistaken for a normal= character.<br> <br> I'm not a floating point expert, but I would expect since floating poin= t is stored in binary, dividing or multiplying by 2 loses no precision at a= ll. =C2=A0But I could be wrong...<br></blockquote><div><br></div><div>Sorry= , I didn't state this very clearly. =C2=A0Multiplying the approximation= of PI in std.math should yield the exact double of that approximation, as = it should just involve increasing the exponent by 1. =C2=A0However, [double= the approximation of the constant] is not necessarily equal to [the approx= imation of double the constant]. =C2=A0Does that make sense?</div> </div> --90e6ba6e8c0ca9a00704a750d43d--

Jul 05 2011

--90e6ba613b24fe399c04a750e371 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 5, 2011 at 12:31 PM, James Fisher <jameshfisher gmail.com>wrote:Sorry, I didn't state this very clearly. Multiplying the approximation of PI in std.math should yield the exact double of that approximation, as it should just involve increasing the exponent by 1. However, [double the approximation of the constant] is not necessarily equal to [the approximation of double the constant]. Does that make sense?

(I think this is why the constants in math.d<https://github.com/D-Programming-Language/phobos/blob/master/std/math.d#L206>are each defined separately rather than in terms of each other.) --90e6ba613b24fe399c04a750e371 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Tue, Jul 5, 2011 at 12:31 PM, James Fisher <s= pan dir=3D"ltr"><<a href=3D"mailto:jameshfisher gmail.com">jameshfisher = gmail.com</a>></span> wrote:<blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class=3D"gmail_quote"><div>Sorry, I didn't state this very clearly= . =C2=A0Multiplying the approximation of PI in std.math should yield the ex= act double of that approximation, as it should just involve increasing the = exponent by 1. =C2=A0However, [double the approximation of the constant] is= not necessarily equal to [the approximation of double the constant]. =C2= =A0Does that make sense?</div> </div> </blockquote></div><br><div>(I think this is why <a href=3D"https://github.= com/D-Programming-Language/phobos/blob/master/std/math.d#L206">the constant= s in math.d</a> are each defined separately rather than in terms of each ot= her.)</div> --90e6ba613b24fe399c04a750e371--

Jul 05 2011

"James Fisher" <jameshfisher gmail.com> wrote in message news:mailman.1426.1309854678.14074.digitalmars-d puremagic.com...Hopefully this won't be taken as frivolous. I (and possibly some of you) have been convinced by the argument at http://tauday.com/. It's very convincing, and I won't rehash it here.

He had me at "TAU == 2PI" I'm sold.

Jul 05 2011

--bcaec52e6045c0378e04a75680b8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 5, 2011 at 12:15 PM, Steven Schveighoffer <schveiguy yahoo.com>wrote:I read an article about this recently, it's definitely interesting. The one place where I haven't seen it mentioned is what happens when you want the area of a circle, since that necessarily involves the radius. I'd gu=

you'd have to use =CF=84/2 * r^2, but even then, that's one formula vs. t=

It's probably a good tradeoff. I can definitely see the advantage when using radians. Never thought I'd have to re-learn trig again...

It embarasses me to say that, after many years, working with radians and pi still makes my head hurt. "So I have to multiply -- no wait, divide -- no wait, multiply that by 2 ..." --bcaec52e6045c0378e04a75680b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Tue, Jul 5, 2011 at 12:15 PM, Steven Schveigh= offer <span dir=3D"ltr"><<a href=3D"mailto:schveiguy yahoo.com">schveigu= y yahoo.com</a>></span> wrote:<blockquote class=3D"gmail_quote" style=3D= "margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> I read an article about this recently, it's definitely interesting. =C2= =A0The one place where I haven't seen it mentioned is what happens when= you want the area of a circle, since that necessarily involves the radius.= =C2=A0I'd guess you'd have to use =CF=84/2 * r^2, but even then, t= hat's one formula vs. the rest. =C2=A0It's probably a good tradeoff= . =C2=A0I can definitely see the advantage when using radians. =C2=A0Never = thought I'd have to re-learn trig again...<br> </blockquote><div><br></div><div>It embarasses me to say that, after many y= ears, working with radians and pi still makes my head hurt. =C2=A0"So = I have to multiply -- no wait, divide -- no wait, multiply that by 2 ...&qu= ot;</div> </div> --bcaec52e6045c0378e04a75680b8--

Jul 05 2011

--20cf3054a013e3447504a759cee0 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 5, 2011 at 8:49 PM, Don <nospam nospam.com> wrote:James Fisher wrote: On Tue, Jul 5, 2011 at 12:31 PM, James Fisher <jameshfisher gmail.com<mailto:jameshfisher gmail.com**>> wrote: Sorry, I didn't state this very clearly. Multiplying the approximation of PI in std.math should yield the exact double of that approximation, as it should just involve increasing the exponent by 1. However, [double the approximation of the constant] is not necessarily equal to [the approximation of double the constant]. Does that make sense?

I understand what you're getting at, but actually multiplication by powers of 2 is always exact for binary floating point numbers. The reason is that the rounding is based on the values after the lowest bit of the _significand_. The exponent plays no role. Multiplication or division by two doesn't change the significand at all, only the exponent, so if the rounding was correct before, it is still correct after the multiplication. Or to put it another way: PI in binary is a infinitely long string of 1s and zeros. Multiplying it by two only shifts the string left and right, it doesn't change any of the 1s to 0s, etc, so the approximation doesn't change either.

Great explanation, thanks. (I think this is why the constants in math.d <https://github.com/D-**Programming-Language/phobos/**blob/master/std/math.d#L206<https://github.com/D-Programming-Language/phobos/blob/master/std/math.d#L206>> are each defined separately rather than in terms of each other.)

Hmm. I'm not sure why PI_2 and PI_4 are there. They should be defined in terms of PI. Probably should fix that.

Another thing -- why are some constants defined in decimal, others in hex, and one (E) with the long 'L' suffix? And is there a significance to the number of decimal/hexadecimal places -- e.g., is this the minimum places required to ensure the closest floating point value for all common hardware accuracies? --20cf3054a013e3447504a759cee0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Tue, Jul 5, 2011 at 8:49 PM, Don <span dir=3D= "ltr"><<a href=3D"mailto:nospam nospam.com" target=3D"_blank">nospam nos= pam.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D= "margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> James Fisher wrote:<div><br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On Tue, Jul 5, 2011 at 12:31 PM, James Fisher <<a href=3D"mailto:jameshf= isher gmail.com" target=3D"_blank">jameshfisher gmail.com</a> <mailto:<a= href=3D"mailto:jameshfisher gmail.com" target=3D"_blank">jameshfisher gmai= l.com</a><u></u>>> wrote:<br> <br> =C2=A0 =C2=A0Sorry, I didn't state this very clearly. =C2=A0Multiplyin= g the<br> =C2=A0 =C2=A0approximation of PI in std.math should yield the exact double= of<br> =C2=A0 =C2=A0that approximation, as it should just involve increasing the<= br> =C2=A0 =C2=A0exponent by 1. =C2=A0However, [double the approximation of th= e constant]<br> =C2=A0 =C2=A0is not necessarily equal to [the approximation of double the<= br> =C2=A0 =C2=A0constant]. =C2=A0Does that make sense?<br> </blockquote> <br></div> I understand what you're getting at, but actually multiplication by pow= ers of 2 is always exact for binary floating point numbers.<br> The reason is that the rounding is based on the values after the lowest bit= of the _significand_. The exponent plays no role.<br> Multiplication or division by two doesn't change the significand at all= , only the exponent, so if the rounding was correct before, it is still cor= rect after the multiplication.<br> <br> Or to put it another way: PI in binary is a infinitely long string of 1s an= d zeros. Multiplying it by two only shifts the string left and right, it do= esn't change any of the 1s to 0s, etc, so the approximation doesn't= change either.<br> </blockquote><div><br></div><div>Great explanation, thanks.</div><div><br><= /div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le= ft:1px #ccc solid;padding-left:1ex"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> (I think this is why the constants in math.d <<a href=3D"https://github.= com/D-Programming-Language/phobos/blob/master/std/math.d#L206" target=3D"_b= lank">https://github.com/D-<u></u>Programming-Language/phobos/<u></u>blob/m= aster/std/math.d#L206</a>> are each defined separately rather than in te= rms of each other.)<br> </blockquote> <br> Hmm. I'm not sure why PI_2 and PI_4 are there. They should be defined i= n terms of PI. Probably should fix that.<br> </blockquote></div><br><div>Another thing -- why are some constants defined= in decimal, others in hex, and one (E) with the=C2=A0long=C2=A0'L'= suffix? =C2=A0And is there a significance to the number of decimal/hexadec= imal places -- e.g., is this the minimum places required to ensure the clos= est floating point value for all common hardware accuracies?</div> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8"> --20cf3054a013e3447504a759cee0--

Jul 05 2011