www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Unum II announcement

reply Nick B <nick.barbalich gmail.com> writes:
"For those of you who think you have already seen unums, this is 
a different approach. Every one of the slides here is completely 
new and has not been presented before the Multicore 2016 
conference [in Wgtn, NZ]."

Here is the link as promised to the new presentation by John 
Gustafson:
http://www.johngustafson.net/unums.html


I strongly recommend that you download the presentation 
[Powerpoint, 35 pages] as there are lots of Notes with the 
presentation.

Note that the previous thread re Unums, can be found here:
https://forum.dlang.org/thread/quzsjahniokjotvtaxnu forum.dlang.org


I welcome any feedback, especially from Walter or Andrei.


cheers Nick
Feb 21 2016
next sibling parent reply Guillaume Piolat <contact gam3sfrommars.fr> writes:
On Monday, 22 February 2016 at 05:08:13 UTC, Nick B wrote:

 Here is the link as promised to the new presentation by John 
 Gustafson:
 http://www.johngustafson.net/unums.html


 I strongly recommend that you download the presentation 
 [Powerpoint, 35 pages] as there are lots of Notes with the 
 presentation.


This looks way better than the previous iteration. Waiting for 
more written material. Definately worth a second look.
Feb 22 2016
parent reply Guillaume Piolat <contact gam3sfrommars.fr> writes:
On Monday, 22 February 2016 at 11:34:25 UTC, Guillaume Piolat 
wrote:

 On Monday, 22 February 2016 at 05:08:13 UTC, Nick B wrote:

 Here is the link as promised to the new presentation by John 
 Gustafson:
 http://www.johngustafson.net/unums.html


 I strongly recommend that you download the presentation 
 [Powerpoint, 35 pages] as there are lots of Notes with the 
 presentation.


 This looks way better than the previous iteration. Waiting for 
 more written material. Definately worth a second look.


PDF link: 
http://www.pdf-archive.com/2016/02/22/multicore2016-jlg/multicore2016-jlg.pdf
Feb 22 2016
parent reply Charles <csmith.ku2013 gmail.com> writes:
On Monday, 22 February 2016 at 13:11:47 UTC, Guillaume Piolat 
wrote:

 On Monday, 22 February 2016 at 11:34:25 UTC, Guillaume Piolat 
 wrote:
 PDF link: 
 http://www.pdf-archive.com/2016/02/22/multicore2016-jlg/multicore2016-jlg.pdf


Just a heads up:

Unfortunately there's an issue with the fonts as well as some 
typos in this.

Ex: Slide 3 the infinity and minus signs don't show up in symbol 
font on my PC (Win7 w/ Office 2013). This reoccurs for every copy 
of the diagram. Slide 12, 0101 is repeated. The top one should 
actually be 0111 I believe (this error also repeats).

Aside from that, the notes were super useful, not sure if you 
could add them in there.
Feb 22 2016
parent reply Nick B <nick.barbalich gmail.com> writes:
On Monday, 22 February 2016 at 17:15:54 UTC, Charles wrote:

 On Monday, 22 February 2016 at 13:11:47 UTC, Guillaume Piolat 
 wrote:


  Slide 12, 0101 is repeated. The top

 one should actually be 0111 I believe (this error also repeats).


I will check with John re this error.


 Aside from that, the notes were super useful, not sure if you 
 could add them in there.


Its likely that we can not add the Notes to the PDF, which is why 
I recommended to everyone, to download the presentation, and read 
it via Powerpoint, then you can see all the Notes.

Nick
Feb 22 2016
parent reply Charles <csmith.ku2013 gmail.com> writes:
On Monday, 22 February 2016 at 21:27:31 UTC, Nick B wrote:

 On Monday, 22 February 2016 at 17:15:54 UTC, Charles wrote:

 On Monday, 22 February 2016 at 13:11:47 UTC, Guillaume Piolat 
 wrote:


  Slide 12, 0101 is repeated. The top

 one should actually be 0111 I believe (this error also 
 repeats).


 I will check with John re this error.


 Aside from that, the notes were super useful, not sure if you 
 could add them in there.


 Its likely that we can not add the Notes to the PDF, which is 
 why I recommended to everyone, to download the presentation, 
 and read it via Powerpoint, then you can see all the Notes.

 Nick


I saw you looking for heavy math users. I work with quite a few 
actuaries, but I probably wouldn't be able to convince them to 
use anything if there wasn't a way to use it with either SAS or 
R. SAS can import C functions, but that's about it in terms of 
interop.

