>@(8!:0~&'d') is leaner than ":"0 and not that much slower and will convert >negative numbers to non-J format.
If I'm trying to output to file for non-J use then I like using 8!:0 because it handles negative numbers appropriately. It is also faster and leaner than say <@":"0 On Tue, Nov 1, 2011 at 1:03 AM, Raul Miller <[email protected]> wrote: > Why do you not like ": and what does >@(8!:0~&'d') offer that's better > than (":"0)? > > Thanks, > > -- > Raul > > On Mon, Oct 31, 2011 at 12:52 AM, Andrew Pennebaker > <[email protected]> wrote: >> Tracy, I completely agree: strings as sequences of characters are an >> intuitive and highly manipulable data structure. One reason strings stand >> out in C, Haskell, and Lisp is that they are easy to map over because their >> interface (and often their underlying implementation) is an iterable >> collection. In contrast, Erlang treats strings as if they weren't made of >> letters at all but solid hunks of unsearchable data, and it needlessly >> makes programming that much harder. >> >> Don, which information is more often relevant: that two strings are >> lt/gt/eq, or which characters differ and which are the same? >> >> Side note: Could we give longer formal names for each short function (e.g., >> numberToString =: > 'd' (8!:0))? It's incredibly hard to Google >> documentation for functions succinctly named. >> >> Cheers, >> >> Andrew Pennebaker >> www.yellosoft.us >> >> On Mon, Oct 31, 2011 at 12:23 AM, Tracy Harms <[email protected]> wrote: >> >>> Although Roger has already replied with strong example code that show how >>> this task is readily accomplished, and comments that explain why the >>> primary verbs have domains defined as they do, I'd like to add a bit more. >>> >>> The term "string" is common among programmers because it is a technical >>> term with particular meanings in many languages. There are, however, no >>> strings in J. We often can work with it in a casual way, but at some point >>> expectations about strings are things that come from other >>> languages--indeed, other language paradigms--and those expectations are >>> likely to clash with the way text is handled in J. This also explains why >>> "string" is missing as a term in J documentation. It not only is not a >>> J-specific term, as a word it can invite confusion. >>> >>> More and more, when I want the likes of "strings" in J it is symbols that >>> do the trick. Not always, but often enough for me to suggest that it may be >>> premature to evaluate how well J facilitates working with text if skill >>> with symbols has not been developed. >>> >>> Finally, I have found that J has brought me to think of literals in the >>> same way I think of numbers. There are, of course, many verbs for which >>> literals fall outside the domain, but thinking of text as lists of >>> characters allows me to approach text-manipulation problems in the same way >>> I approach number-manipulation problems. This kind of consistency is has >>> been highly valued in the development of array languages. It does mean that >>> it is not so easy to do various things with text that, say, >>> text-specialized languages make very easy to do. But it also means that >>> what is easy to do with text is just as easy to do with every other atomic >>> type. >>> >>> I'd enjoy seeing more material about working with text in J, at every skill >>> level. Eventually I may be able to contribute some, myself. Perhaps this >>> thread can initiate a conversation about which sorts of expanded >>> documentation would be most beneficial? >>> >>> --Tracy Harms >>> >>> >>> On Sun, Oct 30, 2011 at 10:35 PM, Alan Stebbens <[email protected]> wrote: >>> >>> > I get sad when I see both expert and new J programmers working hard to do >>> > simple string comparisons. J makes working with strings harder than it >>> > should to be. >>> > ... >>> > J can manage most (any?) programming tasks but common things like >>> > comparing strings ought to be easy. >>> > ... >>> ---------------------------------------------------------------------- >>> 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
