On 2009-Aug-27, at 3:11 pm, Mark J. Reed wrote:
Given how easy chained relational ops make explicit range checking
with endpoints, e.g.
$a <= $x <= $b
I'd be perfectly happy with a Range smartmatching only the elements
that you get out of the RangeIterator.
Yes -- although sometimes that wo
On Aug 27, 2009, at 17:48 , Jon Lang wrote:
On Thu, Aug 27, 2009 at 2:36 PM, Mark J. Reed
wrote:
I think $a <= $^x <= $b is short enough, and lets you choose
between <
and <= on both ends and without having to remember how many dots each
maps to.
"How many dots"?
.. vs. ... operators, I p
On Thu, Aug 27, 2009 at 2:34 PM, Larry Wall wrote:
> On Thu, Aug 27, 2009 at 02:21:12PM -0700, Jon Lang wrote:
> : 2.5 ~~ 1..5 # true: equivalent to "2.5 ~~ 1 <= $_ <= 5".
>
> Current specced behavior for Range objects.
>
> : 2.5 ~~ @(1..5) # false: equivalent to "2.5 ~~ (1, 2, 3, 4, 5)".
>
On Thu, Aug 27, 2009 at 02:21:12PM -0700, Jon Lang wrote:
: 2.5 ~~ 1..5 # true: equivalent to "2.5 ~~ 1 <= $_ <= 5".
Current specced behavior for Range objects.
: 2.5 ~~ @(1..5) # false: equivalent to "2.5 ~~ (1, 2, 3, 4, 5)".
Not by current rules; which say the left side matches the lis
smuj wrote:
> So you're saying you'd like things to stay exactly as they are at the
> moment!? :-)
Not quite. I'd like to see the effects of context spelled out more
clearly than they are; and I'd like a revision so that '..' numifies
its endpoints while a new 'to' operator doesn't. That is, res
On Thu, Aug 27, 2009 at 2:36 PM, Mark J. Reed wrote:
> I think $a <= $^x <= $b is short enough, and lets you choose between <
> and <= on both ends and without having to remember how many dots each
> maps to.
"How many dots"?
Note that there are three sets of comparison operators:
'<' and '<=' n
Jon Lang wrote:
smuj wrote:
I'd personally prefer it if Ranges just did lists, including when smart
matching, but had an interval method or such like for explicit matching
against the endpoints, e.g.
2.5 ~~ interval(1..5) # or
2.5 ~~ $myrange.interval
I don't like the Huffman encoding: "doe
I think $a <= $^x <= $b is short enough, and lets you choose between <
and <= on both ends and without having to remember how many dots each
maps to.
But I do like your "list context for list behavior" idea. I would
support that happily.
On 8/27/09, Jon Lang wrote:
> smuj wrote:
>> TSa wrote:
>
smuj wrote:
> TSa wrote:
>>
>> HaloO,
>>
>> David Green wrote:
>>>
>>> For certain discrete ordered types, like Int, both ways work out the
>>> same, and since Ints are the most common and most obvious use for Ranges,
>>> it's easy to overlook the confusion. The case with strings is a good
>>> exa
Given how easy chained relational ops make explicit range checking
with endpoints, e.g.
$a <= $x <= $b
Imd be perfectly happy with a Range smartmatching only the elements
that you get out of the RangeIterator.
On 8/27/09, smuj wrote:
> TSa wrote:
>> HaloO,
>>
>> David Green wrote:
>>> For certa
TSa wrote:
HaloO,
David Green wrote:
For certain discrete ordered types, like Int, both ways work out the
same, and since Ints are the most common and most obvious use for
Ranges, it's easy to overlook the confusion. The case with strings is
a good example: it really doesn't make sense that
Larry Wall wrote:
Another note, it's likely that numeric literals such as 1.23 will turn
into Rats rather than Nums, at least up to some precision that is
pragmatically determined.
Doing these as Rat would avoid a lot of the precision issues that
floating point
arithmetic has all the time.
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
HaloO,
David Green wrote:
For certain discrete ordered types, like Int, both ways work out the
same, and since Ints are the most common and most obvious use for
Ranges, it's easy to overlook the confusion. The case with strings is a
good example: it really doesn't make sense that a value not
On Thu, Aug 27, 2009 at 2:59 AM, Jon Lang wrote:
> Michael Zedeler wrote:
>> Jon Lang wrote:
>>> As for Str, I'm not sure that we should go so far as to say that you
>>> _can't_ create RangeIterators over them, so much as to say that the
>>> default step algorithm is defined only for single-charact
Shouldn't it autopromote to Bignum at that point?
On 8/27/09, Michael Zedeler wrote:
> Karl Brodowsky wrote:
>> Michael Zedeler schrieb:
>>> Well... maybe. How do you specify the intended precision, then? If I
>>> want the values from 1 to 2 with step size 0.01, I guess that writing
>>>
>>> 1.00
Karl Brodowsky wrote:
Michael Zedeler schrieb:
Well... maybe. How do you specify the intended precision, then? If I
want the values from 1 to 2 with step size 0.01, I guess that writing
1.00 .. 2.00
won't be sufficient. Trying to work out the step size by looking at
the precision of things t
Jon Lang wrote:
Michael Zedeler wrote:
Proposed changes:
It shouldn't be possible to construct RangeIterators over Str (apart from
single length strings) or Complex using the Range operator (..).
I'd go one step further with Complex, to say that Range isn't a useful
concept at all so l
On 2009-Aug-26, at 3:54 pm, Darren Duncan wrote:
The question I have is what to do when a single same authority wants
to release multiple forks or branches of the same module, each
presumably targeting a different use case, and the version numbers
for each fork/branch are not supposed to be
Timothy S. Nelson wrote:
I think a Complex range only makes sense if you provide 4 endpoints,
not 2, but I haven't been following the conversation, so I'll leave it
up to the Complex number experts :).
(start-angle, start-length)
:by(angle-step, length-factor)
--
Ruud
20 matches
Mail list logo