If you don't find people with D, this might be an opportunity.
Feb 22 2016
parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Tuesday, 23 February 2016 at 01:08:38 UTC, Charles wrote:

 On Monday, 22 February 2016 at 21:27:31 UTC, Nick B wrote:

 On Monday, 22 February 2016 at 17:15:54 UTC, Charles wrote:

 [...]


  Slide 12, 0101 is repeated. The top

 [...]


 I will check with John re this error.


 [...]


 Its likely that we can not add the Notes to the PDF, which is 
 why I recommended to everyone, to download the presentation, 
 and read it via Powerpoint, then you can see all the Notes.

 Nick


 I saw you looking for heavy math users. I work with quite a few 
 actuaries, but I probably wouldn't be able to convince them to 
 use anything if there wasn't a way to use it with either SAS or 
 R. SAS can import C functions, but that's about it in terms of 
 interop.

 If you don't find people with D, this might be an opportunity.


There is https://bitbucket.org/bachmeil/dmdinline2
Feb 23 2016
parent reply Charles <csmith.ku2013 gmail.com> writes:
On Tuesday, 23 February 2016 at 08:49:50 UTC, John Colvin wrote:

 I saw you looking for heavy math users. I work with quite a 
 few actuaries, but I probably wouldn't be able to convince 
 them to use anything if there wasn't a way to use it with 
 either SAS or R. SAS can import C functions, but that's about 
 it in terms of interop.

 If you don't find people with D, this might be an opportunity.


 There is https://bitbucket.org/bachmeil/dmdinline2


This seems to be the opposite of what I'd need unfortunately. The 
likelihood of convincing them to use D is probably zero. In 
general, they're closer to mathematicians then programmers.
Feb 23 2016
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 23 February 2016 at 13:46:33 UTC, Charles wrote:

 This seems to be the opposite of what I'd need unfortunately. 
 The likelihood of convincing them to use D is probably zero. In 
 general, they're closer to mathematicians then programmers.


So was John von Neumann, :)

I probably wouldn't press the issue with them. D really isn't yet 
at a place for me to fully replace the stuff I could do in 
R/Matlab/Python. Maybe when this happens:
http://forum.dlang.org/post/ynbohmjwbhjglxjjclzk forum.dlang.org

To me, the case for learning D is the same as if you find 
yourself learning to call C++ from one of those languages. If 
your code runs well enough without needing C++ (for whatever 
reason, speed, memory use, etc), it probably doesn't need D 
either. It's just more fun to write D than C++.
Feb 23 2016
prev sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Tuesday, 23 February 2016 at 13:46:33 UTC, Charles wrote:

 On Tuesday, 23 February 2016 at 08:49:50 UTC, John Colvin wrote:

 I saw you looking for heavy math users. I work with quite a 
 few actuaries, but I probably wouldn't be able to convince 
 them to use anything if there wasn't a way to use it with 
 either SAS or R. SAS can import C functions, but that's about 
 it in terms of interop.

 If you don't find people with D, this might be an opportunity.


 There is https://bitbucket.org/bachmeil/dmdinline2


 This seems to be the opposite of what I'd need unfortunately.


Why not? You can easily wrap that inside some R and no-one would 
know it was D.
Feb 23 2016
parent Charles <csmith.ku2013 gmail.com> writes:
On Tuesday, 23 February 2016 at 15:12:38 UTC, John Colvin wrote:

 On Tuesday, 23 February 2016 at 13:46:33 UTC, Charles wrote:

 On Tuesday, 23 February 2016 at 08:49:50 UTC, John Colvin 
 wrote:

 If you don't find people with D, this might be an 
 opportunity.


 There is https://bitbucket.org/bachmeil/dmdinline2


 This seems to be the opposite of what I'd need unfortunately.


 Why not? You can easily wrap that inside some R and no-one 
 would know it was D.


Because I looked at the wrong example, sorry. Now that I know it 
fits the bill it just needs Windows support (beyond docker) to be 
really practical.
Feb 23 2016
prev sibling next sibling parent reply Basile Burg <basile.b gmx.com> writes:
On Monday, 22 February 2016 at 05:08:13 UTC, Nick B wrote:

 "For those of you who think you have already seen unums, this 
 is a different approach. Every one of the slides here is 
 completely new and has not been presented before the Multicore 
 2016 conference [in Wgtn, NZ]."

 Here is the link as promised to the new presentation by John 
 Gustafson:
 http://www.johngustafson.net/unums.html


 I strongly recommend that you download the presentation 
 [Powerpoint, 35 pages] as there are lots of Notes with the 
 presentation.

 Note that the previous thread re Unums, can be found here:
 https://forum.dlang.org/thread/quzsjahniokjotvtaxnu forum.dlang.org


 I welcome any feedback, especially from Walter or Andrei.


 cheers Nick


