>>>>> "Michael" == Michael Zedeler <mich...@zedeler.dk> writes:
Michael> The Range 1.0001 .. 2.15 makes sense as an interval definition, but Michael> there can hardly be a useful list definition without defining a step Michael> size, at least, making it possible to use step sizes less than one. >> >> The obvious (default) choice for a step size would be the precision of >> the more precise of the two values. So 0.0001 in your example above. >> Michael> Well... maybe. How do you specify the intended precision, then? If I Michael> want the values from 1 to 2 with step size 0.01, I guess that writing Michael> 1.00 .. 2.00 The parser would have to note the precision as represented. On systems which have ieee-754 decimal floats that will be automatic (1., 1.0, 1.00, etc all have different representations in 754 decimal floats); it would not be a bad idea for Perl to keep track of that for all numerics. >> Complex .. Complex should have a defined meaning in p6. Michael> there is no natural ordering of complex numbers, and without Michael> some ordering, you may be able to decide what should be in the Michael> list to return, but not which order to use. [I'm merging stuff here.] Indeed, for interval arith it isn't ordering but inclusion which is relevant. If order is of value, it seems that it would have to be imposed. I can imagine that some people will want to zigzag from the point closest to (−∞,−∞) to the point closest to (+∞,+∞), whereas others might prefer to start at the point with the least r, sweeping θ through either [0°,360°) or (−π,π] or [−π,π) or .... Michael> I believe that anything we put into Perl 6 should have obvious Michael> use cases and fall natural into place in the domain that the Michael> construct in question belongs to. That is reasonable. Michael> but I must admit that I'd prefer if Complex .. Complex was left Michael> undefined in the Perl 6 core, leaving it up to anyone to Michael> specify it later. BTW, it I should have written a disc with diameter running between the two points rather than specifying an enclosing circle. It is true that when I think of p6, I think of more than core. But I would like support for interval arithmetic as ingrained in the p6 culture as, say, regexps. The set of problems which would benefit from widespread use of efficient interval techniques is significant. All that said, it may be the case that the .. syntax, though useful for specifying intervals, may not be preferred by those doing such coding. The may prefer a ± syntax, or something like ΤεΧ’s strech and shrink syntax for glue. -JimC -- James Cloos <cl...@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
