The old Google Groups will be going away soon, but your browser is incompatible with the new version.
How to make a new operator.
 There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic. There was an error processing your request. Please try again. Standard view   View as tree
 Messages 26 - 44 of 44 < Older

From:
To:
Cc:
Followup To:
Subject:
 Validation: For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon.

More options Mar 23 2012, 12:30 am
Newsgroups: perl.perl6.language
From: pmich...@pobox.com ("Patrick R. Michaud")
Date: Thu, 22 Mar 2012 23:30:01 -0500
Local: Fri, Mar 23 2012 12:30 am
Subject: Re: How to make a new operator.

On Fri, Mar 23, 2012 at 03:03:09PM +1300, Martin D Kealey wrote:
> On Thu, 22 Mar 2012, Carl Mäsak wrote:
> > Jonathan Lang (>>), Daniel (>):
> > >>    1, 2, 4 ... 100 # same as 1,2,4,8,16,32,64

> > > That last one doesn't work on Rakudo :-(

> > And it never will. Note that 100 is not a power of 2, and that the goal
> > needs to match exactly.

> Hmmm, so it's likely that most times you get a Num rather than an Int or
> Rat, those won't stop either?

>    1, 7 / 6.0 ... 2
>    1, sqrt(2), 2 ... 8

The expression 7/6.0 produces a Rat, so the first sequence properly
stops at 2.

On Rakudo on my system, sqrt(2) indeed produces a Num,
but since floating point arithmetic doesn't result in
sqrt(2) / 1 == 2 / sqrt(2), no geometric sequence is deduced
and the sequence fails with "unable to deduce sequence".

> Question: do we support

>    1, 2i, -4 ... 256

I think this ought to work, but for some reason Rakudo on my system
hangs whenever I try it.  The following does work in Rakudo:

> say 1, { \$^x * 2i } ... 256
1 0+2i -4+0i -0-8i 16+-0i 0+32i -64+0i -0-128i 256+-0i

The fact that the auto-deduced sequence hangs probably needs to be
filed as a bug report for Rakudo.

Pm

To post a message you must first join this group.
You do not have the permission required to post.
More options Mar 23 2012, 2:01 am
Newsgroups: perl.perl6.language
From: dam...@conway.org (Damian Conway)
Date: Fri, 23 Mar 2012 17:01:43 +1100
Local: Fri, Mar 23 2012 2:01 am
Subject: Re: How to make a new operator.
Patrick correctly observed:

> On Rakudo on my system, sqrt(2) indeed produces a Num,
> but since floating point arithmetic doesn't result in
> sqrt(2) / 1 == 2 / sqrt(2), no geometric sequence is deduced
> and the sequence fails with "unable to deduce sequence".

Although, arguably, that might be considered a bug.

Not that sqrt(2) / 1 should == 2 / sqrt(2) of course, but that, when
deducing a sequence we know we're comparing quotients, so we ought to
allow for the inevitable loss of significant digits within the two
preliminary division ops, and therefore compare the results with an
suitably larger epsilon.

That would not only be computational more justifiable,
I suspect it might also produce more "least surprise". ;-)

Damian

To post a message you must first join this group.
You do not have the permission required to post.
More options Mar 23 2012, 2:30 am
Newsgroups: perl.perl6.language
From: mor...@faui2k3.org (Moritz Lenz)
Date: Fri, 23 Mar 2012 07:30:03 +0100
Local: Fri, Mar 23 2012 2:30 am
Subject: Re: How to make a new operator.
On 03/23/2012 07:01 AM, Damian Conway wrote:

But unless we twist smartmatching semantics for that purpose, it means
we cannot do the same fuzziness for the endpoint, condemning people to
write infinite loops instead of failing fast.

So I'm firmly against such magic. All the previous iterations of the
to regret all of them. This discussion makes me think that maybe
deducing geometric sequences is too much magic as well.

Cheers,
Moritz

To post a message you must first join this group.
You do not have the permission required to post.
More options Mar 23 2012, 2:53 am
Newsgroups: perl.perl6.language
From: mor...@faui2k3.org (Moritz Lenz)
Date: Fri, 23 Mar 2012 07:53:05 +0100
Local: Fri, Mar 23 2012 2:53 am
Subject: Re: How to make a new operator.
On 03/23/2012 05:30 AM, Patrick R. Michaud wrote:

