It seems to me that my particular problem with residue could be fixed in
the residue primitive.
13 | 10^i.20
1 10 9 12 3 4 1 10 9 12 3 4 1 10 0 0 0 0 0 0
13 | 10^i.20x
1 10 9 12 3 4 1 10 9 12 3 4 1 10 9 12 3 4 1 10
What should happen:
13 | 10^i.20
>>Out of bounds error
It seems like residue just needs to check if the floating point number is
too big to process correctly, and throw an error.
Taking a longer view, in the future, IEEE 754 floating point may be
replaced with something that handles these issues more benignly.
www.posithub.org
Inaugural Conference of Next Generation Arithmetic (CoNGA) - 28 March 2018
Focusing on unums and posits
Next Generation Arithmetic Congress Meeting
Call for Papers (Submission deadline: 17 Nov 2017)
Co-located with Supercomputing Asia (SCA) 2018 Conference, at Resort World
Convention Centre, Singapore
https://groups.google.com/forum/#!forum/unum-computing
John Gustafson's talk on Unums 3.0: Posits and Valids
http://web.stanford.edu/class/ee380/Abstracts/170201.html
Skip Cave
Cave Consulting LLC
On Sun, Oct 8, 2017 at 10:36 AM, Don Guinn <[email protected]> wrote:
> That makes good sense, and could be quite useful. The point I was trying to
> make about PLI not using terms like half precision etc., but specifying the
> needed precision is it is more hardware independent. Hardware now is
> oriented around 8 bits or multiples of that. But earlier hardware used 6
> bits. Who knows what the future may hold? It is simply specifying what you
> need and not how to get it.
>
> On Sun, Oct 8, 2017 at 9:24 AM, bill lam <[email protected]> wrote:
>
> > I am thinking of the opposite, if there are available resource,
> > adding new data type for single precision and half-precision
> > would have more benefits. My 2 cents.
> >
> > Вс, 08 окт 2017, Don Guinn написал(а):
> > > I realize this is stating the obvious, but the loss of precision is the
> > > result of 64 bit integer support. Previously "upgrading" a number from
> > > integer to float was exact. Though the residue problem for very large
> > > numbers still existed, at least it didn't involve loss of precision.
> > >
> > > It's my personal opinion that one should always be careful when working
> > > around the limits of a system. But what should be done when things go a
> > > little crazy around those limits? It is unfortunate that IEEE only
> > > implemented indeterminate (_.) when it could have set other flags in
> the
> > > unused bit configuration to indicate things like underflow, but not
> zero
> > or
> > > overflow but not infinity. But they didn't.
> > >
> > > A while back J had an option for upgrade to go to rational instead of
> > > float. It was useful in labs to more easily show interesting properties
> > of
> > > numbers. Is that option still around? If so it could be used in mod as
> an
> > > option. But it cannot be always known that the number will eventually
> be
> > > used in mod. And many transcendental verbs must go to float.
> > >
> > > Current hardware now supports quad precision float, at least some do.
> If
> > > quad float were used then the loss of precision goes away when
> converting
> > > 64 bit integer to float. But that doubles the size of float, and even
> > > though memory is getting huge it's still a concern for big problems.
> Not
> > to
> > > mention that quad float is probably slower than double float. And it
> may
> > > not be supported on all hardware, similar to the AVX problem.
> > >
> > > IBM's PLI has an interesting approach to precision. You told it (in
> > decimal
> > > digits) the largest numbers you will deal with and the number of digits
> > > after the decimal. Then it picked the best way to store the numbers
> given
> > > available hardware. In J we have 64 bit integers and floats with maybe
> 16
> > > significant decimal digits and a tremendous range for exponents. Most
> > > problems we deal with don't need such big numbers. An argument many use
> > > against J in that it uses so much memory for small numbers. Perhaps a
> > > global setting with Foreign Conjunction could give a similar choice for
> > J.
> > > I would argue against it saying things like single/double/quad float or
> > > 16/32/64 bit integers, but specify what range and significance is need
> > and
> > > let J choose how to handle it. Including totally ignoring it for some
> > > implementations. Supporting this could make the J engine larger, but
> > nobody
> > > seems too concerned with the monstrous size Qt.
> > >
> > > Whatever happened with the idea bouncing around of defining a floating
> > > point of arbitrary size and precision like with extended integers and
> > > rationals?
> > >
> > > And now IEEE has a decimal float standard. Right now it seems that only
> > IBM
> > > has implemented it in hardware. But think of all the confusion we see
> > when
> > > decimal numbers like 1.1 are not represented exactly in J.
> > >
> > > Maybe I rambled a bit. But this all involves problems when, for one
> > reason
> > > or another, the hardware can't handle needed precision.
> > > ----------------------------------------------------------------------
> > > For information about J forums see http://www.jsoftware.com/forums.htm
> >
> > --
> > regards,
> > ====================================================
> > GPG key 1024D/4434BAB3 2008-08-24
> > gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
> > gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
> > ----------------------------------------------------------------------
> > For information about J forums see http://www.jsoftware.com/forums.htm
> >
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
