Complexity of 'matching' awards

Awards
,
1

I’ve been thinking a lot about the issues that POTA.app experiences with log ingestion. The current advice is to ‘avoid uploading between these hours’ due to problems in various batch processes.

I’ve been avoiding even thinking about PN&R awards that rely on matching against other logs, but after reflection I think that I can build an awards engine that runs in linear time on the number of QSOs in the ingested log. I also think there’s a way to match for awards in constant time. I could be wrong but it feels correct.

This is making me rethink the type of award to offer. I’m being really cautious about not stepping on the ‘official’ awards. I also need to do a quick prototype of a log matcher and do the performance testing before committing (@w7pfb that’s where your numbers come in handy, to set sizing).

Which brings up a stickier question, how much overlap between PN&R and POTA awards would be tolerated?

Fo the curious, the line I’m following uses lots of small reference tables indexed on tuples. For example, for the ‘counting’ awards like Operator to Operator, keep a small reference table that holds operator pairs:

QSO_Count_By_Pair(
    hunter_id,
    worked_call,
    total_qsos
)

Many of those operations, especially award progress like that example, are going to run in constant time.

2

The point of all of that is that I feel that there’s no need for batch operations…we should be able to ingest and update award progress in real time.

1 Like
3

The problem I see with awards that require matching QSOs in both the activator and hunter logs isn’t the computational complexity of the log ingestion/processing process.

It’s that such awards can be made only when both the activator and hunter upload their logs, and the current culture of POTA is that activators upload logs, and hunters do not. And setting aside the question of whether that’s a good plan or not, that culture would be mighty hard to displace.

Currently on POTA I get credit for an Q in an activation EVEN IF the hunter is not registered with an account on pota.app. That seems a sensible scheme for a program like POTA.

Without really thinking about it it seems to me that QSO matching is rather like file differences, so that would make it (memory is rusty, here) O(n) where N is the size of the logs? Throw in some hand waving around issues like how closely the times must match, &c.

1 Like
4

Right, each log ingest would require

  • O(n) for one pass to match QSO tuples against other logs (one per log entry)
  • O(1) * c where c is the number of awards
  • k for overhead

IOW I don’t think the complexity is that high, certainly not O(n*n), And that’s across everything, I’m pretty sure that I can match and update awards counts across all awards on every log submission, so realtime displays of awards.

THIS IS AN INTERESTING QUESTION: How do we handle hunters? I think it makes sense to treat them like activators and accept their logs. If they said they worked NS1C then by god I’m not going to call Ken up and ask.

5

It would be nice to see symmetry.

The problem I see is this: some hunter (W1GRD) sees me spotted at 14058.5. Maybe there are other activators on/near that frequency.

They fire up their radio, tune to 14058.5, hear a station beeping away, perhaps faintly.

They send their callsign, hear their callsign come back, send a signal report, and log the contact as W7PFB in US-12339.

But what they’ve actually done is heard K7RWB in some other park. I upload my logs, which does not include a contact with our hero, W1GRD. W1GRD uploads his log, with what he believes is the correct info.

When it’s activators upload logs and hunters don’t, we don’t have a problem - regardless of the correctness of the activators log, it rules. As soon as you allow hunters to upload logs, what will you do with QSO’s which do not match the activator’s log? Do you give the activator credit where she insists she should not? What if the activator NEVER uploads a log? Do you give them credit for activating the park? If that’s the only QSO for this phantom activation, is it a successful activation or a failed one.

6

But POTA.app doesn’t cross-check for hunting and activating, do they? I have to admit I’ve never submitted a hunter log so I don’t know what the expectation is.

I think that we don’t care, we’ll trust the activator and we’ll trust the hunter. And the SWL. If they say that’s what went down, then who am I to question their particular version of reality?

Which brings up the question, is there ever any reason to cross-check a log? It’s hella easier just to update counters based on what the submitted log indicates. Is the set of Op-to-Op awards the reason for it at POTA.app? I get that you want something like that at, say, QRZ or LoTW, but let’s be honest, none of this really matters and people have to deal with their own karma.

7

There is no way to upload a hunter log on pota.app. Hunter awards are based entirely on activator logs.

8

Wait, so the My Hunter Log is entirely out of activator uploads? I guess that makes when I think about it.

Like I said, not cross-checking is much, much simpler.

1 Like
9

As Paul @w7pfb says. No way to submit hunter logs.

But all my hunter awards say that I “have submitted proof of” whatever.

Easy to overlook this kind of thing when writing the programs.