"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 ;)
Feb 22 2016
parent reply Guillaume Piolat <name.lastname gmail.com> writes:
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.
Feb 22 2016
parent John L Gustafson <john-gustafs acrc.a-star.edu.sg> writes:
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!
Feb 25 2016
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Mon, Feb 22, 2016 at 05:08:13AM +0000, Nick B via Digitalmars-d wrote:

 "For those of you who think you have already seen unums, this is a
 different approach. Every one of the slides here is completely new and
 has not been presented before the Multicore 2016 conference [in Wgtn,
 NZ]."
 
 Here is the link as promised to the new presentation by John
 Gustafson: http://www.johngustafson.net/unums.html
 
 
 I strongly recommend that you download the presentation [Powerpoint,
 35 pages] as there are lots of Notes with the presentation.


[...]

This is very interesting, and looks more promising than the previous
unum presentation.

While it's too early to hope for a hardware implementation, I'm
interested in implementing a software emulation in D.  D's powerful
templating system could let us experiment with various implementation
possibilities (e.g., different word sizes, variable size vs. fixed
sizes, etc.), to get a feel for how it would work in real-life.  With
the appropriate operator overloading, we might even be able to make it
behave as if it were a hardware type.  If the implementation is complete
enough, it might even be possible to use it in numerical code if you
don't mind the slower performance of the software emulation layer.


T

-- 
"Real programmers can write assembly code in any language. :-)" -- Larry Wall
Feb 23 2016
parent reply Nick B <nick.barbalich gmail.com> writes:
On Tuesday, 23 February 2016 at 18:35:47 UTC, H. S. Teoh wrote:


 This is very interesting, and looks more promising than the 
 previous unum presentation.

 While it's too early to hope for a hardware implementation, I'm 
 interested in implementing a software emulation in D.  D's 
 powerful templating system could let us experiment with various 
 implementation possibilities (e.g., different word sizes, 
 variable size vs. fixed sizes, etc.), to get a feel for how it 
 would work in real-life.  >> T


Excellent suggestion. At least one firm supporter.


Would Andrei or Walter like to comment ?


Please note that the error identified in this thread has now been 
corrected in the Powerpoint presentation. The error may still be 
in the PDF.

Nick
Feb 23 2016
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Feb 23, 2016 at 09:20:23PM +0000, Nick B via Digitalmars-d
wrote:

 On Tuesday, 23 February 2016 at 18:35:47 UTC, H. S. Teoh wrote:
 

This is very interesting, and looks more promising than the previous
unum presentation.

While it's too early to hope for a hardware implementation, I'm
interested in implementing a software emulation in D.  D's powerful
templating system could let us experiment with various implementation
possibilities (e.g., different word sizes, variable size vs. fixed
sizes, etc.), to get a feel for how it would work in real-life. 


 
 Excellent suggestion. At least one firm supporter.


I do want to clarify, though, that I think at this point implementing
unum in the D compiler is almost certainly premature. What I had in mind
was more of a unum library that early adopters can use to get a feel for
how things would work.  If the unum system turns out to have garner
enough support that it starts getting hardware support, then it should
be 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.


T

-- 
Questions are the beginning of intelligence, but the fear of God is the
beginning of wisdom.
Feb 23 2016
next sibling parent reply Nick B <nick.barbalich gmail.com> writes:
On Tuesday, 23 February 2016 at 21:47:10 UTC, H. S. Teoh wrote:

 On Tue, Feb 23, 2016 at 09:20:23PM +0000, Nick B via 
 Digitalmars-d wrote:

 On Tuesday, 23 February 2016 at 18:35:47 UTC, H. S. Teoh wrote:





 What I had in mind was more of a unum library that early 
 adopters can use to get a feel for how things would work. If 
 the unum system turns out to have garner enough support that it 
 starts getting hardware support, then it should be relatively 
 easy to transition it into a built-in type.


I agree that it need to become a test library first for the early 
adopters to play with.

