Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

We have phasers, I vote we blast 'em! -- Bailey, "The Corbomite Maneuver", stardate 1514.2


devel / comp.arch / Re: Mixed EGU/EGO floating-point

SubjectAuthor
* Mixed EGU/EGO floating-pointQuadibloc
`* Re: Mixed EGU/EGO floating-pointMitchAlsup
 +* Re: Mixed EGU/EGO floating-pointMitchAlsup
 |`- Re: Mixed EGU/EGO floating-pointQuadibloc
 +* Re: Mixed EGU/EGO floating-pointQuadibloc
 |`* Re: Mixed EGU/EGO floating-pointAnton Ertl
 | +* Re: Mixed EGU/EGO floating-pointMitchAlsup
 | |`- Re: Mixed EGU/EGO floating-pointMichael S
 | +* Re: Mixed EGU/EGO floating-pointJohn Levine
 | |+- Re: Mixed EGU/EGO floating-pointJohn Dallman
 | |+- Re: Mixed EGU/EGO floating-pointAnton Ertl
 | |+* Re: Mixed EGU/EGO floating-pointJimBrakefield
 | ||`- Re: Mixed EGU/EGO floating-pointEricP
 | |`- Re: Mixed EGU/EGO floating-pointMichael S
 | `* Re: Mixed EGU/EGO floating-pointTerje Mathisen
 |  +* Re: Mixed EGU/EGO floating-pointIvan Godard
 |  |+* Re: Mixed EGU/EGO floating-pointMitchAlsup
 |  ||`- Re: Mixed EGU/EGO floating-pointIvan Godard
 |  |+* Re: Mixed EGU/EGO floating-pointAnton Ertl
 |  ||`* Re: Mixed EGU/EGO floating-pointThomas Koenig
 |  || +* Re: Mixed EGU/EGO floating-pointEricP
 |  || |+* Re: Mixed EGU/EGO floating-pointThomas Koenig
 |  || ||`- Re: Mixed EGU/EGO floating-pointBGB
 |  || |+- Re: Mixed EGU/EGO floating-pointMitchAlsup
 |  || |`* Re: Mixed EGU/EGO floating-pointStephen Fuld
 |  || | +- Re: Mixed EGU/EGO floating-pointEricP
 |  || | +- Re: Mixed EGU/EGO floating-pointJohn Levine
 |  || | +* Re: Mixed EGU/EGO floating-pointTerje Mathisen
 |  || | |`- Re: Mixed EGU/EGO floating-pointIvan Godard
 |  || | `- Re: Mixed EGU/EGO floating-pointGeorge Neuner
 |  || +* Re: Mixed EGU/EGO floating-pointStephen Fuld
 |  || |`- Re: Mixed EGU/EGO floating-pointEricP
 |  || +- Re: Mixed EGU/EGO floating-pointMitchAlsup
 |  || `* Re: Mixed EGU/EGO floating-pointAnton Ertl
 |  ||  `* Re: Mixed EGU/EGO floating-pointThomas Koenig
 |  ||   +* Re: Mixed EGU/EGO floating-pointMitchAlsup
 |  ||   |`* Re: Mixed EGU/EGO floating-pointThomas Koenig
 |  ||   | +* Re: Mixed EGU/EGO floating-pointMitchAlsup
 |  ||   | |+* Re: Mixed EGU/EGO floating-pointStefan Monnier
 |  ||   | ||+- Re: Mixed EGU/EGO floating-pointMitchAlsup
 |  ||   | ||`* Re: Mixed EGU/EGO floating-pointIvan Godard
 |  ||   | || `* Re: Mixed EGU/EGO floating-pointMitchAlsup
 |  ||   | ||  `* Re: Mixed EGU/EGO floating-pointBGB
 |  ||   | ||   `* Re: Mixed EGU/EGO floating-pointMitchAlsup
 |  ||   | ||    `- Re: Mixed EGU/EGO floating-pointBGB
 |  ||   | |`* Re: Mixed EGU/EGO floating-pointAnton Ertl
 |  ||   | | `- Re: Mixed EGU/EGO floating-pointMitchAlsup
 |  ||   | `* Re: Mixed EGU/EGO floating-pointAnton Ertl
 |  ||   |  `- Re: Mixed EGU/EGO floating-pointThomas Koenig
 |  ||   `* Re: Mixed EGU/EGO floating-pointAnton Ertl
 |  ||    +* Re: Mixed EGU/EGO floating-pointBGB
 |  ||    |`- Re: Mixed EGU/EGO floating-pointMitchAlsup
 |  ||    `* Re: Mixed EGU/EGO floating-pointThomas Koenig
 |  ||     `- Re: Mixed EGU/EGO floating-pointMitchAlsup
 |  |`- Re: Mixed EGU/EGO floating-pointTerje Mathisen
 |  `* Re: Mixed EGU/EGO floating-pointMitchAlsup
 |   `- Re: Mixed EGU/EGO floating-pointBGB
 +* Re: Mixed EGU/EGO floating-pointJimBrakefield
 |`* Re: Mixed EGU/EGO floating-pointQuadibloc
 | +* Re: Mixed EGU/EGO floating-pointMitchAlsup
 | |+- Re: Mixed EGU/EGO floating-pointJimBrakefield
 | |`* Perfect roudning of trogonometric functions (was: Mixed EGU/EGO floating-point)Stefan Monnier
 | | `* Re: Perfect roudning of trogonometric functionsTerje Mathisen
 | |  `* Re: Perfect roudning of trogonometric functionsStefan Monnier
 | |   `- Re: Perfect roudning of trogonometric functionsTerje Mathisen
 | `* Re: Mixed EGU/EGO floating-pointEricP
 |  `* Re: Mixed EGU/EGO floating-pointMitchAlsup
 |   +- Re: Mixed EGU/EGO floating-pointJimBrakefield
 |   +- Re: Mixed EGU/EGO floating-pointTerje Mathisen
 |   `- Re: Mixed EGU/EGO floating-pointEricP
 `* Re: Mixed EGU/EGO floating-pointBGB
  `* Re: Mixed EGU/EGO floating-pointMitchAlsup
   +* Re: Mixed EGU/EGO floating-pointStefan Monnier
   |`* Re: Mixed EGU/EGO floating-pointBGB
   | `* Re: Mixed EGU/EGO floating-pointJohn Dallman
   |  +- Re: Mixed EGU/EGO floating-pointMitchAlsup
   |  +* Re: Mixed EGU/EGO floating-pointThomas Koenig
   |  |+- Re: Mixed EGU/EGO floating-pointJohn Dallman
   |  |+* Re: Mixed EGU/EGO floating-pointBGB
   |  ||`* Re: Mixed EGU/EGO floating-pointMitchAlsup
   |  || `* Re: Mixed EGU/EGO floating-pointBGB
   |  ||  `* Re: Mixed EGU/EGO floating-pointMitchAlsup
   |  ||   +* Re: Mixed EGU/EGO floating-pointIvan Godard
   |  ||   |`- Re: Mixed EGU/EGO floating-pointMitchAlsup
   |  ||   `* Re: Mixed EGU/EGO floating-pointBGB
   |  ||    `* Re: Mixed EGU/EGO floating-pointMitchAlsup
   |  ||     `* Re: Mixed EGU/EGO floating-pointBGB
   |  ||      `* Re: Mixed EGU/EGO floating-pointMitchAlsup
   |  ||       `- Re: Mixed EGU/EGO floating-pointBGB
   |  |`* Re: Mixed EGU/EGO floating-pointAnton Ertl
   |  | `* Re: Mixed EGU/EGO floating-pointMitchAlsup
   |  |  +* Re: Mixed EGU/EGO floating-pointQuadibloc
   |  |  |+- Re: Mixed EGU/EGO floating-pointMitchAlsup
   |  |  |`* Re: Mixed EGU/EGO floating-pointAnton Ertl
   |  |  | `- Re: Mixed EGU/EGO floating-pointQuadibloc
   |  |  `* Re: Mixed EGU/EGO floating-pointAnton Ertl
   |  |   `* Re: Mixed EGU/EGO floating-pointMitchAlsup
   |  |    +* Re: Mixed EGU/EGO floating-pointBGB
   |  |    |`* Re: Mixed EGU/EGO floating-pointBGB
   |  |    | `* Re: Mixed EGU/EGO floating-pointQuadibloc
   |  |    |  +- Re: Mixed EGU/EGO floating-pointBGB
   |  |    |  `* Re: Mixed EGU/EGO floating-pointMitchAlsup
   |  |    +- Re: Mixed EGU/EGO floating-pointAnton Ertl
   |  |    `- Re: Mixed EGU/EGO floating-pointQuadibloc
   |  `* Re: Mixed EGU/EGO floating-pointQuadibloc
   `* Re: Mixed EGU/EGO floating-pointBGB

Pages:12345
Re: Perfect roudning of trogonometric functions

<jwva6bjhnnq.fsf-monnier+comp.arch@gnu.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25274&group=comp.arch#25274

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: monn...@iro.umontreal.ca (Stefan Monnier)
Newsgroups: comp.arch
Subject: Re: Perfect roudning of trogonometric functions
Date: Sat, 14 May 2022 16:30:58 -0400
Organization: A noiseless patient Spider
Lines: 24
Message-ID: <jwva6bjhnnq.fsf-monnier+comp.arch@gnu.org>
References: <de735513-d303-42b6-b375-916b89ddafcan@googlegroups.com>
<2a41be98-e9c8-4159-bef7-ba7999e278ecn@googlegroups.com>
<9264b6fa-e9c9-4f77-957b-4a71dc7ca0d3n@googlegroups.com>
<d6081c6f-68db-4a1b-9110-6087189b427en@googlegroups.com>
<0b089a6c-6257-4675-8767-772d5e2a8ce5n@googlegroups.com>
<jwvee0wfbw7.fsf-monnier+comp.arch@gnu.org>
<t5p2er$vso$1@gioia.aioe.org>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="9ec7bdaad37f6f7ef1285b59edb74545";
logging-data="13694"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19IWklyJ6PC0+G0AH+NjDRo"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
Cancel-Lock: sha1:x3J4tvce2RvQIEZ4d3Bxg267FwY=
sha1:BJW2SKlA0c0LH4LO1qyQrlHeBt0=
 by: Stefan Monnier - Sat, 14 May 2022 20:30 UTC

> Their two extra bits sounds exactly the same as guard & sticky which is what
> every FP implementation (hardware or software) need as a minimum solution in
> order to handle any rounding mode correctly.

Indeed, it's just the same.

> I would not call it "round to odd" though, in reality "sticky" is the OR of
> itself and all trailing bits. I.e. if there are _any_ bits set past the
> guard bit, then sticky will be true/1.

For that reason I put it between quotes. In the blog (and in the
article), they do point out that it's not just the like the classic
round to even.

They probably kept the name that was used in
https://hal.archives-ouvertes.fr/inria-00070603
Not sure where that one came from.

But this is also what made me think of this article: if the sticky bit
is 0 it means the representation is exact and if it's 1 it's (almost
always) not.

Stefan

Re: Mixed EGU/EGO floating-point

<t5p52v$shq$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25275&group=comp.arch#25275

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Mixed EGU/EGO floating-point
Date: Sat, 14 May 2022 15:55:45 -0500
Organization: A noiseless patient Spider
Lines: 102
Message-ID: <t5p52v$shq$1@dont-email.me>
References: <de735513-d303-42b6-b375-916b89ddafcan@googlegroups.com>
<2a41be98-e9c8-4159-bef7-ba7999e278ecn@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 14 May 2022 20:57:03 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="697fa5a2c6ff4134b01ea82bf1f3c4a3";
logging-data="29242"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+0TxMRpJ+q1/aIsMSP9rLP"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:+7YsJ5hG29gMRHv+i2gAIuigMw4=
In-Reply-To: <2a41be98-e9c8-4159-bef7-ba7999e278ecn@googlegroups.com>
Content-Language: en-US
 by: BGB - Sat, 14 May 2022 20:55 UTC

