So a few of us have spent a few hours trying to narrow this one down and it's now reproducible, but I'm afraid this may have some far-reaching ramifications.....
Swig-wrapped C++ functions using floats seem to have something like a power-of-2 rounding issue going on.
if you define functions in your top-level .h file like this:
virtual double getTest() const =0;
virtual void setTest(double newValue) =0;
virtual float getTestFloat() const =0;
virtual void setTestFloat(float newValue) =0;
Then implement them like this in your _impl.h file:
double d_test=0.0;
float d_testfloat = 0.0;
virtual double getTest() const {return d_test;};
virtual void setTest(double newValue) { d_test = newValue; };
virtual float getTestFloat() const {return d_testfloat;};
virtual void setTestFloat(float newValue) { d_testfloat = newValue; };
Go ahead and build/install your OOT module then try the get/set with a value like a frequency such as 158355000.0. The float will return 158355008.0 whereas the double will return 158355000.0.
gr-filerepeater is where I was troubleshooting and added the testing hooks, so if you git pull the latest and build it (I added the testing hooks today), then go interactive python from a command-line and try this:
import filerepeater
fs=filerepeater.AdvFileSink(1,1,'/tmp','test',158355000.00,2.4e6,0,0,True,False,False,8,False,False)
fs.setTest(158355000.0)
fs.getTest()
fs.setTestFloat(158355000.0)
fs.getTestFloat()
You'll see the results.
I'm not sure where else in GR the legacy / smaller float versus double may cause processing issues with this.
Any thoughts?
Mike