> > E.g. integer arithmetic etc is a relic from an age long
> > gone, it would be so nice to say good bye to it.
>
> Hmm. Nelson Beebe would raise a lot of objections. He
> regularly tests floating point packages and implementations
> whether they follow the IEEE standards, and there are still
> far too many which don't. Since this has already been
> discussed recently I ask you too look up the archive.
But still, people had no qualms about using floating point
arithmetic (CDC, Cray, Vax) before there ever was an IEEE
standard. [*] And even if some of them might have had a few
nasty features, having floating point at all was better than
not having it. And with regard to groff, we're talking about
convenience, not precision arithmetic. If your groff job
depends subtly on minute differences between one floating point
implementation and the other (this really shouldn't happen in
real-life groff applications), then either [**] accept it as a
fact of life and live with it, or rewrite your computation to
make it more robust.
Still, I think most problems we have with arithmetic in
groff are simply overflows, and those can be cured by doing
all arithmetic in the next larger integer representation.
[*] Furthermore, is there anyone who has scruples using
floating point in pic or grap today?
[**] And remember there is one fundamental design difference
between groff and TeX: TeX has exactly *one* "device"
(in groff parlance), and we expect exactly the same output
in all implementations. Groff has never had that aim.
On the contrary, output is explicitly device dependent
(let's say "device optimized"). Why not generalize
this and allow differences even for the same device
on different installations? If you want people to see
exactly what you have, send the the finished, formatted
output (text, PS, PCL, whatever). If you send them
the source, expect them to edit it and get different
results anyway.
_______________________________________________
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