Nick
Feb 23 2016
parent reply Robbert van Dalen <robbert eigentime.nl> writes:
Sorry to hijack this thread, but I think unum II is the best 
thing since sliced bread!

Note that, next to a D implementation, there are already unum I 
implementations in both Julia, Python (and Pony?).

I believe it would be nice to have a discussion on unum II that 
is indifferent to implementations. Currently, I haven't found any 
discussion or forum on the web that's related to unum (I or II).

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

cheers,
Robbert.
Feb 24 2016
parent reply Nick B <nick.barbalich gmail.com> writes:
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
Feb 24 2016
parent reply Robbert van Dalen <robbert eigentime.nl> writes:
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.
Feb 25 2016
parent Nick B <nick.barbalich gmail.com> writes:
On Thursday, 25 February 2016 at 10:36:08 UTC, Robbert van Dalen 
wrote:

 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:





 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:


Robbert,

I will subscribe, as you suggested.  I see that the new user 
group has been getting page views already. Thats quick.

Nick
Feb 25 2016
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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.
Feb 24 2016
parent reply Nick B <nick.barbalich gmail.com> writes:
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
Feb 24 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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.
Feb 24 2016
prev sibling parent reply Nick B <nick.barbalich gmail.com> writes:
On Tuesday, 23 February 2016 at 21:47:10 UTC, H. S. Teoh wrote:

 On Tue, Feb 23, 2016 at 09:20:23PM +0000, Nick B via 
 Digitalmars-d wrote:

 I do want to clarify, though, that I think at this point 
 implementing unum in the D compiler is almost certainly 
 premature. What I had in mind was more of a unum library that 
 early adopters can use to get a feel for how things would work.
  If the unum system turns out to have garner enough support 
 that it starts getting hardware support, then it should be 
 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.


 T


just a quick update re Unum 2.0

I hope to be able to present a link to the finalised paper on 
Unums within 24 to 48 hours.

Also here, below, is an quick update, on the software development 
on Unums from Prof Gustafson.

"Work is progressing on a reference C implementation on two 
fronts, and I am presently trying to unite the two. One is the 
coding by Isaac Yonemoto, which is being funded by my Singapore 
employer (A*STAR)... which is like having a team of about eight 
programmers, right there. He's an ultra-fast programmer and a 
crack mathematician as well, so he finds amazing shortcuts and 
insights that I don't notice. Isaac tends to code in Julia first, 
and C second. When he does C, he almost does assembler; he 
carefully studies what x86 instructions are available and 
squeezes every cycle.

The other is a small team at UC Santa Cruz with one applied math 
grad student doing most of the coding and a couple of faculty 
advisors (plus me dialing in now and then), and just about has 
plus-minus-times-divide working, the last I heard. This is part 
of an Open Source initiative, so you can bet that this will be 
documented and released into the wild the way open source 
software should be. That one is going for C directly.

There may be other efforts. Some MIT folks also created a Julia 
version of type 2 unums, and it may be almost as fast as C. There 
may be others."
Aug 09 2016
parent reply Nick B <nick.barbalich gmail.com> writes:
On Tuesday, 9 August 2016 at 09:45:58 UTC, Nick B wrote:

 On Tuesday, 23 February 2016 at 21:47:10 UTC, H. S. Teoh wrote:

 On Tue, Feb 23, 2016 at 09:20:23PM +0000, Nick B via 
 Digitalmars-d wrote:




?

 I hope to be able to present a link to the finalised paper on 
 Unums within 24 to 48 hours.


Here is the link to the paper as promised.

http://www.johngustafson.net/pubs/RadicalApproach.pdf

Please note that Figure 8 on page 9 has errors.  Three of the 
four-bit unums on this figure is wrong, as you have duplicates of 
0110, 0100, 0010.

For the correct diagram please see page 20 on  
http://www.johngustafson.net/presentations/Unums2.0.pdf

Nick
Aug 10 2016
next sibling parent reply Nick B <nick.barbalich gmail.com> writes:
On Wednesday, 10 August 2016 at 08:36:41 UTC, Nick B wrote:

 On Tuesday, 9 August 2016 at 09:45:58 UTC, Nick B wrote:
 http://www.johngustafson.net/pubs/RadicalApproach.pdf

 Please note that Figure 8 on page 9 has errors.


Please note these errors have now been corrected, and the paper  
is distributed under the terms of the Creative Commons 
Attribution-Non Commercial 3.0 License which permits 
non-commercial use, reproduction and distribution of the work 
without further permission provided the original work is properly 
cited."