> On Fri, Mar 23, 2012 at 03:03:09PM +1300, Martin D Kealey wrote:
>> Question: do we support

>>        1, 2i, -4 ... 256

> I think this ought to work, but for some reason Rakudo on my system
> hangs whenever I try it.

The problem was that infix:<!=> hung with Complex numbers, because it
was defined for each numeric type, but the Complex candidate was
missing. Thus the most general candidate called .Numeric on its
arguments, re-dispatched, and looped infinitely.

Fixed in 2012.03-3-g4a247b1, and tested in S32-num/complex.t.
This also fixes the sequence 1, 2i, -4 ... 256.

Cheers,
Moritz

To post a message you must first join this group.
You do not have the permission required to post.
More options Mar 23 2012, 4:14 am
Newsgroups: perl.perl6.language
From: dam...@conway.org (Damian Conway)
Date: Fri, 23 Mar 2012 19:14:51 +1100
Local: Fri, Mar 23 2012 4:14 am
Subject: Re: How to make a new operator.

> But unless we twist smartmatching semantics for that purpose,

No!

;-)

> it means we cannot do the same fuzziness for the endpoint,

Except that we will be encouraging people to use: * >= \$END
as their standard endpoint pattern, which will provide
most of the necessary fuzz.

> So I'm firmly against such magic.

But that's the point: it's not magic. It's correct numerical computation
under the limitations of floating-point arithmetic. As discussed in
every numerical computing textbook for the last half a century.

Note that this problem occurs for *arithmetic* deductions as well.
If either number is floating point, some loss of precision in the
difference between them is almost inevitable, especially if the two
numbers are very close.

For example:

1, 1.000000000001, 1.000000000002 ... *

won't deduce a correct arithmetic sequence either (on most hardware).

In fact that example would be slightly more likely to imply a geometric
sequence, since a division operation loses fewer significant digits than
a subtraction when the arguments are both so close to 1.0)

> This discussion makes me think that maybe
> deducing geometric sequences is too much magic as well.

Geometric sequence inference is fine on Ints and Rats.

But, if we can't perform inferences involving Nums in a sound numerical
way (and it may well be that we can't, without taking a noticeable
performance hit), then I think that we would be better off limiting the
deduction of *both* arithmetic and geometric sequences to starting lists
that contain only Ints and Rats.

Damian

To post a message you must first join this group.
You do not have the permission required to post.
More options Mar 23 2012, 12:11 pm
Newsgroups: perl.perl6.language
From: pmich...@pobox.com ("Patrick R. Michaud")
Date: Fri, 23 Mar 2012 11:11:46 -0500
Local: Fri, Mar 23 2012 12:11 pm
Subject: Re: How to make a new operator.

On Thu, Mar 22, 2012 at 11:07:08AM -0500, Bruce Gray wrote:
> Well, it works in Niecza. It does not (yet) work in Rakudo:
>    15:25 <Util> perl6: my @squares := 0, (-> *@a { @a.elems ** 2 })
> ... *; say ~@squares[^11];
>    15:25 <p6eval> ..niecza v15-4-g1f35f89: OUTPUT<<0 1 4 9 16 25 36 49
> 64 81 100NL>>
>    15:25 <p6eval> ..rakudo 1a468d: OUTPUT<<0 0 0 0 0 0 0 0 0 0 0NL>>

It now works in Rakudo, as of 2012.03-5-g69920db:

> my @squares = 0, (-> *@a { @a.elems ** 2 }) ... *; say @squares[^11];
0 1 4 9 16 25 36 49 64 81 100

Also @_ now DTRT again:

> my @squares = { @_ ** 2 } ... *;  say @squares[^11];
0 1 4 9 16 25 36 49 64 81 100

> my @triangle = 1, { @_[*-1] + @_ + 1 } ... *;  say @triangle[^11]
1 3 6 10 15 21 28 36 45 55 66

Note that Rakudo also doesn't require a binding operation for the array...
assignment of detectably infinite lists (indicated here by the final
Whatever term) is supported.

