From frioux@gmail.com

mmmm, perl6
--
fREW Schmidt
http://blog.afoolishmanifesto.com

From frioux@gmail.com

diff --git a/src/builtins/any-num.pir b/src/builtins/any-num.pir
index 6dfcee6..7bf0bbe 100644
--- a/src/builtins/any-num.pir
+++ b/src/builtins/any-num.pir
@@ -21,7 +21,7 @@ the size of that file down and to emphasize their generic,
 .namespace []
 .sub 'onload' :anon :init :load
     $P0 = get_hll_namespace ['Any']
-    '!EXPORT'('abs,cis,int,log,chr,polar,sqrt,truncate,unpolar', 'from'=>$P0)
+    '!EXPORT'('cis,int,log,chr,polar,sqrt,truncate,unpolar', 'from'=>$P0)
 
     ##  pre-seed a random number generator
     $P0 = new 'Random'
@@ -30,17 +30,6 @@ the size of that file down and to emphasize their generic,
 .end
 
 
-=item abs()
-
-=cut
-
-.namespace ['Any']
-.sub 'abs' :method :multi(_)
-    $N0 = self
-    $N1 = abs $N0
-    .return ($N1)
-.end
-
 =item chr()
 
 =cut
diff --git a/src/classes/Int.pir b/src/classes/Int.pir
index 96b9527..eb30b61 100644
--- a/src/classes/Int.pir
+++ b/src/classes/Int.pir
@@ -20,9 +20,6 @@ Int - Perl 6 integers
     intproto = p6meta.'new_class'('Int', 'parent'=>'Integer Any')
     p6meta.'register'('Integer', 'parent'=>intproto, 'protoobject'=>intproto)
     p6meta.'register'('BigInt', 'parent'=>intproto, 'protoobject'=>intproto)
-
-    $P0 = get_hll_namespace ['Int']
-    '!EXPORT'('abs', 'from'=>$P0)
 .end
 
 
@@ -37,12 +34,6 @@ This is a value type, so just returns itself.
 .end
 
 
-.sub 'abs' :method :multi('Integer')
-    $P0 = abs self
-    .return ($P0)
-.end
-
-
 =item ACCEPTS()
 
 =cut
diff --git a/src/setting/Any-num.pm b/src/setting/Any-num.pm
new file mode 100644
index 0000000..a73529a
--- /dev/null
+++ b/src/setting/Any-num.pm
@@ -0,0 +1,94 @@
+class Any is also {
+
+=begin item sign
+
+ our Int multi method sign ( Num $x: ) is export
+
+Returns 1 when C<$x> is greater than 0, -1 when it is less than 0, 0 when it
+is equal to 0, or undefined when the value passed is undefined.
+
+=end item
+
+    our Int multi method sign ( Num $x: ) is export {
+        given self {
+            when 0 { return 0 }
+            when $_ < 0 { return -1 }
+            when $_ > 0 { return 1 }
+            default { fail 'impossible default' }
+        }
+    }
+
+=begin item floor
+
+ our Int multi method floor ( Num $x: ) is export
+
+Returns the highest integer not greater than C<$x>.
+
+=end item
+
+    our Int multi method floor ( Num $x: ) is export {
+        my $truncated = self.truncate;
+        if self == $truncated {
+            return self;
+        } else {
+            given self.sign {
+                when -1 { return $truncated - 1 }
+                when 1 { return $truncated }
+                default { fail 'impossible default' }
+            }
+        }
+    }
+
+=begin item ceiling
+
+ our Int multi method ceiling ( Num $x: ) is export
+
+Returns the lowest integer not less than C<$x>.
+
+=end item
+
+    our Int multi method ceiling ( Num $x: ) is export {
+        my $truncated = self.truncate;
+        if self == $truncated {
+            return self;
+        } else {
+            given self.sign {
+                when -1 { return $truncated }
+                when 1 { return $truncated + 1 }
+                default { fail 'impossible default' }
+            }
+        }
+    }
+
+=begin item round
+
+ our Int multi method round ( Num $x: ) is export
+
+Returns the nearest integer to C<$x>.  The algorithm is C<floor($x + 0.5)>.
+(Other rounding algorithms will be given extended names beginning with "round".)
+
+=end item
+
+    our Int multi method round ( Num $x: ) is export {
+        return floor($x + 0.5);
+    }
+
+=begin item abs
+
+ our Num multi method abs ( Num $x: ) is export
+
+Absolute Value.
+
+=end item
+
+    our Num multi method abs ( Num $x: ) is export {
+        given self.sign {
+            when 1|0 { return self }
+            when -1 { return -self }
+            default { fail 'impossible default' }
+        }
+    }
+
+}
+
+# vim: ft=perl6