Does anyone have any feedback on this paper ?

Does anyone feel that Unums should be part of D ?

Nick
Aug 14 2016
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sun, Aug 14, 2016 at 09:08:31PM +0000, Nick B via Digitalmars-d wrote:

 On Wednesday, 10 August 2016 at 08:36:41 UTC, Nick B wrote:

 On Tuesday, 9 August 2016 at 09:45:58 UTC, Nick B wrote:
 http://www.johngustafson.net/pubs/RadicalApproach.pdf
 
 Please note that Figure 8 on page 9 has errors.


 
 Please note these errors have now been corrected, and the paper  is
 distributed under the terms of the Creative Commons Attribution-Non
 Commercial 3.0 License which permits non-commercial use, reproduction
 and distribution of the work without further permission provided the
 original work is properly cited."
 
 Does anyone have any feedback on this paper ?
 
 Does anyone feel that Unums should be part of D ?


[...]

I'm personally quite interested in a D implementation of unums as
described in the paper. However, I'm unsure if it should be part of the
official D distribution, since this is still very early and the unum
system hasn't been "proven in the field" just yet.  While I certainly
hope this research would eventually revolutionize numerical
applications, it would take a long time before it would catch on, and
until then, I think it's better to have unums available as a library
rather than introducing it into the language itself. Having it available
via dub or something like that would probably be a very good idea.

Thanks to operator overloading and alias this, we can probably do a
pretty good job implementing unums as a library so that people can try
it out.  It would also be an interesting exercise to implement unums in
D and take advantage of CTFE in ways that may give us very nice
implementational possibilities.


T

-- 
A program should be written to model the concepts of the task it performs
rather than the physical world or a process because this maximizes the
potential for it to be applied to tasks that are conceptually similar and, more
important, to tasks that have not yet been conceived. -- Michael B. Allen
Aug 14 2016
parent reply Nick B <nick.barbalich gmail.com> writes:
On Monday, 15 August 2016 at 00:42:16 UTC, H. S. Teoh wrote:

 On Sun, Aug 14, 2016 at 09:08:31PM +0000, Nick B via 
 Digitalmars-d wrote:



 While I certainly hope this research would eventually 
 revolutionize numerical applications, it would take a long time 
 before it would catch on, and until then, I think it's better 
 to have unums available as a library rather than introducing it 
 into the language itself. Having it available via dub or 
 something like that would probably be a very good idea.


I totally agree.


 Thanks to operator overloading and alias this, we can probably 
 do a pretty good job implementing unums as a library so that 
 people can try it out.


It may be easier to link to the reference C implementation first.

I note that I haven't seen any feedback from Walter or Andrei. I 
can only assume that neither are interested in this subject.

Nick
Aug 16 2016
next sibling parent reply Seb <seb wilzba.ch> writes:
On Wednesday, 17 August 2016 at 03:44:48 UTC, Nick B wrote:

 On Monday, 15 August 2016 at 00:42:16 UTC, H. S. Teoh wrote:

 On Sun, Aug 14, 2016 at 09:08:31PM +0000, Nick B via 
 Digitalmars-d wrote:



 While I certainly hope this research would eventually 
 revolutionize numerical applications, it would take a long 
 time before it would catch on, and until then, I think it's 
 better to have unums available as a library rather than 
 introducing it into the language itself. Having it available 
 via dub or something like that would probably be a very good 
 idea.


 I totally agree.


 Thanks to operator overloading and alias this, we can probably 
 do a pretty good job implementing unums as a library so that 
 people can try it out.


 It may be easier to link to the reference C implementation 
 first.

 I note that I haven't seen any feedback from Walter or Andrei. 
 I can only assume that neither are interested in this subject.

 Nick


FWIW I skimmed through the paper and it looks very interesting 
and I would definitely experiment with it if it's available in 
D(ub).

If you want Andrei or Walter's opinion on whether they could in 
principle imagine Unum as part of Phobos or even the language, 
you should ping them directly via mail.
Aug 17 2016
parent reply Nick B <nick.barbalich gmail.com> writes:
On Wednesday, 17 August 2016 at 11:34:15 UTC, Seb wrote:


 If you want Andrei or Walter's opinion on whether they could in 
 principle imagine Unum as part of Phobos or even the language, 
 you should ping them directly via mail.