On 5/13/2022 9:06 AM, MitchAlsup wrote:
> On Thursday, May 12, 2022 at 11:23:44 PM UTC-5, Quadibloc wrote:
>> I tried sending an E-mail about this brainstorm of mine to posituhb.org, and in
>> my unsuccessful attempt to do so, I discovered that John L. Gustafson's E-mail
>> address at the University of Singapore is no longer valid.
>> Also, the most recent news of him I have heard of was that he was hired by
>> ClearSpeed Technology, but that company no longer exists; another company
>> with a similar name makes AI software, not chips.
>>
>> Anyways, the brainstorm I was inspired with by reading the discussion about
>> NaNs is this:
>>
>> Let us consider a floating-point format which is identical to the IEEE 754 floating-point format... when the first three bits of the excess-n exponent
>> field are in the range [001 ... 110].
>>
>> So for the "inner 75%" of the range of IEEE 754 floats, not one bit of
>> precision is lost.
>>
>> In the bottom 12.5%, we have Extremely Gradual Underflow, which I have
>> described before.
>>
>> So if the exponent field starts with 000, _and_ the first bit of the
>> significand field is 1, then:
>>
>> - that first bit of the significand field corresponds to the first bit of the
>> significand, and is no longer "hidden", and
>> - the effective value of the exponent is adjusted the same way the
>> effective value of an all-zeroes exponent is adjusted for conventional
>> IEEE-754 floats; one is added to it..
>>
>> Nothing new here, except that a bit seems to be wasted for no good
>> reason.
>> But if you remember how EGU works, or if you're familiar with posits,
>> you will know what comes next.
>> If the significand field begins with "01", now the effective value of the
>> exponent is adjusted by how it needs to be adjusted so that the range of
>> floats with "01" significands is tacked on neatly to the low end of the
>> range of floats with "1" significands.
>>
>> Or, in posit language, exponents starting with 000 are followed by a
>> "regime" field before a significand field (still with a hidden first bit)
>> starts.
>>
>> And the same happens, but on the high (EGO - Extremely Gradual
>> Overflow) end, for exponents starting with 111.
> <
> Why not a hierarchy of infinities ?
>>
>> The order of bits can be shuffled around to make the resulting number
>> look more like a posit, if you like. (That is, put the regime field
>> immediately after the 000 and 111, then put in the rest of the exponent,
>> before starting the significand, instead of putting the regime field
>> after the whole exponent.)
>>
>> The idea is that now one can switch to this... 25% solution of posits...
>> without the complaint that, oh, noes, we're losing one bit of precision.
>>
>> Now it's only at the outer 25% of the old floating point range, which is
>> obviously totally irrelevant if you don't even believe that posits are
>> necessary and/or useful!
> <
> The most useful thing about posits is that they do not come with all
> the IEEE 754 baggage.

One could go the other direction:
Drop any semantic distinction between Inf and NaN;
Effectively, Inf is just a special case of NaN.
Define "Denormal As Zero" as canonical;
...

FPU operations:
ADD/SUB/MUL
CMP, CONV

Rounding:
Mostly Undefined (Rounding modes may be unsupported or ignored)
ADD/SUB/MUL are ULP +/- 1.5 or 2 or similar
Conversion to integer is always "truncate towards zero".

Could still require that, for the same inputs, the operators will still
produce the same output each time.

Divide and Square-Root are software, and "somewhere in generally the
right area" is regarded as sufficient.

Or, basically, the cheapest FPU possible which is still sufficient as to
be basically usable.

Possible optional additions:
Denormalized formats, which lack a hidden bit
More like the x87 long-double format;
Intermediate precision formats, such as:
Binary48 (S.E11.F36)
Binary24 (S.E8.F15).
If stored in a 32 or 64 bit container:
Will use the same format as Binary32 or Binary64
Will ignore the low order bits.

....

Re: Mixed EGU/EGO floating-point

<30d6cdc7-ee4c-4b55-9ba8-8e7f236cd49fn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25276&group=comp.arch#25276

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:10a8:b0:69f:8b8b:36d9 with SMTP id h8-20020a05620a10a800b0069f8b8b36d9mr7979914qkk.93.1652563778843;
Sat, 14 May 2022 14:29:38 -0700 (PDT)
X-Received: by 2002:a05:6808:3012:b0:2ef:79c7:1342 with SMTP id
ay18-20020a056808301200b002ef79c71342mr188937oib.0.1652563778640; Sat, 14 May
2022 14:29:38 -0700 (PDT)
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!feeder1.cambriumusenet.nl!feed.tweak.nl!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Sat, 14 May 2022 14:29:38 -0700 (PDT)
In-Reply-To: <t5p52v$shq$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:3c12:2a2f:f7f9:90d8;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:3c12:2a2f:f7f9:90d8
References: <de735513-d303-42b6-b375-916b89ddafcan@googlegroups.com>
<2a41be98-e9c8-4159-bef7-ba7999e278ecn@googlegroups.com> <t5p52v$shq$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <30d6cdc7-ee4c-4b55-9ba8-8e7f236cd49fn@googlegroups.com>
Subject: Re: Mixed EGU/EGO floating-point
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Sat, 14 May 2022 21:29:38 +0000
Content-Type: text/plain; charset="UTF-8"
 by: MitchAlsup - Sat, 14 May 2022 21:29 UTC

On Saturday, May 14, 2022 at 3:57:06 PM UTC-5, BGB wrote:
> On 5/13/2022 9:06 AM, MitchAlsup wrote:
> > On Thursday, May 12, 2022 at 11:23:44 PM UTC-5, Quadibloc wrote:
> >> I tried sending an E-mail about this brainstorm of mine to posituhb.org, and in
> >> my unsuccessful attempt to do so, I discovered that John L. Gustafson's E-mail
> >> address at the University of Singapore is no longer valid.
> >> Also, the most recent news of him I have heard of was that he was hired by
> >> ClearSpeed Technology, but that company no longer exists; another company
> >> with a similar name makes AI software, not chips.
> >>
> >> Anyways, the brainstorm I was inspired with by reading the discussion about
> >> NaNs is this:
> >>
> >> Let us consider a floating-point format which is identical to the IEEE 754 floating-point format... when the first three bits of the excess-n exponent
> >> field are in the range [001 ... 110].
> >>
> >> So for the "inner 75%" of the range of IEEE 754 floats, not one bit of
> >> precision is lost.
> >>
> >> In the bottom 12.5%, we have Extremely Gradual Underflow, which I have
> >> described before.
> >>
> >> So if the exponent field starts with 000, _and_ the first bit of the
> >> significand field is 1, then:
> >>
> >> - that first bit of the significand field corresponds to the first bit of the
> >> significand, and is no longer "hidden", and
> >> - the effective value of the exponent is adjusted the same way the
> >> effective value of an all-zeroes exponent is adjusted for conventional
> >> IEEE-754 floats; one is added to it..
> >>
> >> Nothing new here, except that a bit seems to be wasted for no good
> >> reason.
> >> But if you remember how EGU works, or if you're familiar with posits,
> >> you will know what comes next.
> >> If the significand field begins with "01", now the effective value of the
> >> exponent is adjusted by how it needs to be adjusted so that the range of
> >> floats with "01" significands is tacked on neatly to the low end of the
> >> range of floats with "1" significands.
> >>
> >> Or, in posit language, exponents starting with 000 are followed by a
> >> "regime" field before a significand field (still with a hidden first bit)
> >> starts.
> >>
> >> And the same happens, but on the high (EGO - Extremely Gradual
> >> Overflow) end, for exponents starting with 111.
> > <
> > Why not a hierarchy of infinities ?
> >>
> >> The order of bits can be shuffled around to make the resulting number
> >> look more like a posit, if you like. (That is, put the regime field
> >> immediately after the 000 and 111, then put in the rest of the exponent,
> >> before starting the significand, instead of putting the regime field
> >> after the whole exponent.)
> >>
> >> The idea is that now one can switch to this... 25% solution of posits...
> >> without the complaint that, oh, noes, we're losing one bit of precision.
> >>
> >> Now it's only at the outer 25% of the old floating point range, which is
> >> obviously totally irrelevant if you don't even believe that posits are
> >> necessary and/or useful!
> > <
> > The most useful thing about posits is that they do not come with all
> > the IEEE 754 baggage.
> One could go the other direction:
> Drop any semantic distinction between Inf and NaN;
> Effectively, Inf is just a special case of NaN.
<
Infiniity has a defined magnitude :: bigger than any IEEE representable number
NaN has a defined non-value :: not comparable to any IEEE representable
number (including even itself).
<
I don't see why you would want Infinity to just be another NaN.
<
> Define "Denormal As Zero" as canonical;
<
This no longer saves circuitry.
<
> ...
>
> FPU operations:
> ADD/SUB/MUL
> CMP, CONV
>
> Rounding:
> Mostly Undefined (Rounding modes may be unsupported or ignored)
> ADD/SUB/MUL are ULP +/- 1.5 or 2 or similar
<
Even the GPUs are migrating towards full IEEE 754 compliance.
<
> Conversion to integer is always "truncate towards zero".
<
i = ICEIL( x );
....
>
> Could still require that, for the same inputs, the operators will still
> produce the same output each time.
>
> Divide and Square-Root are software, and "somewhere in generally the
> right area" is regarded as sufficient.
<
Unlikely to be accepted by the market.
>
>
> Or, basically, the cheapest FPU possible which is still sufficient as to
> be basically usable.
>
Will end up with the same "avid" following as FIAT here in USA.
>
> Possible optional additions:
> Denormalized formats, which lack a hidden bit
> More like the x87 long-double format;
> Intermediate precision formats, such as:
> Binary48 (S.E11.F36)
> Binary24 (S.E8.F15).
> If stored in a 32 or 64 bit container:
> Will use the same format as Binary32 or Binary64
> Will ignore the low order bits.
<
It seems to me that this is not a job of CPU architects, but a job
for people who want to use quality FP implementations.
>
> ...

Re: Perfect roudning of trogonometric functions

<t5p8bl$1io4$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25277&group=comp.arch#25277

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!10O9MudpjwoXIahOJRbDvA.user.46.165.242.91.POSTED!not-for-mail
From: terje.ma...@tmsw.no (Terje Mathisen)
Newsgroups: comp.arch
Subject: Re: Perfect roudning of trogonometric functions
Date: Sat, 14 May 2022 23:52:55 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t5p8bl$1io4$1@gioia.aioe.org>
References: <de735513-d303-42b6-b375-916b89ddafcan@googlegroups.com>
<2a41be98-e9c8-4159-bef7-ba7999e278ecn@googlegroups.com>
<9264b6fa-e9c9-4f77-957b-4a71dc7ca0d3n@googlegroups.com>
<d6081c6f-68db-4a1b-9110-6087189b427en@googlegroups.com>
<0b089a6c-6257-4675-8767-772d5e2a8ce5n@googlegroups.com>
<jwvee0wfbw7.fsf-monnier+comp.arch@gnu.org> <t5p2er$vso$1@gioia.aioe.org>
<jwva6bjhnnq.fsf-monnier+comp.arch@gnu.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="51972"; posting-host="10O9MudpjwoXIahOJRbDvA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101
Firefox/68.0 SeaMonkey/2.53.12
X-Notice: Filtered by postfilter v. 0.9.2
 by: Terje Mathisen - Sat, 14 May 2022 21:52 UTC

