In your example: ]stringNumString =. x: ". string ". has already converted your string into a limited precision float before it encounters the x: operator.
Instead, I suggest that you suffix your string with the extended precision suffix, then ". yields the extended precision integer not needing the x: operator. ]string =. '98765432109876543210' ]stringNumString =. ". string , 'x' 98765432109876543210 On Fri, Jul 8, 2011 at 11:47 AM, mijj <[email protected]> wrote: > (second attempt! Version 1 was sent using wrong email addy - d'oh! 8-) > > [first of all... "hi" .. 8-) .. it's wonderful to be here. Just a bit > uneasy because the forum isn't in the bulletin board form .. anyhoo .. > here goes...] > > i've discovered that i can't directly convert long digit strings to > exteneded integer with accuracy beyond usually the first 16 digits but > never beyond the first 15 digits (depending on the test string). > > eg.. > > ]string =. '98765432109876543210' > ]stringNumString =. x: ". string > NB. 98765432109876543488 > NB. the result is in extended precision form, but the conversion wasn't. > NB. being something of a novice, i'm not sure if i'm applying > NB. [x:] or [".]correctly. > NB. Prefixing [".] doesnt' make any difference. > > for the same source string i get the same result with > J602 on XP32 XP64 Win7(64) > J701 on XP64 > (note: since the blackholed version.1 of this email, my xp64 j602 is > giving a different (but consistant) error for the last digits. Other > machines still give the old same result.) > > i can get round this by cobbling together the number from segments > i.e .. > 0 : 0 > 'VERB xIntFromLongString DEFINITION AND TEST > '================================= > ) > xIntFromLongString =: 3 : 0 > segWidth =. 7 NB. awkward segment test width > nList =. ". |.("1)(-segWidth) ,\ |.y > +/ nList * 10x ^ segWidth *i. {. $ nList > ) > > ]s =. ,100 20 $ '98765432109876543210' > ]n =. xIntFromLongString s > > (10x^8) | n NB. look at the last 8 digits of n > sns =. ": n > */ s = sns NB. compare s->n->s with original s > 0 : 0 > '================================= > 'END OF TEST > ) > > .. i only accidentally noticed the failure to do the simple direct > conversion of the long digit string when playing with Project Euler prob > 13. (Fortunately, the solution only depended upon the first > 10 digits of the lines of data.) > > should i have expected the direct conversion to be limited (eg. is > there a warning somewhere i didnt see about (".) applied to long numbers?)? > is there a direct way of doing this that, being a novice, i haven't > discoverd? (ie. that doesn't involve chopping up the number string) > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > -- - michael dykman - [email protected] May the Source be with you. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
