dyad o. in J602 have been updated to return floating numbers for
real and imaginary parts, please RTFM. ;-) But like you I use {.@+. for
historical reason.
J just like mathematics where equality of numbers does not depends on
internal storage representation.
But glcmds is not a part of J, it is a cover verb of a foreign function.
A workaround might re-define it as (untested)
glcmds=: 11!:2999 @: ({.@+.)
But I guess it will be more efficient for users to provide correct formated
input data.
Срд, 20 Июл 2011, Ian Clark писал(а):
> I have a data-massaging engine which delivers me an array to plot. In
> certain obscure circumstances this array can be "poisoned", whereupon
> the plot package (J602) falls over and dies.
>
> I spent an evening tearing out my 3 remaining hairs, trying to work
> out what was happening. At last I think I know. The proper remedy is
> not obvious, since IMO there's more than one bug manifesting here.
>
> Let me illustrate with a simple example:
>
> require 'plot'
>
> ]z=: 1j2 , i.9
> 1j2 0 1 2 3 4 5 6 7 8
> z=: }. z
> z
> 0 1 2 3 4 5 6 7 8
> ]Z=: i.9
> 0 1 2 3 4 5 6 7 8
> z -: Z
> 1
> plot Z NB. (plots successfully)
> plot z
> |domain error: glcmds
> | glcmds buf
>
> So we have two nouns, one of which (Z) plots successfully, and the
> other (z) doesn't.
> They look the same, and Match (-:) says they're the same. How (if at
> all) do they differ?
> Answer:
>
> datatype Z
> integer
> datatype z
> complex
>
> Although all the imaginary parts of z are 0, it still retains a memory
> of once having been complex, which is enough to "poison" plot.
> The "poison" is remarkably contagious and resilient. But I've come up
> with a verb capable of cleaning up z for plotting:
>
> real=: ([: {. +.)"0
> real z
> 0 1 2 3 4 5 6 7 8
> datatype z
> complex
> datatype real z
> floating
> plot real z NB. (now it plots successfully)
>
> Two questions:
>
> 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.
>
> 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?
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
