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
