Re: Unum II announcement
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
Re: Unum II announcement
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
Re: Unum II announcement
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
Re: Unum II announcement
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
Re: Unum II announcement
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
Re: Unum II announcement
On Sun, Sep 25, 2016 at 02:22:01AM +, 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.
Re: Unum II announcement
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
Re: Unum II announcement
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.
Re: Unum II announcement
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
Re: Unum II announcement
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
Re: Unum II announcement
On Wednesday, 17 August 2016 at 16:03:22 UTC, H. S. Teoh wrote: On Wed, Aug 17, 2016 at 03:44:48AM +, 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
Re: Unum II announcement
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.
Re: Unum II announcement
On Wed, Aug 17, 2016 at 03:44:48AM +, 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!
Re: Unum II announcement
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 +, 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.
Re: Unum II announcement
On Monday, 15 August 2016 at 00:42:16 UTC, H. S. Teoh wrote: On Sun, Aug 14, 2016 at 09:08:31PM +, 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
Re: Unum II announcement
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.
Re: Unum II announcement
On Sun, Aug 14, 2016 at 09:08:31PM +, 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
Re: Unum II announcement
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
Re: Unum II announcement
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 +, 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
Re: Unum II announcement
On Tuesday, 23 February 2016 at 21:47:10 UTC, H. S. Teoh wrote: On Tue, Feb 23, 2016 at 09:20:23PM +, 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."
Re: Unum II announcement
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
Re: Unum II announcement
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.
Re: Unum II announcement
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!
Re: Unum II announcement
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.
Re: Unum II announcement
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.
Re: Unum II announcement
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
Re: Unum II announcement
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
Re: Unum II announcement
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
Re: Unum II announcement
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.
Re: Unum II announcement
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.
Re: Unum II announcement
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 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 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.)
Re: Unum II announcement
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.
Re: Unum II announcement
On Tuesday, 23 February 2016 at 21:47:10 UTC, H. S. Teoh wrote: On Tue, Feb 23, 2016 at 09:20:23PM +, 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
Re: Unum II announcement
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 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 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)
Re: Unum II announcement
On Tue, Feb 23, 2016 at 09:20:23PM +, 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.
Re: Unum II announcement
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
Re: Unum II announcement
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 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 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?
Re: Unum II announcement
On Mon, Feb 22, 2016 at 05:08:13AM +, 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
Re: Unum II announcement
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.
Re: Unum II announcement
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.
Re: Unum II announcement
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/ynbohmjwbhjglxjjc...@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++.
Re: Unum II announcement
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.
Re: Unum II announcement
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
Re: Unum II announcement
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.
Re: Unum II announcement
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
Re: Unum II announcement
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.
Re: Unum II announcement
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/quzsjahniokjotvta...@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 ;)
Re: Unum II announcement
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.
Re: Unum II announcement
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
Re: Unum II announcement
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.
Unum II announcement
"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/quzsjahniokjotvta...@forum.dlang.org I welcome any feedback, especially from Walter or Andrei. cheers Nick