Agreed.
Sep 23 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/24/16 1:06 AM, Nick B wrote:

 On Wednesday, 17 August 2016 at 11:34:15 UTC, Seb wrote:


 If you want Andrei or Walter's opinion on whether they could in
 principle imagine Unum as part of Phobos or even the language, you
 should ping them directly via mail.


 Agreed.


 From what I read in the freely-available materials on Unum (actually I 
also skimmed the book) it seems to me Unum is predicated on a hardware 
implementation. It seems there would be little interest in a slow 
software emulation. -- Andrei
Sep 24 2016
parent reply Nick B <nick.barbalich gmail.com> writes:
On Saturday, 24 September 2016 at 12:56:48 UTC, Andrei 
Alexandrescu wrote:


 From what I read in the freely-available materials on Unum 
 (actually I also skimmed the book) it seems to me Unum is 
 predicated on a hardware implementation. It seems there would 
 be little interest in a slow software emulation. -- Andrei


Andrei

I suggest that now, programmers would/may have a choice: be slow 
and correct, or fast and incorrect, and that would depend if real 
accuracy is important or not, the types of problems being work 
on, and cost of failure. (see examples in John Powerpoint 
presentation).

But I will ask John G, on the types of users showing interest in 
UNUMS.

Nick
Sep 24 2016
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Sunday, 25 September 2016 at 02:22:01 UTC, Nick B wrote:

 But I will ask John G, on the types of users showing interest 
 in UNUMS.


I've been interested in it. I've got a copy of the book and I've 
read some of the papers/ppts. I'm not quite sure why I care about 
it because as far as I can tell more of my problems have come 
from speed than accuracy. Nevertheless, I have a big worry that 
the more calculations you do the greater the probability that 
small mistakes in accuracy will become bigger problems. Speed 
lets you do more things, but who knows if the things you do are 
valid.
Sep 24 2016
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/24/16 10:22 PM, Nick B wrote:

 I suggest that now, programmers would/may have a choice: be slow and
 correct, or fast and incorrect, and that would depend if real accuracy
 is important or not, the types of problems being work on, and cost of
 failure.


Let me just say it doesn't seem our policy of "slow but correct" has 
bore fruit, and I think it's time to dispense with it. There are methods 
to improve correctness through algorithmic means, but slow primitives 
you're stuck with. -- Andrei
Sep 25 2016
parent deadalnix <deadalnix gmail.com> writes:
On Sunday, 25 September 2016 at 11:00:54 UTC, Andrei Alexandrescu 
wrote:

 On 9/24/16 10:22 PM, Nick B wrote:

 I suggest that now, programmers would/may have a choice: be 
 slow and
 correct, or fast and incorrect, and that would depend if real 
 accuracy
 is important or not, the types of problems being work on, and 
 cost of
 failure.


 Let me just say it doesn't seem our policy of "slow but 
 correct" has bore fruit, and I think it's time to dispense with 
 it. There are methods to improve correctness through 
 algorithmic means, but slow primitives you're stuck with. -- 
 Andrei


<3
Oct 07 2016
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sun, Sep 25, 2016 at 02:22:01AM +0000, Nick B via Digitalmars-d wrote:

 On Saturday, 24 September 2016 at 12:56:48 UTC, Andrei Alexandrescu wrote:
 

 
 From what I read in the freely-available materials on Unum (actually
 I also skimmed the book) it seems to me Unum is predicated on a
 hardware implementation. It seems there would be little interest in
 a slow software emulation. -- Andrei


 
 Andrei
 
 I suggest that now, programmers would/may have a choice: be slow and
 correct, or fast and incorrect, and that would depend if real accuracy
 is important or not, the types of problems being work on, and cost of
 failure.  (see examples in John Powerpoint presentation).
 
 But I will ask John G, on the types of users showing interest in
 UNUMS.


[...]

I stand by my previous comment that I think Unum II should be a library
implementation in D. It's too early to know whether it will ultimately
be the way to go, so adding it to the language (along with all the
associated complexity and maintenance costs) doesn't seem like the way
to go here. Even putting it into Phobos, I think it's a bit premature. A
dub package seems like the best approach at present. I would be quite
interested in such a library solution, FWIW. If it turns out to be a
good idea, then we can consider putting it into Phobos, or perhaps even
the language.  But let's not jump the gun here.


T