Stefan Monnier wrote:
>> Their two extra bits sounds exactly the same as guard & sticky which is what
>> every FP implementation (hardware or software) need as a minimum solution in
>> order to handle any rounding mode correctly.
>
> Indeed, it's just the same.
>
>> I would not call it "round to odd" though, in reality "sticky" is the OR of
>> itself and all trailing bits. I.e. if there are _any_ bits set past the
>> guard bit, then sticky will be true/1.
>
> For that reason I put it between quotes. In the blog (and in the
> article), they do point out that it's not just the like the classic
> round to even.
>
> They probably kept the name that was used in
> https://hal.archives-ouvertes.fr/inria-00070603
> Not sure where that one came from.
>
> But this is also what made me think of this article: if the sticky bit
> is 0 it means the representation is exact and if it's 1 it's (almost
> always) not.

It is only exact (i.e. the actual/delivered result) if both guard and
sticky are zero, any other combination means that rounding _will_ happen.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Re: Mixed EGU/EGO floating-point

<jwvsfpbg54q.fsf-monnier+comp.arch@gnu.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25278&group=comp.arch#25278

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: monn...@iro.umontreal.ca (Stefan Monnier)
Newsgroups: comp.arch
Subject: Re: Mixed EGU/EGO floating-point
Date: Sat, 14 May 2022 17:58:39 -0400
Organization: A noiseless patient Spider
Lines: 25
Message-ID: <jwvsfpbg54q.fsf-monnier+comp.arch@gnu.org>
References: <de735513-d303-42b6-b375-916b89ddafcan@googlegroups.com>
<2a41be98-e9c8-4159-bef7-ba7999e278ecn@googlegroups.com>
<t5p52v$shq$1@dont-email.me>
<30d6cdc7-ee4c-4b55-9ba8-8e7f236cd49fn@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="9ec7bdaad37f6f7ef1285b59edb74545";
logging-data="21036"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+aliStBRdnthCE8MzW+z4h"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
Cancel-Lock: sha1:ICidTGhlUHftABUGo2Zxy6NWuSI=
sha1:iBSidTIFX92bnLC1TYL+xddTHkA=
 by: Stefan Monnier - Sat, 14 May 2022 21:58 UTC

MitchAlsup wrote:
> Even the GPUs are migrating towards full IEEE 754 compliance.

Indeed, for pretty much all software, the direction has historically
been firmly towards ever more bit-for-bit reproducibility (makes a lot
of things much easier), and over the years we've learned how to get that
at reasonable cost.

Neural networks currently don't care so much about it because they live
in a "mushy" world (and arguably because they need to be robust against
small changes, so in a sense they *shouldn't* have to care), but I don't
know if that'll still be true 20 years from now (e.g. maybe when we
start to care about the problem of being able to reproduce existing
results).

BGB wrote:
> Divide and Square-Root are software, and "somewhere in generally the
> right area" is regarded as sufficient.

If you don't care about the last few bits and want to be cheap, then
maybe you should compute with a lower precision (still using an
operation which returns an exactly rounded result) instead.

Stefan

Re: Mixed EGU/EGO floating-point

<t5p9pf$52o$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25279&group=comp.arch#25279

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!10O9MudpjwoXIahOJRbDvA.user.46.165.242.91.POSTED!not-for-mail
From: terje.ma...@tmsw.no (Terje Mathisen)
Newsgroups: comp.arch
Subject: Re: Mixed EGU/EGO floating-point
Date: Sun, 15 May 2022 00:17:21 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t5p9pf$52o$1@gioia.aioe.org>
References: <de735513-d303-42b6-b375-916b89ddafcan@googlegroups.com>
<2a41be98-e9c8-4159-bef7-ba7999e278ecn@googlegroups.com>
<a4400d89-ce0d-4c76-aeb2-de2d13f40318n@googlegroups.com>
<2022May13.200449@mips.complang.tuwien.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="5208"; posting-host="10O9MudpjwoXIahOJRbDvA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101
Firefox/68.0 SeaMonkey/2.53.12
X-Notice: Filtered by postfilter v. 0.9.2
 by: Terje Mathisen - Sat, 14 May 2022 22:17 UTC

Anton Ertl wrote:
> Quadibloc <jsavard@ecn.ab.ca> writes:
>> And the IEEE 754
>> standard has been hugely popular, as illustrated by its wide adoption.
>>
>> This could be due to the market power of the x86 due to Windows, and not
>> to any particular merit of the standard, of course; it's hard to tell.
>
> This particular claim is easy to refute: IEEE 754 won before Windows,
> so it did not become popular because of Windows. Basically all new
> architectures after IEEE 754 (1985) and a few before (e.g., 8087
> (1980), 68881 (1984)) adopted IEEE 754, and in time the older
> architectures adopted it as well. By contrast, Windows was not
> really successful before Windows 3 (1990).

Afair ieee754 can be traced back to around 1978, i.e. the design of the
8087, didn't Intel consult with Kahan around that timeframe?

The original 1985 standard mostly blessed those already-implemented
versions of the prior drafts, this required grandfathering a few
unfortunate parts that had not been clearly defined and which had been
implemented in more than one way.

I.e. what is the correct way to detect subnormal results? Before or
after rounding? (Imho the only sane choice is to first normalize the
result so that any negative (biased) exponent is locked at zero, then
round at that position.)

Another unfortunate choice was in how to encode Signaling vs Quiet NaNs:
Which bit in the mantissa is used and what does it mean?
Is the bit set or reset for Quiet? I have seen it claimed that by having
QNaNs setting the bit, any trap handler which wants to convert an SNaN
to QNaN can do so by setting that bit, without having to worry about the
entire mantissa then ending up zero, which would be illegal since it
turns the value into Inf.

The proper way to encode this, imnsho, would have been to reserve the
two top mantissa bits and disregard the rest for the purpose of
determining Inf vs NaN.

00 - Inf
01 - None (Missing value)
10 - QNaN
11 - SNaN

This way the top mantissa bit would be sticky, always indicating a NaN
(with the exp field 0x1111... of course), the None value would be
treated as zero for FADD/FSUB and 1.0 for FMUL so you could multiply or
add together all elements of an array and not worry about any missing
elements.

Most other operations would of course be invalid, giving a NaN result.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Re: Mixed EGU/EGO floating-point

<t5pb7g$6og$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25280&group=comp.arch#25280

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: iva...@millcomputing.com (Ivan Godard)
Newsgroups: comp.arch
Subject: Re: Mixed EGU/EGO floating-point
Date: Sat, 14 May 2022 15:41:51 -0700
Organization: A noiseless patient Spider
Lines: 56
Message-ID: <t5pb7g$6og$1@dont-email.me>
References: <de735513-d303-42b6-b375-916b89ddafcan@googlegroups.com>
<2a41be98-e9c8-4159-bef7-ba7999e278ecn@googlegroups.com>
<a4400d89-ce0d-4c76-aeb2-de2d13f40318n@googlegroups.com>
<2022May13.200449@mips.complang.tuwien.ac.at> <t5p9pf$52o$1@gioia.aioe.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 14 May 2022 22:41:53 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="a01afe1d7290eaf56b80aaab2cb1266c";
logging-data="6928"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/QB92XXFodLMH5BaAm1jMU"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Cancel-Lock: sha1:7cMEmUA/a754sm0QblDq7MoslME=
In-Reply-To: <t5p9pf$52o$1@gioia.aioe.org>
Content-Language: en-US
 by: Ivan Godard - Sat, 14 May 2022 22:41 UTC

On 5/14/2022 3:17 PM, Terje Mathisen wrote:
> Anton Ertl wrote:
>> Quadibloc <jsavard@ecn.ab.ca> writes:
>>> And the IEEE 754
>>> standard has been hugely popular, as illustrated by its wide adoption.
>>>
>>> This could be due to the market power of the x86 due to Windows, and not
>>> to any particular merit of the standard, of course; it's hard to tell.
>>
>> This particular claim is easy to refute: IEEE 754 won before Windows,
>> so it did not become popular because of Windows.  Basically all new
>> architectures after IEEE 754 (1985) and a few before (e.g., 8087
>> (1980), 68881 (1984)) adopted IEEE 754, and in time the older
>> architectures adopted it as well.  By contrast, Windows was not
>> really successful before Windows 3 (1990).
>
> Afair ieee754 can be traced back to around 1978, i.e. the design of the
> 8087, didn't Intel consult with Kahan around that timeframe?
>
> The original 1985 standard mostly blessed those already-implemented
> versions of the prior drafts, this required grandfathering a few
> unfortunate parts that had not been clearly defined and which had been
> implemented in more than one way.
>
> I.e. what is the correct way to detect subnormal results? Before or
> after rounding? (Imho the only sane choice is to first normalize the
> result so that any negative (biased) exponent is locked at zero, then
> round at that position.)
>
> Another unfortunate choice was in how to encode Signaling vs Quiet NaNs:
> Which bit in the mantissa is used and what does it mean?
> Is the bit set or reset for Quiet? I have seen it claimed that by having
> QNaNs setting the bit, any trap handler which wants to convert an SNaN
> to QNaN can do so by setting that bit, without having to worry about the
> entire mantissa then ending up zero, which would be illegal since it
> turns the value into Inf.
>
> The proper way to encode this, imnsho, would have been to reserve the
> two top mantissa bits and disregard the rest for the purpose of
> determining Inf vs NaN.
>
> 00 - Inf
> 01 - None (Missing value)
> 10 - QNaN
> 11 - SNaN
>
> This way the top mantissa bit would be sticky, always indicating a NaN
> (with the exp field 0x1111... of course), the None value would be
> treated as zero for FADD/FSUB and 1.0 for FMUL so you could multiply or
> add together all elements of an array and not worry about any missing
> elements.
>
> Most other operations would of course be invalid, giving a NaN result.

Don't you want x+None or x*None to be None?

Re: Mixed EGU/EGO floating-point

<19670a53-3f89-406f-86ea-d24641c17066n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25281&group=comp.arch#25281

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:371d:b0:6a0:237c:abb with SMTP id de29-20020a05620a371d00b006a0237c0abbmr8301889qkb.685.1652581630441;
Sat, 14 May 2022 19:27:10 -0700 (PDT)
X-Received: by 2002:a05:6808:6d7:b0:325:67ff:a21b with SMTP id
m23-20020a05680806d700b0032567ffa21bmr5199395oih.105.1652581630240; Sat, 14
May 2022 19:27:10 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Sat, 14 May 2022 19:27:10 -0700 (PDT)
In-Reply-To: <t5p9pf$52o$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:3c12:2a2f:f7f9:90d8;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:3c12:2a2f:f7f9:90d8
References: <de735513-d303-42b6-b375-916b89ddafcan@googlegroups.com>
<2a41be98-e9c8-4159-bef7-ba7999e278ecn@googlegroups.com> <a4400d89-ce0d-4c76-aeb2-de2d13f40318n@googlegroups.com>
<2022May13.200449@mips.complang.tuwien.ac.at> <t5p9pf$52o$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <19670a53-3f89-406f-86ea-d24641c17066n@googlegroups.com>
Subject: Re: Mixed EGU/EGO floating-point
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Sun, 15 May 2022 02:27:10 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 4531
 by: MitchAlsup - Sun, 15 May 2022 02:27 UTC

