HaloO,
John M. Dlugosz wrote:
The sqrt(2) should be a Num of 1.414213562373 with the precision of the
native floating-point that runs at full speed on the platform.
That makes the Num type an Int with non-uniform spacing. E.g. there
are Nums where $x++ == $x. And the -Inf and +Inf were better
TSa wrote:
John M. Dlugosz wrote:
The sqrt(2) should be a Num of 1.414213562373 with the precision of the
native floating-point that runs at full speed on the platform.
That makes the Num type an Int with non-uniform spacing. E.g. there
are Nums where $x++ == $x. And the -Inf and +Inf were
On Fri, May 9, 2008 at 9:10 AM, TSa [EMAIL PROTECTED] wrote:
E.g. sqrt(2) might return a special Inf that can be lazily
stringified to an arbitrary long sequence of digits of sqrt(2).
In what the heck mathematical world is the square root of two an
infinite value? Irrationality and infinitude
On 2008-Jun-1, at 11:20 am, Jon Lang wrote:
David Green wrote:
I thought it already did, but apparently it's something that we
discussed
that didn't actually make it into S09. I agree that .[] should
apply to
hashes just as .{} can apply to arrays. The hashes don't even need
to be
On Mon, Jun 02, 2008 at 11:50:20AM -0700, Jon Lang wrote:
TSa wrote:
John M. Dlugosz wrote:
The sqrt(2) should be a Num of 1.414213562373 with the precision of the
native floating-point that runs at full speed on the platform.
That makes the Num type an Int with non-uniform spacing.
On 2008-Jun-1, at 1:50 pm, Jon Lang wrote:
David Green wrote:
[...] assignment should work like passing args when used on a
function. Then you can easily do whatever you want with it.
[...]
If a routine is rw, you may optionally define a single slurpy
scalar (e.g., '*$value') in its
Ryan Richter wrote:
Jon Lang wrote:
TSa wrote:
John M. Dlugosz wrote:
The sqrt(2) should be a Num of 1.414213562373 with the precision of the
native floating-point that runs at full speed on the platform.
That makes the Num type an Int with non-uniform spacing. E.g. there
are Nums
David Green wrote:
Jon Lang wrote:
Bear in mind that keys are not necessarily sortable, let alone autosorted.
For instance, consider a hash that stores values keyed by complex numbers:
since there's no way to determine .before or .after when comparing two
complex numbers, there's no way to
On Sunday 01 June 2008 19:31:34 Paul Fenwick wrote:
Questions I'm seeking answers to are:
* Is there a document that describes the current p6l exception hierarchy?
My searching skills seem to be impaired today.
* Does anyone have any input they'd like to make before I start fleshing
out
The point is that %h[0] should be legal syntax that works on any hash,
returning the first element. It doesn't matter if the elements are
sorted or even sortable. You get an element. More to the point, if
you don't add any elements to (or remove any elements from) the hash,
you get the *same*
David Green wrote:
Jon Lang wrote:
If a routine is rw, you may optionally define a single slurpy scalar
(e.g., '*$value') in its signature. This scalar counts as the last
positional parameter, much like slurpy arrays and hashes must be declared
after all of the positional parameters have
Mark J. Reed wrote:
The point is that %h[0] should be legal syntax that works on any hash,
returning the first element. It doesn't matter if the elements are
sorted or even sortable. You get an element. More to the point, if
you don't add any elements to (or remove any elements from) the
On Mon, Jun 02, 2008 at 12:31:34PM +1000, Paul Fenwick wrote:
G'day p6l and p5p,
I'm currently working on the 'autodie' pragma for Perl 5, which is
essentially 'Fatal' but with lexical scope. It's similar to the 'fatal'
pragma described in S04/Exceptions.
autodie is implementing an
13 matches
Mail list logo
