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. Greetings, Martin von Gagern
signature.asc
Description: OpenPGP digital signature
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
