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.

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!

John Savard

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.
>
> John Savard

On Friday, May 13, 2022 at 9:06:06 AM UTC-5, MitchAlsup wrote:
Oh and BTW:
John's email (as of Feb) is John Gustafson (johngustafson@earthlink.net)

On Friday, May 13, 2022 at 8:06:06 AM UTC-6, MitchAlsup wrote:

> Why not a hierarchy of infinities ?

I would not be able to define the arithmetic rules fully, given
that the continuum problem hasn't been solved.

Actually, though, that's probably not what you mean, and instead
you're talking about infinities all with the cardinality of aleph-null,
but behaving like calculus infinitesimals, so you can have infinity
squared and so on.

I'm not sure what the point would be; sure, NaN handling might be
potentially subject to improvement, but I was concentrating on ordinary
numbers as the most practical thing.

> The most useful thing about posits is that they do not come with all
> the IEEE 754 baggage.

It's true IEEE 754 has some complexities. But they serve the same goal
as posits have: to make numerical computation better. 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.

John Savard

On Friday, May 13, 2022 at 9:06:06 AM UTC-5, 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.
> >
> > John Savard

|> The most useful thing about posits is that they do not come with all
|> the IEEE 754 baggage.

The revised Posit standard now fixes the number of "es" bits at two for all data sizes.
Simplifies the memory to/from register format conversion somewhat.

https://posithub.org/

Still think there is room for further improvement. However it comes at a cost of
non-2's complement compare of Posits.
Have gradually leaned toward taking a bit to indicate exact versus inexact values
which allows a simpler handling of the Posit regime field.
Another plus for an exact/inexact bit is to have entirely different formats for the two.
Such as something like 754 for exacts (with no denorms) and Posit otherwise.

On Friday, May 13, 2022 at 8:08:11 AM UTC-6, MitchAlsup wrote:

> John's email (as of Feb) is

Thank you very much!
Incidentally, I've now created a page at
http://www.quadibloc.com/comp/cp020101.htm
which includes a more fully fleshed-out description of this proposed
numeric format.

John Savard

On Friday, May 13, 2022 at 11:55:47 AM UTC-6, JimBrakefield wrote:

> Have gradually leaned toward taking a bit to indicate exact versus inexact values
> which allows a simpler handling of the Posit regime field.
> Another plus for an exact/inexact bit is to have entirely different formats for the two.
> Such as something like 754 for exacts (with no denorms) and Posit otherwise.

Huh?

I was thinking that you could get proper sorting of numbers with an inexact bit as
follows:

1) Put the inexact bit at the end of the number. 0 = exact, 1 = inexact.

2) Round inexacts to the halfway points between successive exacts,
instead of to the numerical values that can be represented with exacts.

That way, all the inexacts between two exacts have the representation that
lies between the representations for the two exacts.

Or, if you think of the inexact bit as the last bit of the mantissa - all odd
mantissas are inexact, all even mantissas are exact.

John Savard

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).

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

On Friday, May 13, 2022 at 1:11:42 PM UTC-5, Quadibloc wrote:
> On Friday, May 13, 2022 at 11:55:47 AM UTC-6, JimBrakefield wrote:
>
> > Have gradually leaned toward taking a bit to indicate exact versus inexact values
> > which allows a simpler handling of the Posit regime field.
> > Another plus for an exact/inexact bit is to have entirely different formats for the two.
> > Such as something like 754 for exacts (with no denorms) and Posit otherwise.
> Huh?
>
> I was thinking that you could get proper sorting of numbers with an inexact bit as
> follows:
>
> 1) Put the inexact bit at the end of the number. 0 = exact, 1 = inexact.
>
> 2) Round inexacts to the halfway points between successive exacts,
> instead of to the numerical values that can be represented with exacts.
>
> That way, all the inexacts between two exacts have the representation that
> lies between the representations for the two exacts.
>
> Or, if you think of the inexact bit as the last bit of the mantissa - all odd
> mantissas are inexact, all even mantissas are exact.
<
This gains nothing !!
<
Consider that you lose 1 bit from the fraction in order to represent inexact.
The inexact bit tells you to prepare and operand that is 1.fraction+epsilon
Which is exactly what you would have had if you simply rounded to where
the inexact bit would have been.
>
> John Savard

