FAQ
Author: lwall
Date: 2009-08-29 21:06:40 +0200 (Sat, 29 Aug 2009)
New Revision: 28113

Modified:
docs/Perl6/Spec/S03-operators.pod
Log:
[S03] some tidying of /, %, div, and mod

Modified: docs/Perl6/Spec/S03-operators.pod
===================================================================
--- docs/Perl6/Spec/S03-operators.pod 2009-08-29 18:30:05 UTC (rev 28112)
+++ docs/Perl6/Spec/S03-operators.pod 2009-08-29 19:06:40 UTC (rev 28113)
@@ -14,8 +14,8 @@

Created: 8 Mar 2004

- Version: 169
+ Version: 170

@@ -699,7 +699,16 @@

\$numerator / \$denominator

-If either operand is of C<Num> type, converts both operands to C<Num>
+Performs division of real or complex numbers, returning a real or complex
+number of appropriate type.
+
+If both operands are of integer type, the operator returns the
+corresponding C<Rat> value.
+
+Otherwise, if either operand is of C<Complex> type, converts both
+operands to C<Complex> and does division returning C<Complex>.
+
+Otherwise, if either operand is of C<Num> type, converts both operands to C<Num>
and does division returning C<Num>. If the denominator is zero,
returns an object representing either C<+Inf>, C<NaN>, or C<-Inf>
as the numerator is positive, zero, or negative. (This is construed
@@ -711,19 +720,17 @@
in a non-parallel computation, it will likely throw an exception at
that point.)

-If both operands are of integer type, you still get a C<Num>, but the
-C<Num> type is allowed to do the division lazily; internally it may
-store a C<Rat> until the time a value is called for. If converted
-to C<Rat> directly no division ever need be done.
-
=item *

C<< infix:<div> >>, generic division

\$numerator div \$denominator

-Dispatches to the C<< infix:<div> >> multi most appropriate to the operand
-types. Policy on what to do about division by zero is up to the type,
+Dispatches to the C<< infix:<div> >> multi most appropriate to the
+operand types, typically returning a value of the same type.
+Not coercive, so fails on differing types.
+
+Policy on what to do about division by zero is up to the type,
but for the sake of hyperoperators and junctions those types that
can represent overflow (or that can contain an unthrown exception)
should try to do so rather than simply throwing an exception. (And in
@@ -731,24 +738,40 @@
use in hyperops and junctions, and whether they can profitably benefit
from a lazy exception model.)

-Use of C<div> on two C<Int> values results in a ratio of the C<Rat> type.
+Use of C<div> on built-in integer types is equivalent to taking the
+floor of a real division:

+ \$x div \$y == floor(\$x/\$y);
+
=item *

C<< infix:<%> >>, modulus

\$x % \$mod

-Always floor semantics using C<Num> or C<Int>.
+Coerces to C<Num> (or C<Int> as an optimization) before performing C<mod>.
+That is, has results equivalent to:

+ floor( Num(\$x) / Num(\$y) )
+
+Also preserves the identity:
+
+ \$x % \$y == \$x - floor(\$x / \$y) * \$y
+
=item *

C<< infix:<mod> >>, generic modulus

\$x mod \$mod

-Dispatches to the C<< infix:<mod> >> multi most appropriate to the operand types.
+Dispatches to the C<< infix:<mod> >> multi most appropriate to
+the operand types, typically returning a value of the same type.
+Not coercive, so fails on differing types.

+For built-in types, preserves the identity
+
+ \$x mod \$y == \$x - (\$x div \$y) * \$y
+
=item *

C<< infix:{'+&'} >>, numeric bitwise and

## Search Discussions

•  at Aug 31, 2009 at 8:28 pm ⇧

pugs-commits@feather.perl6.nl wrote:
Author: lwall
Date: 2009-08-29 21:06:40 +0200 (Sat, 29 Aug 2009)
New Revision: 28113

Modified:
docs/Perl6/Spec/S03-operators.pod
Log:
[S03] some tidying of /, %, div, and mod <snip>
@@ -699,7 +699,16 @@

