rounding method adverbs

Martin D Kealey said (in the a..b thread):
 >> So then, "a" cmp "ส้" is always defined, but users can change the
 >> definition.
 >
 > I take the opposite approach; it's always undefined (read, unthrown
 > exception) unless the user tells us how they want it treated. That can be a
 > command-line switch if necessary.
 >
 > To paraphrase Dante, "the road to hell is paved with Reasonable Defaults".
 > Or in programming terms, your reasonable default is the cause of my ugly
 > work-around.

That might be fair.

But if we're going to do that, then I'd like to go a step further and require 
some other operators have mandatory config arguments for users to explicitly 
state the semantics they want, but that once again a lexical pragma can declare 
this at a higher level.

Specifically, I think there should be a configuration for any numeric operations 
that might do rounding, where users specify the rounding method employed.  For 
example, the Int-resulting division and modulo operators should require 
specifying how to round on an uneven division.

I can think of at least 9 rounding methods to choose from off the top of my 
head: up (ceiling), down (floor), to-zero (truncate), to-infinity, half-up 
(common), half-down, half-to-zero, half-to-infinity, and half-to-even 
(statistics, banking, etc).  There are probably more, so this should be extensible.

The point here is that there are multiple distinct expectations on what is a 
reasonable default way to do numeric rounding, and it would be a lot more clear 
for everyone reading code if these semantics were spelled out.  Just because 
such as default is stated in the Perl 6 manual doesn't mean it won't constantly 
trip people up all the same.

In particular, common programming languages are often split between down/floor 
and to-zero/truncate as their semantics, and I believe even Perl 5 and Perl 6 
differ on the issue.

Having these options provided also supports some other common tasks.  For 
example, the up/ceiling option would be common, if the task is to figure out how 
many containers we need to hold our widgets, or how many rows in which to 
display multi-column data.

For example:

   $num_boxes_needed = $num_widgets div $box_capacity :round(Up)

Similarly, explicitly stated rounding semantics are useful for non-integer 
operations such as currency or statistics or science.

Also useful when we want to emulate other languages in Perl 6 elegantly and 
even-handedly.

Now, of course, some rounding methods may be more efficient than others on 
particular hardware, but that's just something that should be documented, or 
alternately an explicit named rounding method of don't care could be provided, 
for users who don't care about exact portable semantics, and the implementation 
can decide what is fastest.  I suggest using the whatever mnemonic for this:

   $a = $b div $c :round(*)

... though for those people, probably they'd do it at the file level.

-- Darren Duncan

• rounding method adverbs by Darren Duncan