Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #125446 > unrolled thread

What happened to short float?

Back to article view | Back to comp.lang.c

Contents

  What happened to short float? Philipp Klaus Krause <pkk@spth.de> - 2018-01-17 17:21 +0100
    Re: What happened to short float? "James R. Kuyper" <jameskuyper@verizon.net> - 2018-01-17 11:42 -0500
      Re: What happened to short float? jacobnavia <jacob@jacob.remcomp.fr> - 2018-02-02 23:08 +0100
        Re: What happened to short float? Jakob Bohm <jb-usenet@wisemo.com> - 2018-02-05 07:57 +0100
          Re: What happened to short float? jameskuyper@verizon.net - 2018-02-05 05:31 -0800
        Re: What happened to short float? Tim Prince <tprince@intelretiree.com> - 2018-02-05 08:55 -0500
          Re: What happened to short float? jacobnavia <jacob@jacob.remcomp.fr> - 2018-02-05 15:46 +0100
          Re: What happened to short float? GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-08 01:29 +0100
            Re: What happened to short float? Keith Thompson <kst-u@mib.org> - 2018-02-07 16:59 -0800
              Re: What happened to short float? Philipp Klaus Krause <pkk@spth.de> - 2018-02-08 09:08 +0100
                Re: What happened to short float? Keith Thompson <kst-u@mib.org> - 2018-02-08 09:27 -0800
              Re: What happened to short float? GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-08 09:54 +0100
                Re: What happened to short float? Keith Thompson <kst-u@mib.org> - 2018-02-08 10:13 -0800
              Re: What happened to short float? jameskuyper@verizon.net - 2018-02-08 06:36 -0800
                Re: What happened to short float? GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-08 17:04 +0100
                  Re: What happened to short float? jameskuyper@verizon.net - 2018-02-08 08:56 -0800
                    Re: What happened to short float? scott@slp53.sl.home (Scott Lurndal) - 2018-02-08 17:23 +0000
                    Re: What happened to short float? GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-08 18:52 +0100
                      Re: What happened to short float? jameskuyper@verizon.net - 2018-02-08 11:27 -0800
                        Re: What happened to short float? GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-08 22:58 +0100
                Re: What happened to short float? Keith Thompson <kst-u@mib.org> - 2018-02-08 10:18 -0800
            Re: What happened to short float? Jakob Bohm <jb-usenet@wisemo.com> - 2018-02-08 18:59 +0100
              Re: What happened to short float? Robert Wessel <robertwessel2@yahoo.com> - 2018-02-08 16:22 -0600
                Re: What happened to short float? Jakob Bohm <jb-usenet@wisemo.com> - 2018-02-09 15:01 +0100
    Re: What happened to short float? Chad <cdalten@gmail.com> - 2018-01-17 09:12 -0800
    Re: What happened to short float? scott@slp53.sl.home (Scott Lurndal) - 2018-01-17 17:31 +0000
    Re: What happened to short float? jacobnavia <jacob@jacob.remcomp.fr> - 2018-01-17 19:52 +0100
      Re: What happened to short float? Philipp Klaus Krause <pkk@spth.de> - 2018-01-18 13:18 +0100
        Re: What happened to short float? bartc <bc@freeuk.com> - 2018-01-18 12:40 +0000

Page 1 of 2  [1] 2  Next page →

#125446 — What happened to short float?

At the 2016 London meeting of WG14, adding a new short float type
(N2016) was discussed, and there was a clear consensus to move forward.

What has happened about short float since?

Philipp

[toc] | [next] | [standalone]

#125447

On 01/17/2018 11:21 AM, Philipp Klaus Krause wrote:
> At the 2016 London meeting of WG14, adding a new short float type
> (N2016) was discussed, and there was a clear consensus to move forward.
> 
> What has happened about short float since?

I don't know the answer, but I've cross-posted this message to 
comp.std.c, since that's a more appropriate place for this question.

[toc] | [prev] | [next] | [standalone]

#126197

Le 17/01/2018 à 17:42, James R. Kuyper a écrit :
> On 01/17/2018 11:21 AM, Philipp Klaus Krause wrote:
>> At the 2016 London meeting of WG14, adding a new short float type
>> (N2016) was discussed, and there was a clear consensus to move forward.
>>
>> What has happened about short float since?
> 
> I don't know the answer, but I've cross-posted this message to 
> comp.std.c, since that's a more appropriate place for this question.

