CGI/Perl Guide | Learning Center | Forums | Advertise | Login
Site Search: in

  Main Index MAIN
INDEX
Search Posts SEARCH
POSTS
Who's Online WHO'S
ONLINE
Log in LOG
IN

Home: Perl Programming Help: Intermediate:
HASH-O-RAMA Data Processing Problem

 

First page Previous page 1 2 3 4 5 Next page Last page  View All


stuckinarut
User

Apr 10, 2015, 10:03 AM

Post #51 of 102 (8277 views)
Re: [Zhris] HASH-O-RAMA Data Processing Problem [In reply to] Can't Post

Ohhhhh... one more thing which may help.

After making the first pass that produces the ERROR LOG, in addition to printing out the CNQ list, I will print out the short SCORES list, which has the actual VALID CNQ Combinations for each of the submitted logs.

It will be a visual "piece-of-cake" to make most of the decisions and any "QID" adjustments as I go down through each entry in the ERROR LOG.

Hopefully, this will all make sense now?

BUT WAIT...THERE'S MORE...

Since what you are generously doing here will substantially reduce the annual "Nightmare" of log processing, I'll go on a campaign to try and at least double or maybe even triple activity in what will be the 10th Anniversary event next year. Maybe even increase the QSO points to 10,000 each, and the Bonus Points to 50,000 so everyone can end up with much BIGGER scores :^)

- Stuckinarut


(This post was edited by stuckinarut on Apr 10, 2015, 10:09 AM)


stuckinarut
User

Apr 10, 2015, 11:42 AM

Post #52 of 102 (8266 views)
Re: [stuckinarut] HASH-O-RAMA Data Processing Problem [In reply to] Can't Post

CORRRRRRRRECTIONS...

Sorry, rushed tooooo fasssst on insufficient sleep and missed flagging a couple in this list:

http://www.xgenesis.com/hashorama/2014_LQP_CNQ_ANALYSIS.pdf

