a. The reason I'm using _. is specifically because I want
problems. It forces me to handle bad data at the source
-- input.
Using _. as a fill value means that if I get one, I'm
guarunteed to have problems later on, and the source of
those problems will be easy to identify.
Using other fill values makes identification of the problem
harder. For example, _ and __ often arise "naturally"
due to arithmetic involving 0 .
Moreover, NaN or "undefined" more closely matches my
conception of a "missing value".
Another way to handle this would be to provide a form of
the primitive (using fit?) that produces an N by 2 array
where the first column is the current result and the second
column is a boolean flag indicating whether the
corresponding value is a good number.
Example:
99 ".!.1 '10 99 bad_number'
10 1
99 1
99 0
b. Since 'bad_number' is a bad number, and since I'm
instructing dyadic ". to replace bad numbers with 99
which is unambiguously an integer, then:
99 ". '123 123x bad_number'
should be equivalent to:
99 ". '123 123x 99'
All the numbers represented in the latter string are
unambiguously integers, thus 123x should be intepreted
in that context, and the postfix form (extended integer)
assumed.
Again, perhaps the solution is to provide an out of band
mechanism to instruct the primitive to return extended
integers if possible. Something like:
flags =. ;: 'IS_GOOD USE_EXTENDED OTHER_FLAG'
('DN_',L:0 flags ,L:0'_z_')=:2^i.#flags
gd_ex =. +./&.:#: DN_IS_GOOD , DN_USE_EXTENDED
] m =. 99 ".!.gd_ex '10 99 bad_number'
10 1
99 1
99 0
datatype m
extended
But this is getting ugly. Since parsing input is such a
common and fundamental requirement in programming, it's
time to admit that it should have its own special family
of foreigns.
The opposites of the new formatting foreigns, in fact; a nice
symmetry. After all, that's what a foriegn is: an interface
to elsewhere.
-Dan
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