From @japhb

On Sat, 2009-03-14 at 14​:07 -0700, fREW Schmidt wrote​:

# New Ticket Created by fREW Schmidt
# Please include the string​: [perl #​63874]
# in the subject line of all future correspondence about this issue.
# <URL​: http://rt.perl.org/rt3/Ticket/Display.html?id=63874 >

mmmm, perl6

I'm all in favor of converting things that are complex in PIR to things
that are simple in Perl 6 ... but why convert things that boil down to a
single instruction in PIR into complex things in Perl 6? Especially
since the complex Perl 6 code is highly likely to run a couple orders of
magnitude slower?

Lesson from the Forth world​: In cases where the semantic of a high-level
word exactly (or very closely) matches an instruction in the hardware's
ISA, it really deserves to be a primitive.

-'f

The RT System itself - Status changed from 'new' to 'open'

From frioux@gmail.com

I'm all in favor of converting things that are complex in PIR to things
that are simple in Perl 6 ... but why convert things that boil down to a
single instruction in PIR into complex things in Perl 6? Especially
since the complex Perl 6 code is highly likely to run a couple orders of
magnitude slower?

Lesson from the Forth world​: In cases where the semantic of a high-level
word exactly (or very closely) matches an instruction in the hardware's
ISA, it really deserves to be a primitive.

-'f

Yeah, the main reason I did it was because it was on the rakudo wiki for
candidates for the setting.

--
fREW Schmidt
http://blog.afoolishmanifesto.com

From @pmichaud

On Sun, Mar 15, 2009 at 01​:25​:28AM -0500, fREW Schmidt wrote​:

Lesson from the Forth world​: In cases where the semantic of a high-level
word exactly (or very closely) matches an instruction in the hardware's
ISA, it really deserves to be a primitive.

Yeah, the main reason I did it was because it was on the rakudo wiki for
candidates for the setting.

By putting floor/ceiling/round/sign/abs as a candidates for the setting
I was really aiming more for "inline PIR" than a pure Perl 6 solution.
We still need those functions to have signatures and (perhaps)
participate in multidispatch, and that's easier if the function
definitions are Perl 6 (with the function bodies being inline PIR
or a mixture of Perl 6 and inline PIR).

Pm

From @japhb

On Mon, 2009-03-16 at 21​:08 -0500, Patrick R. Michaud wrote​:

On Sun, Mar 15, 2009 at 01​:25​:28AM -0500, fREW Schmidt wrote​:

Lesson from the Forth world​: In cases where the semantic of a high-level
word exactly (or very closely) matches an instruction in the hardware's
ISA, it really deserves to be a primitive.

Yeah, the main reason I did it was because it was on the rakudo wiki for
candidates for the setting.

By putting floor/ceiling/round/sign/abs as a candidates for the setting
I was really aiming more for "inline PIR" than a pure Perl 6 solution.
We still need those functions to have signatures and (perhaps)
participate in multidispatch, and that's easier if the function
definitions are Perl 6 (with the function bodies being inline PIR
or a mixture of Perl 6 and inline PIR).

Gotcha. Sounds fine by me (as long as the Perl 6 signatures don't carry
significantly more overhead than the pure-PIR version).

-'f

From @pmichaud

On Mon, Mar 16, 2009 at 09​:41​:37PM -0700, Geoffrey Broadwell wrote​:

On Mon, 2009-03-16 at 21​:08 -0500, Patrick R. Michaud wrote​:

By putting floor/ceiling/round/sign/abs as a candidates for the setting
I was really aiming more for "inline PIR" than a pure Perl 6 solution.
We still need those functions to have signatures and (perhaps)
participate in multidispatch, and that's easier if the function
definitions are Perl 6 (with the function bodies being inline PIR
or a mixture of Perl 6 and inline PIR).

Gotcha. Sounds fine by me (as long as the Perl 6 signatures don't carry
significantly more overhead than the pure-PIR version).

