Mark A. Biggar wrote:
> For the complex trig functions the result set is infinite with no
> obvious order to return the list in even lazily that provides anything
> useful.
Technically, the result set is one element (the principle value),
since a mathematical function - by definition - produces a single
result for any given input. That said:
> The results are all of the form A + (B + 2*pi*N)i where N can
> be any integer.
A lazy list would be feasible if you order it based on N, as long as
you're not forbidden from using negative indices for anything other
than reverse indexing.
> It is worth much more effort to just return a
> consistent principle value and getting the branch cuts and the handling
> of signed zero correct then to worry about trying to return multiple
> values in these cases.
Agreed. That's why my mention of list context for these things was
phrased as an afterthought: such a thing is doable, and I believe that
it might even be practical (once the other issues you mention above
are dealt with); but it's more "this would be nice" than "we need
this".
Furthermore, a list context approach would be an extension of the
functions' built-in capabilities: scalar context would give you the
principle value, while list context would give you every possible
value. This means that you could add list-context capabilities at
some later date (through either packages or revisions) without
damaging code developed in the meantime. You can't do this with the
junction approach, as (last I checked) a junction is a scalar; you'd
have to replace the "return the principle result" behavior with
"return a junction" behavior.
Finally, it's easy to go from list context to junction: just place the
math function in a junctive function ("any", "all", etc.). This makes
it easy to distinguish between "sqrt($x)" (which returns the principle
value) and "any sqrt($x)" (which returns a disjunction of every
possible result): more flexible and more readable than trying for
implicit junctional return values.
--
Jonathan Lang