On Saturday, May 14, 2022 at 5:17:22 PM UTC-5, Terje Mathisen wrote:
> Anton Ertl wrote:
> > Quadibloc <jsa...@ecn.ab.ca> writes:
> >> And the IEEE 754
> >> standard has been hugely popular, as illustrated by its wide adoption.
> >>
> >> This could be due to the market power of the x86 due to Windows, and not
> >> to any particular merit of the standard, of course; it's hard to tell.
> >
> > This particular claim is easy to refute: IEEE 754 won before Windows,
> > so it did not become popular because of Windows. Basically all new
> > architectures after IEEE 754 (1985) and a few before (e.g., 8087
> > (1980), 68881 (1984)) adopted IEEE 754, and in time the older
> > architectures adopted it as well. By contrast, Windows was not
> > really successful before Windows 3 (1990).
> Afair ieee754 can be traced back to around 1978, i.e. the design of the
> 8087, didn't Intel consult with Kahan around that timeframe?
>
> The original 1985 standard mostly blessed those already-implemented
> versions of the prior drafts, this required grandfathering a few
> unfortunate parts that had not been clearly defined and which had been
> implemented in more than one way.
>
> I.e. what is the correct way to detect subnormal results? Before or
> after rounding? (Imho the only sane choice is to first normalize the
> result so that any negative (biased) exponent is locked at zero, then
> round at that position.)
>
> Another unfortunate choice was in how to encode Signaling vs Quiet NaNs:
> Which bit in the mantissa is used and what does it mean?
> Is the bit set or reset for Quiet? I have seen it claimed that by having
> QNaNs setting the bit, any trap handler which wants to convert an SNaN
> to QNaN can do so by setting that bit, without having to worry about the
> entire mantissa then ending up zero, which would be illegal since it
> turns the value into Inf.
>
> The proper way to encode this, imnsho, would have been to reserve the
> two top mantissa bits and disregard the rest for the purpose of
> determining Inf vs NaN.
>
> 00 - Inf
> 01 - None (Missing value)
> 10 - QNaN
> 11 - SNaN
>
> This way the top mantissa bit would be sticky, always indicating a NaN
> (with the exp field 0x1111... of course), the None value would be
> treated as zero for FADD/FSUB and 1.0 for FMUL so you could multiply or
> add together all elements of an array and not worry about any missing
> elements.
<
This may simplify software implementations, but HW implementations
find it easy enough to detect the fraction == 0 as Infinity. In any event,
HW does not process calculations with infinities, just special case them
to decide what the answer wants to be; so the 3 gates of delay checking
for zero is insignificant.
<
Also note: instead of detecting infinity with fraction == 0, one can detect
implementation infinities by ( fraction<52> | fraction<51> ) == 1. (one
gate of delay).
>
> Most other operations would of course be invalid, giving a NaN result.
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

Re: Mixed EGU/EGO floating-point

<5b35639f-5ea0-4b22-8dc7-a6a093bb0fa2n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25282&group=comp.arch#25282

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:622a:40e:b0:2f3:db3b:7d4d with SMTP id n14-20020a05622a040e00b002f3db3b7d4dmr10857959qtx.655.1652581735060;
Sat, 14 May 2022 19:28:55 -0700 (PDT)
X-Received: by 2002:a05:6870:c59b:b0:f1:231c:c82c with SMTP id
ba27-20020a056870c59b00b000f1231cc82cmr8462375oab.217.1652581734867; Sat, 14
May 2022 19:28:54 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Sat, 14 May 2022 19:28:54 -0700 (PDT)
In-Reply-To: <t5pb7g$6og$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:3c12:2a2f:f7f9:90d8;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:3c12:2a2f:f7f9:90d8
References: <de735513-d303-42b6-b375-916b89ddafcan@googlegroups.com>
<2a41be98-e9c8-4159-bef7-ba7999e278ecn@googlegroups.com> <a4400d89-ce0d-4c76-aeb2-de2d13f40318n@googlegroups.com>
<2022May13.200449@mips.complang.tuwien.ac.at> <t5p9pf$52o$1@gioia.aioe.org> <t5pb7g$6og$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <5b35639f-5ea0-4b22-8dc7-a6a093bb0fa2n@googlegroups.com>
Subject: Re: Mixed EGU/EGO floating-point
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Sun, 15 May 2022 02:28:55 +0000
Content-Type: text/plain; charset="UTF-8"
 by: MitchAlsup - Sun, 15 May 2022 02:28 UTC

On Saturday, May 14, 2022 at 5:41:55 PM UTC-5, Ivan Godard wrote:
> On 5/14/2022 3:17 PM, Terje Mathisen wrote:
> > Anton Ertl wrote:
> >> Quadibloc <jsa...@ecn.ab.ca> writes:
> >>> And the IEEE 754
> >>> standard has been hugely popular, as illustrated by its wide adoption.
> >>>
> >>> This could be due to the market power of the x86 due to Windows, and not
> >>> to any particular merit of the standard, of course; it's hard to tell.
> >>
> >> This particular claim is easy to refute: IEEE 754 won before Windows,
> >> so it did not become popular because of Windows. Basically all new
> >> architectures after IEEE 754 (1985) and a few before (e.g., 8087
> >> (1980), 68881 (1984)) adopted IEEE 754, and in time the older
> >> architectures adopted it as well. By contrast, Windows was not
> >> really successful before Windows 3 (1990).
> >
> > Afair ieee754 can be traced back to around 1978, i.e. the design of the
> > 8087, didn't Intel consult with Kahan around that timeframe?
> >
> > The original 1985 standard mostly blessed those already-implemented
> > versions of the prior drafts, this required grandfathering a few
> > unfortunate parts that had not been clearly defined and which had been
> > implemented in more than one way.
> >
> > I.e. what is the correct way to detect subnormal results? Before or
> > after rounding? (Imho the only sane choice is to first normalize the
> > result so that any negative (biased) exponent is locked at zero, then
> > round at that position.)
> >
> > Another unfortunate choice was in how to encode Signaling vs Quiet NaNs:
> > Which bit in the mantissa is used and what does it mean?
> > Is the bit set or reset for Quiet? I have seen it claimed that by having
> > QNaNs setting the bit, any trap handler which wants to convert an SNaN
> > to QNaN can do so by setting that bit, without having to worry about the
> > entire mantissa then ending up zero, which would be illegal since it
> > turns the value into Inf.
> >
> > The proper way to encode this, imnsho, would have been to reserve the
> > two top mantissa bits and disregard the rest for the purpose of
> > determining Inf vs NaN.
> >
> > 00 - Inf
> > 01 - None (Missing value)
> > 10 - QNaN
> > 11 - SNaN
> >
> > This way the top mantissa bit would be sticky, always indicating a NaN
> > (with the exp field 0x1111... of course), the None value would be
> > treated as zero for FADD/FSUB and 1.0 for FMUL so you could multiply or
> > add together all elements of an array and not worry about any missing
> > elements.
> >
> > Most other operations would of course be invalid, giving a NaN result.
> Don't you want x+None or x*None to be None?
<
Which makes None just another kind of NaN.
{Which nobody uses anyway.}

Re: Mixed EGU/EGO floating-point

<t5pq51$nf7$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25283&group=comp.arch#25283

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: iva...@millcomputing.com (Ivan Godard)
Newsgroups: comp.arch
Subject: Re: Mixed EGU/EGO floating-point
Date: Sat, 14 May 2022 19:56:34 -0700
Organization: A noiseless patient Spider
Lines: 64
Message-ID: <t5pq51$nf7$1@dont-email.me>
References: <de735513-d303-42b6-b375-916b89ddafcan@googlegroups.com>
<2a41be98-e9c8-4159-bef7-ba7999e278ecn@googlegroups.com>
<a4400d89-ce0d-4c76-aeb2-de2d13f40318n@googlegroups.com>
<2022May13.200449@mips.complang.tuwien.ac.at> <t5p9pf$52o$1@gioia.aioe.org>
<t5pb7g$6og$1@dont-email.me>
<5b35639f-5ea0-4b22-8dc7-a6a093bb0fa2n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 15 May 2022 02:56:34 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="a01afe1d7290eaf56b80aaab2cb1266c";
logging-data="24039"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18lK4+TcOmLYYIJYvQxV0fN"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Cancel-Lock: sha1:kBIpJH3XWJN+hG/4IIWvFzG6Vxk=
In-Reply-To: <5b35639f-5ea0-4b22-8dc7-a6a093bb0fa2n@googlegroups.com>
Content-Language: en-US
 by: Ivan Godard - Sun, 15 May 2022 02:56 UTC

On 5/14/2022 7:28 PM, MitchAlsup wrote:
> On Saturday, May 14, 2022 at 5:41:55 PM UTC-5, Ivan Godard wrote:
>> On 5/14/2022 3:17 PM, Terje Mathisen wrote:
>>> Anton Ertl wrote:
>>>> Quadibloc <jsa...@ecn.ab.ca> writes:
>>>>> And the IEEE 754
>>>>> standard has been hugely popular, as illustrated by its wide adoption.
>>>>>
>>>>> This could be due to the market power of the x86 due to Windows, and not
>>>>> to any particular merit of the standard, of course; it's hard to tell.
>>>>
>>>> This particular claim is easy to refute: IEEE 754 won before Windows,
>>>> so it did not become popular because of Windows. Basically all new
>>>> architectures after IEEE 754 (1985) and a few before (e.g., 8087
>>>> (1980), 68881 (1984)) adopted IEEE 754, and in time the older
>>>> architectures adopted it as well. By contrast, Windows was not
>>>> really successful before Windows 3 (1990).
>>>
>>> Afair ieee754 can be traced back to around 1978, i.e. the design of the
>>> 8087, didn't Intel consult with Kahan around that timeframe?
>>>
>>> The original 1985 standard mostly blessed those already-implemented
>>> versions of the prior drafts, this required grandfathering a few
>>> unfortunate parts that had not been clearly defined and which had been
>>> implemented in more than one way.
>>>
>>> I.e. what is the correct way to detect subnormal results? Before or
>>> after rounding? (Imho the only sane choice is to first normalize the
>>> result so that any negative (biased) exponent is locked at zero, then
>>> round at that position.)
>>>
>>> Another unfortunate choice was in how to encode Signaling vs Quiet NaNs:
>>> Which bit in the mantissa is used and what does it mean?
>>> Is the bit set or reset for Quiet? I have seen it claimed that by having
>>> QNaNs setting the bit, any trap handler which wants to convert an SNaN
>>> to QNaN can do so by setting that bit, without having to worry about the
>>> entire mantissa then ending up zero, which would be illegal since it
>>> turns the value into Inf.
>>>
>>> The proper way to encode this, imnsho, would have been to reserve the
>>> two top mantissa bits and disregard the rest for the purpose of
>>> determining Inf vs NaN.
>>>
>>> 00 - Inf
>>> 01 - None (Missing value)
>>> 10 - QNaN
>>> 11 - SNaN
>>>
>>> This way the top mantissa bit would be sticky, always indicating a NaN
>>> (with the exp field 0x1111... of course), the None value would be
>>> treated as zero for FADD/FSUB and 1.0 for FMUL so you could multiply or
>>> add together all elements of an array and not worry about any missing
>>> elements.
>>>
>>> Most other operations would of course be invalid, giving a NaN result.
>> Don't you want x+None or x*None to be None?
> <
> Which makes None just another kind of NaN.
> {Which nobody uses anyway.}

It preserves the distinction between missing data and bogus data. There
are algorithms that are massively sped up by having a None (with
suitable None-aware operations present). While bogus is just bogus no
matter what you do with it.

Re: Mixed EGU/EGO floating-point

<2022May15.091837@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25284&group=comp.arch#25284

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: Mixed EGU/EGO floating-point
Date: Sun, 15 May 2022 07:18:37 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 33
Message-ID: <2022May15.091837@mips.complang.tuwien.ac.at>
References: <de735513-d303-42b6-b375-916b89ddafcan@googlegroups.com> <2a41be98-e9c8-4159-bef7-ba7999e278ecn@googlegroups.com> <a4400d89-ce0d-4c76-aeb2-de2d13f40318n@googlegroups.com> <2022May13.200449@mips.complang.tuwien.ac.at> <t5p9pf$52o$1@gioia.aioe.org> <t5pb7g$6og$1@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="a804ed51de3bbe163e8bef27aeacdbb8";
logging-data="3971"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18oa23sFBu8I3jMZW8Ipop9"
Cancel-Lock: sha1:7rpZjKnUMZ2Rl17EA+9U1XpJvQw=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Sun, 15 May 2022 07:18 UTC

