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

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.

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.

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

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?

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

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.

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)

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

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.