On Friday, May 13, 2022 at 1:14:13 PM UTC-5, 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
<
All of the first generation RISC machines were IEEE 754 with some allowance
to compliance. These came out contemporaneously with 68881 and x87 but
later. By 1985 there was nobody making CPUs, and trying to sell them in the
millions*, that was not IEEE 754.
<
(*) leaves out IBM 360 derivatives, Boroughs, Univac, Honeywell, ...
<
> (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).
>
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

Quadibloc wrote:
> On Friday, May 13, 2022 at 11:55:47 AM UTC-6, JimBrakefield wrote:
>
>> Have gradually leaned toward taking a bit to indicate exact versus inexact values
>> which allows a simpler handling of the Posit regime field.
>> Another plus for an exact/inexact bit is to have entirely different formats for the two.
>> Such as something like 754 for exacts (with no denorms) and Posit otherwise.
>
> Huh?
>
> I was thinking that you could get proper sorting of numbers with an inexact bit as
> follows:
>
> 1) Put the inexact bit at the end of the number. 0 = exact, 1 = inexact.
>
> 2) Round inexacts to the halfway points between successive exacts,
> instead of to the numerical values that can be represented with exacts.
>
> That way, all the inexacts between two exacts have the representation that
> lies between the representations for the two exacts.
>
> Or, if you think of the inexact bit as the last bit of the mantissa - all odd
> mantissas are inexact, all even mantissas are exact.
>
> John Savard

The Posit inexact bits were sticky so how did they get reset?
I looked through that Posit book and didn't see a rule.
Because it looked to me as though once they got set,
they would propagate through a calculation.
And if so then they would pretty much always get set on a result.

On Friday, May 13, 2022 at 3:18:31 PM UTC-5, MitchAlsup wrote:
> On Friday, May 13, 2022 at 1:11:42 PM UTC-5, Quadibloc wrote:
> > On Friday, May 13, 2022 at 11:55:47 AM UTC-6, JimBrakefield wrote:
> >
> > > Have gradually leaned toward taking a bit to indicate exact versus inexact values
> > > which allows a simpler handling of the Posit regime field.
> > > Another plus for an exact/inexact bit is to have entirely different formats for the two.
> > > Such as something like 754 for exacts (with no denorms) and Posit otherwise.
> > Huh?
> >
> > I was thinking that you could get proper sorting of numbers with an inexact bit as
> > follows:
> >
> > 1) Put the inexact bit at the end of the number. 0 = exact, 1 = inexact.
> >
> > 2) Round inexacts to the halfway points between successive exacts,
> > instead of to the numerical values that can be represented with exacts.
> >
> > That way, all the inexacts between two exacts have the representation that
> > lies between the representations for the two exacts.
> >
> > Or, if you think of the inexact bit as the last bit of the mantissa - all odd
> > mantissas are inexact, all even mantissas are exact.
> <
> This gains nothing !!
> <
> Consider that you lose 1 bit from the fraction in order to represent inexact.
> The inexact bit tells you to prepare and operand that is 1.fraction+epsilon
> Which is exactly what you would have had if you simply rounded to where
> the inexact bit would have been.
> >
> > John Savard

|> This gains nothing !!
The other choice is to have distinct load and store floating instructions for exact and inexact.

|> > Or, if you think of the inexact bit as the last bit of the mantissa - all odd
|> > mantissas are inexact, all even mantissas are exact.
Yeah!

On Friday, May 13, 2022 at 4:54:45 PM UTC-5, EricP wrote:
> Quadibloc wrote:
> > On Friday, May 13, 2022 at 11:55:47 AM UTC-6, JimBrakefield wrote:
> >
> >> Have gradually leaned toward taking a bit to indicate exact versus inexact values
> >> which allows a simpler handling of the Posit regime field.
> >> Another plus for an exact/inexact bit is to have entirely different formats for the two.
> >> Such as something like 754 for exacts (with no denorms) and Posit otherwise.
> >
> > Huh?
> >
> > I was thinking that you could get proper sorting of numbers with an inexact bit as
> > follows:
> >
> > 1) Put the inexact bit at the end of the number. 0 = exact, 1 = inexact.
> >
> > 2) Round inexacts to the halfway points between successive exacts,
> > instead of to the numerical values that can be represented with exacts.
> >
> > That way, all the inexacts between two exacts have the representation that
> > lies between the representations for the two exacts.
> >
> > Or, if you think of the inexact bit as the last bit of the mantissa - all odd
> > mantissas are inexact, all even mantissas are exact.
> >
> > John Savard
> The Posit inexact bits were sticky so how did they get reset?
<
You store something that is exact into the memory/register.
<
> I looked through that Posit book and didn't see a rule.
<
Obvious rules don't need to be specified.
<
> Because it looked to me as though once they got set,
> they would propagate through a calculation.
> And if so then they would pretty much always get set on a result.
<
One of the crazy things about IEEE 754 is that if you go out of your
way to write exact floating point arithmetic sequences (twoAdd, twoMul),
you invariably end up setting the inexact bit. My 66000 does not set
the inexact bit (or raise exception) when all of the bits of the result
get stored in the result containers. So,
<
CARRY R7,{{0}}
FMUL R6,R5,R4
<
Delivers the exact product to R6 and R7 and does not set the inexact bit.

