[chirp_devel] [RFC] Convert to "integral hertz" for frequency storage
Hi all,
Right now, chirp stores frequencies as a floating point number. That's convenient (at times) but is fatally flawed because the internal representation is Base-2. That leads to odd behavior like this:
$ python
130.8 * 100
13080.000000000002
There are many places where this bites users and results in very odd behavior. The correct way to fix this is to store the frequency in units of Hertz, which we can represent cleanly with an integer. This is a straightforward change, but a wide-sweeping one. I've spent many hours doing my best to carefully convert every driver in the tree to this mode of operation, as well as all the UI elements. The automated tests have made this much easier, but there is still the extreme possibility for errors.
I would really (really) appreciate it if you developer-types could clone the following tree and bang around on it a bit:
http://d-rats.com/hg/hgwebdir.cgi/chirp-intHz.hg/
After an initial sniff-test here, I'll push it into the main repository and hope for some more wide-spread testing.
Thanks!
Dan,
I didn't do any complete testing, but FWIW I did clone from my VX-7R, make a few changes (adding a handful of new repeaters), and clone back successfully. I won't have time tonight to do any more playing, but maybe if I have some downtime at work today.
Mat
On Mon, 16 May 2011 18:31:10 -0700, Dan Smith wrote:
Hi all,
Right now, chirp stores frequencies as a floating point number. That's convenient (at times) but is fatally flawed because the internal representation is Base-2. That leads to odd behavior like this:
$ python
130.8 * 100
13080.000000000002
There are many places where this bites users and results in very odd behavior. The correct way to fix this is to store the frequency in units of Hertz, which we can represent cleanly with an integer. This is a straightforward change, but a wide-sweeping one. I've spent many hours doing my best to carefully convert every driver in the tree to this mode of operation, as well as all the UI elements. The automated tests have made this much easier, but there is still the extreme possibility for errors.
I would really (really) appreciate it if you developer-types could clone the following tree and bang around on it a bit:
http://d-rats.com/hg/hgwebdir.cgi/chirp-intHz.hg/
After an initial sniff-test here, I'll push it into the main repository and hope for some more wide-spread testing.
Thanks!
I didn't do any complete testing, but FWIW I did clone from my VX-7R, make a few changes (adding a handful of new repeaters), and clone back successfully. I won't have time tonight to do any more playing, but maybe if I have some downtime at work today.
Super, thanks very much. Even just the sniff test is helpful and reassuring :)
Some quick tests I did on the new integer hertz storage version:
1. load existing vx-8dr image file into new chirp, export (csv,xml) & save compare output to pre-int-hz versions.
csv & xml exports were identical except for 5 vs 6 decimal places for mhz.
(Writing the image back out produced the identical image other than Bug 115 that I just submitted.)
2. Loaded chirp.csv written with int-Hz version into float-hz version of chirp, wrote csv back out, Verified the only difference was the 5 to 6 decimal place difference.
3. Did the same as number 1 with an .img from the Wouxun written with the float-mhz version. Exported files were the same.
Some quick tests I did on the new integer hertz storage version:
Fan-tastic, thanks for that :)
The nice thing is that the Wouxun driver no longer fails all the tests with errors like "Offset is 0.6, expected 0.6".
I'll let this all stew with everyone until after Dayton and then start to merge the trees when I get back.
Thanks!
participants (3)
-
Dan Smith -
Mathew Mrosko -
Robert Terzi