Could spotters consider a standardised method of spotting frequencies please?
The SOTA Cluster provided by Andy FMF does not take kindly to an extra decimal point.
For example the cluster will display 5403.0 perfectly but it won’t display 5.403.5 correctly, unlike SOTAWatch which will display it. The SOTA Cluster displays the frequency as 0.0
So one decimal point is all the SOTA Cluster will accept, no more. Screenshot captured from the Logger 32 DX Spots window showing a couple of 0.0 entries including a test spot from me. it is not just 5 MHz that is affected it is all frequencies.
Thanks all for your consideration of what is a minor issue.
…or just alter the code on the server to be able to handle, and properly display, such disparate forms of frequency inputs. A few minutes’ work, tops: this isn’t rocket science, folks…
NO, decimal numbers only have one decimal point. What you are suggesting is like the American senator who suggested that because Pi was so difficult they should pass a law to make it equal to 3.
I agree with Colin, a decimal of a decimal makes no sense at all. What people are doing is copying the frequency display format on rigs like the FT8x7 - and it makes no sense there, either, it just introduces an unnecessary character. It is just a bad habit and people should stop doing it.
Hi Phil,
I am not sure if I understood you correctly, but when I am spotting on SOTAwatch,
there is no possibility to spot 7033.1, you have to make it with the point like 7.033.1 for example.
Have a nice Sunday.
Fritz HB9CSA/DL4FDM
Because radios use a dot to separate the figures so it’s understandable people may copy that. Not everybody understands numbers and the separator changes depending where you are in the world.
The issue with 7.033.1 is not understanding which dot is which. Sure you can guess the first is probably the MHz separator and dump the second. But I take a simpler view, if someone has entered an invalid number then I try not to propagate it further. My code does handle some locale munging flipping commas back to dots. But if the input doesn’t look like a number it gets forced to 0.0.
That’s fair enough - then it’s up to the user to get it right.[quote=“G8TMV, post:3, topic:14721”]
NO, decimal numbers only have one decimal point. What you are suggesting is like the American senator who suggested that because Pi was so difficult they should pass a law to make it equal to 3.
[/quote]
Colin, you’re way off the mark - we’re talking here about how a program should handle strings of characters entered by users of a spotting utility. It’s simply a truism that users will, and do, occasionally commit typing errors, and a program written to handle user-inputs should therefore be robust enough to be able to cope effectively with badly-formatted entries - i.e. to analyze the strings to some degree and to try to cope with the most common, less egregious, of such errors. Or, as Andy has said, to simply reject badly-formatted entries: either strategy will result in less errors committed to a database, meaning that fewer such errors will be displayed later. This is all, as our US colleagues might put it, “Programming 101” - programming for beginners.
Rob, as I see it, if the program is robust enough to handle typing errors (and bad habits!) then none of the users will need to correct their own errors and bad habits. If the programs are written to coddle people, then people will have no reason to improve.
Coddling is not the aim: robustness of data is the aim. Decades of programming experience have shown me that there will always be users (and not just the odd few!) who will not, or cannot, listen to reason, or follow rules, or take note of hints, or use the help if such is provided. Such people will never improve, no matter how long one waits. So, in an effort to maximize accuracy or acceptability of data input by mere mortals, it’s therefore incumbent on the programmer to deal with poorly-formatted inputs. It goes with the territory.
It’s probably reasonable for SOTAwatch to accept a variety of malformed frequencies because these may be coming from someone on a hill in wild weather (much like it is now in GM). Rejecting a frequency because it has commas and not dots or too many dots is good from a point of ensuring we always deal with valid data but bad when then end of the line for the data is simply to appear on screen. We humans normally can figure out what someone meant from context and the errant information. And if you don’t get a spot because you typed 2 dots is not good when you are being soaked and blown off a hill!
But now the data is extracted by some screen scraping software (reads the actual HTML data), extracted from the RSS feed (really simple syndication) or extracted using the Beta release API for SOTAwatch. At this point the need for the data to well formed does arise. Should we now force SOTAwatch to reject malformed data because we are using the data elsewhere or should we allow it as humans understand it and force the checking on to the programs now using it?
I think I would prefer SOTAwatch to be less exacting of some data as the context allows human users to understand it. I could spend an afternoon writing a frequency de-mangler that straightens out a lot of common typos or I could handle the easy ones and dump the bad data and replace it with something incorrect but well formatted.
One way this could be handled would be to allow input from Spotlite to meet less exacting standards on format as it is often used by people in the wilds and direct input to SOTAwatch to be more rigorously specified. That probably would give the best of both worlds I think.
My suggestion would be that SOTAwatch should try its best to interpret what is thrown at it, but having worked out what it means, convert it to the canonical format for display. This means that other software processing the spots downstream does not have to do the work again. It also gives gentle but persistent feedback to the end user demonstrating the preferred format.
Forcing the human to conform rigidly to the requirements of the computer is so last century.
As a maths teacher, I am more than content with a system refusing to accept nonsense like “7.033.1”. Licensed radio amateurs should be able to understand which of 7.033.1, 7.0331 or 7033.1 is a valid frequency in the 7MHz allocation, one would have thought.
I don’t like the idea of the erroneous entry being accepted and changed to 0.0. IMO, it should just reject it with an error message.
How? It’s one program asking another for “the latest data”. The latest data can be malformed yet instantly understood by humans. So as a human directed display it is valid. It’s downstream users who have the issue. Especially if downstream programmers cannot be bothered to handle every possible malformed frequency just the easy ones.
The SMS spotter is quite strict and throws away bad frequencies. Then I have to answer the emails “I sent an SMS and there was no spot” with “you typed in a nonsense frequency”. The cluster cleans up simple typos and inserts 0.0 for the rest. It could dump spots it doesn’t understand (i.e. I can’t be bothered to exhaustively fix up). Then I’d have to answer emails “the cluster doesn’t show all spots” with “they were nonsense frequencies”. Cluster users see 0.0 and know a) it’s a nonsense frequency and b) look on SOTAwatch to see what nonsense was typed.
This isn’t a black / white issue. Shades of grey (up to fifty) are acceptable.
… you presumably know that the abstract mathematical concept and the notation for expressing it are two different things. And different contexts may call for different notations. And that different cultures have different conventions.
Yes, 7.033.1 is nonsense as a decimal number. As a way of expressing a frequency I might tune to, it is actually a rather convenient notation in a context in which frequencies are ordinarily given to exactly 3 decimal places. It emphasizes that the extra digit is giving extra precision and is not a mistake (e.g. maybe the 3 key was accidentally hit twice). It is obviously inconvenient for further processing as a number, but I don’t think its use is as contemptible as some people seem to be making it.
