Re: r28113 - docs/Perl6/Spec
pugs-comm...@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 CNum type, converts both operands to CNum +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 CRat value. snip $numerator div $denominator snip -Use of Cdiv on two CInt values results in a ratio of the CRat type. +Use of Cdiv 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
Re: r28113 - docs/Perl6/Spec
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 C42. with just a trailing dot. You must instead say either C42 or C42.0. Pm
Re: r28113 - docs/Perl6/Spec
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 C42. with just a trailing dot. You must instead say either C42 or C42.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
