On Wednesday, 21 September 2016 at 10:25:39 UTC, Nick B wrote:
On Wednesday, 21 September 2016 at 07:52:18 UTC, Ethan Watson
wrote:
On Tuesday, 20 September 2016 at 22:52:57 UTC, Nic Brummell
Is there some central repository with links to the active
projects? I'll try and wrap my head fully
On Wednesday, 21 September 2016 at 07:52:18 UTC, Ethan Watson
wrote:
On Tuesday, 20 September 2016 at 22:52:57 UTC, Nic Brummell
Is there some central repository with links to the active
projects? I'll try and wrap my head fully around the math
before we get to that point though.
Ethan
On Tuesday, 20 September 2016 at 22:52:57 UTC, Nic Brummell wrote:
If anyone is still interested in this concept whatsoever
Now that we've announced we're doing multiplayer games. One of
the guys was saying we'd need a fixed-point library. My response
was "Why not unums?" Thus, in the very
On Tuesday, 20 September 2016 at 22:52:57 UTC, Nic Brummell wrote:
If anyone is still interested in this concept whatsoever, we
are holding a mini-workshop on the current developments of
Unums at the University of California Santa Cruz on Oct 24th.
We'd love to have some participation from
If anyone is still interested in this concept whatsoever, we are
holding a mini-workshop on the current developments of Unums at
the University of California Santa Cruz on Oct 24th. We'd love
to have some participation from interested parties, including
presentations on any attempts to
On Saturday, 20 February 2016 at 23:25:40 UTC, Nick B wrote:
On Wednesday, 17 February 2016 at 16:35:41 UTC, jmh530 wrote:
On Wednesday, 17 February 2016 at 08:11:21 UTC, Nick B wrote:
Having just looked at the slides again, I believe this will
break compatibility with std.math, (for
On Wednesday, 17 February 2016 at 16:35:41 UTC, jmh530 wrote:
On Wednesday, 17 February 2016 at 08:11:21 UTC, Nick B wrote:
Wrt phobos, I would just recommend that whatever unum library
gets eventually written has a companion with the equivalent of
the functions from std.math.
Having
On Wednesday, 17 February 2016 at 08:11:21 UTC, Nick B wrote:
Hi
John Gustafson was in town (Wellington, NZ) for the Multicore
World Conference 2016 ( http://www.multicoreworld.com/)
conference. I caught up with him, tonight, and spoke to him for
about two hours. Here is a quick summary of
Hi
John Gustafson was in town (Wellington, NZ) for the Multicore
World Conference 2016 ( http://www.multicoreworld.com/)
conference. I caught up with him, tonight, and spoke to him for
about two hours. Here is a quick summary of what we discussed.
John has just redesigned Unums, to address
On 17/11/15 07:52, Nick_B wrote:
On Sunday, 15 November 2015 at 04:19:21 UTC, Lionello Lunesu wrote:
On 09/11/15 04:38, Richard Davies wrote:
Yeah, I got curious too. I spend some time on it yesterday and had a
stab at writing it in D.
Hi. I send a email to John Gustafson yesterday, re this
On Sunday, 15 November 2015 at 04:19:21 UTC, Lionello Lunesu
wrote:
On 09/11/15 04:38, Richard Davies wrote:
Yeah, I got curious too. I spend some time on it yesterday and
had a stab at writing it in D.
Hi. I send a email to John Gustafson yesterday, re this thread.
He replied as follows:
On 09/11/15 04:38, Richard Davies wrote:
On Friday, 18 September 2015 at 03:19:26 UTC, Nick B wrote:
On Thursday, 17 September 2015 at 23:53:30 UTC, Anthony Di Franco wrote:
I read the whole book and did not regret it at all, but I was already
looking for good interval arithmetic
On Friday, 18 September 2015 at 03:19:26 UTC, Nick B wrote:
On Thursday, 17 September 2015 at 23:53:30 UTC, Anthony Di
Franco wrote:
I read the whole book and did not regret it at all, but I was
already looking for good interval arithmetic implementations.
I found that the techniques are
On Thursday, 17 September 2015 at 23:53:30 UTC, Anthony Di Franco
wrote:
Whether this library should be part of the standard library, I
don't know. It would seem to depend on how much people want the
standard library to support verified numerical computing. If it
is clear that verified
On Friday, 18 September 2015 at 13:39:24 UTC, skoppe wrote:
You forgot to mention that D is quite attractive for people who
just want to complain on forums.
Yes, but that does not define the language.
That's just a consequence of people having expectations and
caring about where it is
Also keep in mind that people who care about the language
complain only in the forums.
People who no longer care about the language and are upset
because they had too high expectations complain not on the
forums, but on reddit, slashdot and blogs...
So setting expectations where they belong
On Friday, 18 September 2015 at 09:25:00 UTC, Ola Fosheim Grøstad
wrote:
D is created by hackers who enjoy hacking. They don't have the
focus on correctness that verifiable-anything requires. So if
you enjoy hacking you'll have fun. If are into reliability,
stability and correctness you'll get
On Wednesday, 16 September 2015 at 23:28:23 UTC, H. S. Teoh wrote:
I'm not so sure how well this will work in practice, though,
unless we have a working prototype that proves the benefits.
What if you have a 10*10 unum matrix, and during some operation
the size of the unums in the matrix
On Tuesday, 15 September 2015 at 05:16:53 UTC, deadalnix wrote:
On Saturday, 11 July 2015 at 03:02:24 UTC, Nick B wrote:
On Thursday, 20 February 2014 at 10:10:13 UTC, Nick B wrote:
...
If you are at all interested in computer arithmetic or
numerical methods, read this book. It is destined
On Thursday, 17 September 2015 at 23:53:30 UTC, Anthony Di Franco
wrote:
I read the whole book and did not regret it at all, but I was
already looking for good interval arithmetic implementations. I
found that the techniques are not too different (though
improved in important ways) from
On Friday, 18 September 2015 at 03:19:26 UTC, Nick B wrote:
Can you describe what YOU mean by 'verified numerical
computing', as I could not find a good description of it, and
why is it important to have it.
Verified numerical computations provide results that are
guaranteed to be without
On Tuesday, 15 September 2015 at 11:13:59 UTC, Ola Fosheim
Grøstad wrote:
On Tuesday, 15 September 2015 at 10:38:23 UTC, ponce wrote:
On Tuesday, 15 September 2015 at 09:35:36 UTC, Ola Fosheim
Grøstad wrote:
http://sites.ieee.org/scv-cs/files/2013/03/Right-SizingPrecision1.pdf
That's a
On Wednesday, 16 September 2015 at 08:17:59 UTC, Don wrote:
I'm not convinced. I think they are downplaying the hardware
difficulties. Slide 34:
I don't think he is downplaying it. He has said that it will
probably take at least 10 years before it is available in
hardware. There is also a
On Wednesday, 16 September 2015 at 08:17:59 UTC, Don wrote:
On Tuesday, 15 September 2015 at 11:13:59 UTC, Ola Fosheim
Grøstad wrote:
On Tuesday, 15 September 2015 at 10:38:23 UTC, ponce wrote:
On Tuesday, 15 September 2015 at 09:35:36 UTC, Ola Fosheim
Grøstad wrote:
On Saturday, 11 July 2015 at 18:16:22 UTC, Timon Gehr wrote:
On 07/11/2015 05:07 PM, Andrei Alexandrescu wrote:
On 7/10/15 11:02 PM, Nick B wrote:
John Gustafson book is now out:
It can be found here:
On Wednesday, 16 September 2015 at 08:38:25 UTC, deadalnix wrote:
The energy comparison is bullshit. As long as you haven't
loaded the data, you don't know how wide they are. Meaning you
need either to go pessimistic and load for the worst case
scenario or do 2 round trip to memory.
That
On 09/16/2015 10:17 AM, Don wrote:
So:
...
* There is no guarantee that it would be possible to implement it in
hardware without a speed penalty, regardless of how many transistors you
throw at it (hardware analogue of Amdahl's Law)
https://en.wikipedia.org/wiki/Gustafson's_law :o)
On Wednesday, 16 September 2015 at 14:11:04 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 16 September 2015 at 08:38:25 UTC, deadalnix
wrote:
The energy comparison is bullshit. As long as you haven't
loaded the data, you don't know how wide they are. Meaning you
need either to go pessimistic
On Wednesday, 16 September 2015 at 19:40:49 UTC, Ola Fosheim
Grøstad wrote:
You can load continuously 64 bytes in a stream, decode to your
internal format and push them into the scratchpad of other
cores. You could even do this in hardware.
1/ If you load the worst case scenario, then your
On Wednesday, 16 September 2015 at 08:38:25 UTC, deadalnix wrote:
Also, predictable size mean you can split your dataset and
process it in parallel, which is impossible if sizes are random.
I don't recall how he would deal with something similar to cache
misses when you have to promote or
On Wednesday, 16 September 2015 at 19:21:59 UTC, deadalnix wrote:
No you don't. Because the streamer still need to load the unum
one by one. Maybe 2 by 2 with a fair amount of hardware
speculation (which means you are already trading energy for
performances, so the energy argument is weak).
On 09/16/2015 10:46 AM, deadalnix wrote:
On Saturday, 11 July 2015 at 18:16:22 UTC, Timon Gehr wrote:
On 07/11/2015 05:07 PM, Andrei Alexandrescu wrote:
On 7/10/15 11:02 PM, Nick B wrote:
John Gustafson book is now out:
It can be found here:
On Wednesday, 16 September 2015 at 21:12:11 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 16 September 2015 at 20:53:37 UTC, deadalnix
wrote:
On Wednesday, 16 September 2015 at 20:30:36 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 16 September 2015 at 20:06:43 UTC, deadalnix
wrote:
You know,
On Wednesday, 16 September 2015 at 08:53:24 UTC, Ola Fosheim
Grøstad wrote:
I don't think he is downplaying it. He has said that it will
probably take at least 10 years before it is available in
hardware. There is also a company called Rex Computing that are
looking at unum:
Oh hey, I
On Wednesday, 16 September 2015 at 20:35:16 UTC, Wyatt wrote:
On Wednesday, 16 September 2015 at 08:53:24 UTC, Ola Fosheim
Grøstad wrote:
I don't think he is downplaying it. He has said that it will
probably take at least 10 years before it is available in
hardware. There is also a company
On Wednesday, 16 September 2015 at 20:53:37 UTC, deadalnix wrote:
On Wednesday, 16 September 2015 at 20:30:36 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 16 September 2015 at 20:06:43 UTC, deadalnix
wrote:
You know, when you have no idea what you are talking about,
you can just move on to
On Wednesday, 16 September 2015 at 20:06:43 UTC, deadalnix wrote:
You know, when you have no idea what you are talking about, you
can just move on to something you understand.
Ah, nice move. Back to your usual habits?
Prefetching would not change anything here. The problem come
from variable
On Wednesday, 16 September 2015 at 20:30:36 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 16 September 2015 at 20:06:43 UTC, deadalnix
wrote:
You know, when you have no idea what you are talking about,
you can just move on to something you understand.
Ah, nice move. Back to your usual habits?
On Wed, Sep 16, 2015 at 08:06:42PM +, deadalnix via Digitalmars-d wrote:
[...]
> When you have a floating point unit, you get your 32 bits you get 23
> bits that go into the mantissa FU and 8 in the exponent FU. For
> instance, if you multiply floats, you send the 2 exponent into a
> adder,
On Tuesday, 15 September 2015 at 05:16:53 UTC, deadalnix wrote:
The guy seems to have good credential. Why should I read that
book ?
The sample chapter dissipates a bit the marketing cloud.
One of the ideas is that the imprecise bit encode an interval
between 2 values, hence automatically
On Tuesday, 15 September 2015 at 07:07:20 UTC, ponce wrote:
On Tuesday, 15 September 2015 at 05:16:53 UTC, deadalnix wrote:
The guy seems to have good credential. Why should I read that
book ?
The sample chapter dissipates a bit the marketing cloud.
One of the ideas is that the imprecise
On Tuesday, 15 September 2015 at 08:24:30 UTC, ponce wrote:
However if unum aren't fast, they will be only for prototyping
and the real algorithm would rely on IEEE floats with different
precision characteristics, so yeah hardware is critical.
I think he is looking into 32 bit floats for a
On Tuesday, 15 September 2015 at 07:57:01 UTC, deadalnix wrote:
On Tuesday, 15 September 2015 at 07:07:20 UTC, ponce wrote:
On Tuesday, 15 September 2015 at 05:16:53 UTC, deadalnix wrote:
The guy seems to have good credential. Why should I read that
book ?
The sample chapter dissipates a
On Tuesday, 15 September 2015 at 09:35:36 UTC, Ola Fosheim
Grøstad wrote:
http://sites.ieee.org/scv-cs/files/2013/03/Right-SizingPrecision1.pdf
That's a pretty convincing case. Who does it :)?
On Tuesday, 15 September 2015 at 10:38:23 UTC, ponce wrote:
On Tuesday, 15 September 2015 at 09:35:36 UTC, Ola Fosheim
Grøstad wrote:
http://sites.ieee.org/scv-cs/files/2013/03/Right-SizingPrecision1.pdf
That's a pretty convincing case. Who does it :)?
You:9
On Wednesday, 22 July 2015 at 20:41:42 UTC, jmh530 wrote:
On Wednesday, 22 July 2015 at 19:28:41 UTC, Andrei Alexandrescu
wrote:
On 7/13/15 1:20 AM, Nick B wrote:
All we can do now, with our limited resources, is to keep an
eye on developments and express cautious interest. If someone
able
On Saturday, 11 July 2015 at 03:02:24 UTC, Nick B wrote:
On Thursday, 20 February 2014 at 10:10:13 UTC, Nick B wrote:
Hi everyone.
John Gustafson Will be presenting a Keynote on Thursday 27th
February at 11:00 am
The abstract is here:
On 7/13/15 1:20 AM, Nick B wrote:
On Sunday, 12 July 2015 at 03:52:32 UTC, jmh530 wrote:
On Saturday, 11 July 2015 at 03:02:24 UTC, Nick B wrote:
FYI
John Gustafson book is now out:
I wouldn't have known about this way to deal with it if you hadn't
bumped this thread. So thanks, it's
On Wednesday, 22 July 2015 at 19:28:41 UTC, Andrei Alexandrescu
wrote:
On 7/13/15 1:20 AM, Nick B wrote:
All we can do now, with our limited resources, is to keep an
eye on developments and express cautious interest. If someone
able and willing comes along with a unum library for D, that
On 7/16/15 9:49 PM, Nick B wrote:
On Monday, 13 July 2015 at 21:25:12 UTC, Per Nordlöw wrote:
Can we do anything useful with unums in numeric algorithms if only
have forward or bidirectional access? Similar to algorithms such as
Levenshtein that are compatible with UTF-8 and UTF-16, Andrei? :)
On Monday, 13 July 2015 at 21:25:12 UTC, Per Nordlöw wrote:
Can we do anything useful with unums in numeric algorithms if
only have forward or bidirectional access? Similar to
algorithms such as Levenshtein that are compatible with UTF-8
and UTF-16, Andrei? :)
Question for Andrei, above, if
On Thursday, 20 February 2014 at 21:30:10 UTC, jerro wrote:
Also, because they are variable sized, you need to access them
through pointers if you want random access. Now you are reading
Unless the author was thinking in terms of D Ranges, for the
algorithms that does *not* require random
On Sunday, 12 July 2015 at 03:52:32 UTC, jmh530 wrote:
On Saturday, 11 July 2015 at 03:02:24 UTC, Nick B wrote:
FYI
John Gustafson book is now out:
I wouldn't have known about this way to deal with it if you
hadn't bumped this thread. So thanks, it's interesting (not
sure if this book
On 12 Jul 2015 14:30, Shachar Shemesh via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 11/07/15 06:02, Nick B wrote:
On Thursday, 20 February 2014 at 10:10:13 UTC, Nick B wrote:
Hi everyone.
John Gustafson Will be presenting a Keynote on Thursday 27th February
at 11:00 am
The
On 11/07/15 06:02, Nick B wrote:
On Thursday, 20 February 2014 at 10:10:13 UTC, Nick B wrote:
Hi everyone.
John Gustafson Will be presenting a Keynote on Thursday 27th February
at 11:00 am
The abstract is here:
http://openparallel.com/multicore-world-2014/speakers/john-gustafson/
There
On 7/10/15 11:02 PM, Nick B wrote:
John Gustafson book is now out:
It can be found here:
http://www.amazon.com/End-Error-Computing-Chapman-Computational/dp/1482239868/ref=sr_1_1?s=booksie=UTF8qid=1436582956sr=1-1keywords=John+Gustafsonpebp=1436583212284perid=093TDC82KFP9Y4S5PXPY
Very
On 07/11/2015 05:07 PM, Andrei Alexandrescu wrote:
On 7/10/15 11:02 PM, Nick B wrote:
John Gustafson book is now out:
It can be found here:
On Sat, 2015-07-11 at 11:07 -0400, Andrei Alexandrescu via Digitalmars
-d wrote:
On 7/10/15 11:02 PM, Nick B wrote:
John Gustafson book is now out:
It can be found here:
http://www.amazon.com/End-Error-Computing-Chapman
On Saturday, 11 July 2015 at 03:02:24 UTC, Nick B wrote:
FYI
John Gustafson book is now out:
I was just thinking about overflow (more for my own interest than
a practical reason). I wouldn't have known about this way to deal
with it if you hadn't bumped this thread. So thanks, it's
On Saturday, 11 July 2015 at 03:02:24 UTC, Nick B wrote:
If you are at all interested in computer arithmetic or
numerical methods, read this book. It is destined to be a
classic.
Sample chapter here:
http://radiofreehpc.com/tmp/TheEndofErrorSampleChapter.pdf
On Thursday, 20 February 2014 at 10:10:13 UTC, Nick B wrote:
Hi everyone.
John Gustafson Will be presenting a Keynote on Thursday 27th
February at 11:00 am
The abstract is here:
http://openparallel.com/multicore-world-2014/speakers/john-gustafson/
There is also a excellent background
Hi
I will ask my question again.
Is there any interest in this format within the D community ?
Nick
On 20 February 2014 22:46, bearophile bearophileh...@lycos.com wrote:
Iain Buclaw:
Most encoding formats use a form of discrete cosine transform, which
involves floating point maths.
I don't believe this much :-(
:-(
I looked up vorbis (very, very) briefly way of example. Most structs
On Friday, 21 February 2014 at 20:27:18 UTC, Frustrated wrote:
On Friday, 21 February 2014 at 09:04:40 UTC, Ivan Kazmenko
wrote:
Thus repeating decimal for a fraction p/q will take up to q-1
bits when we store it as a repeating decimal, but
log(p)+log(q) bits when stored as a rational number
On Saturday, 22 February 2014 at 14:17:23 UTC, Ivan Kazmenko
wrote:
Sometimes there is a non-degenerate pre-period part before the
period:
13/10 = 1.0100110011 = 1.0(1001) as a binary fraction, the
1.0 part being the pre-period and the (1001) part the
period. The same goes for decimal
On Friday, 21 February 2014 at 05:21:53 UTC, Frustrated wrote:
I think though adding a repeating bit would make it even more
accurate so that repeating decimals within the bounds of maximum
bits used could be represented perfectly. e.g., 1/3 = 0....
could be represented perfectly with such a
On Thursday, 20 February 2014 at 23:43:18 UTC, Nordlöw wrote:
The unum variable length encoding is very similar to how
msgpack packs integers. See msgpack-d on github for a superb
implementation in D.
msgpack-d is indeed a great library that makes serialization
almost instant to implement.
On Friday, 21 February 2014 at 09:04:40 UTC, Ivan Kazmenko wrote:
I believe that the repeating decimals, or better, repeating
binary fractions, will hardly be more useful than a rational
representation like p/q.
Yeah, in retrospect I would say that a binary layout like:
numberator length |
On Friday, 21 February 2014 at 07:42:36 UTC, francesco cattoglio
wrote:
On Friday, 21 February 2014 at 05:21:53 UTC, Frustrated wrote:
I think though adding a repeating bit would make it even more
accurate so that repeating decimals within the bounds of
maximum
bits used could be represented
On Friday, 21 February 2014 at 19:12:39 UTC, Frustrated wrote:
Simply not true. Maple, for example, uses constants and can
compute using constants.
You are mixing symbolic calculus and numerical computations. The
two are completely unrelated.
Basically the benefit of this(and potential)
On Friday, 21 February 2014 at 19:59:36 UTC, Francesco Cattoglio
wrote:
On Friday, 21 February 2014 at 19:12:39 UTC, Frustrated wrote:
Simply not true. Maple, for example, uses constants and can
compute using constants.
You are mixing symbolic calculus and numerical computations.
The two are
On Friday, 21 February 2014 at 09:04:40 UTC, Ivan Kazmenko wrote:
On Friday, 21 February 2014 at 05:21:53 UTC, Frustrated wrote:
I think though adding a repeating bit would make it even more
accurate so that repeating decimals within the bounds of
maximum
bits used could be represented
On Thursday, 20 February 2014 at 10:10:13 UTC, Nick B wrote:
Hi everyone.
I'm attend the SKA conference in Auckland next week and I would
like to discuss a opportunity for the D community.
Sorry if I was not clear what the SKA is. In a nutshell is a
truely massive telescope project
On Thursday, 20 February 2014 at 10:10:13 UTC, Nick B wrote:
Hi everyone.
I'm attend the SKA conference in Auckland next week and I would
like to discuss a opportunity for the D community.
I am based in Wellington, New Zealand. In Auckland, NZ, from
Tuesday to Friday next week there will
On Thursday, 20 February 2014 at 10:10:13 UTC, Nick B wrote:
Hi everyone.
I'm attend the SKA conference in Auckland next week and I would
like to discuss a opportunity for the D community.
I am based in Wellington, New Zealand. In Auckland, NZ, from
Tuesday to Friday next week there will
This is very interesting, thank you for sharing this. My
knowledge of assembly, compilers, and how machines actually work
is limited, but I knew enough about the details of floating point
to get the gist of it. The diagrams in the PDF also helped. I
hope someone does more research on this, as
Slide 6:
Even the IEEE standard (1985) made choices that look dubious now
On the other hand it's still working surprisingly well today.
Negative zero. (ugh!)
It's not bad.
Slide 15: are (Page Rank and) mp3 Players using floating point
values?
Slide 18: is harder than doing THIS
Regarding the variable length of his FP numbers, their energy
savings are beer-based numbers, I don't think they have any
experimental basis (yet).
Also, because they are variable sized, you need to access them
through pointers if you want random access. Now you are reading
both the pointer
On 20 February 2014 15:26, bearophile bearophileh...@lycos.com wrote:
Slide 6:
Even the IEEE standard (1985) made choices that look dubious now
On the other hand it's still working surprisingly well today.
Negative zero. (ugh!)
It's not bad.
Slide 15: are (Page Rank and) mp3 Players
On 2/20/2014 2:10 AM, Nick B wrote:
1. Would it be possible to implement the unum representation in D and
therefore make it a contender for the SKA ?
Yes, as a library type. I don't think it'll save any energy, though.
2. Is there any interest in this format within the D community
I
Iain Buclaw:
Most encoding formats use a form of discrete cosine transform,
which involves floating point maths.
I don't believe this much :-(
Bye,
bearophile
On Thursday, 20 February 2014 at 10:10:13 UTC, Nick B wrote:
The abstract is here:
http://openparallel.com/multicore-world-2014/speakers/john-gustafson/
The pursuit of exascale floating point is ridiculous, since we
do not need to be making 10^18 sloppy rounding errors per second;
we need
Also, because they are variable sized, you need to access them
through pointers if you want random access. Now you are reading
both the pointer and the value from memory.
We might not need random access though.
For basic linear algebra forward or bidirectional should be
enough which should
We might not need random access though.
Even if you don't need random access, you can't
store them in a packed way if you want to be able
to mutate them in place, since mathematical operations
on them can change the number of bits they take.
Depends on the application.
I suspect that in
The unum variable length encoding is very similar to how msgpack
packs integers. See msgpack-d on github for a superb
implementation in D.
On Thursday, 20 February 2014 at 23:21:26 UTC, Nordlöw wrote:
We might not need random access though.
For basic linear algebra forward or bidirectional should be
enough which should suit this format.
Depends on the application.
Basic Linear Algebra often requires sparse matrices. Sparse
On Thursday, 20 February 2014 at 23:13:20 UTC, Francesco
Cattoglio wrote:
On Thursday, 20 February 2014 at 10:10:13 UTC, Nick B wrote:
The abstract is here:
http://openparallel.com/multicore-world-2014/speakers/john-gustafson/
The pursuit of exascale floating point is ridiculous, since we
On Thursday, 20 February 2014 at 23:52:13 UTC, Chris Williams
wrote:
I don't quite understand his ubox stuff, but his unum format
doesn't really solve the 0.1 problem, except maybe by allowing
the size of his values to exceed 64-bits so that precision
errors creap up a little bit slower. (I'm
On Thursday, 20 February 2014 at 23:41:12 UTC, jerro wrote:
We might not need random access though.
Even if you don't need random access, you can't
store them in a packed way if you want to be able
to mutate them in place, since mathematical operations
on them can change the number of bits
On Friday, 21 February 2014 at 05:21:53 UTC, Frustrated wrote:
I think though adding a repeating bit would make it even more
accurate so that repeating decimals within the bounds of maximum
bits used could be represented perfectly. e.g., 1/3 = 0....
could be represented perfectly with such
90 matches
Mail list logo
