HaloO,
Michael Zedeler wrote:
James Cloos wrote:
Michael> Complex .. Complex -> undef, exception or some other bad thing.
Complex .. Complex should have a defined meaning in p6.
A definition which is easy to compute would be the set of points
contained by the square which has opposite corners at the two
specified points.
We should not think of complex ranges as areas. The thing used in
complex analysis is the path along which you integrate. OTOH circles
are the two dimensional equivalents of intervals.
But is that useful? Complex numbers are mostly for mathematics, so I
guess we have to look in that domain for a good use case. In that domain
there is no natural ordering of complex numbers, and without some
ordering, you may be able to decide what should be in the list to
return, but not which order to use.
I have stated elsewhere that order is not necessary. A notion of
distance suffices. The direction of iteration is well defined
by the complex step size.
I believe that anything we put into Perl 6 should have obvious use cases
and fall natural into place in the domain that the construct in question
belongs to. This means we have to come up with a design (there currently
is no specification of Complex .. Complex), some kind of use case to as
justification and finally a validation that ensures that the design is
consistent with other things in the language.
The complex case should result in the numeric case when given real
numbers as bounds and step size. So my proposal for complex range
iteration is to use complex addition to generate the next candidate
and complex distance to check whether it is closer to the endpoint
or not. The only drawback I see is that 1.2 .. 5 then iterates up
to 5.2 not 4.2 as in the order based approach. But I don't consider
this a bad outcome because the endpoint isn't hit in both cases and
5.2 is closer ;)
Applying the above metric procedure to complex range matches is
however a bit more problematic because the direction from start
to end is not necessarily the same as that given by the step size.
Since the step size should be ignored in real matches we should do
so in the complex case as well and check whether the number in
question lies on the line from start to end. Problem is how accurate
this check shall be. IOW, what is the line width of the range?
I would add an eps parameter to the range creating operator with
a default around 1e-10. This would be useful for real ranges with
excluded ends as well. Actually this parameter should be a relative
error not an absolute one.
Another idea is to make matches succeed in the intersection of the
two circles around the endpoints through the other endpoint. E.g.
then 2+i ~~ 1..3 is true and 2+2i ~~ 1..3 is false. This works for
reals such that 1..3 is the intersection of -1..3 and 1..5 which
are the one dimensional circles of radius 2 around 1 and 3 respectively.
Note that this metric definition of interval can be generalized to
vector spaces of arbitrary dimension where one intersects hyperspheres
around two points. One can also generalise to non-euclidean metrics,
of course. Perhaps even a string distance function might work.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
