[chirp_devel] [PATCH][UV-5R] Add VFO Frequency Presets to Work Mode Tab [#467]

[Andrew Errington]

On Mon, 28 Jan 2013 19:33:44 Jim Unroe wrote:
> I'm don't believe I understand what "try with integers" means.

Hi there,

Sorry to be so mysterious.

By using integers I mean you should store the frequency as a whole number with 
no decimal part (i.e. an integer).  Integers are handled accurately by Python 
(or any language) but floating point numbers are a 'representation' of the 
number, so they can sometimes differ slightly (although they are usually 
close enough).  The problem you are having seems that 146.940 cannot be 
stored accurately and instead gives you 146.939 (which I think is what you 
meant to write in your message as 146.390 would be *way off*).  As you can 
see, 146.939 is 'close enough'.

So, internally to your code, treat the frequency as an integer, maybe a whole 
number of Hz or kHz.

146.940 MHz is a floating point number.
146940000 Hz is the same value as an integer
146940 kHz is the same value too.

This will always be accurate, and will always convert to a string of digits 
the same as what you thought you stored.  As a programmer you have to 
remember where the decimal point goes when you display the value to the user 
in MHz, which is a good reason for choosing Hz as your unit.  If you are 
constantly juggling between Hz, kHz and MHz you will make a mistake 
somewhere.

When you display it as a string you can insert a decimal point in the right 
place.  When you ask for user input you can treat it as a string of digits, 
strip out the decimal point and convert to an integer number.

Anyway, that's my attempt at explaining my meaning, but I just did a quick 
check in Python and I can accurately store and retrieve the value 146.94 in a 
variable, and convert it to an exact string representation so there must be 
something up somewhere else.  Probably a rounding error somewhere.

73,

Andrew