Pm

To post a message you must first join this group.
You do not have the permission required to post.
More options Mar 24 2012, 8:16 pm
Newsgroups: perl.perl6.language
From: la...@wall.org (Larry Wall)
Date: Sat, 24 Mar 2012 17:16:51 -0700
Local: Sat, Mar 24 2012 8:16 pm
Subject: Re: How to make a new operator.
On Fri, Mar 23, 2012 at 07:14:51PM +1100, Damian Conway wrote:

: For example:
:
:     1, 1.000000000001, 1.000000000002 ... *
:
: won't deduce a correct arithmetic sequence either (on most hardware).

Actually, that one works fine in both niecza and rakudo, since those are Rats.

Larry

To post a message you must first join this group.
You do not have the permission required to post.
More options Mar 24 2012, 8:26 pm
Newsgroups: perl.perl6.language
From: dam...@conway.org (Damian Conway)
Date: Sun, 25 Mar 2012 11:26:39 +1100
Local: Sat, Mar 24 2012 8:26 pm
Subject: Re: How to make a new operator.

> Actually, that one works fine in both niecza and rakudo, since those are Rats.

Oh, that's good to hear.

It doesn't change my underlying argument however. Any operations
performed on genuine floats are going to lose precision, and if we're
using such operations to infer relationships (such as equality or
sequence) then we ought to take the loss of precision we're causing
into account when deciding outcomes.

Which seems to mean either (a) making it a compiletime error to request
sequence inferences on floats , or (b) comparing the differences and
quotients within the sequence inference with a larger epsilon (or using
interval arithmetic).

Damian

To post a message you must first join this group.
You do not have the permission required to post.
More options Mar 24 2012, 9:16 pm
Newsgroups: perl.perl6.language
From: datawea...@gmail.com (Jonathan Lang)
Date: Sat, 24 Mar 2012 18:16:58 -0700
Local: Sat, Mar 24 2012 9:16 pm
Subject: Re: How to make a new operator.
On Mar 24, 2012, at 5:26 PM, Damian Conway <dam...@conway.org> wrote:

IMHO: if we're going to take loss of precision into account, we should do so explicitly.  I'm a bit rusty, so forgive me if I misuse the terminology: if a number has an epsilon, the epsilon should be attached to it as a trait so that it can be accessed by the program.  This allows all sorts of things, like "close enough" smart-matching and error propagation.  The main question is if Perl should assign a minimum epsilon to all floats by default, or if this should be an "all's fair if you predeclare" type of thing.

