> Does this help?
Yes, thank you.
In fact I had come up with a somewhat similar approach.
Very straightforward ideas: separate whole and fractional
parts, multiply fractional by 16^desired precision and round,
convert each part and combine with '.' accounting for sign.
require 'convert'
NB.*hff v hex from fractional
hff=: 4 :'''_'',^:(0>y)tolower(,''.''&,)&hfd/<.0.5+(1,16^x)*0 1#:|y'
6 hff 16babcdef.123456
abcdef.123456
6 hff -16babcdef.123456
_abcdef.123456
1 hff 16bff.17
ff.1
1 hff 16bff.18
ff.2
1 hff 16b_ff.18 NB. correct place for sign
_ff.2
1 hff _16bff.18 NB. base _16
_e1.1
Note: does not handle 0 precision correctly.
--- Raul Miller <[EMAIL PROTECTED]> wrote:
> 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
>
____________________________________________________________________________________
Be a better pen pal.
Text or chat with friends inside Yahoo! Mail. See how.
http://overview.mail.yahoo.com/
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
