www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - add phobos module std.halffloat ?

reply Walter Bright <newshound2 digitalmars.com> writes:
https://github.com/D-Programming-Language/phobos/pull/1018/files
Dec 18 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-12-19 08:30, Walter Bright wrote:

 https://github.com/D-Programming-Language/phobos/pull/1018/files


Cool, Walter does a pull request. Should this be put in the review queue 
or is this a small enough change to be added anyway?

-- 
/Jacob Carlborg
Dec 18 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 19-12-2012 08:35, Jacob Carlborg wrote:

 On 2012-12-19 08:30, Walter Bright wrote:

 https://github.com/D-Programming-Language/phobos/pull/1018/files


 Cool, Walter does a pull request. Should this be put in the review queue
 or is this a small enough change to be added anyway?


Seems a bit overkill to throw it in the review queue, but I don't know 
how rigorous we want to be about that.

-- 
Alex Rønne Petersen
alex alexrp.com / alex lycus.org
http://lycus.org
Dec 19 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/19/2012 12:47 AM, Alex Rønne Petersen wrote:

 On 19-12-2012 08:35, Jacob Carlborg wrote:

 On 2012-12-19 08:30, Walter Bright wrote:

 https://github.com/D-Programming-Language/phobos/pull/1018/files


 Cool, Walter does a pull request. Should this be put in the review queue
 or is this a small enough change to be added anyway?


 Seems a bit overkill to throw it in the review queue, but I don't know how
 rigorous we want to be about that.


Probably the main point of this module is to demonstrate how to do new 
arithmetic types like this without needing compiler support. It also shows how 
to do IEEE floating point rounding correctly, which is not obvious and not
trivial.

This particular type is a standard type and crops up in graphics code, so there 
is a use for it.
Dec 19 2012
next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 19 December 2012 08:55, Walter Bright <newshound2 digitalmars.com> wrote=
:


 On 12/19/2012 12:47 AM, Alex R=F8nne Petersen wrote:


 On 19-12-2012 08:35, Jacob Carlborg wrote:


 On 2012-12-19 08:30, Walter Bright wrote:


 https://github.com/D-**Programming-Language/phobos/**pull/1018/files<h=








ttps://github.com/D-Programming-Language/phobos/pull/1018/files>


 Cool, Walter does a pull request. Should this be put in the review queu=






e

 or is this a small enough change to be added anyway?


 Seems a bit overkill to throw it in the review queue, but I don't know h=




ow

 rigorous we want to be about that.


 Probably the main point of this module is to demonstrate how to do new
 arithmetic types like this without needing compiler support. It also show=


s

 how to do IEEE floating point rounding correctly, which is not obvious an=


d

 not trivial.


How difficult would you think it would be to scale down (or up) this
library type so it can be an emulated IEEE type of any size? (The whole
shebang eg: quarter, half, single, double, quad, double-quad, 80bit and
96-bit).   Just interested as I think that a module which implements an
IEEE floating point type that produces constant results cross-platform
would be better than a dedicated module just for half float types.


--=20
Iain Buclaw

*(p < e ? p++ : p) =3D (c & 0x0f) + '0';



 Dec 19 2012



 next sibling parent reply "tn" <no email.com>  writes:


On Wednesday, 19 December 2012 at 10:13:56 UTC, Iain Buclaw wrote:

 On 19 December 2012 08:55, Walter Bright 
 <newshound2 digitalmars.com> wrote:


 On 12/19/2012 12:47 AM, Alex Rønne Petersen wrote:


 On 19-12-2012 08:35, Jacob Carlborg wrote:


 On 2012-12-19 08:30, Walter Bright wrote:


 https://github.com/D-**Programming-Language/phobos/**pull/1018/files<https://github.com/D-Programming-Language/phobos/pull/1018/files>


 Cool, Walter does a pull request. Should this be put in the 
 review queue
 or is this a small enough change to be added anyway?


 Seems a bit overkill to throw it in the review queue, but I 
 don't know how
 rigorous we want to be about that.


 Probably the main point of this module is to demonstrate how 
 to do new
 arithmetic types like this without needing compiler support. 
 It also shows
 how to do IEEE floating point rounding correctly, which is not 
 obvious and
 not trivial.


 How difficult would you think it would be to scale down (or up) 
 this
 library type so it can be an emulated IEEE type of any size? 
 (The whole
 shebang eg: quarter, half, single, double, quad, double-quad, 
 80bit and
 96-bit).   Just interested as I think that a module which 
 implements an
 IEEE floating point type that produces constant results 
 cross-platform
 would be better than a dedicated module just for half float 
 types.