-- 
Give me some fresh salted fish, please.
Sep 25 2016
parent Nick B <nick.barbalich gmail.com> writes:
On Sunday, 25 September 2016 at 21:47:15 UTC, H. S. Teoh wrote:

 A dub package seems like the best approach at present. I would 
 be quite interested in such a library solution, FWIW. If it 
 turns out to be a good idea, then we can consider putting it 
 into Phobos, or perhaps even the language.  But let's not jump 
 the gun here.


 T


Agreed.  This would be a good first step.
Just need to wait for a reference implementation and test cases 
to be developed, and published.

Nick
Sep 25 2016
prev sibling parent reply Nick B <nick.barbalich gmail.com> writes:
On Sunday, 25 September 2016 at 02:22:01 UTC, Nick B wrote:

 I suggest that now, programmers would/may have a choice: be 
 slow and correct, or fast and incorrect, and that would depend 
 if real accuracy is important or not, the types of problems 
 being work on, and cost of failure. (see examples in John 
 Powerpoint presentation).

 But I will ask John G, on the types of users showing interest 
 in UNUMS.


Hi.
Below is a copy of John's reply, which is interesting and 
insightful!

[starts]


There are some kinds of problems that can only be solved by unums 
and not by floats. Initially, those are the main focus. Examples 
include:

  * Global optimization where proof is needed that all optima have 
been found

  * Root-finding methods for fully general functions, including 
non-differentiable functions and other poorly-behaved functions

  * N-body dynamics with rigorous bounds on the orbital 
trajectories that grow only linearly in the number of time steps

  * Methods that need ultra-fast but ultra-low-precision initial 
solution with guaranteed mathematical correctness

  * Solutions of systems of nonlinear equations that also reveal 
whether the problem is stiff or unstable.

It is a misconception, more common than I would like, that the 
purpose of unums is to substitute for floats in existing floats 
and then show some kind of superiority. That can happen in terms 
of getting better answers with fewer bits, and I gave some 
examples in my book, but they won't be "faster," whatever that 
means. Floats are a guess about the answer, so they contain no 
rigorous mathematical bound on the answer; how do I compare their 
speed at guessing, with the speed of a method that is rigorous? 
Most people don't even think about the information in an answer 
as the goal of a benchmark, and just measure the time to finish 
an algorithm and print a result.

Put another way, if you don't care whether an answer is 
mathematically correct, then I can compute very fast indeed. 
Instantly, in fact.

[ends]

Insightful indeed. Of course, these types of problems may be too 
specialised for the  general D community. I really don't know for 
sure.

In light of what John has stated above, I should therefore 
correct my previous statement:

"I suggest that now, programmers going forward will have a 
choice: be slower with a rigorous mathematical bound answer, or 
use a fast and incorrect guess, and that would depend if real 
accuracy is important or not, the types of problems being work 
on, and the cost of failure".