Ivan Godard <ivan@millcomputing.com> writes:
>On 5/14/2022 3:17 PM, Terje Mathisen wrote:
>> The proper way to encode this, imnsho, would have been to reserve the
>> two top mantissa bits and disregard the rest for the purpose of
>> determining Inf vs NaN.
>>
>> 00 - Inf
>> 01 - None (Missing value)
>> 10 - QNaN
>> 11 - SNaN
>>
>> This way the top mantissa bit would be sticky, always indicating a NaN
>> (with the exp field 0x1111... of course), the None value would be
>> treated as zero for FADD/FSUB and 1.0 for FMUL so you could multiply or
>> add together all elements of an array and not worry about any missing
>> elements.
>>
>> Most other operations would of course be invalid, giving a NaN result.
>
>Don't you want x+None or x*None to be None?

No, we already have NaNs for that. He wants to be able to compute the
sum/product of all present data, and what he proposes works for that.

Having a result that tells me that there is something missing but not
bogus (the distinction you want to make) appears not as useful, but
using NaN payloads may be a way to achieve that. How much is that
standardized?

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Re: Mixed EGU/EGO floating-point

<t5qc6a$2q7$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25285&group=comp.arch#25285

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Mixed EGU/EGO floating-point
Date: Sun, 15 May 2022 03:03:07 -0500
Organization: A noiseless patient Spider
Lines: 232
Message-ID: <t5qc6a$2q7$1@dont-email.me>
References: <de735513-d303-42b6-b375-916b89ddafcan@googlegroups.com>
<2a41be98-e9c8-4159-bef7-ba7999e278ecn@googlegroups.com>
<t5p52v$shq$1@dont-email.me>
<30d6cdc7-ee4c-4b55-9ba8-8e7f236cd49fn@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 15 May 2022 08:04:26 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="22c988749cee306dd5bbb12b51208a05";
logging-data="2887"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+ukVFJu5u/SRFX21pQ2QTn"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:XiJFR+Zl7mqczvNA+w3hjCz/cgQ=
In-Reply-To: <30d6cdc7-ee4c-4b55-9ba8-8e7f236cd49fn@googlegroups.com>
Content-Language: en-US
 by: BGB - Sun, 15 May 2022 08:03 UTC

On 5/14/2022 4:29 PM, MitchAlsup wrote:
> On Saturday, May 14, 2022 at 3:57:06 PM UTC-5, BGB wrote:
>> On 5/13/2022 9:06 AM, MitchAlsup wrote:
>>> On Thursday, May 12, 2022 at 11:23:44 PM UTC-5, Quadibloc wrote:
>>>> I tried sending an E-mail about this brainstorm of mine to posituhb.org, and in
>>>> my unsuccessful attempt to do so, I discovered that John L. Gustafson's E-mail
>>>> address at the University of Singapore is no longer valid.
>>>> Also, the most recent news of him I have heard of was that he was hired by
>>>> ClearSpeed Technology, but that company no longer exists; another company
>>>> with a similar name makes AI software, not chips.
>>>>
>>>> Anyways, the brainstorm I was inspired with by reading the discussion about
>>>> NaNs is this:
>>>>
>>>> Let us consider a floating-point format which is identical to the IEEE 754 floating-point format... when the first three bits of the excess-n exponent
>>>> field are in the range [001 ... 110].
>>>>
>>>> So for the "inner 75%" of the range of IEEE 754 floats, not one bit of
>>>> precision is lost.
>>>>
>>>> In the bottom 12.5%, we have Extremely Gradual Underflow, which I have
>>>> described before.
>>>>
>>>> So if the exponent field starts with 000, _and_ the first bit of the
>>>> significand field is 1, then:
>>>>
>>>> - that first bit of the significand field corresponds to the first bit of the
>>>> significand, and is no longer "hidden", and
>>>> - the effective value of the exponent is adjusted the same way the
>>>> effective value of an all-zeroes exponent is adjusted for conventional
>>>> IEEE-754 floats; one is added to it..
>>>>
>>>> Nothing new here, except that a bit seems to be wasted for no good
>>>> reason.
>>>> But if you remember how EGU works, or if you're familiar with posits,
>>>> you will know what comes next.
>>>> If the significand field begins with "01", now the effective value of the
>>>> exponent is adjusted by how it needs to be adjusted so that the range of
>>>> floats with "01" significands is tacked on neatly to the low end of the
>>>> range of floats with "1" significands.
>>>>
>>>> Or, in posit language, exponents starting with 000 are followed by a
>>>> "regime" field before a significand field (still with a hidden first bit)
>>>> starts.
>>>>
>>>> And the same happens, but on the high (EGO - Extremely Gradual
>>>> Overflow) end, for exponents starting with 111.
>>> <
>>> Why not a hierarchy of infinities ?
>>>>
>>>> The order of bits can be shuffled around to make the resulting number
>>>> look more like a posit, if you like. (That is, put the regime field
>>>> immediately after the 000 and 111, then put in the rest of the exponent,
>>>> before starting the significand, instead of putting the regime field
>>>> after the whole exponent.)
>>>>
>>>> The idea is that now one can switch to this... 25% solution of posits...
>>>> without the complaint that, oh, noes, we're losing one bit of precision.
>>>>
>>>> Now it's only at the outer 25% of the old floating point range, which is
>>>> obviously totally irrelevant if you don't even believe that posits are
>>>> necessary and/or useful!
>>> <
>>> The most useful thing about posits is that they do not come with all
>>> the IEEE 754 baggage.
>> One could go the other direction:
>> Drop any semantic distinction between Inf and NaN;
>> Effectively, Inf is just a special case of NaN.
> <
> Infiniity has a defined magnitude :: bigger than any IEEE representable number
> NaN has a defined non-value :: not comparable to any IEEE representable
> number (including even itself).
> <
> I don't see why you would want Infinity to just be another NaN.
> <

If either Inf or NaN happens, it usually means "something has gone
wrong". Having them as distinct cases adds more special cases that need
to be detected and handled by hardware, without contributing much beyond
slightly different ways of saying "Well, the math has broken".

In practice, the distinction contributes little in terms of either
practical use cases nor is much benefit for debugging.

Though, I am still generally in favor of keeping NaN around.

>> Define "Denormal As Zero" as canonical;
> <
> This no longer saves circuitry.
> <

Denormal numbers are only really "free" if one has an FMA unit rather
than separate FADD/FMUL (so, eg, both FMUL and FADD can share the same
renormalization logic).

Though, the cheaper option here seemingly being to not have FMA, in
which case it is no longer free.

Though, I would assume the particular interpretation of DAZ as FTZ
(Flush to Zero) on the results, since the interpretation where "result
exponent may be random garbage" results in other (generally worse)
issues regarding the semantics.

Also technically cheaper to implement FMUL and FADD in a way where most
of the low order bits which "fall off the bottom" are effectively
discarded from the calculation, because only a relatively limited number
of bits below the ULP are likely to have much effect on the rounded result.

Though, FADD does need a mantissa large enough internally to deal with
integer conversion (so, say, 66 bits to deal with Binary64<->Int64
conversion).

Reusing FADD for conversion makes more sense, since FADD already has
most of the logic needed for doing conversions, and this is cheaper than
repeating the logic for a dedicated module.

For FMUL, given the relatively limited dynamic range of the results (for
normalized inputs), the renormalization step is very minimal:
Result is 1<=x<2, All is good (do nothing);
Result is 2<=x<4, Shift right by 1 bit and add 1 to exponent.

Main expensive part of FMUL being the "multiply the two mantissas
together" aspect.

>> ...
>>
>> FPU operations:
>> ADD/SUB/MUL
>> CMP, CONV
>>
>> Rounding:
>> Mostly Undefined (Rounding modes may be unsupported or ignored)
>> ADD/SUB/MUL are ULP +/- 1.5 or 2 or similar
> <
> Even the GPUs are migrating towards full IEEE 754 compliance.

This is more likely due to GPGPU uses than due to full 754 being
particularly useful for graphics processing and similar.

> <
>> Conversion to integer is always "truncate towards zero".
> <
> i = ICEIL( x );
> ...

There are ways to implement floor/ceil/... that don't depend on having
multiple rounding modes in hardware, or multiple float->int conversions.

For example, it is frequently useful to implement float->int conversion
in a way that rounds towards negative infinity, but usually this is
handled by doing something like, say:
long floor_to_long(double x)
{
if(x<0)
{
return(-(long)((-x)+0.999999999999));
}
return((long)x);
}

Or similar...

>>
>> Could still require that, for the same inputs, the operators will still
>> produce the same output each time.
>>
>> Divide and Square-Root are software, and "somewhere in generally the
>> right area" is regarded as sufficient.
> <
> Unlikely to be accepted by the market.

This likely depends on what the processor can pull off effectively.

I have yet to figure out a "good" and "cheap" way to do FDIV and FSQRT
moderately quickly in hardware.

So, doing it in software is still faster in my case.

And, in software, one can use versions which cut back on the number of
N-R stages. Say, for example, one finds that for a given calculation,
two N-R stages is sufficient (and we don't want to spend the cycles to
converge it all the way to the ULP).

>>
>>
>> Or, basically, the cheapest FPU possible which is still sufficient as to
>> be basically usable.
>>
> Will end up with the same "avid" following as FIAT here in USA.

Dunno.

>>
>> Possible optional additions:
>> Denormalized formats, which lack a hidden bit
>> More like the x87 long-double format;
>> Intermediate precision formats, such as:
>> Binary48 (S.E11.F36)
>> Binary24 (S.E8.F15).
>> If stored in a 32 or 64 bit container:
>> Will use the same format as Binary32 or Binary64
>> Will ignore the low order bits.
> <
> It seems to me that this is not a job of CPU architects, but a job
> for people who want to use quality FP implementations.


Click here to read the complete article
Re: Mixed EGU/EGO floating-point

<t5qe8t$fh0$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25286&group=comp.arch#25286

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Mixed EGU/EGO floating-point
Date: Sun, 15 May 2022 03:38:39 -0500
Organization: A noiseless patient Spider
Lines: 84
Message-ID: <t5qe8t$fh0$1@dont-email.me>
References: <de735513-d303-42b6-b375-916b89ddafcan@googlegroups.com>
<2a41be98-e9c8-4159-bef7-ba7999e278ecn@googlegroups.com>
<t5p52v$shq$1@dont-email.me>
<30d6cdc7-ee4c-4b55-9ba8-8e7f236cd49fn@googlegroups.com>
<jwvsfpbg54q.fsf-monnier+comp.arch@gnu.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 15 May 2022 08:39:57 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="22c988749cee306dd5bbb12b51208a05";
logging-data="15904"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19RGGFeDMeSofekMulMNNba"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:/7UJZOHJXm0gDWSQSsYSmwFfhls=
In-Reply-To: <jwvsfpbg54q.fsf-monnier+comp.arch@gnu.org>
Content-Language: en-US
 by: BGB - Sun, 15 May 2022 08:38 UTC

On 5/14/2022 4:58 PM, Stefan Monnier wrote:
> MitchAlsup wrote:
>> Even the GPUs are migrating towards full IEEE 754 compliance.
>
> Indeed, for pretty much all software, the direction has historically
> been firmly towards ever more bit-for-bit reproducibility (makes a lot
> of things much easier), and over the years we've learned how to get that
> at reasonable cost.
>

