> Let me record this here, for the sake of other novices ... > > ]z=: 0.45+i.6 > 0.45 1.45 2.45 3.45 4.45 5.45 > foo=: 3 : 'y-.''.''' NB. simply removes the decimal point > foo &.": z > 45 145 245 345 445 545
I made a mistake. To work separately on each individual number we need: (foo &.":)"0 z On Thu, Jul 21, 2011 at 2:05 PM, Ian Clark <[email protected]> wrote: >> I think, for plotting purposes, that ]&.": should usually suffice. > > That is nifty, Raul. > > It took me all of 5 minutes to work out how that worked. And now I see > it lets me process any numeric array with a string manipulation > function that handles each numeric atom like a string, but returns the > array in numeric form. I have loads of uses for that. > > Let me record this here, for the sake of other novices ... > > ]z=: 0.45+i.6 > 0.45 1.45 2.45 3.45 4.45 5.45 > foo=: 3 : 'y-.''.''' NB. simply removes the decimal point > foo &.": z > 45 145 245 345 445 545 > >> This defect seems to be a "fundamental feature" of plot. I cannot >> think how to remove it without redesigning plot. > > I appreciate that plot needs to accept complex arrays, to plot > functions over the complex plane. And I had other things on my mind > than to get diverted into debugging plot. But maybe just it could > crash in glcmds a little more elegantly, without hiding the evidence? > (Maybe Bill's fix does that?) > > I'm totally in accord with Bill when he says "equality of numbers > [should] not depend on internal storage representation". It's always > been the big selling point of the APL family of languages, at least > since 1968 when I first met APL on the 1100. When the received wisdom > in the DP world at large was that a number variable should be typed > for the range of data intended to fit in it. And it's significant that > it broke down for me not inside J code, but where J has to interface > with foreign code. So I wasn't really surprised when plot choked over > a pathological piece of data: a "complex" array that wasn't. > > What surprised me (...perhaps it shouldn't?) is that a noun in J > carries around its provenance with it, and infects (perhaps "poisons" > is too emotive a term) any noun it's used to build. And I discover it > doesn't just happen with 'complex', but with 'boolean' too... > > datatype b=: 1 0 1 1 0 1 0 > boolean > ]z=: {. 0 1 2.22 > 0 > datatype z > floating > datatype b,z > floating > > Which surely means that "datatype", or 3!:0, is at best only a guess > at the logical content of a numeric array? I shall be more alert to > that possibility in future, when using 3!:0. > > > > On Wed, Jul 20, 2011 at 3:55 PM, Raul Miller <[email protected]> wrote: >> On Wed, Jul 20, 2011 at 10:36 AM, Ian Clark <[email protected]> wrote: >>> 1. Can anyone think of a neater way of cleaning up z than my verb: >>> real? I expect there's a primitive capable of filtering the "poison" >>> but I haven't found it yet. >> >> I think, for plotting purposes, that ]&.": should usually suffice. >> >>> 2. Can someone fix the plot package so that it either tolerates or >>> correctly reports "poisoned" arrays, and doesn't just fall over in a >>> puzzling way? >> >> This defect seems to be a "fundamental feature" of plot. I cannot >> think how to remove it without redesigning plot. >> >> -- >> Raul >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm >> > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