On Friday, May 13, 2022 at 5:29:49 PM UTC-5, MitchAlsup wrote:
> On Friday, May 13, 2022 at 4:54:45 PM UTC-5, EricP wrote:
> > Quadibloc wrote:
> > > On Friday, May 13, 2022 at 11:55:47 AM UTC-6, JimBrakefield wrote:
> > >
> > >> Have gradually leaned toward taking a bit to indicate exact versus inexact values
> > >> which allows a simpler handling of the Posit regime field.
> > >> Another plus for an exact/inexact bit is to have entirely different formats for the two.
> > >> Such as something like 754 for exacts (with no denorms) and Posit otherwise.
> > >
> > > Huh?
> > >
> > > I was thinking that you could get proper sorting of numbers with an inexact bit as
> > > follows:
> > >
> > > 1) Put the inexact bit at the end of the number. 0 = exact, 1 = inexact.
> > >
> > > 2) Round inexacts to the halfway points between successive exacts,
> > > instead of to the numerical values that can be represented with exacts.
> > >
> > > That way, all the inexacts between two exacts have the representation that
> > > lies between the representations for the two exacts.
> > >
> > > Or, if you think of the inexact bit as the last bit of the mantissa - all odd
> > > mantissas are inexact, all even mantissas are exact.
> > >
> > > John Savard
> > The Posit inexact bits were sticky so how did they get reset?
> <
> You store something that is exact into the memory/register.
> <
> > I looked through that Posit book and didn't see a rule.
> <
> Obvious rules don't need to be specified.
> <
> > Because it looked to me as though once they got set,
> > they would propagate through a calculation.
> > And if so then they would pretty much always get set on a result.
> <
> One of the crazy things about IEEE 754 is that if you go out of your
> way to write exact floating point arithmetic sequences (twoAdd, twoMul),
> you invariably end up setting the inexact bit. My 66000 does not set
> the inexact bit (or raise exception) when all of the bits of the result
> get stored in the result containers. So,
> <
> CARRY R7,{{0}}
> FMUL R6,R5,R4
> <
> Delivers the exact product to R6 and R7 and does not set the inexact bit.

I think the 754 committee overlooked the need (and support thereof) for extended precision.

Also the typical status register should be replaced by a "residue" register, whether within the
register file or separate; collecting floating-point residue, remainder, carry and overflow.
Not arguing for or against the way MY 66000 does it.

According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>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).

MS-DOS was certainly popular in the 1980s. I was one of the authors of
Javelin, a time-series modelling package for MS DOS in the mid-1980s,
and all of the numeric stuff depended on 8087 arithmetic. There was a
hack to trap to an emulator if you didn't have a real 8087 but I think
the people who did stuff like bond yields usually did.

At the time, the alternatives were IBM hex arithmetic which only ran on
expensive mainframes and has well-known performance issues, and I suppose
the formats that DEC used on the PDP-11 and Vax. Who else was selling
significant amounts of FP hardware in the 1980s? Moto didn't ship the
68881 until 1984 which was pretty late.

R's,
John
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

In article <t5mqb6$1jpo$1@gal.iecc.com>, johnl@taugh.com (John Levine)
wrote:

> At the time, the alternatives were IBM hex arithmetic which only
> ran on expensive mainframes and has well-known performance issues,

Also on Data General's bigger machines, and some other minis.

> and I suppose the formats that DEC used on the PDP-11 and Vax.

Those are recognizably ancestors of IEEE. They have a few more mantissa
bits and correspondingly fewer in the exponent, but work the same way.

