On 24.02.2016 00:52, Nicholas Wilson wrote:
> On Tuesday, 23 February 2016 at 20:22:19 UTC, jmh530 wrote:
>> On Monday, 22 February 2016 at 05:08:13 UTC, Nick B wrote:
>>>
>>> I strongly recommend that you download the presentation [Powerpoint,
>>> 35 pages] as there are lots of Notes with the presentation.
>>>
>>
>> I had a chance to go through the presentation a bit.
>>
>> The part about SORNs is a little confusing. For instance, suppose I
>> divide 0 by 0 using unums. What would be internally represented? I
>> assume that it has to be the SORN because it is encompasses all the
>> unums plus arbitrary ranges of unums.
>>
> 0 I think. 0/0 == 0*(/0)==0*inf and then the set of numbers
> that represents that is the empty set == 0 (i think)
>

The result should be everything. a/b is a number c such that a = b·c. If a and b are 0, c is arbitrary.


>> For instance, the 0's could be represented by 00 in the 2bit unum on
>> page 3. But alternately, they could be expressed as 0010 in the SORN
>> calculation. However, the result should be the SORN 1111 from page 7
>> because the unum is undefined.
>>
>> In my head, I imagine the process would be something like, I type
>> unum x = 0;
>> this creates a SORN variable equal to 0010 in bits.
>>
>> I then divide
>> auto y = x / x;
>> Behind the scenes, it will do the table lookup and give y as the SORN
>> representing 1111 in bits.
>>
>> If instead of the above for y, it does
>> auto z = x / 1
>> where 1 is a unum literal, then it will get the unum value of the SORN
>> in each case and do the appropriate operation as unums, get the unum
>> result, then convert that to a SORN result.
>>
>> Does this make sense?
>
> There is no conversion to a sorn result. think of unum is to sorn
> what a pointer is to an address space: a unum is a "location" in that set.
> a mapping of n bits to 2^n possible representations.
> (my understanding)
>

Unums represent either single numbers or entire segments and those segments are not closed under the arithmetic operations, so without a efficient representation for sets, Unums are not useful as a more rigorous replacement for floating point numbers.

The suggested tables for the arithmetic operations seem to map two Unums to one 16 bit SORN. (See slide 27 and 30 if in doubt.)

On Tuesday, 23 February 2016 at 21:47:10 UTC, H. S. Teoh wrote:
> relatively easy to transition it into a built-in type.  I don't see this happening for at least another 5-10, though.  It took at least as long (probably longer) for hardware manufacturers to adopt the IEEE standard, and right now unums aren't even standardized yet.

Implement unum-computing as GPU-compute-shaders. They are present in OpenGL ES 3.1, so they will become ubiquitous.

On Wednesday, 24 February 2016 at 20:59:20 UTC, Timon Gehr wrote:
> Unums represent either single numbers or entire segments and those segments are not closed under the arithmetic operations, so without a efficient representation for sets, Unums are not useful as a more rigorous replacement for floating point numbers.

I don't know if Unums are more useful than interval arithmetics, but without the 2008 edition of IEEE754 you cannot even represent interval arithmetics using floats AFAIK!

The basic idea for Unums seems that you get an estimate of the bounds and then recompute using higher precision or better algorithm when necessary. With regular floats you just get a noisy value and you need much more heavy machinery to know whether you need to recompute using a better algorithm/higher precision.

On Wednesday, 24 February 2016 at 21:07:01 UTC, Ola Fosheim Grøstad wrote:

>
> Implement unum-computing as GPU-compute-shaders. They are present in OpenGL ES 3.1, so they will become ubiquitous.

Are you sure ?
Here is a link to the spec (pdf, 505 pages) and I can find no mention of unums ?

https://www.khronos.org/registry/gles/specs/3.1/es_spec_3.1.pdf


Nick

On Wednesday, 24 February 2016 at 20:11:39 UTC, Robbert van Dalen wrote:
> Sorry to hijack this thread, but I think unum II is the best thing since sliced bread!

:)


> It would be great if Dr. Gustafson would initiate a google group so we can discuss the inner workings of unum II. If not, I guess I will start one :)

Where do you suggest that such a group hang out ?

Robert, what is your background ?

I have asked Dr. Gustafson how he would like to respond to some of the questions raised on this forum.

Nick

On Wednesday, 24 February 2016 at 21:14:46 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 24 February 2016 at 20:59:20 UTC, Timon Gehr wrote:

