Re: default for quotRem in terms of divMod?

On Sun, 12 Aug 2007, Lennart Augustsson wrote:
CPU design cannot be changed, because they implement well defined ISA.
What is ISA? Why is it not possible to add CPU functions for `div` and `mod`?
The only processor I know of (NS 32k) with a different division is long dead.
If efficiency on current CPUs is the only advantage of `quot` and `rem`, then for future versions of Haskell I propose to fix these functions to the type Int rather than making them class methods. For non-machine types like Integer the efficiency argument does certainly not hold.

Henning Thielemann wrote:
On Sun, 12 Aug 2007, Lennart Augustsson wrote:
CPU design cannot be changed, because they implement well defined ISA.
What is ISA? Why is it not possible to add CPU functions for `div` and `mod`?
"Instruction set architecture" - it would take a concerted industry effort to add these to new machines (and new machines only, obviously), maybe. Then compilers would have to support the new instructions. Probably it would not help efficiency much, anyway (div and mod are rather fast too, Haskell is generally slower with current compilers, algorithms can often be defined in a way that uses only nonnegative numbers...).
If efficiency on current CPUs is the only advantage of `quot` and `rem`, then for future versions of Haskell I propose to fix these functions to the type Int rather than making them class methods. For non-machine types like Integer the efficiency argument does certainly not hold.
It is not. *Sometimes I want to round towards zero*. Aside from my Haskell-implemented Integer type, which as well as using quotRem also provides a quotRem that is a little faster than divMod (I have no idea what GMP's speeds are like)... I believe I have used quotRem to round a difference (a directed distance vector, in a discrete space) towards zero, while preserving its sign. And I was using Integer, not Int, for correctness. I think quotRem deserves to stay usable on Integrals, and also it would break too many things to remove it from the class (it may be something to consider for Prelude redesigns though, along with the rest of the numeric hierarchy!). Isaac
participants (2)
-
Henning Thielemann
-
Isaac Dupree