> Who else was selling significant amounts of FP hardware in the 1980s?

Lots of smaller players, with a wide variety of formats. Some are here:

https://nssdc.gsfc.nasa.gov/nssdc/formats/

John

John Levine <johnl@taugh.com> writes:
>According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>>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).
>
>MS-DOS was certainly popular in the 1980s.

True, but the claim did not mention MS-DOS.

The IBM PC, PC XT, and its clones were popular and had an 8087 socket,
so these machines were the way to go if you needed to do a lot of FP
and could not afford a minicomputer with an FPU (e.g., a VAX).

But according to
<https://en.wikipedia.org/wiki/IEEE_754-1985#History>, other vendors
were already worried about Intel's work in the late 70s, i.e., before
the IBM PC, and set up a standardization effort. That standardization
work then included Kahan and Intel and adopted a large part of Intel's
work (Intel's 80-bit format was not as standardized as the 64 and
32-bit formats).

It's interesting that Intel, who AFAIK played a much smaller role in
the late 70s than today would worry the other vendors so much. I
guess the perspective of a low-cost micro eating the FP lunch of minis
and maybe even mainframes was worrying even if they did not consider
micros to be proper computers otherwise.

>At the time, the alternatives were IBM hex arithmetic which only ran on
>expensive mainframes and has well-known performance issues, and I suppose
>the formats that DEC used on the PDP-11 and Vax. Who else was selling
>significant amounts of FP hardware in the 1980s? Moto didn't ship the
>68881 until 1984 which was pretty late.

All the mini companies and all the mainframe companies had computers
with FP units, but of course DEC and IBM were the big players in these
markets.

And of course all the RISCs (except ARM AFAIK) had FPUs, but that was
from 1985 onwards, and by that time IEEE 754 had already won.

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

MitchAlsup wrote:
> On Friday, May 13, 2022 at 4:54:45 PM UTC-5, EricP wrote:
>> Quadibloc wrote:
>>> On Friday, May 13, 2022 at 11:55:47 AM UTC-6, JimBrakefield wrote:
>>>
>>>> Have gradually leaned toward taking a bit to indicate exact versus inexact values
>>>> which allows a simpler handling of the Posit regime field.
>>>> Another plus for an exact/inexact bit is to have entirely different formats for the two.
>>>> Such as something like 754 for exacts (with no denorms) and Posit otherwise.
>>>
>>> Huh?
>>>
>>> I was thinking that you could get proper sorting of numbers with an inexact bit as
>>> follows:
>>>
>>> 1) Put the inexact bit at the end of the number. 0 = exact, 1 = inexact.
>>>
>>> 2) Round inexacts to the halfway points between successive exacts,
>>> instead of to the numerical values that can be represented with exacts.
>>>
>>> That way, all the inexacts between two exacts have the representation that
>>> lies between the representations for the two exacts.
>>>
>>> Or, if you think of the inexact bit as the last bit of the mantissa - all odd
>>> mantissas are inexact, all even mantissas are exact.
>>>
>>> John Savard
>> The Posit inexact bits were sticky so how did they get reset?
> <
> You store something that is exact into the memory/register.
> <
>> I looked through that Posit book and didn't see a rule.
> <
> Obvious rules don't need to be specified.
> <
>> Because it looked to me as though once they got set,
>> they would propagate through a calculation.
>> And if so then they would pretty much always get set on a result.
> <
> One of the crazy things about IEEE 754 is that if you go out of your
> way to write exact floating point arithmetic sequences (twoAdd, twoMul),
> you invariably end up setting the inexact bit. My 66000 does not set
> the inexact bit (or raise exception) when all of the bits of the result
> get stored in the result containers. So,
> <
> CARRY R7,{{0}}
> FMUL R6,R5,R4
> <
> Delivers the exact product to R6 and R7 and does not set the inexact bit.
>
For the exact same reason, the new Augmented[Addition|Multiplication]
operations (two-in, two-out) will report exact results for everything
except borderline operations, like gradual underflow of subnormals.

Your CARRY is of course a wonderful way to implement these: Not just
nice to have here but generally extremely useful.

Terje

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

