Kevan Benson wrote:
That said, I submit that it's a very confusing part of the language as
defined currently, and I haven't seen a very thorough explanation of the
purpose of each method in the chain the instantiates a new object. S12
touches upon them slightly, but not in enough detail
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 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
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. ...
20 matches
Mail list logo