I need an 'ERROR LOG' for myself ;-(

Uploaded a 2nd corrected version (found one more goof). Now it's even between GOOD and BAD at 50% each !!!

FYI,

- Stuckinarut


(This post was edited by stuckinarut on Apr 10, 2015, 11:55 AM)


stuckinarut
User

Apr 10, 2015, 11:49 AM

Post #53 of 102 (8265 views)
Re: [stuckinarut] HASH-O-RAMA Data Processing Problem [In reply to] Can't Post

Yet another thought...

Some NON-Log Submitter folks just show up for sometimes the last few minutes of an on-air event like this. For some time I've been chewing on *maybe* establishing an 'MQT' (Minimum QSO Threshold) for which these CNQ Combinations *MUST* show up in the Log Submitter Logs in order to be valid. Maybe 5 which I think is reasonable, or 3 if I want to be more "Mulligan-Ish" :^) That would still save me time in sending out individual emails to ascertain IF some of these potential "One-Offs" actually participated.

FYI (again),

- Stuckinarut


Zhris
Enthusiast

Apr 10, 2015, 12:07 PM

Post #54 of 102 (8258 views)
Re: [stuckinarut] HASH-O-RAMA Data Processing Problem [In reply to] Can't Post

Hi,

Finally have a new version, please see attached. I have read back all your messages over the last week plus in order to implement whats remaining. Forgive me if I have missed anything. It might be worth you going back through all of your messages and retesting / report anything not to your satisfaction. Please read all of the notes below in detail as they may offer explnations to some of your queries.

Recommended usage:

$perl main.pl --interactive --phase_n=0
$perl main.pl --interactive --phase_n=1
$perl main.pl --interactive --phase_n=2

add --base=path/to/dir to temporarily run on a different set of data.
add --case_sensitive to temporarily turn on case sensitivity.
add --wtf_threshold=7 to temporarily adjust the wtf threshold.

Notes:

- code better organized. The core algorithm is in one place now, the _input_contestants function. This makes the code more manageable, although still not perfect. I have used a couple of bad practices purely for simplicity. Interactive / configuration interface not that great. Etc etc etc. When the code finally works as desired, we can consider refactoring and improving, but probably isn't necessary.

- if you have problems installing List::MoreUtils, remove the use statement at the top and add 'any' to the List::Util import list. I don't want to upgrade List::Util on my test machine at the moment to support the any function.

- boolean command line arguments now controlled via on = --arg and off = --noarg or don't supply i.e. --case_sensitive, --nocase_sensitive.

- phase2 added since the introduction of adjustments. Once you have run phase1 you can make adjustments then run phase2 to rescore, repeat if necessary. phase2 does not modify the errors log.

- revamped prompt system. For non input prompts, you just type c to continue or e to exit the script. For input files that don't exist or are empty you can input lines if you wish, just type each line / return, then type c when you have finished, especially useful for testing different adjustments.

- no return accuracy has been massively improved, but still not perfect. I have left it in for now, you'll notice the error log is no longer flooded with them. If desired i'll make all errors configurable on / off.

- selfie error added. I hadn't noticed it by eye, but I noticed in the errors log there was one selfie error in your 2014 data!

- outputted total rows at end of each output file in the format "# total = n". I would prefer to keep the # at the beginning as this indicates a comment line and is ignored when read, especially important when reading back in the weights and errors logs.

- I haven't adjusted the weighting algorithm, I will if you are still not satisfied, it is easy to adjust. Remember, a single wtf shouldn't have much meaning alone, it only has meaning as a comparison against other wtfs. The current weighting algorithm is prepared for potential issues that we have not yet seen with our test data. But I do agree with you, that perhaps we should only weight call cnqs, not log cnqs.

- unsubmitted log created during phase1, it contains log signs that were deciphered to come from unsubmitted logs.

- every error now listed under errors column in errors log. As a result, for now I have removed the wtf<wtf_threshold under the wtf column when cnq error.

- looking over your comparisons pdf, there are indeed huge differences between manual and automatic. I believe improvements to this version will reduce this gap, especially the no return. It would be good if you could regenerate this comparison. We should then consider selecting sample records and investigate the differences.

- you described issues with log sign K6NV against call sign VE3KI, but I failed to confirm this during my own investigation upon testing this version. Also you raised this issue when you had muddled up old and new data. Please revist this.

- I didn't go over your case studies pdf in detail, these should be revisited.

- you discussed weighting percentages. I didn't quite understand what you mean. Did you mean that you would like to group wtfs by their sign in the weights log, and calculate their individual percentages.

- I need to re read your notes regarding piped locations in the scores log. Although as far as I can tell, it wouldn't really be possible to figure out that when location x is supplied, they actually meant location y, and you will probably have to control this via the adjustments log instead. Let me know if I didn't understand correctly.

- Always keep in mind that you have the power to accurately control the outcome by adjusting the weights and adjustments logs. Adjusting a weight controls a range of outcomes, while inserting an adjustment controls a specific outcome.

Regards,

Chris
Attachments: contestcrosschecker.zip (21.0 KB)


stuckinarut
User

Apr 10, 2015, 12:09 PM

Post #55 of 102 (8257 views)
Re: [stuckinarut] HASH-O-RAMA Data Processing Problem [In reply to] Can't Post

DARN... that's the problem with RUSHING too fast. Just caught one more Error in my hasty CNQ ANALYSIS, and uploaded (another) corrected version at 1908 UTC (10 April):

http://www.xgenesis.com/hashorama/2014_LQP_CNQ_ANALYSIS.pdf

Apologies for the screw-ups ;-(

- Stuckinarut


(This post was edited by stuckinarut on Apr 10, 2015, 12:10 PM)


Zhris
Enthusiast

Apr 10, 2015, 12:11 PM

Post #56 of 102 (8255 views)
Re: [stuckinarut] HASH-O-RAMA Data Processing Problem [In reply to] Can't Post

Shows how little testing I have done since adding phase2, it shouldn't cause any problems as is, but please add the following code on line 253:


Code
<$handle_input_errors>; # discard headings.


Chris


stuckinarut
User

Apr 10, 2015, 3:05 PM

Post #57 of 102 (8241 views)
Re: [Zhris] HASH-O-RAMA Data Processing Problem [In reply to] Can't Post

Chris:

Back online just briefly, and it seems our previous postings kinda "crossed in the mail" so to speak :^)

Will download the new .zip file and make the code line change you indicated. 4 hours of sleep is not cutting it here again, so need a brief "Power Nap"first lest I really screw something up !

I'll then run some tests and report back.

THANKS-THANKS!!!

- Stuckinarut


Zhris
Enthusiast

Apr 10, 2015, 3:19 PM

Post #58 of 102 (8237 views)
Re: [stuckinarut] HASH-O-RAMA Data Processing Problem [In reply to] Can't Post

No problem.

A lot of the tests and summaries you have been working on will unfortunately need to be revisited, hence why I haven't responded much on these, hopefully you'll notice a satisfying general improvement.

I'm off to sleep now too.

Chris


stuckinarut
User

Apr 11, 2015, 12:40 AM

Post #59 of 102 (8202 views)
Re: [Zhris] HASH-O-RAMA Data Processing Problem [In reply to] Can't Post

(For Thread Readers)

LOTS of PM's & test results being uploaded, but trying to keep the volume down here. Will be reporting details later.

- Stuckinarut


Zhris
Enthusiast

Apr 11, 2015, 10:28 AM

Post #60 of 102 (8174 views)
Re: [stuckinarut] HASH-O-RAMA Data Processing Problem [In reply to] Can't Post

Hi,

As per our discussions, attached is the update.

Notes:

- I'll start collecting older code versions from now named main-{version}.pl.

- Updated entries.txt included.

- The phases have been adjusted to suit new requirements. phase0 adds a new qid column to entries.txt, you must run this first, then only re-run it if you change entries.txt and don't add the qid in yourself. phase1 generates the weights. phase2 does the rest. You can re-run phase1 and phase2 however you like, errors.txt is now updated as per adjustments. Fundamentally there is now a prep phase, and no longer a seperate phase for adjustments.

- Everything else we discussed implemented, with a few improvements I made at my own discretion.

Regards,

Chris
Attachments: contestcrosschecker.zip (26.5 KB)


stuckinarut
User

Apr 11, 2015, 12:54 PM

Post #61 of 102 (8157 views)
Re: [Zhris] HASH-O-RAMA Data Processing Problem [In reply to] Can't Post


In Reply To
- The phases have been adjusted to suit new requirements. phase0 adds a new qid column to entries.txt, you must run this first, then only re-run it if you change entries.txt and don't add the qid in yourself. phase1 generates the weights. phase2 does the rest. You can re-run phase1 and phase2 however you like, errors.txt is now updated as per adjustments. Fundamentally there is now a prep phase, and no longer a seperate phase for adjustments.


Just downloaded the latest and did a quick run. I like the n=0, n=1 & n=2 'prep-to-final' approach which makes sense. That auto-assignment of the QID's now eliminates what would be another potential error-introduction manual step in Excel to do it.

I'm really getting EXCITED about how this is looking now, but must force myself to return to the tax stuff for the rest of the day/early evening. Later on tonight I'll do some updated manual data comparisons as before and PM them to you with comments.

Thanks very much, Chris!

- Stuckinarut


stuckinarut
User

Apr 11, 2015, 2:05 PM

Post #62 of 102 (8141 views)
Re: [Zhris] HASH-O-RAMA Data Processing Problem [In reply to] Can't Post

Hey, Chris:

Had a lenthy incoming phone call, so before returning to my annual dreaded task, decided to play a couple minutes of Hookey with the script and files again :^)

