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
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
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
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
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.
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
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
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
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
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
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
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.
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
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
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
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.
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
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
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.
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
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
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
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
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
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
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.
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
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 ?
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
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
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.
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
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
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
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
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
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
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]."
>
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
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
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
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
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
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).
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,
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.
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
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
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
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
"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:
51 matches
Mail list logo
