# Re: s29 and Complex numbers

```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
```