basic wave indexing question
kaikin
Sat, 12/05/2020 - 03:03 pm
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
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:
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:
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 +:
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