What is the difference between std.numeric.CustomFloat and this?



 Dec 19 2012



  parent reply Iain Buclaw <ibuclaw ubuntu.com>  writes:


On 19 December 2012 11:30, tn <no email.com> wrote:


 On Wednesday, 19 December 2012 at 10:13:56 UTC, Iain Buclaw wrote:


 On 19 December 2012 08:55, Walter Bright <newshound2 digitalmars.com>
 wrote:

  On 12/19/2012 12:47 AM, Alex R=F8nne Petersen wrote:

  On 19-12-2012 08:35, Jacob Carlborg wrote:

  On 2012-12-19 08:30, Walter Bright wrote:

  https://github.com/D-****Programming-Language/phobos/****

 pull/1018/files<https://github.com/D-**Programming-Language/phobos/*=












*pull/1018/files>

 <https://**github.com/D-Programming-**Language/phobos/pull/1018/**
 files<https://github.com/D-Programming-Language/phobos/pull/1018/fil=












es>




 Cool, Walter does a pull request. Should this be put in the review
 queue
 or is this a small enough change to be added anyway?


  Seems a bit overkill to throw it in the review queue, but I don't


 know how
 rigorous we want to be about that.


 Probably the main point of this module is to demonstrate how to do new
 arithmetic types like this without needing compiler support. It also
 shows
 how to do IEEE floating point rounding correctly, which is not obvious
 and
 not trivial.


  How difficult would you think it would be to scale down (or up) this


 library type so it can be an emulated IEEE type of any size? (The whole
 shebang eg: quarter, half, single, double, quad, double-quad, 80bit and
 96-bit).   Just interested as I think that a module which implements an
 IEEE floating point type that produces constant results cross-platform
 would be better than a dedicated module just for half float types.


 What is the difference between std.numeric.CustomFloat and this?


With this, there's a choice of rounding modes,  casting between float and
integral types,  and the fact that not many people know about it?

--=20
Iain Buclaw

*(p < e ? p++ : p) =3D (c & 0x0f) + '0';



 Dec 19 2012



  parent  "Robert Jacques" <rjacque2 live.johnshopkins.edu>  writes:


On Wed, 19 Dec 2012 05:47:38 -0600, Iain Buclaw <ibuclaw ubuntu.com> wro=
te:

 On 19 December 2012 11:30, tn <no email.com> wrote:

 On Wednesday, 19 December 2012 at 10:13:56 UTC, Iain Buclaw wrote:

 On 19 December 2012 08:55, Walter Bright <newshound2 digitalmars.com=





 wrote:
  On 12/19/2012 12:47 AM, Alex R=F8nne Petersen wrote:

  On 19-12-2012 08:35, Jacob Carlborg wrote:

  On 2012-12-19 08:30, Walter Bright wrote:










[snip]


 What is the difference between std.numeric.CustomFloat and this?


 With this, there's a choice of rounding modes,  casting between float =


and

 integral types,  and the fact that not many people know about it?


*Ahem* That should be possible future support for rounding modes.  =

Currently, the code paths exist but are restricted to ROUND.TONEAREST. I=
'm  =

not sure why this is given std.math.FloatingPointControl.rounding.



 Dec 19 2012



prev sibling  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 12/19/2012 2:13 AM, Iain Buclaw wrote:

 How difficult would you think it would be to scale down (or up) this library
 type so it can be an emulated IEEE type of any size? (The whole shebang eg:
 quarter, half, single, double, quad, double-quad, 80bit and 96-bit).   Just
 interested as I think that a module which implements an IEEE floating point
