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

[IZ3GME Marco]

Right!

in other words Jim:
- use RadioSettingValueInteger to store freq as tens of Hz
- remove / 100000.0 from convert_bytes_to_freq
- remove whole real_freq = int(freq * 100000) line from 
convert_freq_to_bytes

73 de IZ3GME Marco

P.S.
Sorry I don't have the time to write and test code myself today


On 28/01/2013 12:55, Andrew Errington wrote:
> 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
> _______________________________________________
> chirp_devel mailing list
> chirp_devel at intrepid.danplanet.com
> http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
> Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
>