Jonathan Lang wrote:
In the hypothetical module that I'm describing, the principle value
approach _would_ be used - in scalar context. The only time the "list
of all possible results" approach would be used would be if you use
list context. If you have no need of the list feature, then you don't
have to use it.
This might suprise people:
@a = (1,4,9);
@b = @a.map:{sqrt};
ok([EMAIL PROTECTED] == [EMAIL PROTECTED]); # fails because of list context
The problem is that the two coordinate systems don't just differ in
terms of which methods they make available; they also differ in terms
of how they represent the value that they represent
And they also differ in what values they can represent, assuming the
underlying representation of real numbers uses a finite number of bits.
In the former
regard, this would be much like C's union; but it would differ from
them in that it would be designed to preserve the logical value (what
the data represents) rather than the physical value (the sequence of
bits in memory).
Which is not possible in the general case.
That probably doesn't mean that there isn't a good use for the concept,
but I'd be wary of it for precision math stuff.
