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 Mon, Aug 31, 2009 at 12:42 AM, TSa thomas.sandl...@vts-systems.de 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
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
Karl == Karl Brodowsky lis...@brodowsky.com 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
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
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 less than,
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
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
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
Shouldn't it autopromote to Bignum at that point?
On 8/27/09, Michael Zedeler mich...@zedeler.dk 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
On Thu, Aug 27, 2009 at 2:59 AM, Jon Langdatawea...@gmail.com 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
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
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
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.
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
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 s...@iol.ie wrote:
TSa wrote:
HaloO,
David Green wrote:
For
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
example: it really doesn't
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 datawea...@gmail.com wrote:
smuj wrote:
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:
On Thu, Aug 27, 2009 at 2:36 PM, Mark J. Reedmarkjr...@gmail.com 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:
''
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,
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 list
On Thu, Aug 27, 2009 at 2:34 PM, Larry Wallla...@wall.org 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,
On Aug 27, 2009, at 17:48 , Jon Lang wrote:
On Thu, Aug 27, 2009 at 2:36 PM, Mark J. Reedmarkjr...@gmail.com
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. ...
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
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 after
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
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
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
James Cloos wrote:
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
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 guess
On Tue, Aug 25, 2009 at 5:58 PM, Jon Langdatawea...@gmail.com 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
Mark J. Reed wrote:
On Tue, Aug 25, 2009 at 5:58 PM, Jon Langdatawea...@gmail.com 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
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 precision,
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, in
35 matches
Mail list logo