type
 that produces constant results cross-platform would be better than a dedicated
 module just for half float types.


You'd have to add support for add, sub, mul, div, and compare. The halffloat 
only does conversions.

Other than that, the algorithm used is quite extendible to other IEEE types.



 Dec 19 2012



prev sibling  parent reply d coder <dlang.coder gmail.com>  writes:


On Wed, Dec 19, 2012 at 3:43 PM, Iain Buclaw <ibuclaw ubuntu.com> wrote:


 How difficult would you think it would be to scale down (or up) this
 library type so it can be an emulated IEEE type of any size? (The whole
 shebang eg: quarter, half, single, double, quad, double-quad, 80bit and
 96-bit).   Just interested as I think that a module which implements an
 IEEE floating point type that produces constant results cross-platform
 would be better than a dedicated module just for half float types.



+1



 Dec 19 2012



  parent reply "Robert Jacques" <rjacque2 live.johnshopkins.edu>  writes:


On Wed, 19 Dec 2012 04:49:59 -0600, d coder <dlang.coder gmail.com> wrote:


 On Wed, Dec 19, 2012 at 3:43 PM, Iain Buclaw <ibuclaw ubuntu.com> wrote:


 How difficult would you think it would be to scale down (or up) this
 library type so it can be an emulated IEEE type of any size? (The whole
 shebang eg: quarter, half, single, double, quad, double-quad, 80bit and
 96-bit).   Just interested as I think that a module which implements an
 IEEE floating point type that produces constant results cross-platform
 would be better than a dedicated module just for half float types.



 +1


See std.numeric.CustomFloat. It supports quarter, half, single, double and  
80-bit. The wikipedia article on the  floating point (IEEE 754) includes a  
Quad type but not a double-quad or 96-bit type. 96-bit Should be possible,  
as it's just 80-bits with padding. Quad and double quad would be tougher  
to do, do to the lack of a quad integer type or a 112-bit bit shift  
operator.



 Dec 19 2012



  parent reply "Rob T" <rob ucora.com>  writes:


On Wednesday, 19 December 2012 at 20:44:19 UTC, Robert Jacques 
wrote:

 See std.numeric.CustomFloat. It supports quarter, half, single, 
 double and 80-bit. The wikipedia article on the  floating point 
 (IEEE 754) includes a Quad type but not a double-quad or 96-bit 
 type. 96-bit Should be possible, as it's just 80-bits with 
 padding. Quad and double quad would be tougher to do, do to the 
 lack of a quad integer type or a 112-bit bit shift operator.


I did not see anything in the reference docs to indicate 
consistency across platform. Do these produce constant results 
cross-platform? Actually do any of the basic floating point types 
do this (Real excluded)?

--rt



 Dec 19 2012



  parent  "Robert Jacques" <rjacque2 live.johnshopkins.edu>  writes:


On Thu, 20 Dec 2012 00:06:04 -0600, Rob T <rob ucora.com> wrote:


 On Wednesday, 19 December 2012 at 20:44:19 UTC, Robert Jacques wrote:

 See std.numeric.CustomFloat. It supports quarter, half, single, double  
 and 80-bit. The wikipedia article on the  floating point (IEEE 754)  
 includes a Quad type but not a double-quad or 96-bit type. 96-bit  
 Should be possible, as it's just 80-bits with padding. Quad and double  
 quad would be tougher to do, do to the lack of a quad integer type or a  
 112-bit bit shift operator.


 I did not see anything in the reference docs to indicate consistency  
 across platform. Do these produce constant results cross-platform?  
 Actually do any of the basic floating point types do this (Real  
 excluded)?

 --rt


CustomFloat is for storage purposes only. All operations are prefixed by  
converting the custom float to real first, which is what x86 does  
internally. This is in the Ddoc comments in the code, but because  
CustomFloat is a template, they don't appear in the html docs. As for  
consistent results, you do get a consistent storage size, which you don't  
get with real, but aside from that, IEEE only specifies a minimum accuracy  
for each operation. Combined with truncation issues, this means that  
results will very from platform to platform and from compiler to compiler.  
There is nothing new about this. In fact, x86 is more precise than x86-64  
due to the switch from the x87 to SSE for floats/doubles.



 Dec 19 2012



