It looks like the built-in regular expression handling that some languages have could be really handy. However, I find my self avoiding the RE addon for J when I could be using it because I can get by with less-general J code that works fine, perhaps even more usefully.
For instance, the defect in J I reported a few days ago is something I encountered because I'm classifying compound names by distinct parts within each name. That is, I use an expression like +./&>(<'part') E.&.>wholes to locate the elements of "wholes" containing "part". This works well and I can generalize it to check that my coverage is complete and non-overlapping for a set of partial strings using an expression like +./&>parts E.&.>/ wholes which returns a boolean that is (#parts) by (#wholes), e.g. parts=. 'aa';'ab';'bc' whole=. 'aaa';'abz';'abx';'aaz';'bca';'bcz';'zab';'zaa' ]check=. +./&>parts E.&.>/ whole 1 0 0 1 0 0 0 1 0 1 1 0 0 0 1 0 0 0 0 0 1 1 0 0 The "check" boolean allows me to investigate a number of properties, e.g. "*./1=+/check" verifies that each part is in only one whole (and each "whole" has a single "part") and " +/"1 check " gives me the count for each category defined by the "part" matches. On Mon, Oct 31, 2011 at 10:05 AM, Raul Miller <[email protected]> wrote: > 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 > -- Devon McCormick, CFA ^me^ at acm. org is my preferred e-mail ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