I changed the WTF to 3, and of course a few more CNQ Combos showed up in the Weights & Error log files.

Here are a couple minor tweaks that would also save manual massaging in Excel to come up with some additional totals for Annual comparison purposes.

1. In the scores.txt file, in addition to the existing Total figure, to include Sub-Totals for 'Logs' and 'No Logs' (i.e., the -minus callsigns).

2. One new 'calls123.txt' file that would list any callsigns of Nologs folks sorted by Callsign (ASC) then the CNQ Weight (ASC) for CNQ's with Weights of 1, 2 and 3. This would abe like an INSTANT 'Hit List' of candidates to send an email to verify that they did, in fact, participate - as well as exactly what NAME and QTH they used. I would do this BEFORE making any adjustments using the Error log and new adjustments.txt file. Yes, this would increase potential accuracy in decision making.

Hmmm... now that I think about it, this #2 above *could* just be an addition to the bottom of the existing 'weights.txt' file (below the Total line). If there were a settings entry in the 'userconfig' section, I could easily change this upward to include 4 or 5 if desired. Maybe something like lwt=3 (Low Weight Threshold = 3 would include 1,2 & 3. lwt=5 would include 1,2,3,4 & 5.

Whaddya think?

Thanks!

- Stuckinarut


Zhris
Enthusiast

Apr 11, 2015, 3:43 PM

Post #63 of 102 (8129 views)
Re: [stuckinarut] HASH-O-RAMA Data Processing Problem [In reply to] Can't Post

Hi,

1) just to be sure, on top of score you want, 1) score_submitted, the total score where call signs had submitted their logs, 2) score_unsubmitted, the total score where call signs had not submitted their logs. I just realised what you meant, I forgot about the total at the bottom, I fully understand. You'll notice 2 contestants at the bottom of scores.txt who scored 0 because they didn't submit their logs, although you provided a category for them.