Nick
Oct 07 2016
parent reply Nick B <nick.barbalich gmail.com> writes:
On Saturday, 8 October 2016 at 00:35:31 UTC, Nick B wrote:

 On Sunday, 25 September 2016 at 02:22:01 UTC, Nick B wrote:

 I suggest that now, programmers would/may have a choice: be 
 slow and correct, or fast and incorrect, and that would depend 
 if real accuracy is important or not, the types of problems 
 being work on, and cost of failure. (see examples in John 
 Powerpoint presentation).

 But I will ask John G, on the types of users showing interest 
 in UNUMS.


 Hi.
 Below is a copy of John's reply, which is interesting and 
 insightful!

 [starts]


 There are some kinds of problems that can only be solved by 
 unums and not by floats. Initially, those are the main focus. 
 Examples include:

  * Global optimization where proof is needed that all optima 
 have been found

  * Root-finding methods for fully general functions, including 
 non-differentiable functions and other poorly-behaved functions

  * N-body dynamics with rigorous bounds on the orbital 
 trajectories that grow only linearly in the number of time steps

  * Methods that need ultra-fast but ultra-low-precision initial 
 solution with guaranteed mathematical correctness

  * Solutions of systems of nonlinear equations that also reveal 
 whether the problem is stiff or unstable.

 It is a misconception, more common than I would like, that the 
 purpose of unums is to substitute for floats in existing floats 
 and then show some kind of superiority. That can happen in 
 terms of getting better answers with fewer bits, and I gave 
 some examples in my book, but they won't be "faster," whatever 
 that means. Floats are a guess about the answer, so they 
 contain no rigorous mathematical bound on the answer; how do I 
 compare their speed at guessing, with the speed of a method 
 that is rigorous? Most people don't even think about the 
 information in an answer as the goal of a benchmark, and just 
 measure the time to finish an algorithm and print a result.

 Put another way, if you don't care whether an answer is 
 mathematically correct, then I can compute very fast indeed. 
 Instantly, in fact.

 [ends]

 Insightful indeed. Of course, these types of problems may be 
 too specialised for the  general D community. I really don't 
 know for sure.


  I decided to pop this [John G's reply] up again, in case anyone 
was interested in  * rigorous mathematical bound [solutions] on 
[an] answer * even if this is for a small D audience.

Nick
Oct 09 2016
parent Nick B <nick.barbalich gmail.com> writes:
On Monday, 10 October 2016 at 05:32:55 UTC, Nick B wrote:

 On Saturday, 8 October 2016 at 00:35:31 UTC, Nick B wrote:

 On Sunday, 25 September 2016 at 02:22:01 UTC, Nick B wrote:

 I suggest that now, programmers would/may have a choice: be 
 slow and correct, or fast and incorrect, and that would 
 depend if real accuracy is important or not, the types of 
 problems being work on, and cost of failure. (see examples in 
 John Powerpoint presentation).







Hi Everyone.

Here is a link:  [ http://ubiquity.acm.org/article.cfm?id=2913029 
  ]
of an interview between John L Gustafson & Walter Tichy 
(Professor of Computer Science) published in the ACM Digital 
Library. Published April 2016. pdf - 11 pages.
It is a easy and informative read with a computer science lens.

I loved this quote at the end of this interview: "Unums are to 
floats what floats are to integers. They are the next step in the 
evolution of computer arithmetic". Perhaps what D will need in 
the future.


cheers
Nick
Nov 13 2016
prev sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Aug 17, 2016 at 03:44:48AM +0000, Nick B via Digitalmars-d wrote:

 On Monday, 15 August 2016 at 00:42:16 UTC, H. S. Teoh wrote:


[...]

 Thanks to operator overloading and alias this, we can probably do a
 pretty good job implementing unums as a library so that people can
 try it out.


 
 It may be easier to link to the reference C implementation first.


Easier, certainly. But I think D may offer some advantages over a purely
C implementation. It's worth exploring, at any rate.



 I note that I haven't seen any feedback from Walter or Andrei. I can
 only assume that neither are interested in this subject.


[...]

More likely, they are too busy with other things to respond.


T

-- 
The diminished 7th chord is the most flexible and fear-instilling chord. Use it
often, use it unsparingly, to subdue your listeners into submission!
Aug 17 2016
parent Nick B <nick.barbalich gmail.com> writes:
On Wednesday, 17 August 2016 at 16:03:22 UTC, H. S. Teoh wrote:

 On Wed, Aug 17, 2016 at 03:44:48AM +0000, Nick B via 
 Digitalmars-d wrote:

 On Monday, 15 August 2016 at 00:42:16 UTC, H. S. Teoh wrote:


 [...]

 Thanks to operator overloading and alias this, we can 
 probably do a pretty good job implementing unums as a 
 library so that people can try it out.


 
 It may be easier to link to the reference C implementation 
 first.


 Easier, certainly. But I think D may offer some advantages over 
 a purely C implementation. It's worth exploring, at any rate.


For anyone interested, John Gustafson has posted recently a 
Powerpoint presentation (dated 2 June 2016), which details the 
failures (both technical and dollar wise) of Floating Point 
calculations. At the end of the presentation, he details the 
state of the current implementations (eg Lawrence Livermore 
National Lab, and others etc), and the proposed implementations 
in hardware!


http://www.johngustafson.net/presentations/UnumArithmetic-ICRARseminar.pptx

enjoy.

Nick
Sep 23 2016
prev sibling parent deadalnix <deadalnix gmail.com> writes:
On Wednesday, 10 August 2016 at 08:36:41 UTC, Nick B wrote:

 For the correct diagram please see page 20 on  
 http://www.johngustafson.net/presentations/Unums2.0.pdf


This still mention:

 1-clock binary ops with no exception cases


Sure it can, but you won't like the frequency.
Aug 15 2016
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
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.

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?
Feb 23 2016
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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)


 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)
Feb 23 2016
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.)
Feb 24 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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.
Feb 24 2016
next sibling parent Nick B <nick.barbalich gmail.com> writes:
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
Feb 24 2016
prev sibling parent John L Gustafson <john-gustafs acrc.a-star.edu.sg> writes:
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.
Feb 25 2016