Thanks, Simon, that construct works nicely to solve the problem I posed. I have to say, though, that I find Matlab's colon range behavior more intuitive and generally useful, even if it isn't as "exact" as Julia's.
--Peter On Wednesday, April 23, 2014 7:17:23 PM UTC-7, Simon Kornblith wrote: > > 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 <psimo...@gmail.com> 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 >>>> >>>> >>>