2) you'll notice a unsubmitted.txt file is generated after phase2 which lists all the log signs of unsubmitted logs. This could be extended to include all the other information you desire. I'm not sure I quite understand why you would want to list where the wtf was i.e. 1, if this is below the wtf threshold then it has been derived to be a CNQ as oppose to unsubmitted and therefore fundamentally a non existant contestant. You can adjust the wtf's in weighs.txt after phase1 if any guenuine entries are below the wtf threshold, and vice versa. Also, the reason unsubmitted.txt has to be generated at phase2 and not phase1 is because it needs the outcome of the weights and any weight adjustments you made in order to derive which are unsubmitted and which are cnqs. For ease, we wouldn't want to add any information to the bottom of weights.txt because this needs to be read back in for phase2. Remember you can re-run phase1 and phase2 however you wish, therefore you can run phase2 to generate unsubmitted.txt, then send emails, then re-run it. If I have misunderstood, could you please explain in more detai.

Regards,

Chris


(This post was edited by Zhris on Apr 11, 2015, 3:46 PM)


stuckinarut
User

Apr 11, 2015, 3:59 PM

Post #64 of 102 (8119 views)
Re: [Zhris] HASH-O-RAMA Data Processing Problem [In reply to] Can't Post

Yes, the 2 logs with 0 entries were the 2 'Manual' logs last year...1 multiple screen capture .jpg's by one of the 'Bonus' point station, and 1 paper log (my own due to Confuzzzzer logging software problems that year). When things are at the point of being able to run the 2015 stuff, there will be lots of entries in all category logs including #12 and #13 :^)

I don't think I explained well enough about the other file (calls123.txt or something) addition. Will chew on this some better verbiage. Not a major issue - just a time savings to narrowly define and yield a 'Hit List' for email inquiries without having to import into Excel and delete the unwanted entries for that specific (manual) purpose in the processing.

Back to the grind here ;-(

Thanks, Chris!

- Stuckinarut


(This post was edited by stuckinarut on Apr 11, 2015, 4:00 PM)


stuckinarut
User

Apr 12, 2015, 1:23 AM

Post #65 of 102 (8035 views)
Re: [Zhris] HASH-O-RAMA Data Processing Problem [In reply to] Can't Post

Hey, Chris:

Faster to upload the .pdf file here.

It's 0112 local, so likely an error or two in the manual copy & paste anlyais, however it opened my eyes to a new issue.

I omitted the actual scores and only used the first 2 columns from the scores.txt file :^)

Look at all the callsigns NOT included on the 'unsubmitted' list. Some I've annotated - the others are most likely all 'Busted' calls.

IMHO, shouldn't the W6YA & K6VVA calls from the unsubmitted list also show with -minus signs in the (category) scores listing? What criteria is used to produce the unsubmitted list?

Here's what I'm thinking.

1. Omit the -minus entries from the Scores list - only actual log-submitted scores will be copy & pasted into the Results document anyway.

2. Include ALL Callsigns with NO LOGS on the unsubmitted list, and the 'Weight' in an adjacent column.

For stepping manually through the Error log one entry at a time, I just thought of something else that would really help in this task. That would be to add a final column on the right (after the 'WTF' column): NOLOG

So any Calls in the CALLWKD column that are Non-Log Submitters (possibly 'Busted' Calls) would be FLAGGED as 'NOLOG' :^)

This would be very useful especially if an increase in future year's volume of both log and nolog QSOs with unfamiliar callsigns in play.

**** DARN - I've uploaded the .pdf 3 times but it doesn't display. Hold on... I just stuck it up here:

http://www.xgenesis.com/hashorama/totalcallsanalysis.pdf

FYI & Thanks,

- Stuckinrut


(This post was edited by stuckinarut on Apr 12, 2015, 5:53 AM)
Attachments: totalcallsanalysis.pdf (208 KB)


stuckinarut
User

Apr 12, 2015, 6:02 AM

Post #66 of 102 (7971 views)
Re: [stuckinarut] HASH-O-RAMA Data Processing Problem [In reply to] Can't Post

Chris:

Got 4 hours of sleep and back at it.

Oooops, just realized why W6YA & K6VVA did NOT show as ~minus (log) entries... they are in CAT 12 & 13 (even though no QSO line log entries were in the entries.txt file).

I went through each of the MORE CALLSWKD NO LOGS list and checked them against the actual CALLSWKD CNQ's in the entries.txt file. Definitely more were 'BUSTED' calls. Corrected several errors I made (as suspected in the 0100 hour).