Though, FWIW, expecting bit-identical floating-point results between
architectures or target machines is asking for trouble.

Even an inexact implementation of the FPU will still give the same
results for each run of a given program on a given machine (even if
different machines may produce different results).

In my case, for my emulator, in a few cases I had ended up to (more
deliberately) implement the logic for some of the oddball semantics of a
few of the operators though (since they don't behave exactly the same as
their x86 counterparts).

Eg:
Conversion operators have a "slightly unusual" way of dealing with
zero exponents;
FADD/FSUB/FMUL are DAZ+FTZ;
...

In some cases, this means the emulator may basically skip using the
native hardware FPU in some of these cases, and implement the FPU
instructions using integer operations.

Though, being "fast" isn't the primary use-case for the emulator in this
case (so long as it is basically fast enough to keep up with real-time
emulation, basically good enough).

> Neural networks currently don't care so much about it because they live
> in a "mushy" world (and arguably because they need to be robust against
> small changes, so in a sense they *shouldn't* have to care), but I don't
> know if that'll still be true 20 years from now (e.g. maybe when we
> start to care about the problem of being able to reproduce existing
> results).
>

Dunno.

This is more a case though where we could ask, say, both parties to be
able to implement things with DAZ/FTZ semantics, rather than be like
"DAZ and FTZ are bad".

There was apparently (from something I saw before) for a while bugs in
some major N64 emulators resulting from them using native x86 FPU ops
for emulation, rather than implementing the proper (for N64) semantics
of DAZ and always truncating towards zero.

I guess something else I had seen was for a while PlayStation emulators
were also having issues where games wouldn't look correct if rendered on
a modern GPU (which uses perspective correct texturing rather than
affine texturing), so apparently went and had to write shaders to fake
the behavior of affine texturing on more modern GPUs.

> BGB wrote:
>> Divide and Square-Root are software, and "somewhere in generally the
>> right area" is regarded as sufficient.
>
> If you don't care about the last few bits and want to be cheap, then
> maybe you should compute with a lower precision (still using an
> operation which returns an exactly rounded result) instead.
>

In some cases, this could be viable for Binary64 -> Binary32.
This is much less likely to be viable for Binary32 -> Binary16, due to
the limited dynamic range and precision of Binary16.

In some cases, truncating Binary32 to the equivalent of 24 bits or so
could still be useful.

Re: Mixed EGU/EGO floating-point

<t5qmb9$1m30$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25287&group=comp.arch#25287

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!10O9MudpjwoXIahOJRbDvA.user.46.165.242.91.POSTED!not-for-mail
From: terje.ma...@tmsw.no (Terje Mathisen)
Newsgroups: comp.arch
Subject: Re: Mixed EGU/EGO floating-point
Date: Sun, 15 May 2022 12:57:51 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t5qmb9$1m30$1@gioia.aioe.org>
References: <de735513-d303-42b6-b375-916b89ddafcan@googlegroups.com>
<2a41be98-e9c8-4159-bef7-ba7999e278ecn@googlegroups.com>
<a4400d89-ce0d-4c76-aeb2-de2d13f40318n@googlegroups.com>
<2022May13.200449@mips.complang.tuwien.ac.at> <t5p9pf$52o$1@gioia.aioe.org>
<t5pb7g$6og$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="55392"; posting-host="10O9MudpjwoXIahOJRbDvA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101
Firefox/68.0 SeaMonkey/2.53.12
X-Notice: Filtered by postfilter v. 0.9.2
 by: Terje Mathisen - Sun, 15 May 2022 10:57 UTC

Ivan Godard wrote:
> On 5/14/2022 3:17 PM, Terje Mathisen wrote:
>> Anton Ertl wrote:
>>> Quadibloc <jsavard@ecn.ab.ca> writes:
>>>> And the IEEE 754
>>>> standard has been hugely popular, as illustrated by its wide adoption.
>>>>
>>>> This could be due to the market power of the x86 due to Windows, and
>>>> not
>>>> to any particular merit of the standard, of course; it's hard to tell.
>>>
>>> This particular claim is easy to refute: IEEE 754 won before Windows,
>>> so it did not become popular because of Windows.  Basically all new
>>> architectures after IEEE 754 (1985) and a few before (e.g., 8087
>>> (1980), 68881 (1984)) adopted IEEE 754, and in time the older
>>> architectures adopted it as well.  By contrast, Windows was not
>>> really successful before Windows 3 (1990).
>>
>> Afair ieee754 can be traced back to around 1978, i.e. the design of
>> the 8087, didn't Intel consult with Kahan around that timeframe?
>>
>> The original 1985 standard mostly blessed those already-implemented
>> versions of the prior drafts, this required grandfathering a few
>> unfortunate parts that had not been clearly defined and which had been
>> implemented in more than one way.
>>
>> I.e. what is the correct way to detect subnormal results? Before or
>> after rounding? (Imho the only sane choice is to first normalize the
>> result so that any negative (biased) exponent is locked at zero, then
>> round at that position.)
>>
>> Another unfortunate choice was in how to encode Signaling vs Quiet NaNs:
>> Which bit in the mantissa is used and what does it mean?
>> Is the bit set or reset for Quiet? I have seen it claimed that by
>> having QNaNs setting the bit, any trap handler which wants to convert
>> an SNaN to QNaN can do so by setting that bit, without having to worry
>> about the entire mantissa then ending up zero, which would be illegal
>> since it turns the value into Inf.
>>
>> The proper way to encode this, imnsho, would have been to reserve the
>> two top mantissa bits and disregard the rest for the purpose of
>> determining Inf vs NaN.
>>
>> 00 - Inf
>> 01 - None (Missing value)
>> 10 - QNaN
>> 11 - SNaN
>>
>> This way the top mantissa bit would be sticky, always indicating a NaN
>> (with the exp field 0x1111... of course), the None value would be
>> treated as zero for FADD/FSUB and 1.0 for FMUL so you could multiply
>> or add together all elements of an array and not worry about any
>> missing elements.
>>
>> Most other operations would of course be invalid, giving a NaN result.
>
> Don't you want x+None or x*None to be None?
>
I've been back & forth on this issue but lean towards letting None be
non-sticky (i.e. let it disappear when that makes sense) vs NaN which is
100% sticky.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Re: Mixed EGU/EGO floating-point

<memo.20220515153920.11824J@jgd.cix.co.uk>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25290&group=comp.arch#25290

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: jgd...@cix.co.uk (John Dallman)
Newsgroups: comp.arch
Subject: Re: Mixed EGU/EGO floating-point
Date: Sun, 15 May 2022 15:39 +0100 (BST)
Organization: A noiseless patient Spider
Lines: 16
Message-ID: <memo.20220515153920.11824J@jgd.cix.co.uk>
References: <t5qe8t$fh0$1@dont-email.me>
Reply-To: jgd@cix.co.uk
Injection-Info: reader02.eternal-september.org; posting-host="8f769413a9fc99acd515f40d9a70ab70";
logging-data="31886"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18VLjUjaZuxJn1OidGGgd1P4+NOuSRuIiI="
Cancel-Lock: sha1:LgNY+VgitZO2cVV186BYKDH7Rj0=
 by: John Dallman - Sun, 15 May 2022 14:39 UTC

In article <t5qe8t$fh0$1@dont-email.me>, cr88192@gmail.com (BGB) wrote:

> Though, FWIW, expecting bit-identical floating-point results
> between architectures or target machines is asking for trouble.

It is. A manufacturer once told us we could not expect bit-identical
results between two different kinds of FP registers on the same machine,
both usable at the same time. For ISVs who use compilers, rather than
assembler, that's deadly.

Or rather, they tried to avoid telling us that by flipping two slides
rapidly in their presentation. That really didn't go down well.
Fortunately, it turned out that the people doing the presentation were
confused, and the hardware was being sensible.

John

Re: Mixed EGU/EGO floating-point

<t5r53e$cjh$1@newsreader4.netcologne.de>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25292&group=comp.arch#25292

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!.POSTED.2001-4dd7-5c6-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de!not-for-mail
From: tkoe...@netcologne.de (Thomas Koenig)
Newsgroups: comp.arch
Subject: Re: Mixed EGU/EGO floating-point
Date: Sun, 15 May 2022 15:09:34 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <t5r53e$cjh$1@newsreader4.netcologne.de>
References: <de735513-d303-42b6-b375-916b89ddafcan@googlegroups.com>
<2a41be98-e9c8-4159-bef7-ba7999e278ecn@googlegroups.com>
<a4400d89-ce0d-4c76-aeb2-de2d13f40318n@googlegroups.com>
<2022May13.200449@mips.complang.tuwien.ac.at> <t5p9pf$52o$1@gioia.aioe.org>
<t5pb7g$6og$1@dont-email.me> <2022May15.091837@mips.complang.tuwien.ac.at>
Injection-Date: Sun, 15 May 2022 15:09:34 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2001-4dd7-5c6-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de:2001:4dd7:5c6:0:7285:c2ff:fe6c:992d";
logging-data="12913"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Sun, 15 May 2022 15:09 UTC

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:

> No, we already have NaNs for that. He wants to be able to compute the
> sum/product of all present data, and what he proposes works for that.

s = sum(a,mask=.not. ieee_is_nan(a))

works fine.

Simply ignoring values for summation would start leading to
"interesting" results when you want to have an average instead of
a sum, for example.

Introducing new classes of numbers in floating point is no substitute
for careful thought on part of the programmer.

Re: Mixed EGU/EGO floating-point

<hf9gK.27170$6dof.15166@fx13.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25295&group=comp.arch#25295

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx13.iad.POSTED!not-for-mail
From: ThatWoul...@thevillage.com (EricP)
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
Newsgroups: comp.arch
Subject: Re: Mixed EGU/EGO floating-point
References: <de735513-d303-42b6-b375-916b89ddafcan@googlegroups.com> <2a41be98-e9c8-4159-bef7-ba7999e278ecn@googlegroups.com> <a4400d89-ce0d-4c76-aeb2-de2d13f40318n@googlegroups.com> <2022May13.200449@mips.complang.tuwien.ac.at> <t5p9pf$52o$1@gioia.aioe.org> <t5pb7g$6og$1@dont-email.me> <2022May15.091837@mips.complang.tuwien.ac.at> <t5r53e$cjh$1@newsreader4.netcologne.de>
In-Reply-To: <t5r53e$cjh$1@newsreader4.netcologne.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 29
Message-ID: <hf9gK.27170$6dof.15166@fx13.iad>
X-Complaints-To: abuse@UsenetServer.com
NNTP-Posting-Date: Sun, 15 May 2022 15:46:21 UTC
Date: Sun, 15 May 2022 11:46:00 -0400
X-Received-Bytes: 1933
 by: EricP - Sun, 15 May 2022 15:46 UTC

Thomas Koenig wrote:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>
>> No, we already have NaNs for that. He wants to be able to compute the
>> sum/product of all present data, and what he proposes works for that.
>
> s = sum(a,mask=.not. ieee_is_nan(a))
>
> works fine.
>
> Simply ignoring values for summation would start leading to
> "interesting" results when you want to have an average instead of
> a sum, for example.
>
> Introducing new classes of numbers in floating point is no substitute
> for careful thought on part of the programmer.

None/Null missing values occur all the time in datasets.
Applications that can have missing values already deal with this.
Currently they just all deal with it individually.

It might be nice to standardize the behavior.

For example, how should compare operators > >= < <=
work for different values of left and right operands,
so that it makes sense for Min(a,b) and Max(a,b).

Re: Mixed EGU/EGO floating-point

