Idea: Create 'Frequency' class to store frequency and associated tolerance

[ikbenkous]

I see that frequencies are handled internally as a double representing megahertz.
This may be bad form and open to interpretation. Someone might be under the assumption that those doubles are Hz or kHz instead of MHz.

It may be better to have a dedicated Frequency object with a well defined interface.
Things such as:

• overloaded operator== to compare two Frequency objects that takes into account clock precision.
• band() function returning enum (or a class Band object).
• overloaded user literals for nice coding.
• math operations

Something like f1.band() == f2.band() is possible, or even math such as f1 - f2 returning a third frequency.
Division should probably return a double.

I think an associated precision for every Frequency instance is a smart idea.
Because I hear QRSS QSOs have sub-hertz precision while SSB QSO just doesn't need a lot of clock stability.

With every instance having a precision, you can truly have a smart isSameFreq() function that checks whether two frequencies are the same. This seems like a future proof idea and better than passing doubles around.

Thoughts?

[ea4k]

I agree, what you says makes sense and would make KLog better designed.
I will add your comment to the Enhancement list.
Thank you

[ikbenkous]

How would one handle comparing two frequencies taking into account the precision/accuracy/trueness of the transceivers?

For now I think exposing a 'ppm' function, assuming the frequency error is a symmetrical bell curve and returning true if the smaller ppm range is mostly within the larger ppm range. In other words, the following behavior:

(F1 != F2) // true
(F1 == F2) // false

(F1 != F3) // false
(F1 == F3) // true

(F1 != F4) // false // Can we establish that F1 and F4 are not the same? No.
(F1 == F4) // false // Can we establish that F1 and F4 are the same? No!

Is this kind of behavior 'too smart'?
Maybe a basic comparison function isSame(max_diff) returning true/false is better and less prone to usage bugs...
Then again: having a way to simply change the receiver frequency ppm based on the current mode (SSB) is a nice easy way of going about things.
100 Hz isn't that much with feldhell.
100 Hz is everything with CW...

Or maybe the comparison operators should do some statistical math and calculate if a statement is true >=50% of the cases?

I don't know.

[ea4k]

The Frequency class has been created in d6b5603

There are some usage already in the DXCluster class.
Thank you for the suggestion!

All contributions are welcome! :-)