>
> The basic idea for Unums seems that you get an estimate of the bounds and then recompute using higher precision or better algorithm when necessary.

Agreed. This seems to be my understanding as well.

Nick

On Wednesday, 24 February 2016 at 21:37:44 UTC, Nick B wrote:
> On Wednesday, 24 February 2016 at 21:07:01 UTC, Ola Fosheim Grøstad wrote:
>
>>
>> Implement unum-computing as GPU-compute-shaders. They are present in OpenGL ES 3.1, so they will become ubiquitous.
>
> Are you sure ?
> Here is a link to the spec (pdf, 505 pages) and I can find no mention of unums ?

Sorry, I meant that  GPU-compute-shaders will be present in OpenGL ES 3.1, which would make OpenGL ES 3.1 a potentially very useful target for an unum implementation. From chapter 17:

«In addition to graphics-oriented shading operations such as vertex and fragment
shading, generic computation may be performed by the GL through the use of
compute shaders. The compute pipeline is a form of single-stage machine that runs
generic shaders.»

So, that means that _if_ one can do Unum efficiently using compute-shaders then one can have efficient Unum support on all platforms (eventually). That would make it a valid language target IMO.

On Wednesday, 24 February 2016 at 21:43:59 UTC, Nick B wrote:
> On Wednesday, 24 February 2016 at 20:11:39 UTC, Robbert van Dalen wrote:
>> Sorry to hijack this thread, but I think unum II is the best thing since sliced bread!
>
> :)
>
>
>> It would be great if Dr. Gustafson would initiate a google group so we can discuss the inner workings of unum II. If not, I guess I will start one :)
>
> Where do you suggest that such a group hang out ?
>
> Robert, what is your background ?
>
> I have asked Dr. Gustafson how he would like to respond to some of the questions raised on this forum.
>
> Nick

Nick,

I've just asked Dr. Gustafson to create a group on his behalf and he was fine with it:
https://groups.google.com/forum/#!forum/unum-computing

 It would be nice if you'd subscribe to it:

BTW. my background is 3D computer graphics and computer programming languages.
I'm interested in unum II because it appears to be a very neat (closed) algebra, even under division by 0.

I've been dabbling with division with zero in the past, and studied the wheel algebra and meadows algebra (both allow division by zero).

I'm not sure (yet) but it appears that unum II has similar nice properties like wheels and meadows. (and more!)

Robbert.

On Monday, 22 February 2016 at 18:42:03 UTC, Guillaume Piolat wrote:
> On Monday, 22 February 2016 at 17:42:07 UTC, Basile Burg wrote:
>>
>> "Reverse all bits but the first one and add 1, to reciprocate. Works without exception. +1 and –1 do not change."
>>
>> There's magic out there ;)
>
> What I don't get is: is there an exposant anymore? I don't see any mention of it.

That's part of the breakthrough: the separation of bit fields that is so deeply built into IEEE floats, has far more drawbacks then advantages. That's where all the problems with gradual underflow, wasted bit patterns on NaNs, hidden bits, and wasted bit patterns in general, stem from. It is possible to extract the exponent, in the traditional sense, by an integer divide if the lattice is one chosen to be self-similar as the dynamic range increases. The integer divide need NOT be by a power of 2, nor do you need to do the divide very often at all... think different about the way we represent reals with bit strings!

On Wednesday, 24 February 2016 at 21:14:46 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 24 February 2016 at 20:59:20 UTC, Timon Gehr wrote:
>> Unums represent either single numbers or entire segments and those segments are not closed under the arithmetic operations, so without a efficient representation for sets, Unums are not useful as a more rigorous replacement for floating point numbers.
>
> I don't know if Unums are more useful than interval arithmetics, but without the 2008 edition of IEEE754 you cannot even represent interval arithmetics using floats AFAIK!
>
> The basic idea for Unums seems that you get an estimate of the bounds and then recompute using higher precision or better algorithm when necessary. With regular floats you just get a noisy value and you need much more heavy machinery to know whether you need to recompute using a better algorithm/higher precision.

Not quite. What you describe is a very old idea. When unums lose accuracy, they become multiple unums in a row, or in a multidimensional volume (uboxes). The next calculation starts not from the "interval" described by the largest and smallest unum, but from each unum in the set; the results are then combined as a set union, which leads to bounds that grow linearly instead of exponentially.