Thanks, I hadn't been aware of the range() function (even though it is
right there in the docs). So this works:
julia> range(0.0, pi/100.0, 101)
0.0:0.031415926535897934:3.1415926535897936
The final value is sufficiently close to pi:
julia> range(0.0, pi/100.0, 101)[end] - pi
4.440892098500626e-16
This, and the solution suggested by Simon Kornblith both work fine for
setting up inputs to CoordInterpGrid. So the functionality is definitely
there. But I think that most new users (especially Matlab converts) are
going to try the colon notation first, and perhaps struggle a bit in
figuring out the right way to generate the desired range.
--Peter
On Thursday, April 24, 2014 7:19:59 AM UTC-7, Tobias Knopp wrote:
>
> Shouldn't it be possible to use Range{T}(start::T,step,len::Integer) for
> this?
>
> Am Donnerstag, 24. April 2014 16:09:51 UTC+2 schrieb Peter Simon:
>>
>> At present, the Grid package function CoordInterpGrid will not accept a
>> linspace-generated vector as the x-coordinates, making precise,
>> coordinate-based interpolation a little problematic.
>>
>> --Peter
>>
>> On Thursday, April 24, 2014 6:51:40 AM UTC-7, J Luis wrote:
>>>
>>> I also agree that the Matlab behavior is more intuitive, but even it can
>>> fail for the same reason discussed here. After being bitten by one of such
>>> case that took me a while to debug, when I need the exact ends I now always
>>> use linspace()
>>>
>>> Quinta-feira, 24 de Abril de 2014 14:28:16 UTC+1, Peter Simon escreveu:
>>>>
>>>> *Matlab behavior:*
>>>>
>>>> >> format long
>>>> >> x = 0:pi/100:pi;
>>>> >> length(x)
>>>>
>>>> ans =
>>>>
>>>> 101
>>>>
>>>> >> x(1) - 0
>>>>
>>>> ans =
>>>>
>>>> 0
>>>>
>>>> >> x(end) - pi
>>>>
>>>> ans =
>>>>
>>>> 0
>>>>
>>>> >> diff([max(diff(x)), min(diff(x))])
>>>>
>>>> ans =
>>>>
>>>> -4.440892098500626e-16
>>>>
>>>>
>>>> *Julia behavior:*
>>>>
>>>> julia> x = 0:pi/100:pi;
>>>>
>>>> julia> length(x)
>>>> 100
>>>>
>>>> julia> x[1]-0
>>>> 0.0
>>>>
>>>> julia> x[end]-pi
>>>> -0.031415926535897754
>>>>
>>>> julia> diff([maximum(diff(x)), minimum(diff(x))])
>>>> 1-element Array{Float64,1}:
>>>> -4.44089e-16
>>>>
>>>>
>>>> I highlighted the important differences in red. IMO the Matlab
>>>> behavior is more intuitive. If you choose an increment that "very nearly"
>>>> (apparently within a few ulp, as stated by Stefan) evenly divides the
>>>> difference between the first and last entries in the colon notation,
>>>> Matlab
>>>> assumes that you want the resulting vector to begin and end with exactly
>>>> these values. This makes sense in most situations, IMO. E.g. when using
>>>> a
>>>> range to specify sample points in a numerical integration scheme, or when
>>>> using a range to specify x-coordinates in an interpolation scheme. In
>>>> both
>>>> of these cases you don't want the last point to be adjusted away from what
>>>> you specified using the colon notation.
>>>>
>>>> --Pete
>>>>
>>>> --Peter
>>>>
>>>> On Thursday, April 24, 2014 5:28:19 AM UTC-7, andrew cooke wrote:
>>>>>
>>>>>
>>>>> how does matlab differ from julia here? (i though the original
>>>>> problem was related to "fundamental" issues of how you represent numbers
>>>>> on
>>>>> a computer, not language specific).
>>>>>
>>>>>
>>>>> On Thursday, 24 April 2014 02:24:59 UTC-3, Peter Simon wrote:
>>>>>>
>>>>>> 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
>>>>>>>>> <[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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