To post a message you must first join this group.
You do not have the permission required to post.
More options Mar 24 2012, 9:36 pm
Newsgroups: perl.perl6.language
From: stefa...@cox.net (Stefan O'Rear)
Date: Sat, 24 Mar 2012 18:36:27 -0700
Local: Sat, Mar 24 2012 9:36 pm
Subject: Re: How to make a new operator.

On Sat, Mar 24, 2012 at 06:16:58PM -0700, Jonathan Lang wrote:
> IMHO: if we're going to take loss of precision into account, we should do so explicitly.  I'm a bit rusty, so forgive me if I misuse the terminology: if a number has an epsilon, the epsilon should be attached to it as a trait so that it can be accessed by the program.  This allows all sorts of things, like "close enough" smart-matching and error propagation.  The main question is if Perl should assign a minimum epsilon to all floats by default, or if this should be an "all's fair if you predeclare" type of thing.

Speaking as an implementor, I think this is quite unlikely.  Some of my
reasons:

1. Interval arithmetic (this is the correct technical term) is very
inefficient on some popular architectures.

2. After a long computation which is numerically stable *but which Perl
cannot _prove_ the stability of*, error bounds will be very large, and
if smart-matching automatically takes them into account, it will tend
to result in extremely suprising false positives.

3. Adding hidden state to numbers that is not visible by default will make
debugging harder.  Not hiding the state will make output much noisier.

Larry is free to override this of course.  Also, interval arithmetic ought
to be possible as a module.

-Stefan

To post a message you must first join this group.
You do not have the permission required to post.
More options Mar 24 2012, 11:20 pm
Newsgroups: perl.perl6.language
From: datawea...@gmail.com (Jonathan Lang)
Date: Sat, 24 Mar 2012 20:20:12 -0700
Local: Sat, Mar 24 2012 11:20 pm
Subject: Re: How to make a new operator.
On Mar 24, 2012, at 6:36 PM, Stefan O'Rear <stefa...@cox.net> wrote:

> On Sat, Mar 24, 2012 at 06:16:58PM -0700, Jonathan Lang wrote:
>> IMHO: if we're going to take loss of precision into account, we should do so explicitly.  I'm a bit rusty, so forgive me if I misuse the terminology: if a number has an epsilon, the epsilon should be attached to it as a trait so that it can be accessed by the program.  This allows all sorts of things, like "close enough" smart-matching and error propagation.  The main question is if Perl should assign a minimum epsilon to all floats by default, or if this should be an "all's fair if you predeclare" type of thing.

> Speaking as an implementor, I think this is quite unlikely.  Some of my
> reasons:

> 1. Interval arithmetic (this is the correct technical term) is very
>   inefficient on some popular architectures.

> 2. After a long computation which is numerically stable *but which Perl
>   cannot _prove_ the stability of*, error bounds will be very large, and
>   if smart-matching automatically takes them into account, it will tend
>   to result in extremely suprising false positives

I'll concede that these two (especially the second one) are sufficient arguments against the "default epsilon" idea, rendering my disagreement on the third point largely moot.  That said:

> 3. Adding hidden state to numbers that is not visible by default will make
>   debugging harder.  Not hiding the state will make output much noisier.

That's why I was suggesting making epsilon available as a trait (e.g., something like "5 but error(.01)"): if you need it, it would be easy to look it up; if you don't need it, it would be easy to ignore it.

> Larry is free to override this of course.  Also, interval arithmetic ought
> to be possible as a module.

Absolutely, it would be possible as a module.  And with your second point above, it ought to be a module, to be explicitly applied when the programmer wants to use interval arithmetic.

To post a message you must first join this group.
You do not have the permission required to post.
 Discussion subject changed to "Floating-point equality (was Re: How to make a new operator.)" by David Green
More options Mar 24 2012, 11:59 pm
Newsgroups: perl.perl6.language
From: david.gr...@telus.net (David Green)
Date: Sat, 24 Mar 2012 21:59:20 -0600
Local: Sat, Mar 24 2012 11:59 pm
Subject: Floating-point equality (was Re: How to make a new operator.)
On 2012-March-23, at 12:01 am, Damian Conway wrote:

> [...] we ought to allow for the inevitable loss of significant digits within the two preliminary division ops, and therefore compare the results with an suitably larger epsilon.
> That would not only be computational more justifiable, I suspect it might also produce more "least surprise". ;-)

I think that comparisons for floating-point values should take some kind of 'significance' adverb and complain if it's missing.  Having to be explicit makes for the least surprise of all.

π == 22/7                   # error
π == 22/7 :within(0.002)    # true
π == 22/7 :within(0.00002)  # false

Probably with something like 'use epsilon :within(0.0002)' as way to declare the fuzziness for a given scope if you have a lot of comparisons.  And of course you could use (the equivalent of) 'use epsilon :within(0)' to say, "I know what I'm doing, just give me straight what I ask for and I'll take the consequences."

Alternatively, maybe have float-comparisons give an error or warning, and introduce an "approximation operator": π == ~22/7 :within(\$epsilon).  (Except "~" is already taken!)

