basic wave indexing question

Share icon

I have read the help file on "Interpolation in Wave Assignments" but am still surprised by this behavior:

macro decimalindexing_macro()
    Make/D/O/N=10 w1 = p*100
    print w1[2.4] // prints 240
    print w1(2.4) // prints 240
end

function decimalindexing_Fn()
    Make/D/O/N=10 w1 = p*100
    print w1[2.4] // prints 200
    print w1(2.4) // prints 240
end

This must be something pretty basic that I'm missing, but I can't see why the macro and function produce different results when the wave w1 is using the default point scaling.

Hi,

Even a bit odder. I made a slight tweak to the function:

function decimalindexing_Fn()
    Make/D/O/N=10 w1 = p*100
    variable test=2.4
    print w1[test] // prints 240
    print w1[2.4] // prints 200
    test= w1(2.4) // prints 240
    print test
end

Andy

December 5, 2020 at 03:17 pm - Permalink

From what I get from the manual, only the line 'print w1[2.4]' inside the function is out-of-spec. The rest apparently behaves as intended. The manual reads:

If you specify a fractional point number or an X value that falls between two data points, Igor will return a linearly interpolated data value. For example, wave1[1.75] returns the value of wave1 three-quarters of the way from the data value of point 1 to the data value of point 2.

This is obviously not the case inside the function for whatever reason. Apparently the literal number when inside [] brackets is rounded before even getting passed into the point evaluation. If the fact that its a floating point number is obscured, like in the example w1[test] or even by just using w1[abs(2.4)], then the correct result is achieved. The round brackets work fine, but will give a value according to the wave's scaling. This may be a bug.

December 6, 2020 at 01:59 am - Permalink

Looks like bug - I tried this in Igor 9 beta and is behaving same way.

I actually found out, that you can obscure the number by simple addition of +:

function decimalindexing_Fn()
    Make/D/O/N=10 w1 = p*100
    variable test=2.4
    print w1[test] // prints 240
    print w1[2.4]  // prints 200
    print w1[+2.4] // prints 240
    test= w1(2.4)  // prints 240
    print test
end

 

 

December 6, 2020 at 07:56 pm - Permalink

I see the same thing in Igor 6.3.7.2 and Igor 8.0.4.2 64-bit (both Win10).  If you change the index to 2.9, you still get 200, so it appears to be truncating the index.  

December 7, 2020 at 08:25 am - Permalink

When Igor sees a simple wave expression like Variable v=wave[number] some faster optimization code is used to save the number at compile time (rather than at runtime).

That code was converting from float to integer, apparently in the belief that of course it would be an integer anyway.

I've changed Igor 9 so that the "Interpolation in Wave Assignments" promise is kept, by using the slower runtime method if the number isn't an integer. Sometimes it is better to be correct than fast.

December 8, 2020 at 10:58 am - Permalink