🚀 go-pugleaf

From article <1989Jul21.035825.27704@cs.rochester.edu>, by crowl@cs.rochester.edu (Lawrence Crowl):
> There are a number of reasons that rounding modes are not used more.  And
> unfortunately, the reasons feed each other.
> 
> - Programming languages historically do not support rounding modes.
> - So, such use has been restricted generally to changing modes between program
>   runs (for a warm fuzzy).
> - So, specifying the rounding modes is part of device setup and not part of
>   the operation instruction.
> - So, changing the rounding mode is a difficult and time consuming operation.
> - So, newer programming languages tend not to support rounding modes because
>   the designers know users will not pay the cost.
> 
> We can break the cycle and provide good access to faster, more robust floating
> point programs with the following efforts.
> 
> - Specify the rounding mode as part of the operation.  In essence, I am saying
>   that rounding MODES are a self-defeating way of looking at the capability.
>   We should have ADD-ROUNDING-UP and ADD-ROUNDING-DOWN, etc.
> - Make these operations available in a programming language.
> - Make these operations convenient in a programming language, e.g. operator
>   overloading in Ada and C++.
> 
I have been in hollidays, so this comes a little late.

I hate to say it again and again:

There are languages which have rounding with their operations, so you
can write

     x := y +> z;    (* + with round upward *)

and this also with < e.g. +<, for all operations.

These languages are    PASCAL-SC    and     FORTRAN-SC.

I will stop here since I know this is not a language group -:).
Only one sentence: The only thing these languages lack are vendors who
port them to their hardware ( No market they say )

R. Kirchner

kirchner@uklirb.uucp
kinf89@dkluni01.bitnet     ( preferred )