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

Groups > comp.compilers > #2061 > unrolled thread

Unum numbers

Back to article view | Back to comp.compilers

Contents

  Unum numbers Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2018-04-12 10:29 +0200
    Re: Unum numbers Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2018-04-12 23:13 -0400
      Re: Unum numbers Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2018-04-18 10:50 +0200

#2061 — Unum numbers

A friend just pointed me to the Universal Number formats, which may have
been subject to the IEEE 754 thread. Before I tweet my own thoughts
here, I'd like to hear more about the practice of Unum numbers. From
theory the Unum formats try to increase the number precision (around
1.0) and range (towards 0 and Inf). What are these attempts worth in
real life?

DoDi

[toc] | [next] | [standalone]

#2069

On 4/12/2018 4:29 AM, Hans-Peter Diettrich wrote:
> A friend just pointed me to the Universal Number formats, which may have
> been subject to the IEEE 754 thread. Before I tweet my own thoughts
> here, I'd like to hear more about the practice of Unum numbers. From
> theory the Unum formats try to increase the number precision (around
> 1.0) and range (towards 0 and Inf). What are these attempts worth in
> real life?

There are a few different variants of unum proposals floating around.
The original proposals were variable width, which tend to be a
spectacularly bad idea (The argument, as I understand it, is that the
memory is where you eat the most energy costs, but the reality is that
you're going to have to either deal with padding to get easy address
calculations, store indexes for easy access, or deal with high-latency
traversals, killing your ability to use data-parallel architectures like
GPUs). I understand that the newest proposal returns to fixed-width size.

Beyond that, the only thing I really know about unums is that their
inventor claims them and interval arithmetic to eliminate the need for
numerical analysts, which is contested by one of the leads of the IEEE
754 standard, and I'm not really qualified to comment on this debate.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

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

#2086

Am 13.04.2018 um 05:13 schrieb Joshua Cranmer 🐧:

> I understand that the newest proposal returns to fixed-width size.

This and further simplifications IMO didn't make the last (Posit)
variant much more practical. At least had I moved the variable-sized
Regime bitfield to the end of the number, so that exponent and
fraction keep starting at fixed bit positions. In a hardware
implementation this modification will save some shift cycles in the
compression and expansion between the external Posit format and the
internal quire registers.

> Beyond that, the only thing I really know about unums is that their
> inventor claims them and interval arithmetic to eliminate the need for
> numerical analysts, which is contested by one of the leads of the IEEE
> 754 standard, and I'm not really qualified to comment on this debate.

For Posit numbers of 32 bit size the author suggests a quire register
size of at least 256 bit, which is much larger than the 83 bit
accumulator in the IEEE hardware. For 64 bit size 512 bytes are
suggested as a minimum, and for full IEEE "double" compatibility with
11 exponent bits a size of 524288 bits is suggested. So many register
bits may help with certain numerical problems in computations, but not
when afterwards a result is stored in 64 bits again. E.g. the external
format requires at least 11 bits for the representation of all
integral numbers up to 64, with 3 more bits for every next quadruple
integer (1 regime bit, 2 fraction bits).

I'm too lazy to write a simulation of both the Posit and a super size
IEEE implementation, so that the presented benchmark codes could be
compared when calculated with the same quire register size.

DoDi

[toc] | [prev] | [standalone]

Back to top | Article view | comp.compilers

csiph-web