MitchAlsup wrote:
> On Friday, May 13, 2022 at 4:54:45 PM UTC-5, EricP wrote:
>> Quadibloc wrote:
>>> On Friday, May 13, 2022 at 11:55:47 AM UTC-6, JimBrakefield wrote:
>>>
>>>> Have gradually leaned toward taking a bit to indicate exact versus inexact values
>>>> which allows a simpler handling of the Posit regime field.
>>>> Another plus for an exact/inexact bit is to have entirely different formats for the two.
>>>> Such as something like 754 for exacts (with no denorms) and Posit otherwise.
>>> Huh?
>>>
>>> I was thinking that you could get proper sorting of numbers with an inexact bit as
>>> follows:
>>>
>>> 1) Put the inexact bit at the end of the number. 0 = exact, 1 = inexact.
>>>
>>> 2) Round inexacts to the halfway points between successive exacts,
>>> instead of to the numerical values that can be represented with exacts.
>>>
>>> That way, all the inexacts between two exacts have the representation that
>>> lies between the representations for the two exacts.
>>>
>>> Or, if you think of the inexact bit as the last bit of the mantissa - all odd
>>> mantissas are inexact, all even mantissas are exact.
>>>
>>> John Savard
>> The Posit inexact bits were sticky so how did they get reset?
> <
> You store something that is exact into the memory/register.

Ok, so explicit reset only.
Functions Exact() and Inexact() to clear or set it,
and IsExact() to test it.

> <
>> I looked through that Posit book and didn't see a rule.
> <
> Obvious rules don't need to be specified.
> <
>> Because it looked to me as though once they got set,
>> they would propagate through a calculation.
>> And if so then they would pretty much always get set on a result.
> <
> One of the crazy things about IEEE 754 is that if you go out of your
> way to write exact floating point arithmetic sequences (twoAdd, twoMul),
> you invariably end up setting the inexact bit. My 66000 does not set
> the inexact bit (or raise exception) when all of the bits of the result
> get stored in the result containers. So,
> <
> CARRY R7,{{0}}
> FMUL R6,R5,R4
> <
> Delivers the exact product to R6 and R7 and does not set the inexact bit.

But the Posit inexact bit, which John is referring to, is in
the lsb of the mantissa not in a separate status register.
And if it almost always gets set, how is that not just making
the mantissa 1 bit smaller and tacking a "1" on the end?

For an Inexact lsb to be useful, calculations would check it
every so often (otherwise why have it on every value) and do what?
And they would sprinkle Exact() calls about to clear it every so often.
Presumably there would be guidelines for when to toss the Inexact bit.

On Friday, May 13, 2022 at 6:41:29 PM UTC-5, John Levine wrote:
> According to Anton Ertl <an...@mips.complang.tuwien.ac.at>:
> >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).
> MS-DOS was certainly popular in the 1980s. I was one of the authors of
> Javelin, a time-series modelling package for MS DOS in the mid-1980s,
> and all of the numeric stuff depended on 8087 arithmetic. There was a
> hack to trap to an emulator if you didn't have a real 8087 but I think
> the people who did stuff like bond yields usually did.
>
> At the time, the alternatives were IBM hex arithmetic which only ran on
> expensive mainframes and has well-known performance issues, and I suppose
> the formats that DEC used on the PDP-11 and Vax. Who else was selling
> significant amounts of FP hardware in the 1980s? Moto didn't ship the
> 68881 until 1984 which was pretty late.
>
> R's,
> John
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

|>Who else was selling > significant amounts of FP hardware in the 1980s?
https://en.wikipedia.org/wiki/Floating_Point_Systems

> Consider that you lose 1 bit from the fraction in order to represent inexact.
> The inexact bit tells you to prepare and operand that is 1.fraction+epsilon
> Which is exactly what you would have had if you simply rounded to where
> the inexact bit would have been.

This reminds me of the "round to odd" used in:

https://blog.sigplan.org/2022/04/28/one-polynomial-approximation-to-produce-correctly-rounded-results-for-multiple-representations-and-rounding-modes/

They're not arguing for this "round to odd" behavior as the best choice
for the actual end result, but they take advantage of the fact that at
the cost of 2 extra bits of precision this rounding mode gives you
a number from which you can correctly round to any other (at least 2 bit
shorter) length in any rounding mode without suffering from any double
rounding error.

This lets them return "perfect" (½ ULP) results for sin/cos/... with any
rounding mode without having to use slightly different tables/formulas
for every different rounding.

Stefan