prev sibling next sibling parent reply "ponce" <spam spam.org>  writes:


On Wednesday, 19 December 2012 at 07:30:54 UTC, Walter Bright
wrote:

 https://github.com/D-Programming-Language/phobos/pull/1018/files



If that ever helps, I implemented this fast conversion
ftp://www.fox-toolkit.org/pub/fasthalffloatconversion.pdf for a
half wrapper here:
https://github.com/p0nce/gfm/blob/master/math/half.d
It's woefully untested though.

In 3D graphics efficiently converting float to half can speed up
vertex submission.



 Dec 19 2012



 next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 12/19/2012 2:22 AM, ponce wrote:

 On Wednesday, 19 December 2012 at 07:30:54 UTC, Walter Bright
 wrote:

 https://github.com/D-Programming-Language/phobos/pull/1018/files



 If that ever helps, I implemented this fast conversion
 ftp://www.fox-toolkit.org/pub/fasthalffloatconversion.pdf for a
 half wrapper here:
 https://github.com/p0nce/gfm/blob/master/math/half.d
 It's woefully untested though.

 In 3D graphics efficiently converting float to half can speed up
 vertex submission.


The pdf file shows as corrupted.



 Dec 19 2012



 next sibling parent  "Robert Jacques" <rjacque2 live.johnshopkins.edu>  writes:


On Wed, 19 Dec 2012 13:48:29 -0600, Walter Bright  
<newshound2 digitalmars.com> wrote:


 On 12/19/2012 2:22 AM, ponce wrote:

 On Wednesday, 19 December 2012 at 07:30:54 UTC, Walter Bright
 wrote:

 https://github.com/D-Programming-Language/phobos/pull/1018/files



 If that ever helps, I implemented this fast conversion
 ftp://www.fox-toolkit.org/pub/fasthalffloatconversion.pdf for a
 half wrapper here:
 https://github.com/p0nce/gfm/blob/master/math/half.d
 It's woefully untested though.

 In 3D graphics efficiently converting float to half can speed up
 vertex submission.


 The pdf file shows as corrupted.


It opens fine for me. (Win7/Adobe Reader 10.0.1)



 Dec 19 2012



prev sibling  parent reply =?UTF-8?B?TWFydGluIERyYcWhYXI=?= <drasar ics.muni.cz>  writes:


Dne 19.12.2012 20:48, Walter Bright napsal(a):

 On 12/19/2012 2:22 AM, ponce wrote:

 On Wednesday, 19 December 2012 at 07:30:54 UTC, Walter Bright
 wrote:

 https://github.com/D-Programming-Language/phobos/pull/1018/files



 If that ever helps, I implemented this fast conversion
 ftp://www.fox-toolkit.org/pub/fasthalffloatconversion.pdf for a
 half wrapper here:
 https://github.com/p0nce/gfm/blob/master/math/half.d
 It's woefully untested though.

 In 3D graphics efficiently converting float to half can speed up
 vertex submission.


 The pdf file shows as corrupted.


Happened to me as well when I clicked on the link. It worked fine after 
copy+pasting the link into the browser.

Also it did not work when I tried it in two different browsers. I have 
temporary uploaded correctly working pdf version here: 
http://mysharegadget.com/528634723

Martin



 Dec 19 2012



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 12/19/2012 12:28 PM, Martin Drašar wrote:

 Also it did not work when I tried it in two different browsers. I have
temporary
 uploaded correctly working pdf version here: http://mysharegadget.com/528634723


Thanks, that worked.



 Dec 19 2012



