This might be the function you need:
10 ^&.x: 18
1000000000000000000
/Erling
On 2017-10-08 19:24, Erling Hellenäs wrote:
Hi Skip!
You can create a new power verb with the power conjunction which has
an integer result. Then you can handle what an integer can handle.
Over that you will have to use extended precision.
[ 10&*^:18 [ 1
1000000000000000000
17| [ 10&*^:18 [ 1
15
3!:0 [ 10&*^:18 [ 1
4
3!:0 [ 10&*^:19 [ 1
8
There is surely a way to create a verb which creates a power function
which raises any integer to any other integer and gives an integer
result as well, if you need it, just I don't immediately know how.
Sure, there are several problems which could possibly be fixed with
the floating point version, but you want to work with integers anyway?
Cheers,
Erling Hellenäs
On 2017-10-08 18:06, 'Skip Cave' via Beta wrote:
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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
