On 2012-09-14 16:17:43 +0000, Joseph S. Myers wrote: > On Fri, 14 Sep 2012, Vincent Lefevre wrote: > > > round-to-odd would be a good solution if it were provided directly > > in hardware. Otherwise a "direct" implementation would probably be > > more efficient (in particular when the implementation of the usual > > operation is done in software, like for decimal arithmetic). > > It's the case for a lot of libm operations that the best implementation > for software floating point is not the same as for hardware floating point > (anything implemented using Dekker's algorithms or similar precision > extension techniques would probably better use higher precision more > directly on integers, for example).
The main difference is that most processors have hardware FP, so that FP expansions are better in general to implement libm math functions (a hardware FMA is very useful for that too, but most processors will have one in the near future), while round-to-odd is not provided in hardware, not in IEEE 754-2008, and probably won't be provided in hardware at least before a distant future. So, there is work to do in software... Then, between implementing round-to-odd and implementing a direct formatOf operation, I don't think there is much difference concerning the work to do (I would even say that round-to-odd could require more work). > It's also the case that there hasn't been any actual interest in > optimal software implementations for these cases in glibc (I guess > people concerned about floating-point performance are generally > using hardware floating point). If people really need decimal (e.g. for financial applications), they would use it instead of hardware binary FP. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
