Thanks for the explanation--it makes sense now. This question arose for me because of the example presented in https://groups.google.com/d/msg/julia-users/CNYaDUYog8w/QH9L_Q9Su9YJ :
x = [0:0.01:pi] used as the set of x-coordinates for sampling a function to be integrated (ideally over the interval (0,pi)). But the range defined in x has a last entry of 3.14, which will contribute to the inaccuracy of the integral being sought in that example. As an exercise, I was trying to implement the interpolation solution described later in that thread by Cameron McBride: "BTW, another possibility is to use a spline interpolation on the original data and integrate the spline evaluation with quadgk()". It seems that one cannot use e.g. linspace(0,pi,200) for the x values, because CoordInterpGrid will not accept an array as its first argument, so you have to use a range object. But the range object has a built-in error for the last point because of the present issue. Any suggestions? Thanks, --Peter On Wednesday, April 23, 2014 3:24:10 PM UTC-7, Stefan Karpinski wrote: > > The issue is that float(pi) < 100*(pi/100). The fact that pi is not > rational – or rather, that float64(pi) cannot be expressed as the division > of two 24-bit integers as a 64-bit float – prevents rational lifting of the > range from kicking in. I worried about this kind of issue when I was > working on FloatRanges, but I'm not sure what you can really do, aside from > hacks where you just decide that things are "close enough" based on some ad > hoc notion of close enough (Matlab uses 3 ulps). For example, you can't > notice that pi/(pi/100) is an integer – because it isn't: > > julia> pi/(pi/100) > 99.99999999999999 > > > One approach is to try to find a real value x such that float64(x/100) == > float64(pi)/100 and float64(x) == float64(pi). If any such value exists, it > makes sense to do a lifted FloatRange instead of the default naive stepping > seen here. In this case there obviously exists such a real number – π > itself is one such value. However, that doesn't quite solve the problem > since many such values exist and they don't necessarily all produce the > same range values – which one should be used? In this case, π is a good > guess, but only because we know that's a special and important number. > Adding in ad hoc special values isn't really satisfying or acceptable. It > would be nice to give the right behavior in cases where there is only one > possible range that could have been intended (despite there being many > values of x), but I haven't figured out how determine if that is the case > or not. The current code handles the relatively straightforward case where > the start, step and stop values are all rational. > > > On Wed, Apr 23, 2014 at 5:59 PM, Peter Simon <[email protected]<javascript:> > > wrote: > >> The first three results below are what I expected. The fourth result >> surprised me: >> >> julia> (0:pi:pi)[end] >> 3.141592653589793 >> >> julia> (0:pi/2:pi)[end] >> 3.141592653589793 >> >> julia> (0:pi/3:pi)[end] >> 3.141592653589793 >> >> julia> (0:pi/100:pi)[end] >> 3.1101767270538954 >> >> Is this behavior correct? >> >> Version info: >> julia> versioninfo() >> Julia Version 0.3.0-prerelease+2703 >> Commit 942ae42* (2014-04-22 18:57 UTC) >> Platform Info: >> System: Windows (x86_64-w64-mingw32) >> CPU: Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz >> WORD_SIZE: 64 >> BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY) >> LAPACK: libopenblas >> LIBM: libopenlibm >> >> >> --Peter >> >> >