[I was going to suggest that as a way to handle stopping points in a sequence: 1, 3, 5 ... ~10, but that still wouldn't work without treating the Num::Approx values as a special case, which defeats the purpose.  Though with a postfix "up from" operator, you could say: 1, 3, 5 ... 10^.]

-David

To post a message you must first join this group.
You do not have the permission required to post.
 Discussion subject changed to "Not-so-smart matching (was Re: How to make a new operator.)" by David Green
More options Mar 25 2012, 12:35 am
Newsgroups: perl.perl6.language
From: david.gr...@telus.net (David Green)
Date: Sat, 24 Mar 2012 22:35:55 -0600
Local: Sun, Mar 25 2012 12:35 am
Subject: Not-so-smart matching (was Re: How to make a new operator.)
On 2012-March-21, at 6:38 pm, Daniel Carrera wrote:

> The idea of smart-matching a function just doesn't quite fit with my brain. I can memorize the fact that smart-matching 7 and &foo means evaluating foo(7) and seeing if the value is true, but I can't say I "understand" it.

Maybe it just needs a better name.  "Match" implies that two (or more) things are being compared against each other, and that's how smart-matching started out, but it's been generalised beyond that.  The underlying .ACCEPTS method suggests "acceptance"... but that's too broad (a function can "accept" args without returning true).  "Agreement" fits, in the sense of "that [food] agrees with me", but I think it suggests equality a bit too strongly.  "Accordance"?  "Conformance"?  "Validation"?  That seems a good match (ahem) for the concept: ~~ checks whether some value is "valid" (or "desired"?) according to certain criteria.  The obvious way to validate some value against a simple string or number is to compare them; or against a pattern, to see if the value matches; but given a function, you check the value by passing it to the function and seeing whether it says yea or nay.

I'm not sure "validation" or "validity" is the best name, but it conforms better to what smart-"matching" does.  Or "conformance"....  Hm.  But terminology that sets up the appropriate expectations is a good thing.

-David

To post a message you must first join this group.
You do not have the permission required to post.
 Discussion subject changed to "How to make a new operator." by Moritz Lenz
More options Mar 25 2012, 12:38 am
Newsgroups: perl.perl6.language
From: mor...@faui2k3.org (Moritz Lenz)
Date: Sun, 25 Mar 2012 06:38:04 +0200
Local: Sun, Mar 25 2012 12:38 am
Subject: Re: How to make a new operator.

On 03/23/2012 09:14 AM, Damian Conway wrote:

>> it means we cannot do the same fuzziness for the endpoint,

> Except that we will be encouraging people to use: * >= \$END
> as their standard endpoint pattern, which will provide
> most of the necessary fuzz.

and which will still surprise those people who are surprised
by floating point inaccuracies.

>> This discussion makes me think that maybe
>> deducing geometric sequences is too much magic as well.

> Geometric sequence inference is fine on Ints and Rats.

> But, if we can't perform inferences involving Nums in a sound numerical
> way (and it may well be that we can't, without taking a noticeable
> performance hit), then I think that we would be better off limiting the
> deduction of *both* arithmetic and geometric sequences to starting lists
> that contain only Ints and Rats.

Floating point numbers *can* represent a huge number of commonly used
values without errors, and you can do error-free arithmetic operations
on many of them. Excluding Nums from automatic deduction feels like an
unnecessary pessimization or stigmatization, especially if you consider
that writing a number like 0.001 in your program gives a Rat by default
not a Num.

Most of the time you only get a Num in Perl 6 if you consciously decide
to write one, in which case you should also be well aware of the
limitations of FP math.

At least in #perl6 I've never seen anybody try to write an auto-deduced
sequence, and fail because of floating-point errors.

Cheers,
Moritz

To post a message you must first join this group.
You do not have the permission required to post.
 Discussion subject changed to "Floating-point equality (was Re: How to make a new operator.)" by Moritz Lenz
More options Mar 25 2012, 12:55 am
Newsgroups: perl.perl6.language
From: mor...@faui2k3.org (Moritz Lenz)
Date: Sun, 25 Mar 2012 06:55:44 +0200
Local: Sun, Mar 25 2012 12:55 am
Subject: Re: Floating-point equality (was Re: How to make a new operator.)

On 03/25/2012 05:59 AM, David Green wrote:

> On 2012-March-23, at 12:01 am, Damian Conway wrote:
>> [...] we ought to allow for the inevitable loss of significant digits within the two preliminary division ops, and therefore compare the results with an suitably larger epsilon.
>> That would not only be computational more justifiable, I suspect it might also produce more "least surprise". ;-)

> I think that comparisons for floating-point values should take some kind of 'significance' adverb and complain if it's missing.  Having to be explicit makes for the least surprise of all.