JimBrakefield wrote:
> On Friday, May 13, 2022 at 6:41:29 PM UTC-5, John Levine wrote:
>> According to Anton Ertl <an...@mips.complang.tuwien.ac.at>:
>>> 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).
>> MS-DOS was certainly popular in the 1980s. I was one of the authors of
>> Javelin, a time-series modelling package for MS DOS in the mid-1980s,
>> and all of the numeric stuff depended on 8087 arithmetic. There was a
>> hack to trap to an emulator if you didn't have a real 8087 but I think
>> the people who did stuff like bond yields usually did.
>>
>> At the time, the alternatives were IBM hex arithmetic which only ran on
>> expensive mainframes and has well-known performance issues, and I suppose
>> the formats that DEC used on the PDP-11 and Vax. Who else was selling
>> significant amounts of FP hardware in the 1980s? Moto didn't ship the
>> 68881 until 1984 which was pretty late.
>>
>> R's,
>> John
>> --
>> Regards,
>> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
>> Please consider the environment before reading this e-mail. https://jl.ly
>
> |>Who else was selling > significant amounts of FP hardware in the 1980s?
> https://en.wikipedia.org/wiki/Floating_Point_Systems

https://en.wikipedia.org/wiki/Weitek

On Friday, May 13, 2022 at 11:23:56 PM UTC+3, MitchAlsup wrote:
> On Friday, May 13, 2022 at 1:14:13 PM UTC-5, 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
> <
> All of the first generation RISC machines were IEEE 754 with some allowance
> to compliance. These came out contemporaneously with 68881 and x87 but
> later. By 1985 there was nobody making CPUs, and trying to sell them in the
> millions*, that was not IEEE 754.

That is true for rather narrow definition of "CPU" that does not include TMS320C30/C40 series
that definitely was sold in higher numbers than S/360 and all dwarfs combined, and likely
by orders of magnitude.
I think, but not sure, that Motorola's 96000 series was also non- IEEE 754, but this one was not
particularly successful.
On the other hand, ADI 21000/SHARC series was IEEE-754 based from the beginning.

> <
> (*) leaves out IBM 360 derivatives, Boroughs, Univac, Honeywell, ...
> <
> > (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).
> >
> > - anton
> > --
> > 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> > Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On Saturday, May 14, 2022 at 2:41:29 AM UTC+3, John Levine wrote:
> According to Anton Ertl <an...@mips.complang.tuwien.ac.at>:
> >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).
> MS-DOS was certainly popular in the 1980s. I was one of the authors of
> Javelin, a time-series modelling package for MS DOS in the mid-1980s,
> and all of the numeric stuff depended on 8087 arithmetic. There was a
> hack to trap to an emulator if you didn't have a real 8087 but I think
> the people who did stuff like bond yields usually did.
>
> At the time, the alternatives were IBM hex arithmetic which only ran on
> expensive mainframes and has well-known performance issues, and I suppose
> the formats that DEC used on the PDP-11 and Vax. Who else was selling
> significant amounts of FP hardware in the 1980s?

Depends on definition of "significant".
Supercomputer vendors (Cray, NEC, other Japanese vendors and one or two Soviet) we
not selling many machines, but rather significant number of FLOPs. Of course, significant
by standards of the 1st half of 80s, i.e, before the famous attack of the 'Killer Micros'.

> Moto didn't ship the
> 68881 until 1984 which was pretty late.
>
> R's,
> John
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

Stefan Monnier wrote:
>> Consider that you lose 1 bit from the fraction in order to represent inexact.
>> The inexact bit tells you to prepare and operand that is 1.fraction+epsilon
>> Which is exactly what you would have had if you simply rounded to where
>> the inexact bit would have been.
>
> This reminds me of the "round to odd" used in:
>
> https://blog.sigplan.org/2022/04/28/one-polynomial-approximation-to-produce-correctly-rounded-results-for-multiple-representations-and-rounding-modes/
>
> They're not arguing for this "round to odd" behavior as the best choice
> for the actual end result, but they take advantage of the fact that at
> the cost of 2 extra bits of precision this rounding mode gives you
> a number from which you can correctly round to any other (at least 2 bit
> shorter) length in any rounding mode without suffering from any double
> rounding error.
>
> This lets them return "perfect" (½ ULP) results for sin/cos/... with any
> rounding mode without having to use slightly different tables/formulas
> for every different rounding.

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.

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.

Terje

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