Ok, when formatting for non-j consumers, I can see using 8!:0... But I am also wondering why the >@ (instead of, for example ;:inv@)
Is it really more convenient to generate columns of formatted numbers than rows of formatted numbers? -- Raul On Mon, Oct 31, 2011 at 8:59 AM, Ric Sherlock <[email protected]> wrote: >>@(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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