They do carry more overhead (perhaps even a significant amount), but it's
a necessary overhead because we want them to properly participate in
multidispatch, and we'd like things like .signature to work properly.

Pm

From @japhb

On Tue, 2009-03-24 at 11​:56 -0500, Patrick R. Michaud wrote​:

On Mon, Mar 16, 2009 at 09​:41​:37PM -0700, Geoffrey Broadwell wrote​:

On Mon, 2009-03-16 at 21​:08 -0500, Patrick R. Michaud wrote​:

By putting floor/ceiling/round/sign/abs as a candidates for the setting
I was really aiming more for "inline PIR" than a pure Perl 6 solution.
We still need those functions to have signatures and (perhaps)
participate in multidispatch, and that's easier if the function
definitions are Perl 6 (with the function bodies being inline PIR
or a mixture of Perl 6 and inline PIR).

Gotcha. Sounds fine by me (as long as the Perl 6 signatures don't carry
significantly more overhead than the pure-PIR version).

They do carry more overhead (perhaps even a significant amount), but it's
a necessary overhead because we want them to properly participate in
multidispatch, and we'd like things like .signature to work properly.

I get the feeling that dispatch performance is going to be utterly
critical for Perl 6 (all implementations). It seems to me that in
gaining flexibility and orthogonality, we've lost a lot of places that
Perl 5 could special case things for speed.

Of course, Perl 6 allows us to optimize *different* things for speed --
hyperoperators come to mind -- but it's hard to let go of the things
that you already have, you know?

/me goes back to blind faith in the coming happy place ....

-'f

From @jnthn

Geoffrey Broadwell wrote​:

On Tue, 2009-03-24 at 11​:56 -0500, Patrick R. Michaud wrote​:

On Mon, Mar 16, 2009 at 09​:41​:37PM -0700, Geoffrey Broadwell wrote​:

Gotcha. Sounds fine by me (as long as the Perl 6 signatures don't carry
significantly more overhead than the pure-PIR version).

They do carry more overhead (perhaps even a significant amount), but it's a necessary overhead because we want them to properly participate in multidispatch, and we'd like things like .signature to work properly.

I get the feeling that dispatch performance is going to be utterly
critical for Perl 6 (all implementations). It seems to me that in
gaining flexibility and orthogonality, we've lost a lot of places that
Perl 5 could special case things for speed.

Of course, Perl 6 allows us to optimize *different* things for speed --
hyperoperators come to mind -- but it's hard to let go of the things
that you already have, you know?

While performance now isn't that much of a priority for me right now,
having some concrete ideas about how to get it later is more of one. :-)

Dispatch performance will indeed matter heavily. In fact, one of the few
bits of performance-related work that has been done in Rakudo is in that
area​: our MMD implementation has a cache. The Parrot one currently does
not, meaning that on the decision about what to call we might actually
get a small win moving things into setting.

However, anything we win there we lose overall because signature binding
is currently really quite unoptimized. So yes, moving things into the
setting will slow us down for now. But signature binding is going to be
an improvable hot-path further down the line (but it's not worth
spending time on now since it probably needs more changes yet, and
optimized code is harder to maintain and build on).

Further, because we have a much richer type system now, there's going to
be space for a bunch of type-based analysis. This I hope will not just
give more performance, but also detect more errors at compile time.
Another bonus in this area is that the language is designed so we can
know the set of candidates at compile time for things in our current and
outer scope, meaning we might even be able to skip multi-dispatch
entirely. (Note that even if you do a "use" which imports more stuff,
we'll still know about them, since that happens at compile time). The
whole area of type-driven optimization is something I really look
forward to working in - but it's secondary to a complete implementation
of the Perl 6 spec.

Anyway, the take away from this is​: yes, I do expect we'll be able to
make this performant later and there have been choices in the language
design to aid this. However, it's too early to really dig into
optimization - not only because we should have a focus on
feature-completeness first, but also because we probably don't have
adequate test coverage yet to know when we've got an optimization and
when we've found a fast way to give the wrong answer. :-)

Jonathan

From @pmichaud

Other PIR-based versions of these functions were added as part of RT
#​64020 and committed in 9a08c4f .

Resolving ticket, thanks!

Pm

@pmichaud - Status changed from 'open' to 'resolved'