Igor 7: 64 bit integer complex waves supported?
fabrizio
I see some weirdness when trying to use 64 bit integer complex waves. E.g.
• make/o/L/c/n=1 test = cmplx(1,1); print/f test
results in
test[1,1] =
(4.60718e+18,0)
and
edit test
shows 4.60718e+18
for both real and imaginary part.And even weirder:
• make/o/L/c test = {cmplx(1,1)}; print/f test
has a different result than above code line, namely
test[1,1] =
(1,0)
Are 64 bit integer complex waves not supported by Igor 7 ?
Igor version 7.01 64 bit
Windows 7 Enterprise Service Pack 1
Thanks,
Fabrizio
Especially as
•Edit/K=1 root:test
does show the content in both columns, altough still incorrect.January 11, 2017 at 09:13 am - Permalink
32 bit ints seem to work OK but 64 has issues.
Larry Hutchinson
WaveMetrics
support@WaveMetrics.com
January 11, 2017 at 11:34 am - Permalink
The command should not have been allowed and I have checked in code to catch that on the command line. In Functions, it was already an error.
For IP8, I will investigate adding support for this.
Larry Hutchinson
WaveMetrics
support@WaveMetrics.com
January 12, 2017 at 08:18 am - Permalink
+1 from me for future 64 bit integer complex support in Igor :)
Fabrizio
January 12, 2017 at 12:35 pm - Permalink
January 13, 2017 at 04:33 pm - Permalink
AG
January 13, 2017 at 04:34 pm - Permalink
Up to Igor 7, I used matlab for >32 bit integer related calculations; e.g. to load binary 64 bit integer files, save filter coefficients in fixed point notation > 32 bit, ... . Things have much improved with Igor 7, but I would love to have the same Igor functionality for 64 bit integer as for 32 bit integer. As for the complex Igor datatype, I just got used to it, and it is a nice container for e.g. IQ data.
One simple fictional example is two 64 bit arrays, each constructed of sixteen 1 bit flags and one 48 bit signed integer, saved as interleaved binary.
Igor 7 already allows me to load the 64 bit arrays as integers and extract the flags and 48 bit integers with the bitwise and operator, but then I have to be careful to not use unsupported operations on the 48 bit integers (stored in 64 bit integers).
I also sometimes use double float on Igor as a poor mans 52 bit integer, but it is more natural to me to use integer types for integers.
Of course, most people would say to just use Matlab for FPGA related work, but I prefer (i.e. have better knowledge of) Igor in general ;)
But, to be honest, I only found out about the complex 64 bit integer problem when I wrote below code to convert floating point to integer values and tried to make it as general as possible, thus also including 64 bit integer complex:
// Convert a floating point wave to signed integer:
// Recast wave to integer (8, 16, 32, or 64 bit depending
// on 'amplitude') and overwrite it with integer values
// nb: only Igor version >=7 supports 64 bit integers.
// amplitude: peak amplitude of integer wave;
// default: 32767 (fill 16 bit signed integer wave)
//
// fg 2017/01/03 first implementation
wave data
variable amplitude
amplitude = paramisdefault(amplitude) ? 2^15-1 : amplitude
if ((wavetype(data) & (2^1 + 2^2)) == 0)
print "input data is not floating point; aborting"
return -1
endif
variable bits
bits = ceil(log(amplitude+1)/log(2)) + 1 // +1 for signed
bits = 2^(ceil(log(bits)/log(2))) // round to next highest power of 2,
bits = max(bits, 8) // starting at 8
matrixop/free maxreal = maxval(abs(real(data))) // hack: use matrixop to support both complex and real waves
matrixop/free maximag = maxval(abs(imag(data)))
variable maximum = max(maxreal[0], maximag[0])
variable Vscale = amplitude / maximum
if (bits > 64 || bits > 32 && IgorVersion() < 7)
print "Amplitude too large; would require", bits, "bits"
return - 1
else
variable complexBit = wavetype(data) & 2^0
variable typeCode = bits == 64 ? complexBit + bits*2 : complexBit + bits // inconsistent bit value for 64 bit for historical reasons...
matrixop/o data = Vscale * data
redimension/Y=(typeCode) data
endif
end
and I noticed that e.g.
make/c/d/o data = exp(cmplx(0,2*pi*p/16))
toInteger(data, amplitude = 2^47-1)
results in 'wrong' imaginary numbers.
Cheers,
Fabrizio
January 16, 2017 at 09:00 am - Permalink
AG
January 16, 2017 at 10:34 am - Permalink