pi*(0:0.01:1) or similar should work.
On Wednesday, April 23, 2014 7:12:58 PM UTC-4, Peter Simon wrote: > > 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]> 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 >>> >>> >>