\$numerator / \$denominator

-If either operand is of C<Num> type, converts both operands to C<Num>
+Performs division of real or complex numbers, returning a real or complex
+number of appropriate type.
+
+If both operands are of integer type, the operator returns the
+corresponding C<Rat> value. <snip>
\$numerator div \$denominator <snip>
-Use of C<div> on two C<Int> values results in a ratio of the C<Rat> type.
+Use of C<div> on built-in integer types is equivalent to taking the
+floor of a real division:

+ \$x div \$y == floor(\$x/\$y);
<snippage>

This is a great move; thanks for this change.

So now writing things like 5/43 in code will DWIM and produce a Rat which
maintains the intended value exactly, with no floating-point imprecision; and so
plain 5/43 is now a plain Rat literal, same as 1.23 is.

Similarly its good that by default 'div' can be counted on to result in values
of the same type as its operands, such as Int,Int-->Int.

Generally speaking, the simpler/terse looking numeric operators like "/" should
produce exact results from exact inputs where possible, and leave the inexact
(float) results from exact inputs to more complex/verbose looking operators.

Much appreciated.

-- Darren Duncan
•  at Aug 31, 2009 at 10:20 pm ⇧

On Mon, Aug 31, 2009 at 01:28:08PM -0700, Darren Duncan wrote:
This is a great move; thanks for this change.

So now writing things like 5/43 in code will DWIM and produce a Rat which
maintains the intended value exactly, with no floating-point imprecision;
and so plain 5/43 is now a plain Rat literal, same as 1.23 is.
FWIW, presently the specification somewhat implies that 1.23 is a Num
literal, and doesn't say anything about it producing a Rat.
(Yes, conversations on #perl6 have indicated that it may be otherwise,
but nothing is currently in the spec about it.)

S02:401 :
One consequence of all this is that you may no longer write a Num as
C<42.> with just a trailing dot. You must instead say either C<42>
or C<42.0>.

Pm
•  at Aug 31, 2009 at 10:38 pm ⇧

Patrick R. Michaud wrote:
On Mon, Aug 31, 2009 at 01:28:08PM -0700, Darren Duncan wrote:
This is a great move; thanks for this change.

So now writing things like 5/43 in code will DWIM and produce a Rat which
maintains the intended value exactly, with no floating-point imprecision;
and so plain 5/43 is now a plain Rat literal, same as 1.23 is.
FWIW, presently the specification somewhat implies that 1.23 is a Num
literal, and doesn't say anything about it producing a Rat.
(Yes, conversations on #perl6 have indicated that it may be otherwise,
but nothing is currently in the spec about it.)

S02:401 :
One consequence of all this is that you may no longer write a Num as
C<42.> with just a trailing dot. You must instead say either C<42>
or C<42.0>.
My understanding of Perl 6 to date is that:

Num is effectively a wrapper type that represents a real number some-how and
that internally its representation could either be an Int or a Rat or something
that does IEEE floating-point or something else.

That is, any Int or Rat could be exactly matched by a Num but a Num could also
represent other values that neither an Int nor a Rat can, or that Num can do
approximate (eg, IEEE float) math while Int and Rat would only do exact math
(and so not support certain ops that might result in an irrational).

And so, any context that expects a Num will accept any Int or Rat, but the
reverse may not be true without coersion.

That is, Num will support both exact and inexact numbers, but Int/Rat don't.

Therefore, any literal such as 42.0, because it is exact, should be interpreted
as a plain Rat, same as 42 is interpreted as a plain Int, but they would still
work with any context wanting a Num.

I also don't think this interpretation would harm type-based routine dispatch
since using Rat ops on Rat-compatible inputs would still produce results
suitable for use in Num contexts, I would think.

-- Darren Duncan

## Related Discussions

Discussion Overview
 group perl6-language categories perl posted Aug 29, '09 at 7:06p active Aug 31, '09 at 10:38p posts 4 users 3 website perl6.org

### 3 users in discussion

Content

People

Support

Translate

site design / logo © 2021 Grokbase