Martin von Gagern
gagern at ma.tum.de
Thu Aug 27 06:10:21 UTC 2015
On 26.08.2015 23:37, Waldemar Horwat wrote:
> It doesn't make sense to encode a rounding mode such as "round down"
> into a value type. If you multiply it by -1, half of the time it will
> start doing the wrong thing.
I agree: If this were implemented using a value type, then I'd envision
myself converting between types all the time, since the rounding mode is
indeed a property of the operation, not the value. User-definable value
types would be very useful to build (multi-precision?) interval
arithmetic on top of the directed rounding, though.
> Instead, you want functions that perform the primitive operations (+, -,
> *, /, sqrt, sin, etc.) in a rounding mode specified by the name of the
> function or perhaps a third parameter.
I wonder which of these would be easier for engines to optimize.
Detecting certain functions and inlining them during JIT compilation is
already established, I think. Turning that third parameter into some
machine-specific code is likely harder, but shouldn't be too hard as
long as the third parameter is a literal or some constant. But this is
my guessing, without too much knowledge about how intrinsics are
actually handled during compilation.
On the other hand, if that parameter might change, i.e. if you want to
perform the same computation repeatedly with different rounding modes,
then a parameter might be better than passing different combinations of
functions as arguments. I can think of no real-world application where
the same lengthy operation would be performed with different rounding
modes, due to the sign change issues you already mentioned. But it might
be worthwhile to investigate open source code which is using fesetround
and friends to see whether I'm missing some application here.
Martin von Gagern
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: OpenPGP digital signature
More information about the es-discuss