On Nov 29, 2007 3:40 AM, Oleg Kobchenko <[EMAIL PROTECTED]> wrote:
> What would be the J equivalent to Javascript
>
> 11259375.071111083.toString(16)
> abcdef.123456
>
> That is the "inverse" of
>
> 0j10 ": 16babcdef.123456
> 11259375.0711110830
Here's how I would approach this:
First off, I would construct a J model for breaking hexadecimal
integers into digits. (I am not showing results here, you can
16 | 16babcdef
15
16 (<[EMAIL PROTECTED] , |) 16babcdef
703710 15
16 ((<[EMAIL PROTECTED] , |)&{. , [EMAIL PROTECTED])^:2: 16babcdef
43981 14 15
16 ((<[EMAIL PROTECTED] , |)&{. , [EMAIL PROTECTED])^:([ <: [EMAIL
PROTECTED])^:_: 16babcdef
10 11 12 13 14 15
This does not deal with negative numbers, but that representation issues is
straightforward, and should be dealt with at a higher level. Now to go the
other direction:
16 * 16b0.123456
1.13778
16 (0 1&#:)@* 16b0.123456
1 0.137777
16 (}:@] , (0 1&#:)@*&{:)^:2: 16b0.123456
1 2 0.204437
16 (}:@] , (0 1&#:)@*&{:)^:(0 < {:@])^:9: 16b0.123456
1 2 3 4 5 6 0
This leaves us with a trailing zero (or a trailing digit or trailing garbage for
some edge cases), but that can be dealt with at a higher level. I also
arbitrarily limited the precision of this mechanism to 9 trailing digits, and
in a more general context this should instead be an estimation of the
digits needed for the representation based on the structure of floating
point numbers.
There is also the issue of switching to "scientific notation" for arguments
of some magnitudes. However, this representation issue should be
straightforward (you test against some threshold, scale the result
and drop the digits into an appropriate display formatting mechanism).
Does this help?
Thanks,
--
Raul
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
