No, the implementation is not definitive. NuVoc is definitive. NuVoc
has material at many levels, but I assume here that detailed information
there will be modified only by someone who understands the system
thoroughly, including the motivations behind the design.
The statement that the Dictionary is wrong is a personal value judgement
of mine. I am saying _ should return empty or be an error. I have
offered my arguments for this opinion. Roger's implementation returned
empty - perhaps he would agree. We can argue about it. There is a
reasonable counterargument that if you want to have subarrays in one
dimension that include all of another dimension, _ is the easiest way to
do it.
Until that argument changes minds, NuVoc as amended describes the system
as I think it ought to be, and is.
Henry Rich
On 11/1/2019 4:30 PM, Raul Miller wrote:
Ok, so what you now seem to be saying is that the implementation is
definitive, not NuVoc. But that's something of a tautology and offers
no guidance for improvement. So I'm not comfortable with that point of
view.
If we go back to "NuVoc" is definitive, I suppose we could say that
"NuVoc" is definitive for future versions, ... but that brings us back
to NuVoc being easily changed so it seems like a moot point rather
than a rationale in and of itself.
Anyways...
I do not understand the rationale for two of your statements here:
(1) The statement that the dictionary is wrong.
(2) the statement that
(3,: _) ];._3 ] 3 0 7 2 9 1 5 8 4 6
should return empty.
If the rationale is that _ should be interpreted literally, then we should see:
$(3,: _) ];._3 ] 3 0 7 2 9 1 5 8 4 6
0 _
But that won't work, because elements of shape are integer values, not
floating point values and we don't currently have integer
representations of infinities. (And I'm not sure that adopting such an
approach would be an improvement.)
So that leaves us with throwing an error, or doing something special
instead of an error.
Meanwhile, in other contexts (like the rank operator) we have the
convention that an infinite value represents a calculated finite
value.
Now, there might be compelling reasoning that I'm over looking here,
but this seems like a relatively simple issue (which only needs to be
handled on the code path where the left argument is not already an
integer).
What am I missing?
Thanks,
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
