Open DanielSank opened 9 years ago
I don't think it is generally useful or possible to insist that the floating point representation match an exact digital value.
That is precisely why having a unitful integer type would be useful. This type would be able to convert to smaller units, but not bigger ones. This automatically takes care of not trying to set a device's parameter finer than it's allowed resolution.
If rounding a value to the nearest representation doesn't make sense
Rounding to the nearest representation is exactly what my change does, so now I don't understand the objection. I would say, however,
Any code which expects floating point values to have exact results is broken.
I agree. Who said otherwise?
Consider this: the fastbias cards cannot be set to 1.0 volts. The nearest legal value is approximately 999.985 mV. Should that server really fail if you ask it to produce 1 volt?
Yes.
1) write code whose correctness does not depend on small changes needed to coerce to a legal value
I can't imagine how to make that work.
2) Eliminate floating point numbers and used only fixed point for anything that will be used to set a hardware value
Fixed point unitful type, please.
3) Query the device after setting it to learn the actual value it was configured for, and base further computation off of that. Keep in mind that devices like frequency generators that use an internal decimal representation may not return something that is exactly representable as a floating point number, so this may not even fix the problem.
This would be fine but I don't trust people to do this consistently. It puts too much responsibility on the programmer.
Sorry, I misread the patch. Based on your pull request message I thought you were going to cause an error if rounding changed the value, i.e., the input were not an exact integer number of Hz.
The rounding is fine.
On Sat, Apr 11, 2015 at 3:31 PM, Daniel Sank notifications@github.com wrote:
I don't think it is generally useful or possible to insist that the floating point representation match an exact digital value.
That is precisely why having a unitful integer type would be useful. This type would be able to convert to smaller units, but not bigger ones. This automatically takes care of not trying to set a device's parameter finer than it's allowed resolution.
If rounding a value to the nearest representation doesn't make sense
Rounding to the nearest representation is exactly what my change does, so now I don't understand the objection. I would say, however,
Any code which expects floating point values to have exact results is broken.
I agree. Who said otherwise?
Consider this: the fastbias cards cannot be set to 1.0 volts. The nearest legal value is approximately 999.985 mV. Should that server really fail if you ask it to produce 1 volt?
Yes.
1) write code whose correctness does not depend on small changes needed to coerce to a legal value
I can't imagine how to make that work.
2) Eliminate floating point numbers and used only fixed point for anything that will be used to set a hardware value
Fixed point unitful type, please.
3) Query the device after setting it to learn the actual value it was configured for, and base further computation off of that. Keep in mind that devices like frequency generators that use an internal decimal representation may not return something that is exactly representable as a floating point number, so this may not even fix the problem.
This would be fine but I don't trust people to do this consistently. It puts too much responsibility on the programmer.
— Reply to this email directly or view it on GitHub https://github.com/martinisgroup/servers/issues/90#issuecomment-91935856 .
The problem is roughly that
fails when
freq_Hz
is not a legal value accepted by the Hittite. In this case, the Hittite seems to just ignore the command.Copying from #89:
Dan wrote:
Evan wrote: