I threw together an arbitrary precision floating point conversion routine on the J wiki:
https://code.jsoftware.com/wiki/User:Raul_Miller/Floating_Point I have tested it, but I haven't *heavily* tested it, so feel free to double check its results (and maybe even let me know, if you notice an error). Also... the IEEE-has 754 standard leaves some issues open to interpretation. For example, this routine will happily give you 23 bit floating point numbers if you ask for them, even though the standard itself doesn't talk about such things. This shouldn't matter (no one is building 23 bit floating point hardware), I hope. Thanks, -- Raul On Tue, Oct 15, 2019 at 2:13 PM Raul Miller <[email protected]> wrote: > > https://www.jsoftware.com/help/dictionary/d200.htm says: > > "For a non-negative integer y, the phrase x ^ y is equivalent to */y # > x; in particular, */ on an empty list is 1, and x^0 is 1 for any x, > including 0 ." > > That turns out to be true only of the values, not of the storage formats: > > exp=: 4 :'*/y#x' > (3!:0)@exp&>/~0;1;2 > 1 1 1 > 1 1 1 > 1 4 4 > > That said, it could be argued that the implementation is at fault for > inadequate use of approximations for some examples on a 64 bit > platform, like > 2|536870913^2 > 0 > > ... but the general case of this gets into a resource constraint. And, > if you do not mind burning extra time, you can instead use: > 2|536870913^2x > 1 > > For more insight into these issues, you might start at: > https://en.wikipedia.org/wiki/Numerical_analysis > > Thanks, > > -- > Raul > > On Tue, Oct 15, 2019 at 3:19 AM ethiejiesa via Programming > <[email protected]> wrote: > > > > Playing around with type bounds, I just discovered these things about ^ > > that I don't recall seeing in the documentation: > > > > 9!:14 '' > > j807/j64nonavx/linux/release/GPL3/voidlinux.org/2019-09-30T12:27:01 > > 2&^ 1023 1024 > > 8.98847e307 _ > > (3!:0)@^&>/~ 0;1;2 > > 4 4 8 > > 4 4 8 > > 8 8 8 > > > > and from j-bot on the IRC channel: > > > > 9!:14 '' > > j701/2011-01-10/11:25 > > (3!:0)@^&>/~ 0;1;2 > > 1 1 8 > > 1 1 8 > > 4 4 8 > > > > So it seems that ^ is producing floats in general. I assume this is why > > 2^1024 is _ here, since IEEE floats have a maximum exponent of 1023 in > > their 64-bit binary representation. Does this mean that on 32-bit machines > > _ = 2^128? I suspect this is something to be aware of if developing > > cross-platform. > > > > Futhermore, looking at the type tables above, what's going on in the > > top-left corner? My naive interpretation is that ^ handles boolean > > arguments specially. I am also curious about the origin of the j701 and > > j807 difference. > > > > Stepping back a bit though, I also wonder if I am digging around in details > > that are mostly ignorable (by design). For the most part everything seems > > to Just Work TM, irrespective of the implicit type conversions, e.g. > > > > |: (, 3!:0)&-.&> 0;1;(<"0) i.2 > > 1 0 1 0 > > 1 1 4 4 > > > > For which we might say that integer 0 and 1 agree with the boolean > > arguments because probability complement agrees with boolean Not in these > > cases. > > > > About the only suprise with types I've actually stumbled upon is with > > monadic <. and how it handles tolerance differently for real vs. complex > > arguments, which I posted about in a previous comment. > > > > Does J's implicit type conversion have any other gotchas that one should be > > aware of? > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
