Thank you.
On Tuesday, December 8, 2015 at 1:56:13 PM UTC-5, Simon Byrne wrote: > > Assuming you're using the default openlibm math library (i.e. your > Base.libm_name == "libopenlibm"), then yes I believe that should be the > case. The precise accuracy details are given in the file headers, e.g. for > exp(x::Float64), ( > https://github.com/JuliaLang/openlibm/blob/master/src/e_exp.c): > > > according to an error analysis, the error is always less than 1 ulp > (unit in the last place). > > Note these typically assume you haven't done anything funny like change > the rounding mode. > > The trig functions simply say that they're "nearly rounded", which from > what I can tell means that they satisfy the same as above (they're > certainly not correctly rounded-to-nearest). > > In some cases tighter bounds should be available: I've found that the trig > functions are accurate to less than 0.75 ulps or so, but getting those > bounds involves lots of tedious error analysis. > > If you've compile Julia to use the system libm, these can differ in their > accuracy: I've generally found the OS X one to be more accurate than > openlibm (except for their gamma function), but they don't provide any > details or guarantees. The GNU C libm actually provides correctly > rounded-to-nearest for a lot of their functions (certainly most of the 1 > argument ones), but as a result they can be a quite a bit slower. > > -Simon > > On Tuesday, 8 December 2015 15:54:31 UTC, Jeffrey Sarnoff wrote: >> >> ``` >> julia> x, exp(x), Float64(exp(big(x))) >> (0.05489354701373524,1.0564281487582248,1.0564281487582246) >> ``` >> Is it known that e.g. all elementary functions return a value v such that >> true value is in: prevfloat(v)..nextfloat(v)? >> Are tighter results known for some functions? >> >>
