On Thu, Mar 18, 2010 at 6:55 AM, Ian Clark <[email protected]>wrote:
> ... I unconsciously
> distinguish between features whose results are unreliable and those
> which compromise integrity by permitting a hard crash with legal
> usage. With all due respect I have to ask: is Indeterminate (_.) a
> supported feature, or an unsupported forensic side-effect that just
> happens to be documented in Voc?
It makes sense to me that you want an accurate sense of when an aspect of
the language may be used, and I certainly see Indeterminate as exceptional
in that it is not supported as part of the numeric domain. It is an
exception by which J primaries signal when the numeric domain has been
breached, as you're aware. The word "forensic" seems appropriate, here, and
even "side-effect," but I can't agree with calling it unsupported.
The documented meaning of Indeterminate, and the restrictions on its
validity, are genuine support for a useful feature. This feature allows
edge-cases and exceptions to be automatically caught within the J engine,
problem-situations that would otherwise have to be hand-coded. From your
description of the calculator you're porting, you have a better awareness
than I do of the details of such qualities.
> A prominent warning there that it can
> crash J would be nice. So would a domain error when (_.) is used as
> the left arg to Numbers (".)
>
There are ways in which J gives us enough rope to hang ourselves, as the
saying goes. I'm not in a position to say whether this counts as one of
those cases, but I can guess that the cost of restricting when and where
(_.) will be accepted in arguments, while retaining its intended value,
would be quite high. That is, I'm guessing the decision to communicate a
restriction to J writers, rather than building it in to the software system,
was made after careful consideration.
>
> (_.) would be a useful facility (at least I think so) were it safe to
> use, as I imagine Infinity (_) is. I'm porting a calculator from APL
> in which every number can take the pseudo-values UNDEFINED or INVALID
> -- and there is some pervasive and very cumbersome code to support
> this. So far I've been able to dispense with it all -- it was a major
> reason for porting to J. But if I can't trust (_.".) when applied to
> raw user input then I'm going to have to bring some of it back.
>
>
That's what I learned when I pursued this question. It may be that J
facilitates less obtrusive techniques than the ones that were used in the
system you're converting. In any event, Indeterminate won't serve as an atom
for marking things like UNDEFINED or INVALID.
In earlier Programming forum discussions, some recommendations were posted
as to how such marking can be managed in J. I think that was about three
years ago.
--
Tracy
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