Wow!
What an ovewhelming feedback!
After three weeks there is only silence...

[toc] | [prev] | [next] | [standalone]

#126286

On 02/02/2018 23:08, jacobnavia wrote:
> Le 17/01/2018 à 17:42, James R. Kuyper a écrit :
>> On 01/17/2018 11:21 AM, Philipp Klaus Krause wrote:
>>> At the 2016 London meeting of WG14, adding a new short float type
>>> (N2016) was discussed, and there was a clear consensus to move forward.
>>>
>>> What has happened about short float since?
>>
>> I don't know the answer, but I've cross-posted this message to 
>> comp.std.c, since that's a more appropriate place for this question.
> 
> Wow!
> What an ovewhelming feedback!
> After three weeks there is only silence...

The newsgroup has been embroiled in a flamewar over other topics, so
noone sufficiently knowledgeable about this particular question has had
the time (and I don't have that information myself).

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[toc] | [prev] | [next] | [standalone]

#126290

On Monday, February 5, 2018 at 1:57:19 AM UTC-5, Jakob Bohm wrote:
> On 02/02/2018 23:08, jacobnavia wrote:
> > Le 17/01/2018 à 17:42, James R. Kuyper a écrit :
> >> On 01/17/2018 11:21 AM, Philipp Klaus Krause wrote:
> >>> At the 2016 London meeting of WG14, adding a new short float type
> >>> (N2016) was discussed, and there was a clear consensus to move forward.
> >>>
> >>> What has happened about short float since?
> >>
> >> I don't know the answer, but I've cross-posted this message to 
> >> comp.std.c, since that's a more appropriate place for this question.
> > 
> > Wow!
> > What an ovewhelming feedback!
> > After three weeks there is only silence...
> 
> The newsgroup has been embroiled in a flamewar over other topics, so
> noone sufficiently knowledgeable about this particular question has had
> the time (and I don't have that information myself).

In my experience, flame wars tend not to distract knowledgeable users
from answering questions they can easily answer that have nothing to do
with the flame war. Rather, answering such questions provides some
welcome relief from the stress of the war. I'm afraid that the simple
reason why there's been no answer is simply that no one who knows the
answer is monitoring either of these newsgroups.

[toc] | [prev] | [next] | [standalone]

#126292

On 2/2/2018 5:08 PM, jacobnavia wrote:
> Le 17/01/2018 à 17:42, James R. Kuyper a écrit :
>> On 01/17/2018 11:21 AM, Philipp Klaus Krause wrote:
>>> At the 2016 London meeting of WG14, adding a new short float type
>>> (N2016) was discussed, and there was a clear consensus to move forward.
>>>
>>> What has happened about short float since?
>>
>> I don't know the answer, but I've cross-posted this message to
>> comp.std.c, since that's a more appropriate place for this question.
> 
> Wow!
> What an ovewhelming feedback!
> After three weeks there is only silence...
Perhaps there is little more to say.  The format has little attraction
for portable code, as many platforms can't implement it efficiently.

-- 
Tim Prince

[toc] | [prev] | [next] | [standalone]

#126294

Le 05/02/2018 à 14:55, Tim Prince a écrit :
> On 2/2/2018 5:08 PM, jacobnavia wrote:
>> Le 17/01/2018 à 17:42, James R. Kuyper a écrit :
>>> On 01/17/2018 11:21 AM, Philipp Klaus Krause wrote:
>>>> At the 2016 London meeting of WG14, adding a new short float type
>>>> (N2016) was discussed, and there was a clear consensus to move forward.
>>>>
>>>> What has happened about short float since?
>>>
>>> I don't know the answer, but I've cross-posted this message to
>>> comp.std.c, since that's a more appropriate place for this question.
>>
>> Wow!
>> What an ovewhelming feedback!
>> After three weeks there is only silence...
> Perhaps there is little more to say.  The format has little attraction
> for portable code, as many platforms can't implement it efficiently.
> 

This format is supported by the CPU that runs most phones in the world: 
ARM, and also by most GPUs (Nvidia, etc)

[toc] | [prev] | [next] | [standalone]

#126394

On Mon, 5 Feb 2018 08:55:00 -0500
Tim Prince <tprince@intelretiree.com> wrote:

> On 2/2/2018 5:08 PM, jacobnavia wrote:
> Perhaps there is little more to say.  The format has little attraction
> for portable code, as many platforms can't implement it efficiently.
> 
> -- 
> Tim Prince

Any IEEE 754 compliant hardware that supports the float type (aka single
precision float) would be able to support the short float type (i.e.
less or equal to single precision float).

Actually the AMD64 architecture FPU only computes 80-bit floats and
the long double type is a synonym for the double or float types since
they are internally the same thing.

The short float type implementation shouldn't be as hard as:

typedef float sflt_t;

Once more, the F16C instruction set enables to convert single precision
floats to half precision floats for storage purpose. Thus, the
implementation shouldn't be as hard as:

typedef char half_t[2];
typedef half_t sflt_t;

-- 
GOTHIER Nathan

[toc] | [prev] | [next] | [standalone]

#126400

GOTHIER Nathan <nathan.gothier@gmail.com> writes:
> On Mon, 5 Feb 2018 08:55:00 -0500
> Tim Prince <tprince@intelretiree.com> wrote:
>> On 2/2/2018 5:08 PM, jacobnavia wrote:
>> Perhaps there is little more to say.  The format has little attraction
>> for portable code, as many platforms can't implement it efficiently.
>
> Any IEEE 754 compliant hardware that supports the float type (aka single
> precision float) would be able to support the short float type (i.e.
> less or equal to single precision float).

Wouldn't you need extra code to convert between 16-bit and 32-bit
formats?  For normal values you'd need to do some bit-twiddling.
Special values like infinities, NaNs, subnormals, and so forth might
require some extra work (I haven't looked into the details).

> Actually the AMD64 architecture FPU only computes 80-bit floats and
> the long double type is a synonym for the double or float types since
> they are internally the same thing.
>
> The short float type implementation shouldn't be as hard as:
>
> typedef float sflt_t;
>
> Once more, the F16C instruction set enables to convert single precision
> floats to half precision floats for storage purpose. Thus, the
> implementation shouldn't be as hard as:
>
> typedef char half_t[2];

(I'd use uint16_t, or at least unsigned char[2] rather than char[2].)

> typedef half_t sflt_t;

Sure, if you have a CPU instruction that does the conversion, it's easy.

If you don't, it's not prohitively difficult, but it's not quite as
obvious that it's worth the effort.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#126420

Am 08.02.2018 um 01:59 schrieb Keith Thompson:
> GOTHIER Nathan <nathan.gothier@gmail.com> writes:
>> On Mon, 5 Feb 2018 08:55:00 -0500
>> Tim Prince <tprince@intelretiree.com> wrote:
>>> On 2/2/2018 5:08 PM, jacobnavia wrote:
>>> Perhaps there is little more to say.  The format has little attraction
>>> for portable code, as many platforms can't implement it efficiently.
>>
>> Any IEEE 754 compliant hardware that supports the float type (aka single
>> precision float) would be able to support the short float type (i.e.
>> less or equal to single precision float).
> 
> Wouldn't you need extra code to convert between 16-bit and 32-bit
> formats?  For normal values you'd need to do some bit-twiddling.
> Special values like infinities, NaNs, subnormals, and so forth might
> require some extra work (I haven't looked into the details).

If your system can't do 16-bit floats efficiently, why not just make
them 32 bits?

Philipp

[toc] | [prev] | [next] | [standalone]

#126444

Philipp Klaus Krause <pkk@spth.de> writes:
> Am 08.02.2018 um 01:59 schrieb Keith Thompson:
>> GOTHIER Nathan <nathan.gothier@gmail.com> writes:
>>> On Mon, 5 Feb 2018 08:55:00 -0500
>>> Tim Prince <tprince@intelretiree.com> wrote:
>>>> On 2/2/2018 5:08 PM, jacobnavia wrote:
>>>> Perhaps there is little more to say.  The format has little attraction
>>>> for portable code, as many platforms can't implement it efficiently.
>>>
>>> Any IEEE 754 compliant hardware that supports the float type (aka single
>>> precision float) would be able to support the short float type (i.e.
>>> less or equal to single precision float).
>> 
>> Wouldn't you need extra code to convert between 16-bit and 32-bit
>> formats?  For normal values you'd need to do some bit-twiddling.
>> Special values like infinities, NaNs, subnormals, and so forth might
>> require some extra work (I haven't looked into the details).
>
> If your system can't do 16-bit floats efficiently, why not just make
> them 32 bits?

Good point, I hadn't thought of that.  N2016 even mentioned that
possibility.  (Similarly, it's possible for float, double, and even
long double all to have the same representation.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#126422

On Wed, 07 Feb 2018 16:59:53 -0800
Keith Thompson <kst-u@mib.org> wrote:

> Wouldn't you need extra code to convert between 16-bit and 32-bit
> formats?  For normal values you'd need to do some bit-twiddling.
> Special values like infinities, NaNs, subnormals, and so forth might
> require some extra work (I haven't looked into the details).

No. Supporting the short float type for computing purpose doesn't mean
you have to implement the half floating point format.

Since the IEEE 754 standard requires only the implementation of the
single precision float format, any compliant hardware could implement
the short float type as a single precision float. Hardware with a full
specific half float support could provide more performance.


> > typedef char half_t[2];
> 
> (I'd use uint16_t, or at least unsigned char[2] rather than char[2].)

I agree, the object should be stored at least as unsigned char[2].


> Sure, if you have a CPU instruction that does the conversion, it's
> easy.

Not really. The F16C instruction set for example only provides the
conversion to half precision float but not the arithmetic.
Consequently, the implementation should distinguish the storage format
from the computing format such as:

typedef unsigned char half_t[2];
typedef float sflt_t;

sflt_t *htosf(half_t *x);
half_t *sftoh(sflt_t *x);

 
> If you don't, it's not prohitively difficult, but it's not quite as
> obvious that it's worth the effort.

As already said, there's no need to implement the half precision
format. The short float type should only provide hardware acceleration
when available.


-- 
GOTHIER Nathan

[toc] | [prev] | [next] | [standalone]

#126448

GOTHIER Nathan <nathan.gothier@gmail.com> writes:
> On Wed, 07 Feb 2018 16:59:53 -0800
> Keith Thompson <kst-u@mib.org> wrote:
>> Wouldn't you need extra code to convert between 16-bit and 32-bit
>> formats?  For normal values you'd need to do some bit-twiddling.
>> Special values like infinities, NaNs, subnormals, and so forth might
>> require some extra work (I haven't looked into the details).
>
> No. Supporting the short float type for computing purpose doesn't mean
> you have to implement the half floating point format.
>
> Since the IEEE 754 standard requires only the implementation of the
> single precision float format, any compliant hardware could implement
> the short float type as a single precision float. Hardware with a full
> specific half float support could provide more performance.
>
>> > typedef char half_t[2];
>> 
>> (I'd use uint16_t, or at least unsigned char[2] rather than char[2].)
>
> I agree, the object should be stored at least as unsigned char[2].

If a compiler supports short float as a 16-bit type, it's going to be a
distinct type.  I don't see the point of a typedef.  A short float would
be stored in 16 bits; it would not be an array of unsigned char any more
than short int is.

>> Sure, if you have a CPU instruction that does the conversion, it's
>> easy.
>
> Not really. The F16C instruction set for example only provides the
> conversion to half precision float but not the arithmetic.

If there are CPU instructions for arithmetic on 32-bit floating-point
but not for 16-bit floating-point, then arithmetic on 16-bit short
float would be performed by converting to 32-bit float, performing
the operation, and then converting back to 16-bit short float.
The same can be done with float and double, depending on what the
hardware directly supports.

> Consequently, the implementation should distinguish the storage format
> from the computing format such as:
>
> typedef unsigned char half_t[2];
> typedef float sflt_t;
>
> sflt_t *htosf(half_t *x);
> half_t *sftoh(sflt_t *x);

The standard already permits floating-point operations to be done using
a wider type.  This would be no different.

>> If you don't, it's not prohitively difficult, but it's not quite as
>> obvious that it's worth the effort.
>
> As already said, there's no need to implement the half precision
> format. The short float type should only provide hardware acceleration
> when available.

I don't understand the scenario you're suggesting.  How could the
short float type provide hardware acceleration if the format isn't
implemented?

I see the following possibilities:

1. short float and float are both 32 bits.  Using short float rather
than float doesn't provide any advantage in speed or storage for
the particular platform.

2. short float is 16 bits, float is 32 bits.  The hardware doesn't
provide 16-bit floating-point arithmetic operations.  Arithmetic
operations on short float values are performed by converting to a
wider floating-point type and back again.

3. short float is 16 bits, float is 32 bits.  The hardware provides
16-bit and 32-bit hardware floating-point arithmetic instructions.
short float arithmetic operates directly on 16-bit values (and,
we hope, is faster than 32-bit arithmetic).

(In response to the question that started this thread, I have no idea
what, if anything, has been done with the proposal.  Since the next
edition of the C standard is several years away, there's probably
no particular urgency.  There could be more information in the WG14
meeting notes, but I haven't checked.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#126437

On Wednesday, February 7, 2018 at 8:00:05 PM UTC-5, Keith Thompson wrote:
> GOTHIER Nathan <nathan.gothier@gmail.com> writes:
> > On Mon, 5 Feb 2018 08:55:00 -0500
> > Tim Prince <tprince@intelretiree.com> wrote:
> >> On 2/2/2018 5:08 PM, jacobnavia wrote:
> >> Perhaps there is little more to say.  The format has little attraction
> >> for portable code, as many platforms can't implement it efficiently.
> >
> > Any IEEE 754 compliant hardware that supports the float type (aka single
> > precision float) would be able to support the short float type (i.e.
> > less or equal to single precision float).
> 
> Wouldn't you need extra code to convert between 16-bit and 32-bit
> formats?  For normal values you'd need to do some bit-twiddling.
> Special values like infinities, NaNs, subnormals, and so forth might
> require some extra work (I haven't looked into the details).

I'd expect that the characteristics of a new short float type would be
specified in the same way as they are for float, double, and long
double. The requirements in 5.2.4.2.2 on the numeric characteristics of
floating point types set either maximum values, or minimum values, or
minimums on the magnitude of the values - so there's nothing preventing
float, for instance, from being an 80-bit floating point type. The same
would therefore also be true of short float. I'd expect at least some
implementations targeting a platform with no hardware support for a
16-bit type to use a 32-bit floating point type for short float.

I've just reviewed the proposal, and it doesn't go into such details.

[toc] | [prev] | [next] | [standalone]

#126440

On Thu, 8 Feb 2018 06:36:44 -0800 (PST)
jameskuyper@verizon.net wrote:

> I'd expect that the characteristics of a new short float type would be
> specified in the same way as they are for float, double, and long
> double. The requirements in 5.2.4.2.2 on the numeric characteristics
> of floating point types set either maximum values, or minimum values,
> or minimums on the magnitude of the values - so there's nothing
> preventing float, for instance, from being an 80-bit floating point
> type. The same would therefore also be true of short float. I'd
> expect at least some implementations targeting a platform with no
> hardware support for a 16-bit type to use a 32-bit floating point
> type for short float.
> 
> I've just reviewed the proposal, and it doesn't go into such details.

IMHO, it could be better to define an half_t type capable of
representing at least an half precision floating point number. It would
be more portable for most implementations.

The analogy of the short float type with the long double type doesn't
work well since the long double type give an alternative to implement a
quad precision floating pointer type with an extended double precision
floating point type. Moreover, the C programming language usually
defines types with minimal magnitude values.

-- 
GOTHIER Nathan

[toc] | [prev] | [next] | [standalone]

#126441

On Thursday, February 8, 2018 at 11:06:22 AM UTC-5, GOTHIER Nathan wrote:
> On Thu, 8 Feb 2018 06:36:44 -0800 (PST)
> jameskuyper@verizon.net wrote:
> 
> > I'd expect that the characteristics of a new short float type would be
> > specified in the same way as they are for float, double, and long
> > double. The requirements in 5.2.4.2.2 on the numeric characteristics
> > of floating point types set either maximum values, or minimum values,
> > or minimums on the magnitude of the values - so there's nothing
> > preventing float, for instance, from being an 80-bit floating point
> > type. The same would therefore also be true of short float. I'd
> > expect at least some implementations targeting a platform with no
> > hardware support for a 16-bit type to use a 32-bit floating point
> > type for short float.
> > 
> > I've just reviewed the proposal, and it doesn't go into such details.
> 
> IMHO, it could be better to define an half_t type capable of
> representing at least an half precision floating point number. It would
> be more portable for most implementations.

Could you explain more precisely how half_t would differ from short
float?

> The analogy of the short float type with the long double type doesn't
> work well since the long double type give an alternative to implement a
> quad precision floating pointer type with an extended double precision
> floating point type. Moreover, the C programming language usually
> defines types with minimal magnitude values.

True (except for *_EPSILON and *_MIN for floating point types). And
that's exactly what I'm suggesting should continue to be the case for
short float: minimal magnitude limits for every item in 5.2.4.2.2p11,
minimum values for *_MAX, and maximum values for *_EPSILON and *_MIN.
Are you suggesting the required characteristics of short float should be described in some other fashion? If so, how?

Incidentally, has anyone specified what those required characteristics
should be? The minimum requirements for float and double are
deliberately somewhat less than the values that correspond to IEEE
single and double precision floating point formats (and the maximum
requirements are somewhat larger), to allow for non-IEEE formats. Should
the same be true for short float? If so, how much lower (higher) should
they be?

[toc] | [prev] | [next] | [standalone]

#126443

jameskuyper@verizon.net writes:
>On Thursday, February 8, 2018 at 11:06:22 AM UTC-5, GOTHIER Nathan wrote:
>> On Thu, 8 Feb 2018 06:36:44 -0800 (PST)
>> jameskuyper@verizon.net wrote:
>> 
>> > I'd expect that the characteristics of a new short float type would be
>> > specified in the same way as they are for float, double, and long
>> > double. The requirements in 5.2.4.2.2 on the numeric characteristics
>> > of floating point types set either maximum values, or minimum values,
>> > or minimums on the magnitude of the values - so there's nothing
>> > preventing float, for instance, from being an 80-bit floating point
>> > type. The same would therefore also be true of short float. I'd
>> > expect at least some implementations targeting a platform with no
>> > hardware support for a 16-bit type to use a 32-bit floating point
>> > type for short float.

>Incidentally, has anyone specified what those required characteristics
>should be? The minimum requirements for float and double are
>deliberately somewhat less than the values that correspond to IEEE
>single and double precision floating point formats (and the maximum
>requirements are somewhat larger), to allow for non-IEEE formats. Should
>the same be true for short float? If so, how much lower (higher) should
>they be?

Might start here:

https://gcc.gnu.org/onlinedocs/gcc/Half-Precision.html

[toc] | [prev] | [next] | [standalone]

#126446

On Thu, 8 Feb 2018 08:56:54 -0800 (PST)
jameskuyper@verizon.net wrote:

> > IMHO, it could be better to define an half_t type capable of
> > representing at least an half precision floating point number. It
> > would be more portable for most implementations.
> 
> Could you explain more precisely how half_t would differ from short
> float?

According to N2016 the short float type should be less or equal to a
single precision floating point number (32 bits) with no minimal
representation. It could be as tiny as a non standard 8-bit floating
point number or a standard IEEE 754 half precision floating point
number (16 bits).

The half_t type I suggest would provide a minimal support for an half
floating point number (16 bits) that can be translated to a standard
IEEE 754 single precision floating pointer number (32 bits) for most
implementations that doesn't have any native hardware support.


> True (except for *_EPSILON and *_MIN for floating point types). And
> that's exactly what I'm suggesting should continue to be the case for
> short float: minimal magnitude limits for every item in 5.2.4.2.2p11,
> minimum values for *_MAX, and maximum values for *_EPSILON and *_MIN.
> Are you suggesting the required characteristics of short float should
> be described in some other fashion? If so, how?

I assume the intended goal of the short float type is to take advantages
from some half floats compatible architectures. I think the short float
is a badly formulated solution to this.


> Incidentally, has anyone specified what those required characteristics
> should be? The minimum requirements for float and double are
> deliberately somewhat less than the values that correspond to IEEE
> single and double precision floating point formats (and the maximum
> requirements are somewhat larger), to allow for non-IEEE formats.
> Should the same be true for short float? If so, how much lower
> (higher) should they be?

The N2016 document is pretty unclear!

The IEEE 754-2008 standard defines the half precision floating point
format as binary16 (16 bits) implemented in many chips. I'm not an IEEE
754 expert but the requirements for float and double seem pretty in
phase with the IEEE 754 standard with provisions for non binary formats.

-- 
GOTHIER Nathan

[toc] | [prev] | [next] | [standalone]

#126455

On Thursday, February 8, 2018 at 12:54:56 PM UTC-5, GOTHIER Nathan wrote:
> On Thu, 8 Feb 2018 08:56:54 -0800 (PST)
> jameskuyper@verizon.net wrote:
> 
> > > IMHO, it could be better to define an half_t type capable of
> > > representing at least an half precision floating point number. It
> > > would be more portable for most implementations.
> > 
> > Could you explain more precisely how half_t would differ from short
> > float?
> 
> According to N2016 the short float type should be less or equal to a
> single precision floating point number (32 bits) with no minimal
> representation. It could be as tiny as a non standard 8-bit floating
> point number or a standard IEEE 754 half precision floating point
> number (16 bits).

I would not be in favor of a new floating point type with no significant
minimal requirements on it's range or precision. The proposal mentions a
10-bit OpenGL format as one that it wants to be usable as short float. I
suppose that the characteristics of that format could be used to set the
minimum requirements for short float.

...
> > Incidentally, has anyone specified what those required characteristics
> > should be? The minimum requirements for float and double are
> > deliberately somewhat less than the values that correspond to IEEE
> > single and double precision floating point formats (and the maximum
> > requirements are somewhat larger), to allow for non-IEEE formats.
> > Should the same be true for short float? If so, how much lower
> > (higher) should they be?
> 
> The N2016 document is pretty unclear!
> 
> The IEEE 754-2008 standard defines the half precision floating point
> format as binary16 (16 bits) implemented in many chips. I'm not an IEEE
> 754 expert but the requirements for float and double seem pretty in
> phase with the IEEE 754 standard with provisions for non binary formats.

I don't agree. Based upon 5.2.4.2.2p11,12,13, and 16, here's a
comparison of the requirements for C float and double with the actual
characteristics of IEEE single and double precision formats:

Feature     |float|  IEEE single  |double|      IEEE double
================================================================
_EPSILON    |1E-5 |   0X1P-23F    | 1E-9 |        0X1P-52
_DECIMAL_DIG|  6  |       9       |  10  |          17
_DIG        |  6  |       6       |  10  |          15
_MIN        |1E-37|   0X1P-126F   | 1E-37|       0X1P-1022
_TRUE_MIN   |1E-37|   0X1P-149F   | 1E-37|       0X1P-1074
_MIN_10_EXP | -37 |      -37      |  -37 |         -307
_MAX        |1E37 |0X1.fffffeP127F| 1E37 |0X1.fffffffffffffP1023
_MAX_10_EXP | 37  |       38      |  37  |          308

The requirements of the standard appear to have been targeted to a base
10 implementation. Allowing for that fact, the limits on the MIN and MAX
values for float and double (which are identical) are pretty close to
IEEE single precision. However, the minimum values for the precision-
related characteristics are different for float and double, and
significantly lower than actual values for the corresponding IEEE formats.

[toc] | [prev] | [next] | [standalone]

#126462

On Thu, 8 Feb 2018 11:27:51 -0800 (PST)
jameskuyper@verizon.net wrote:

> I don't agree. Based upon 5.2.4.2.2p11,12,13, and 16, here's a
> comparison of the requirements for C float and double with the actual
> characteristics of IEEE single and double precision formats:
> 
> Feature     |float|  IEEE single  |double|      IEEE double
> ================================================================
> _EPSILON    |1E-5 |   0X1P-23F    | 1E-9 |        0X1P-52
> _DECIMAL_DIG|  6  |       9       |  10  |          17
> _DIG        |  6  |       6       |  10  |          15
> _MIN        |1E-37|   0X1P-126F   | 1E-37|       0X1P-1022
> _TRUE_MIN   |1E-37|   0X1P-149F   | 1E-37|       0X1P-1074
> _MIN_10_EXP | -37 |      -37      |  -37 |         -307
> _MAX        |1E37 |0X1.fffffeP127F| 1E37 |0X1.fffffffffffffP1023
> _MAX_10_EXP | 37  |       38      |  37  |          308
> 
> The requirements of the standard appear to have been targeted to a
> base 10 implementation. Allowing for that fact, the limits on the MIN
> and MAX values for float and double (which are identical) are pretty
> close to IEEE single precision. However, the minimum values for the
> precision- related characteristics are different for float and
> double, and significantly lower than actual values for the
> corresponding IEEE formats.

Clearly, you're right! I was a bit distracted by the binary definitions
from the IEEE 754 standard.

Obviously the collective defined limits for the float, double and long
double type doesn't work for an half_t type covering the IEEE 754
binary16 format.

Since the exponent width of the binary16 format is 5 bits corresponding
to the range [-14, +15] with a 15 exponent bias, it could be safe to
define an half_t type with HLF_MIN equal to 1E-4 and HLF_MAX equal to
1E+4. This range should be enought to cover a normalized value in
[0.0, 1.0] corresponding to the [0, 1023] range for a 10-bit color
component.

-- 
GOTHIER Nathan

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web