On Mon, Aug 31, 2009 at 12:42 AM, TSa wrote:
>
> HaloO,
>
> Jon Lang wrote:
>>
>> '<' and '<=' numify their arguments before comparing them.
>> 'lt' and 'le' stringify their arguments before comparing them.
>> 'before' compares its arguments without any coercion. Note that
>> there's no equivalen
HaloO,
Jon Lang wrote:
'<' and '<=' numify their arguments before comparing them.
'lt' and 'le' stringify their arguments before comparing them.
'before' compares its arguments without any coercion. Note that
there's no equivalent to '<='.
This last one is !after and !before is '>='.
Regards
On Thursday, 27. August 2009 23:58:51 Jon Lang wrote:
> It might also be nice to have a stringifying version; perhaps 'be',
> using the same "everything's an acronym" naming convention used by
> other stringifying operators (e.g., 'lt' is "less than", 'le' is 'less
> than or equal to', 'leg' is "le
> "Michael" == Michael Zedeler 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 (de
> "Karl" == Karl Brodowsky writes:
Karl> - or should there be a new numeric type similar to Rat that is always
Karl> having powers of 10 as denominator (like BigDecimal in Java or
Karl> LongDecimal for Ruby or decimal in C# or so)?
If so, please use something compatable with ieee 754 decima
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
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
On Wed, 26 Aug 2009, Michael Zedeler wrote:
Thanks to everyone who has posted their thoughts on Ranges.
Here are the conclusions I have drawn:
Ranges are for checking whether something is within a given interval.
RangeIterators are for iterating over elements in a Range with a given step
size
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 that are double or float
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 long as "before" and
Thanks to everyone who has posted their thoughts on Ranges.
Here are the conclusions I have drawn:
Ranges are for checking whether something is within a given interval.
RangeIterators are for iterating over elements in a Range with a given
step size using :by.
We discussed using "Series" or "
On Tue, Aug 25, 2009 at 02:58:05PM -0700, Jon Lang wrote:
: Michael Zedeler wrote:
: >> 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.
: >>
: >
: > Well... maybe. How do you specify the intended preci
Mark J. Reed wrote:
> On Tue, Aug 25, 2009 at 5:58 PM, Jon Lang wrote:
>> Also, I want to second David Green's point: we're not talking "Range"
>> and "Interval" here; we're talking "Range" and "Series".
>
> But a "series" refers to a more general concept than a discrete range.
> I still think Ran
On Tue, Aug 25, 2009 at 5:58 PM, Jon Lang wrote:
> Also, I want to second David Green's point: we're not talking "Range"
> and "Interval" here; we're talking "Range" and "Series".
But a "series" refers to a more general concept than a discrete range.
I still think Range and Interval fit better.
Michael Zedeler wrote:
>> 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.
>>
>
> 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
James Cloos wrote:
"Michael" == Michael Zedeler 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 tha
On 2009-Aug-24, at 4:17 pm, Daniel Ruoso wrote:
Em Seg, 2009-08-24 às 23:50 +0200, Michael Zedeler escreveu:
The most elegant solution would be if the data types themselves
indicated their capabilities.
One thing I think you missed entirely is the fact that the infix:<..>
operator is a multi su
> "Michael" == Michael Zedeler 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)
Em Seg, 2009-08-24 às 23:50 +0200, Michael Zedeler escreveu:
> The most elegant solution would be if the data types themselves
> indicated their capabilities.
One thing I think you missed entirely is the fact that the infix:<..>
operator is a multi sub, so it falls to regular dispatch semantics,
Hi Perl 6 people.
I've been looking closely at the definition of the Range class in S02
and the current Rakudo implementation, and I have some comments...
It seems that there are two intended uses for this class:
Range A pair of Ordered endpoints
Lets call the above the "interval defin
37 matches
Mail list logo