prev sibling  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 12/19/2012 2:22 AM, ponce wrote:

 On Wednesday, 19 December 2012 at 07:30:54 UTC, Walter Bright
 wrote:

 https://github.com/D-Programming-Language/phobos/pull/1018/files



 If that ever helps, I implemented this fast conversion
 ftp://www.fox-toolkit.org/pub/fasthalffloatconversion.pdf for a
 half wrapper here:
 https://github.com/p0nce/gfm/blob/master/math/half.d
 It's woefully untested though.

 In 3D graphics efficiently converting float to half can speed up
 vertex submission.


Thanks, I read the paper. It looks interesting. I did notice, however, that it 
does not appear to do IEEE rounding correctly (unless I misunderstood the
code), 
nor does it have any hooks for detection of Inexact, Underflow and Overflow.

These come into play when converting a float to a half.



 Dec 19 2012



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 12/19/12 2:30 AM, Walter Bright wrote:

 https://github.com/D-Programming-Language/phobos/pull/1018/files


Shouldn't it be part of std.numeric?

Related, we should have a decision point "this must go through the 
review process" vs. "the pull review process is sufficient". New modules 
definitely must go through the review process, as should large additions 
to existing models.


Andrei



 Dec 19 2012



  parent reply "Robert Jacques" <rjacque2 live.johnshopkins.edu>  writes:


On Wed, 19 Dec 2012 09:35:39 -0600, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 On 12/19/12 2:30 AM, Walter Bright wrote:

 https://github.com/D-Programming-Language/phobos/pull/1018/files


 Shouldn't it be part of std.numeric?

 Related, we should have a decision point "this must go through the  
 review process" vs. "the pull review process is sufficient". New modules  
 definitely must go through the review process, as should large additions  
 to existing models.


 Andrei


It _IS_ part of std.numeric! Specifically std.numeric.CustomFloat!16; To  
quote our own documentation:

// Define a 16-bit floating point values
  CustomFloat!16                                x;     // Using the number  
of bits
  CustomFloat!(10, 5)                           y;     // Using the  
precision and exponent width
  CustomFloat!(10, 5,CustomFloatFlags.ieee)     z;     // Using the  
precision, exponent width and format flags
  CustomFloat!(10, 5,CustomFloatFlags.ieee, 15) w;     // Using the  
precision, exponent width, format flags and exponent offset bias

  // Use the 16-bit floats mostly like normal numbers
  w = x*y - 1;
  writeln(w);

  // Functions calls require conversion
  z = sin(+x)           + cos(+y);                     // Use uniary plus  
to concisely convert to a real
  z = sin(x.re)         + cos(y.re);                   // Or use the .re  
property to convert to a real
  z = sin(x.get!float)  + cos(y.get!float);            // Or use get!T
  z = sin(cast(float)x) + cos(cast(float)y);           // Or use cast(T) to  
explicitly convert

-------------------
The only item missing from std.numeric.CustomFloat is to add an alias this  
line so that implicit conversion is supported. Oh, and documentation of  
the standard float properties, such as infinity/min/min/etc, which exist  
in the code, but are template methods and so don't appear in the ddoc.



 Dec 19 2012



  parent  "tn" <no email.com>  writes:


On Wednesday, 19 December 2012 at 19:52:41 UTC, Robert Jacques 
wrote:

 On Wed, 19 Dec 2012 09:35:39 -0600, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:


 On 12/19/12 2:30 AM, Walter Bright wrote:

 https://github.com/D-Programming-Language/phobos/pull/1018/files


 Shouldn't it be part of std.numeric?

 Related, we should have a decision point "this must go through 
 the review process" vs. "the pull review process is 
 sufficient". New modules definitely must go through the review 
 process, as should large additions to existing models.


 Andrei


 It _IS_ part of std.numeric!


Why is it in std.numeric anyway? I would expect std.numeric to 
contain numerical algorithms, not something like this.

Suggestion: Combine HalfFloat with CustomFloat and move the 
result in a separate module, say std.float. Also move there 
IeeeFlags, FloatingPointControl, NaN, getNaNPayload, nextUp, 
nextDown, nextafter and related things. Those have nothing to do 
with math. Possibly also isNaN, isFinite, isNormal, isSubnormal 
and isInfinity.



 Dec 21 2012