The .pdf finally showed up to the posting. Just deleted the initial one & uploaded a corrected version (likely at least one error in this at the rate things are going). Also uploaded/overwrote the other location/URL:

http://www.xgenesis.com/hashorama/totalcallsanalysis.pdf

Also attaching the new file to this post - hopefully it will display.

I hope this helps shed some light on a few tweaks needed.

Thanks!

- Stuckinarut


(This post was edited by stuckinarut on Apr 12, 2015, 6:05 AM)
Attachments: totalcallsanalysis.pdf (208 KB)


Zhris
Enthusiast

Apr 12, 2015, 6:05 AM

Post #67 of 102 (7969 views)
Re: [stuckinarut] HASH-O-RAMA Data Processing Problem [In reply to] Can't Post

Hi,

Now that the codes in a good state I will go through your analysis properly and try to explain each situation.

For now in answer to your querys:

- An unsubmitted log is one who's sign has at least one entry in the weights log that was more than or equal to the wtf threshold but did not make any calls across bands.

- w6ya and w6vva have categories associated with them in the categories log, hence why not assigned the default -1.

Regards,

Chris


stuckinarut
User

Apr 12, 2015, 6:07 AM

Post #68 of 102 (7967 views)
Re: [Zhris] HASH-O-RAMA Data Processing Problem [In reply to] Can't Post

Ahhh... Tnx for clarifying the unsubmitted decision making. Need to chew on this.

Just re-uploaded an additionally corrected .pdf ... I am embarrassed about making so many Errors myself, and need to slowwwww down. Trying to juggle tooooo many plates here at once with an ongoing sleep deficit ;-(

- Stuckinarut


stuckinarut
User

Apr 12, 2015, 6:11 AM

Post #69 of 102 (7966 views)
Re: [stuckinarut] HASH-O-RAMA Data Processing Problem [In reply to] Can't Post


In Reply To
- An unsubmitted log is one who's sign has at least one entry in the weights log that was more than or equal to the wtf threshold but did not make any calls across bands.


Do you mean the weight threshold for JUST the Callsign, or the entire CNQ ???

Thanks!


stuckinarut
User

Apr 12, 2015, 6:18 AM

Post #70 of 102 (7961 views)
Re: [stuckinarut] HASH-O-RAMA Data Processing Problem [In reply to] Can't Post


In Reply To

In Reply To
- An unsubmitted log is one who's sign has at least one entry in the weights log that was more than or equal to the wtf threshold but did not make any calls across bands.


Do you mean the weight threshold for JUST the Callsign, or the entire CNQ ???

Thanks!


FYI, I just changed the WTF back to '2' and did a re-run. N4LOV does not show up in the unsubmitted file even though there are '2' entries in the submitted logs. Maybe the unsubmitted file is not updated for re-runs? If so, can this be re-tweaked?

Thanks, Chris.

- Stuckinarut


stuckinarut
User

Apr 12, 2015, 6:27 AM

Post #71 of 102 (7959 views)
Re: [Zhris] HASH-O-RAMA Data Processing Problem [In reply to] Can't Post

Maybe time to switch back to 'PM' mode? :^)

The more I think about this, I really believe ALL (potential) unsubmitted calls need to show up on the unsubmitted list, but with the 'Weight' included - maybe even in the same format as the weights.txt file, but also with a final NOLOG column added like I suggested for the Error log:


Code
SIGN  NAME  QTH  WTF  NOLOG


WOW... if the weights.txt file could also have the NOLOG column added, then all of these documents would be of great benefit during the manual processing. Really helpful.

*** ESPECIALLY when I have 2 or 3 documents open (or printed out in front of me) to make decisions.

FYI & Thanks,

- Stuckinrut


(This post was edited by stuckinarut on Apr 12, 2015, 6:29 AM)


Zhris
Enthusiast

Apr 12, 2015, 6:29 AM

Post #72 of 102 (7957 views)
Re: [stuckinarut] HASH-O-RAMA Data Processing Problem [In reply to] Can't Post


Quote
Do you mean the weight threshold for JUST the Callsign, or the entire CNQ ???


Hehe its kind of complicated. As you know the weights log has multiple entries per sign, that is because of the variation in names and qths used. For a particular sign, it only takes 1 line where the wtf >= wtf threshold to be counted as a valid contestant, but all the lines are taken into consideration when deciding which names and which qths and valid. Lets look at the first five entries in the weights log:


Code
K0AC    BILL    IA      1 
K0AD LOCUST MD 1
K0AD LOCUST MN 84
K0EU JOHN CO 1
K0EU KEN CO 112


- K0AC has 1 entry with wtf below the threshold, therefore is an invalid contestant.
- K0AD has 2 entries with 1 entry with wtf above the threshold. Therefore the sign K0AD is a valid contestant, but as a whole the location MD is invalid, therefore only the name LOCUST and location MN will be assigned against it.
- K0EU like K0AD, but only the name KEN and location CO will be assigned against it.

If you decided K0AC is actually a valid contestant, you could change the wtf of 1 to something above the wtf threshold i.e. 9999999 for safety before running phase2. Likewise if you decided K0AD is actually an invalid contestant, make sure all their wtf's are below the wtf threshold i.e. -1 for safety.

I have just gone throough a couple of signs under more callswkd (no logs) and not certain I quite understand the notes in brackets, every one I checked appeared to have been handled as expected.

Regards,

Chris


stuckinarut
User

Apr 12, 2015, 6:32 AM

Post #73 of 102 (7954 views)
Re: [Zhris] HASH-O-RAMA Data Processing Problem [In reply to] Can't Post


In Reply To

Quote
Do you mean the weight threshold for JUST the Callsign, or the entire CNQ ???


Hehe its kind of complicated. As you know the weights log has multiple entries per sign, that is because of the variation in names and qths used. For a particular sign, it only takes 1 line where the wtf >= wtf threshold to be counted as a valid contestant, but all the lines are taken into consideration when deciding which names and which qths and valid. Lets look at the first five entries in the weights log:


Code
K0AC    BILL    IA      1 
K0AD LOCUST MD 1
K0AD LOCUST MN 84
K0EU JOHN CO 1
K0EU KEN CO 112


- K0AC has 1 entry with wtf below the threshold, therefore is an invalid contestant.
- K0AD has 2 entries with 1 entry with wtf above the threshold. Therefore the sign K0AD is a valid contestant, but as a whole the location MD is invalid, therefore only the name LOCUST and location MN will be assigned against it.
- K0EU like K0AD, but only the name KEN and location CO will be assigned against it.

If you decided K0AC is actually a valid contestant, you could change the wtf of 1 to something above the wtf threshold i.e. 9999999 for safety before running phase2. Likewise if you decided K0AD is actually an invalid contestant, make sure all their wtf's are below the wtf threshold i.e. -1 for safety.

I have just gone throough a couple of signs under more callswkd (no logs) and not certain I quite understand the notes in brackets, every one I checked appeared to have been handled as expected.

Regards,

Chris


Thanks for the explanation. Hmmm...I really need to chew on this now. Will get back with you later today via PM mode to reduce the thread traffic with these discussions :^)


Zhris
Enthusiast

Apr 12, 2015, 6:41 AM

Post #74 of 102 (7952 views)
Re: [stuckinarut] HASH-O-RAMA Data Processing Problem [In reply to] Can't Post

You mentioned N4LOV for wtf threshold of 2. Here are its weight entries:


Code
N4LOV   AL      AL      1 
N4LOV CARL AL 1


Both are below the threshold therefore its an invalid contestant. In the current version, you would look through the weight log before phase2 and adjust the weights of any as you see fit.

Chris


(This post was edited by Zhris on Apr 12, 2015, 6:42 AM)


Zhris
Enthusiast

Apr 12, 2015, 6:52 AM

Post #75 of 102 (7947 views)
Re: [stuckinarut] HASH-O-RAMA Data Processing Problem [In reply to] Can't Post


Quote
The more I think about this, I really believe ALL (potential) unsubmitted calls need to show up on the unsubmitted list


The thing is, based on the wtf the code has already tried its best to decipher who are the potential unsubmitters. The only thing beyond that would be to include EVERYONE else, you should use the weights log to control whos valid and whos not before hand.

With regards to adding a nolog col to the weights log, this could be done by duplicating later logic but I feel this is beyond what the weights log purpose entails, at the stage of creating the weights log it doesn't know which entries are from non submitters, this is the job of the unsubmitters log. You can assume any group of entries in the weights log where 1 of them has a wtf above the proposed wtf threshold will be a valid contestant whether or not they submitted a log.

Chris

First page Previous page 1 2 3 4 5 Next page Last page  View All
 
 


Search for (options) Powered by Gossamer Forum v.1.2.0

Web Applications & Managed Hosting Powered by Gossamer Threads
Visit our Mailing List Archives