<t5r9i2$e0m$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25296&group=comp.arch#25296

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: sfu...@alumni.cmu.edu.invalid (Stephen Fuld)
Newsgroups: comp.arch
Subject: Re: Mixed EGU/EGO floating-point
Date: Sun, 15 May 2022 09:25:37 -0700
Organization: A noiseless patient Spider
Lines: 29
Message-ID: <t5r9i2$e0m$1@dont-email.me>
References: <de735513-d303-42b6-b375-916b89ddafcan@googlegroups.com>
<2a41be98-e9c8-4159-bef7-ba7999e278ecn@googlegroups.com>
<a4400d89-ce0d-4c76-aeb2-de2d13f40318n@googlegroups.com>
<2022May13.200449@mips.complang.tuwien.ac.at> <t5p9pf$52o$1@gioia.aioe.org>
<t5pb7g$6og$1@dont-email.me> <2022May15.091837@mips.complang.tuwien.ac.at>
<t5r53e$cjh$1@newsreader4.netcologne.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 15 May 2022 16:25:39 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="a509753fa6896ee6e789545f2bc1ed99";
logging-data="14358"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18VY7Hwa/jP0nArnT5l/b36cd7/xRSDBX8="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Cancel-Lock: sha1:XGV7eJFM2Ua8tmaGj5Fm7tqqBcw=
In-Reply-To: <t5r53e$cjh$1@newsreader4.netcologne.de>
Content-Language: en-US
 by: Stephen Fuld - Sun, 15 May 2022 16:25 UTC

On 5/15/2022 8:09 AM, Thomas Koenig wrote:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>
>> No, we already have NaNs for that. He wants to be able to compute the
>> sum/product of all present data, and what he proposes works for that.
>
> s = sum(a,mask=.not. ieee_is_nan(a))
>
> works fine.
>
> Simply ignoring values for summation would start leading to
> "interesting" results when you want to have an average instead of
> a sum, for example.

If you can compute the sum of the non-missing values, you can certainly
compute the count of non-missing values, thus the average is as
meaningful as the sum. And, you can get an idea of "how meaningful" by
comparing the count of non-missing values to the count of all values.

> Introducing new classes of numbers in floating point is no substitute
> for careful thought on part of the programmer.

Absolutely.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Re: Mixed EGU/EGO floating-point

<t5r9vs$f19$1@newsreader4.netcologne.de>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25297&group=comp.arch#25297

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!newsreader4.netcologne.de!news.netcologne.de!.POSTED.2001-4dd7-5c6-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de!not-for-mail
From: tkoe...@netcologne.de (Thomas Koenig)
Newsgroups: comp.arch
Subject: Re: Mixed EGU/EGO floating-point
Date: Sun, 15 May 2022 16:33:00 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <t5r9vs$f19$1@newsreader4.netcologne.de>
References: <de735513-d303-42b6-b375-916b89ddafcan@googlegroups.com>
<2a41be98-e9c8-4159-bef7-ba7999e278ecn@googlegroups.com>
<a4400d89-ce0d-4c76-aeb2-de2d13f40318n@googlegroups.com>
<2022May13.200449@mips.complang.tuwien.ac.at> <t5p9pf$52o$1@gioia.aioe.org>
<t5pb7g$6og$1@dont-email.me> <2022May15.091837@mips.complang.tuwien.ac.at>
<t5r53e$cjh$1@newsreader4.netcologne.de> <hf9gK.27170$6dof.15166@fx13.iad>
Injection-Date: Sun, 15 May 2022 16:33:00 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2001-4dd7-5c6-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de:2001:4dd7:5c6:0:7285:c2ff:fe6c:992d";
logging-data="15401"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Sun, 15 May 2022 16:33 UTC

EricP <ThatWouldBeTelling@thevillage.com> schrieb:
> Thomas Koenig wrote:
>> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>
>>> No, we already have NaNs for that. He wants to be able to compute the
>>> sum/product of all present data, and what he proposes works for that.
>>
>> s = sum(a,mask=.not. ieee_is_nan(a))
>>
>> works fine.
>>
>> Simply ignoring values for summation would start leading to
>> "interesting" results when you want to have an average instead of
>> a sum, for example.
>>
>> Introducing new classes of numbers in floating point is no substitute
>> for careful thought on part of the programmer.
>
> None/Null missing values occur all the time in datasets.
> Applications that can have missing values already deal with this.
> Currently they just all deal with it individually.
>
> It might be nice to standardize the behavior.

This so strongly depends on the application that any attempt to
standardize via a new numeric type is likely to fail in the huge
majority of cases.

Re: Mixed EGU/EGO floating-point

<M1agK.11129$pqKf.3938@fx12.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25298&group=comp.arch#25298

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!news.neodome.net!feeder1.feed.usenet.farm!feed.usenet.farm!peer01.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx12.iad.POSTED!not-for-mail
From: ThatWoul...@thevillage.com (EricP)
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
Newsgroups: comp.arch
Subject: Re: Mixed EGU/EGO floating-point
References: <de735513-d303-42b6-b375-916b89ddafcan@googlegroups.com> <2a41be98-e9c8-4159-bef7-ba7999e278ecn@googlegroups.com> <a4400d89-ce0d-4c76-aeb2-de2d13f40318n@googlegroups.com> <2022May13.200449@mips.complang.tuwien.ac.at> <t5p9pf$52o$1@gioia.aioe.org> <t5pb7g$6og$1@dont-email.me> <2022May15.091837@mips.complang.tuwien.ac.at> <t5r53e$cjh$1@newsreader4.netcologne.de> <t5r9i2$e0m$1@dont-email.me>
In-Reply-To: <t5r9i2$e0m$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 25
Message-ID: <M1agK.11129$pqKf.3938@fx12.iad>
X-Complaints-To: abuse@UsenetServer.com
NNTP-Posting-Date: Sun, 15 May 2022 16:40:12 UTC
Date: Sun, 15 May 2022 12:39:55 -0400
X-Received-Bytes: 2035
 by: EricP - Sun, 15 May 2022 16:39 UTC

Stephen Fuld wrote:
> On 5/15/2022 8:09 AM, Thomas Koenig wrote:
>> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>
>>> No, we already have NaNs for that. He wants to be able to compute the
>>> sum/product of all present data, and what he proposes works for that.
>>
>> s = sum(a,mask=.not. ieee_is_nan(a))
>>
>> works fine.
>>
>> Simply ignoring values for summation would start leading to
>> "interesting" results when you want to have an average instead of
>> a sum, for example.
>
> If you can compute the sum of the non-missing values, you can certainly
> compute the count of non-missing values, thus the average is as
> meaningful as the sum. And, you can get an idea of "how meaningful" by
> comparing the count of non-missing values to the count of all values.

If all the vector values are None then the sum is None.
The count could be either 0.0 or None.
And the average could be None/0.0 = Nan or None, or None/None = None.

Re: Mixed EGU/EGO floating-point

<d8205d83-305d-4612-abae-314b009d00e9n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25302&group=comp.arch#25302

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:10a8:b0:69f:8b8b:36d9 with SMTP id h8-20020a05620a10a800b0069f8b8b36d9mr10066027qkk.93.1652634490922;
Sun, 15 May 2022 10:08:10 -0700 (PDT)
X-Received: by 2002:aca:e155:0:b0:325:6d76:da4b with SMTP id
y82-20020acae155000000b003256d76da4bmr6674331oig.125.1652634490660; Sun, 15
May 2022 10:08:10 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Sun, 15 May 2022 10:08:10 -0700 (PDT)
In-Reply-To: <t5qc6a$2q7$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:4811:b402:98e:d212;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:4811:b402:98e:d212
References: <de735513-d303-42b6-b375-916b89ddafcan@googlegroups.com>
<2a41be98-e9c8-4159-bef7-ba7999e278ecn@googlegroups.com> <t5p52v$shq$1@dont-email.me>
<30d6cdc7-ee4c-4b55-9ba8-8e7f236cd49fn@googlegroups.com> <t5qc6a$2q7$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <d8205d83-305d-4612-abae-314b009d00e9n@googlegroups.com>
Subject: Re: Mixed EGU/EGO floating-point
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Sun, 15 May 2022 17:08:10 +0000
Content-Type: text/plain; charset="UTF-8"
 by: MitchAlsup - Sun, 15 May 2022 17:08 UTC

On Sunday, May 15, 2022 at 3:04:30 AM UTC-5, BGB wrote:
> On 5/14/2022 4:29 PM, MitchAlsup wrote:
> > On Saturday, May 14, 2022 at 3:57:06 PM UTC-5, BGB wrote:
> >> On 5/13/2022 9:06 AM, MitchAlsup wrote:

> > Infiniity has a defined magnitude :: bigger than any IEEE representable number
> > NaN has a defined non-value :: not comparable to any IEEE representable
> > number (including even itself).
> > <
> > I don't see why you would want Infinity to just be another NaN.
> > <
> If either Inf or NaN happens, it usually means "something has gone
> wrong". Having them as distinct cases adds more special cases that need
> to be detected and handled by hardware, without contributing much beyond
> slightly different ways of saying "Well, the math has broken".
<
Needing to test for an explicit -0.0 has similar problems.
>
> In practice, the distinction contributes little in terms of either
> practical use cases nor is much benefit for debugging.
>
> Though, I am still generally in favor of keeping NaN around.
> >> Define "Denormal As Zero" as canonical;
> > <
> > This no longer saves circuitry.
> > <
> Denormal numbers are only really "free" if one has an FMA unit rather
> than separate FADD/FMUL (so, eg, both FMUL and FADD can share the same
> renormalization logic).
>
> Though, the cheaper option here seemingly being to not have FMA, in
> which case it is no longer free.
<
Then you are not compliant with IEEE 754-2008 so why bother with the
rest of it.
>
> Though, I would assume the particular interpretation of DAZ as FTZ
> (Flush to Zero) on the results, since the interpretation where "result
> exponent may be random garbage" results in other (generally worse)
> issues regarding the semantics.
>
>
> Also technically cheaper to implement FMUL and FADD in a way where most
> of the low order bits which "fall off the bottom" are effectively
> discarded from the calculation, because only a relatively limited number
> of bits below the ULP are likely to have much effect on the rounded result.
<
Yes, and FMAC is a bit larger than a FMUL and an FADD. But not hideously so.
>
> Though, FADD does need a mantissa large enough internally to deal with
> integer conversion (so, say, 66 bits to deal with Binary64<->Int64
> conversion).
>
> Reusing FADD for conversion makes more sense, since FADD already has
> most of the logic needed for doing conversions, and this is cheaper than
> repeating the logic for a dedicated module.
>
>
>
> For FMUL, given the relatively limited dynamic range of the results (for
> normalized inputs), the renormalization step is very minimal:
> Result is 1<=x<2, All is good (do nothing);
> Result is 2<=x<4, Shift right by 1 bit and add 1 to exponent.
<
Only if you FTZ. Otherwise if you process denorms by not "inventing"
the hidden bit, you have to scan for the hidden bit and shift the
result accordingly.
>
> Main expensive part of FMUL being the "multiply the two mantissas
> together" aspect.
> >> ...
> >>
> >> FPU operations:
> >> ADD/SUB/MUL
> >> CMP, CONV
> >>
> >> Rounding:
> >> Mostly Undefined (Rounding modes may be unsupported or ignored)
> >> ADD/SUB/MUL are ULP +/- 1.5 or 2 or similar
> > <
> > Even the GPUs are migrating towards full IEEE 754 compliance.
<
> This is more likely due to GPGPU uses than due to full 754 being
> particularly useful for graphics processing and similar.
<
I was told that GPUs were migrating towards full IEEE so as to reduce
image "shimmer".
> > <
> >> Conversion to integer is always "truncate towards zero".
> > <
> > i = ICEIL( x );
> > ...
> There are ways to implement floor/ceil/... that don't depend on having
> multiple rounding modes in hardware, or multiple float->int conversions.
<
When you look at the circuitry required, it is small. So, the best thing is
to create direct instructions for these things. Given HW than can perform
<
i = TRUNK( x );
<
adding CEIL, FLOOR, RND; adds only a few percent more gates.
>
> For example, it is frequently useful to implement float->int conversion
> in a way that rounds towards negative infinity, but usually this is
> handled by doing something like, say:
> long floor_to_long(double x)
> {
> if(x<0)
> {
> return(-(long)((-x)+0.999999999999));
> }
> return((long)x);
> }
>
> Or similar...
> >>
> >> Could still require that, for the same inputs, the operators will still
> >> produce the same output each time.
> >>
> >> Divide and Square-Root are software, and "somewhere in generally the
> >> right area" is regarded as sufficient.
> > <
> > Unlikely to be accepted by the market.
> This likely depends on what the processor can pull off effectively.
>
>
> I have yet to figure out a "good" and "cheap" way to do FDIV and FSQRT
> moderately quickly in hardware.
>
> So, doing it in software is still faster in my case.
>
>
> And, in software, one can use versions which cut back on the number of
> N-R stages. Say, for example, one finds that for a given calculation,
> two N-R stages is sufficient (and we don't want to spend the cycles to
> converge it all the way to the ULP).
> >>
> >>
> >> Or, basically, the cheapest FPU possible which is still sufficient as to
> >> be basically usable.
> >>
> > Will end up with the same "avid" following as FIAT here in USA.
> Dunno.
> >>
> >> Possible optional additions:
> >> Denormalized formats, which lack a hidden bit
> >> More like the x87 long-double format;
> >> Intermediate precision formats, such as:
> >> Binary48 (S.E11.F36)
> >> Binary24 (S.E8.F15).
> >> If stored in a 32 or 64 bit container:
> >> Will use the same format as Binary32 or Binary64
> >> Will ignore the low order bits.
> > <
> > It seems to me that this is not a job of CPU architects, but a job
> > for people who want to use quality FP implementations.
> These options would be like faster or cheaper alternatives for the full
> width versions.
>
> Though, trying to pass them off as their full-width siblings is unlikely
> to go unnoticed.
>
>
> But, for example, semantically-truncating Binary32 to 24 bits could be
> useful for SIMD in cases where Binary16 is insufficient, but where full
> Binary32 precision isn't needed, in cases where the truncated form could
> be handled in fewer clock cycles.