>    π == 22/7                   # error
>    π == 22/7 :within(0.002)    # true
>    π == 22/7 :within(0.00002)  # false

Note that neither 22/7 nor 0.002 are floating-point values.

I don't know if the majority of the perl6-language posters have realized
it yet, but both Perl 6 and the its implementations are quite mature
these days. Mature enough that such proposals should be prototyped as
modules, and thoroughly tested on lots of existing code before taken
into consideration for

Niecza supports operator adverbs, and supports them on user-defined
operators, so there's nothing to stop you from trying it.

Cheers,
Moritz

To post a message you must first join this group.
You do not have the permission required to post.
 Discussion subject changed to "How to make a new operator." by Damian Conway
More options Mar 25 2012, 2:09 am
Newsgroups: perl.perl6.language
From: dam...@conway.org (Damian Conway)
Date: Sun, 25 Mar 2012 17:09:16 +1100
Local: Sun, Mar 25 2012 2:09 am
Subject: Re: How to make a new operator.

> At least in #perl6 I've never seen anybody try to write an auto-deduced
> sequence, and fail because of floating-point errors.

Except for Martin's 1, sqrt(2), 2...8

But, yes, the widespread use of Rats rather than Nums
means only the edgiest of edge-cases fails. And as you get
an explicit Failure when it does happen, at least people will
know when the numerical computations don't work as hoped.

Damian

To post a message you must first join this group.
You do not have the permission required to post.
 Discussion subject changed to "Floating-point equality (was Re: How to make a new operator.)" by Moritz Lenz
More options Mar 25 2012, 12:44 pm
Newsgroups: perl.perl6.language
From: mor...@faui2k3.org (Moritz Lenz)
Date: Sun, 25 Mar 2012 18:44:57 +0200
Local: Sun, Mar 25 2012 12:44 pm
Subject: Re: Floating-point equality (was Re: How to make a new operator.)
On 03/25/2012 06:55 AM, Moritz Lenz wrote:

> I don't know if the majority of the perl6-language posters have realized
> it yet, but both Perl 6 and the its implementations are quite mature
> these days. Mature enough that such proposals should be prototyped as
> modules, and thoroughly tested on lots of existing code before taken
> into consideration for

... inclusion into the spec.

Sometimes I do finish my sentences with several hours delay, sorry for that.

Cheers,
Moritz

To post a message you must first join this group.
You do not have the permission required to post.
 Discussion subject changed to "Not-so-smart matching (was Re: How to make a new operator.)" by yary
More options Mar 25 2012, 2:34 pm
Newsgroups: perl.perl6.language
From: not....@gmail.com (yary)
Date: Sun, 25 Mar 2012 14:34:11 -0400
Local: Sun, Mar 25 2012 2:34 pm
Subject: Re: Not-so-smart matching (was Re: How to make a new operator.)
I also like "agreement", "conformance"... In a situation like this, I
reach for a thesaurus- very useful when looking for just the right
name for a variable/method name/way to describe a concept. Here's a

accord, agree, conformance, conformation, conformity, congruence,
congruity, consensus, consonance, correspondence, harmony, unison
agree, fit, correspond, compeer, meet, gibe, pair, mate, twin, cope with, touch

Fit, correspond, congruity, harmonize seem like other good
descriptions for the concept. Fit is especially good due to its
brevity, and congruence is good due to the use of ~~ as the smartmatch
aka congruence/fitness/agreement/harmonizing/correspondence/conformance
operator.

(Bikeshed?)

-y

To post a message you must first join this group.
You do not have the permission required to post.
More options Mar 25 2012, 3:45 pm
Newsgroups: perl.perl6.language
From: dam...@conway.org (Damian Conway)
Date: Mon, 26 Mar 2012 06:45:20 +1100
Local: Sun, Mar 25 2012 3:45 pm
Subject: Re: Not-so-smart matching (was Re: How to make a new operator.)
yary suggested:

> In a situation like this, I reach for a thesaurus

The standout from that list for me is: 'consonance'.
Second favorite is: 'gibe' or 'jibe'.

But the underlying operation is .ACCEPTS(),
so perhaps the operation should be referred to
as "acceptance" or "acceptibility".

Damian