On Tue, Feb 7, 2012 at 7:19 PM, Julien Puydt <julien.pu...@laposte.net>wrote:
> Le Tue, 7 Feb 2012 20:23:08 -0800 (PST), > Jason <jason.harri...@gmail.com> a écrit : > > One benefit of programs like matlab and mathematica is that not only > > do they bring together many different functions with a common syntax, > > but that they (presumably) have standardized precision and accuracy > > control. So coming up with a standard in this area is important. I > > think such a standard could even be used by developers of algorithms > > who have nothing to do with sage as at least a guideline so they know > > if their function is "sage compatible" or not. The standard doesn't > > have to be a single hard limit, but whatever the experts come up with. > > It could be as little as required documentation to as much as explicit > > benchmarks or classifications. Maybe functions that implement the > > standard could be a special type, so if you use only those functions > > there is some type of guarantee about the overall calculation that can > > be made.. Just some random thoughts here. > > As far as I know, the only way to make this work is with interval > arithmetic, as it's pretty easy to see that the precision of a > computation cannot be constant [1]. > > Snark on #sagemath > > [1] http://en.wikipedia.org/wiki/Interval_arithmetic > > No, it is quite possible to make it work, just not that easy. Note that certain numerical computations in Sage _will_ be the same on any platform where Sage is working properly (modulo bugs, of course). For example, RealField uses mpfr as a backend, so computations with RealField are very well defined and results will be the same on any platform. (At least, they should be the same, and if they are not it is definitely a bad bug.) Also, when you are working at a high level, the default is for all floating point computations to go through RealField. If ARM and x86 were giving different answers for RR(6).gamma(), or RR(anything).gamma(), that would be a serious bug. The issue is in trying to ensure consistency of "lower level" computations, like operations on python floats, which map to machine doubles. This would be doable in principle, but more difficult. At the very least it would require elimination of any calls to libc math functions (which could perhaps be somewhat implemented by writing our own libm and always linking to it). There are also more subtle issues that come up, like compiler inconsistencies and 64-bit vs 80-bit floating point. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