Re: Mixed EGU/EGO floating-point

<88600023-f705-42af-bc45-177c5f4b5209n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25303&group=comp.arch#25303

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ac8:7fd0:0:b0:2f3:fda4:6ddf with SMTP id b16-20020ac87fd0000000b002f3fda46ddfmr12394334qtk.323.1652634884359;
Sun, 15 May 2022 10:14:44 -0700 (PDT)
X-Received: by 2002:a05:6830:2467:b0:606:b036:b15f with SMTP id
x39-20020a056830246700b00606b036b15fmr4928543otr.213.1652634884153; Sun, 15
May 2022 10:14:44 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Sun, 15 May 2022 10:14:43 -0700 (PDT)
In-Reply-To: <memo.20220515153920.11824J@jgd.cix.co.uk>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:4811:b402:98e:d212;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:4811:b402:98e:d212
References: <t5qe8t$fh0$1@dont-email.me> <memo.20220515153920.11824J@jgd.cix.co.uk>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <88600023-f705-42af-bc45-177c5f4b5209n@googlegroups.com>
Subject: Re: Mixed EGU/EGO floating-point
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Sun, 15 May 2022 17:14:44 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2055
 by: MitchAlsup - Sun, 15 May 2022 17:14 UTC

On Sunday, May 15, 2022 at 9:39:25 AM UTC-5, John Dallman wrote:
> In article <t5qe8t$fh0$1...@dont-email.me>, cr8...@gmail.com (BGB) wrote:
>
> > Though, FWIW, expecting bit-identical floating-point results
> > between architectures or target machines is asking for trouble.
> It is. A manufacturer once told us we could not expect bit-identical
> results between two different kinds of FP registers on the same machine,
> both usable at the same time. For ISVs who use compilers, rather than
> assembler, that's deadly.
<
This is an argument against having more than 1 register set.
>
> Or rather, they tried to avoid telling us that by flipping two slides
> rapidly in their presentation. That really didn't go down well.
> Fortunately, it turned out that the people doing the presentation were
> confused, and the hardware was being sensible.
>
> John

Re: Mixed EGU/EGO floating-point

<98838dd1-baf3-433d-9375-996d9853b34an@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25304&group=comp.arch#25304

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:6214:2b09:b0:45b:59b:5df6 with SMTP id jx9-20020a0562142b0900b0045b059b5df6mr12270568qvb.22.1652634966245;
Sun, 15 May 2022 10:16:06 -0700 (PDT)
X-Received: by 2002:a54:4e92:0:b0:325:224c:8ff7 with SMTP id
c18-20020a544e92000000b00325224c8ff7mr6119937oiy.154.1652634966029; Sun, 15
May 2022 10:16:06 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Sun, 15 May 2022 10:16:05 -0700 (PDT)
In-Reply-To: <t5r53e$cjh$1@newsreader4.netcologne.de>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:4811:b402:98e:d212;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:4811:b402:98e:d212
References: <de735513-d303-42b6-b375-916b89ddafcan@googlegroups.com>
<2a41be98-e9c8-4159-bef7-ba7999e278ecn@googlegroups.com> <a4400d89-ce0d-4c76-aeb2-de2d13f40318n@googlegroups.com>
<2022May13.200449@mips.complang.tuwien.ac.at> <t5p9pf$52o$1@gioia.aioe.org>
<t5pb7g$6og$1@dont-email.me> <2022May15.091837@mips.complang.tuwien.ac.at> <t5r53e$cjh$1@newsreader4.netcologne.de>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <98838dd1-baf3-433d-9375-996d9853b34an@googlegroups.com>
Subject: Re: Mixed EGU/EGO floating-point
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Sun, 15 May 2022 17:16:06 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2199
 by: MitchAlsup - Sun, 15 May 2022 17:16 UTC

On Sunday, May 15, 2022 at 10:09:38 AM UTC-5, Thomas Koenig wrote:
> Anton Ertl <an...@mips.complang.tuwien.ac.at> schrieb:
> > No, we already have NaNs for that. He wants to be able to compute the
> > sum/product of all present data, and what he proposes works for that.
> s = sum(a,mask=.not. ieee_is_nan(a))
>
> works fine.
>
> Simply ignoring values for summation would start leading to
> "interesting" results when you want to have an average instead of
> a sum, for example.
<
Do you also avoid incrementing the number of values in the summation
{So that you can compute average} ?
>
> Introducing new classes of numbers in floating point is no substitute
> for careful thought on part of the programmer.

Re: Mixed EGU/EGO floating-point

<t5rco4$ga5$1@newsreader4.netcologne.de>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25305&group=comp.arch#25305

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!.POSTED.2001-4dd7-5c6-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de!not-for-mail
From: tkoe...@netcologne.de (Thomas Koenig)
Newsgroups: comp.arch
Subject: Re: Mixed EGU/EGO floating-point
Date: Sun, 15 May 2022 17:20:04 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <t5rco4$ga5$1@newsreader4.netcologne.de>
References: <t5qe8t$fh0$1@dont-email.me>
<memo.20220515153920.11824J@jgd.cix.co.uk>
Injection-Date: Sun, 15 May 2022 17:20:04 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2001-4dd7-5c6-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de:2001:4dd7:5c6:0:7285:c2ff:fe6c:992d";
logging-data="16709"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Sun, 15 May 2022 17:20 UTC

John Dallman <jgd@cix.co.uk> schrieb:
> In article <t5qe8t$fh0$1@dont-email.me>, cr88192@gmail.com (BGB) wrote:
>
>> Though, FWIW, expecting bit-identical floating-point results
>> between architectures or target machines is asking for trouble.
>
> It is. A manufacturer once told us we could not expect bit-identical
> results between two different kinds of FP registers on the same machine,
> both usable at the same time. For ISVs who use compilers, rather than
> assembler, that's deadly.

Sounds like a broken design to me. What exactly were the different
kinds of FP registers, and how were they different?

Re: Mixed EGU/EGO floating-point

<31579c1d-a5ac-4341-aae2-c23a626e7bfbn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25306&group=comp.arch#25306

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a37:c44:0:b0:69f:81cb:1d6a with SMTP id 65-20020a370c44000000b0069f81cb1d6amr9951614qkm.494.1652635391471;
Sun, 15 May 2022 10:23:11 -0700 (PDT)
X-Received: by 2002:a05:6870:5818:b0:ee:e90:46cc with SMTP id
r24-20020a056870581800b000ee0e9046ccmr7763229oap.37.1652635391291; Sun, 15
May 2022 10:23:11 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Sun, 15 May 2022 10:23:11 -0700 (PDT)
In-Reply-To: <hf9gK.27170$6dof.15166@fx13.iad>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:4811:b402:98e:d212;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:4811:b402:98e:d212
References: <de735513-d303-42b6-b375-916b89ddafcan@googlegroups.com>
<2a41be98-e9c8-4159-bef7-ba7999e278ecn@googlegroups.com> <a4400d89-ce0d-4c76-aeb2-de2d13f40318n@googlegroups.com>
<2022May13.200449@mips.complang.tuwien.ac.at> <t5p9pf$52o$1@gioia.aioe.org>
<t5pb7g$6og$1@dont-email.me> <2022May15.091837@mips.complang.tuwien.ac.at>
<t5r53e$cjh$1@newsreader4.netcologne.de> <hf9gK.27170$6dof.15166@fx13.iad>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <31579c1d-a5ac-4341-aae2-c23a626e7bfbn@googlegroups.com>
Subject: Re: Mixed EGU/EGO floating-point
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Sun, 15 May 2022 17:23:11 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 3120
 by: MitchAlsup - Sun, 15 May 2022 17:23 UTC

On Sunday, May 15, 2022 at 10:46:24 AM UTC-5, EricP wrote:
> Thomas Koenig wrote:
> > Anton Ertl <an...@mips.complang.tuwien.ac.at> schrieb:
> >
> >> No, we already have NaNs for that. He wants to be able to compute the
> >> sum/product of all present data, and what he proposes works for that.
> >
> > s = sum(a,mask=.not. ieee_is_nan(a))
> >
> > works fine.
> >
> > Simply ignoring values for summation would start leading to
> > "interesting" results when you want to have an average instead of
> > a sum, for example.
> >
> > Introducing new classes of numbers in floating point is no substitute
> > for careful thought on part of the programmer.
> None/Null missing values occur all the time in datasets.
> Applications that can have missing values already deal with this.
> Currently they just all deal with it individually.
>
> It might be nice to standardize the behavior.
>
> For example, how should compare operators > >= < <=
> work for different values of left and right operands,
<
My 66000 compare instruction has a result set of TRUE, FALSE,
and NOT_COMPARABLE. When NOT_COMPARABLE, both the
TRUE and FALSE conditions are set to zero.
<
My 66000 compare to zero Branch (and PRED) instructions
provide Branch on (!operator | NOT_COMPARABLE) so that
NaN comparisons go to the else-clause; when used typically.
<
> so that it makes sense for Min(a,b) and Max(a,b).
<
I should note that IEEE 765-2019 requires
<
MAX( -0.0, +0.0 ) to be +0.0
and
MIN( -0.0, +0.0 ) to be -0.0
and
totalorder( -0.0, +0.0 ) to be TRUE
and
totalorder( +0.0, -0.0 ) to be FALSE

Pages:12345
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor