Как и чем судим соревнования ?

**RV3YR** · 26.06.2009, 20:28

Сообщение от RW3VZ

RK3PWF ошибся при приёме позывного. Должно быть RW3WWW. Программа, не анализируя ситуацию, тупо влепила NoLog и не зачла связи. При этом RW3WWW тоже получил "баранки". А мог бы получить очки, если бы правила не учитывали ошибки корреспондентов. И, опять же, если бы за ошибки приема начислялись пенальти, то RK3PWF должен был их отгрести.

Андрей, в данный момент в программе уже есть возможность устанавливать режим такого зачета, или не зачета в соответствии с Положением теста. Так что все в порядке, проехали дальше...

Добавлено через 14 минут

Сообщение от RU3AX

Я не думаю, что косяк в алгоритме судейства. Это вопрос концепции судейства соревнований вообще и концепций судейства организаторов конкретных соревнований.

To: RW3VZ!
Андрей, у меня такое чувство, что Вы включились в работу по тестированию программы лишь с целью, чтобы найти в ней, как Вы выражаетесь, "копнуть" только негатив. Начали с того, что у вас не оказалось Админ. прав на работу с программой, а теперь рассматриваете единичный случай, делая выводы по всей работе программы. Думаю, что это зря, в т.ч. и с поспешными выводами для тех, кто купил программу. Хочу предупредить, что у Вас в руках ДЕМО-ВЕРСИЯ с очень ограниченными правами. Я могу, конечно, выслать Вам полную версию, зарегистрировать ее, и Вы убедитесь, что Вы ПОЛНОСТЬЮ НЕ ПРАВЫ, притом ВО ВСЕМ, о чем пишите!!! И вот еще что: Вы лихо делаете выводы по работе программы, забывая, что для каждого соревнования пишется свой модуль, в котором реализуются все условия, предусмотренные конкретным положением. Это кратко и надеюсь доходчиво. В последующем, очень прошу и Вас выражать свои мысли более понятно, т.к. из прочитанного я не совсем понял, что Вам не так? И притом в частном модуле "Школа Чемпионов", замечу, он судился кажется 9 версией, а сегодня вышла уже 23-я. Так, что QRT, please, давайте не спешить с выводами о полной непригодности программы. Добавлю, перерыл весь Инет, но не нашел ничего, что было бы хотя бы в 10 раз проще того, что сегодня имеем. Если бы нашел, то и делать бы не стали этот продукт. А цель форума и тема была: кто и чем судит??? Пока ответа на данный вопрос я не получил, а значит как и ничем...
А может Вы можете похвалиться более качественным продуктом, то пожалуйста, я жду, тоже хочу его протестировать...

Добавлено через 25 минут

Сообщение от RW3VZ

Неважно, как оно называется. Главное - результат. Автор представляет нам продукт, причем коммерческий, и просит потестировать. Я лишь высказываю первые замечания, причем самые поверхностные. Нет времени копнуть глубже. Кое-кто уже купил, но вероятно, ещё не наступил на такие грабли.
__________________
73. Андрей

Андрей, Вас я уже НЕ ПРОШУ, т.к. это не тестирование, а "копание" ни в том месте, где надо...
Конкретных замечаний мы с автором от Вас не получили, кроме как админ. доступа.
Спасибо за "тест" и всего хорошего...

Добавлено через 1 час 49 минут

Сообщение от RW3VZ

В программе не рассматривается момент, который часто возникает при судействе. В демо-примере он неочевиден, поскольку все связи должны быть подтверждены отчетами и за неверный приём позывного или номера не применяется штрафование.

А вот что отвечает автор программы на Ваш вопрос:
- Дело в том, что определить ошибся корреспондент на приёме позывного
или это действительно NoLog невозможно. В примере приведена ошибка в одном знаке и автор делает подобное заключение на основе домыслов. А если ошибка в двух или более знаках позывного, то автор не сможет сделать даже этих
домыслов а тоже запишет это как NoLog, согласившись с железным мозгом. то есть пример притянут за уши.

Я скажу больше - автор может сделать эти домыслы по причине того что у
него в руках десяток логов и он их всех в состоянии анализировать.
Подобный трюк с 1000 логов он сделать не сможет.

Добавлено через 1 час 51 минуту

Сообщение от RW3VZ

RK3PWF ошибся при приёме позывного. Должно быть RW3WWW. Программа, не анализируя ситуацию, тупо влепила NoLog и не зачла связи. При этом RW3WWW тоже получил "баранки". А мог бы получить очки, если бы правила не учитывали ошибки корреспондентов. И, опять же, если бы за ошибки приема начислялись пенальти, то RK3PWF должен был их отгрести.

И далее:
Ошибку в позывном диагностировать невозможно в принципе, потому что никаких оснований искать неподтверждённую связь в логах участников с несовпадающим позывным нет.

Добавлено через 1 час 55 минут
Андрей выбил главную мысль: готова версия 23, в которой появилось разделение на "Протокол" и "UBN". Внесены соответствующие изменения на сайт и в хелп программы. Зарегистрированные пользователи получат 23-ю сборку на выходные.

**RV3YR** · 27.06.2009, 18:35

TO: RW3VZ:::
Андрей, могу ошибиться, но Вы, по-видимому, сами занимались чем-то подобным и наступили на эту тему (невозможности определения ошибки приёма позывного), поэтому сразу привели заранее не решаемый тест, чтобы убедиться, что не только Вам это не под силу,-и радостно это описали.
Ваш пример, очень искуственный и лукавый, Вы сначала сказали, что нашли пару связей, потом положили их рядом и сделали очевидную диагностику - "ошибка приёма позывного".

Представьте: вы держите в руках лог участника, перед вами ящик полный логов остальных, вам надо найти подтверждение связи:

14 CW 2009-01-01 1000 RV3YR 599 007 AA1BB 599 017

Как вы это будете делать? (когда вы найдёте - вы конечно расскажете про любые ошибки приёма и всё такое подобное! Но как вы найдёте пару?!!! Наверное Вы попробуете найти лог участника AA1BB - его нет - что дальше?
Здесь Вы слукавили во второй раз - Вы говорите, что в соревновании есть участник
AA1BC и возможно это он и есть а тут мы видим просто ошибку приёма позывного (потом афтар эффектно вытаскивает лог AA1BC и, о чудо! Его предположение верно - но это фокус, ему просто повезло)...
Но в практике проблема не в диагностике очевидного, а в том чтобы НАЙТИ эту самую пару связей. А Вы этот вопрос не рассматривали вообще.
Ошибка могла быть такой, что позывной не "похож" ни на какой в соревновании, то есть можно просто считать, что мы НЕ ЗНАЕМ позывной корреспондента и нам предстоит найти подтверждающую связь, перерыв ВСЕ логи ВСЕХ участников в поисках "похожей" (!) связи.

Помните анекдот про лесорубов и японскую бензопилу? Это, когда ей в конце подсунули перепилить рельс и она сдохла, - что порадовало лесорубов. Вот это чисто как в этом анекдоте.

Итак, то, что Вы описали (теоретически возможное неверное исчисление очков) возможно только при очень редком стечении обстоятельств, а именно:

1. Должно быть положение, которое предусматривает РАЗНЫЙ результат для разных
ошибок (например ошибку приёма засчитывает, а отсутствие лога нет, или начисляет пенальти за ошибку приёма, и не начисляет за ноулог). Таких положений во-первых мало (я например не встречал ещё) а во-вторых мы просто не возьмёмся судить те соревнования на которых возможны подобные косяки. Как минимум, честно предупредим такого заказчика (если таковой вообще объявится, потому что ПОДАВЛЯЮЩЕЕ большинство положений
обрабатываются правильно).

2. Участник должен допустить ТОЛЬКО ошибку в позывном и НЕ ДОПУСТИТЬ никаких более, - только в этом случае теоретически можно искать запись, НЕ ЗНАЯ ПОЗЫВНОГО (!). Если ошибки были не только в позывном, - запись всё равно найти скорее всего не получится, и диагностика всё равно будет ноулог.

Есть тезисы, почему такой поиск лучше не делать вообще:

напомню проблему (отбросив лишнее и несущественные детали) - надо найти подтверждающую связь для запиcи, считая что позывной корреспондента мы не знаем:
(14 CW 2009-01-01 1000 RV3YR 599 007 ----- 599 017 )

Человек-судья, думаю, такую задачу решить не в состоянии вообще, но от программы почему-то ждут чуда (а если она "коммерческая", как Вы пишите, так непременно должна кормить хлебами голодных и превращать воду в вино!!!)

Придётся перебирать ВСЕ QSO ВСЕХ участников и искать ту, которая КАЖЕТСЯ ПОХОЖА на подтверждающую.

Против этого:

1. Начнём с того, что это НЕ НАДО подавляющему большинству соревнований - на их результат не влияет, по какой причине будет забанена связь, -по ноулог или ошибке приёма, - она просто снимается обоим или тому кто ошибся и всё.

2. Это катастрофически скажется на производительности - время расчёта превратится из секунд в ЧАСЫ и СУТКИ только ради того, чтобы ПО НЕКОТОРЫМ записям, ЕСЛИ ПОВЕЗЁТ, вместо ноулог стояла ошибка приёма. На результат, повторяю, это НЕ ВЛИЯЕТ, - т.е. это бесполезно потраченное время.

3. Если я, все-таки, переработав тучу данных, нашел ПОХОЖУЮ запись и засчитал ошибку приёма, и если я ошибся (ведь кроме моих домыслов и критериев "похожести" записи ничего нет, это чисто субъективный выбор), то я НЕ ЗАЧТУ эту найденную запись тому, кому положено (одна запись подтверждает одну связь), т.е. я испорчу связи кому-то только потому, что не непонятно зачем полез искать вероятное подтверждение чужой связи.

Подведем итог:

1. Описанное явление "невозможность диагностирования ошибки приёма позывного" является фундаметальной и неразрешимой в общем случае проблемой, которая крайне редко может повлиять на результат соревнований.

2. Мы честно предупредим заказчика, если его положение не может быть обсчитано (или просто не возьмеся считать, или будем что-то придумывать для этого случая), поэтому случайно "напороться" у него шансов - "0".

3. Мы предлагаем услугу индивидуальной работы с заказчиком и в простых и в тяжёлых случаях и стараемся помочь в меру возможностей и здравого смысла.

**R8TX** · 27.06.2009, 22:05

Сообщение от RV3YR

А вот что отвечает автор программы на Ваш вопрос:
- Дело в том, что определить ошибся корреспондент на приёме позывного
или это действительно NoLog невозможно. В примере приведена ошибка в одном знаке и автор делает подобное заключение на основе домыслов. А если ошибка в двух или более знаках позывного, то автор не сможет сделать даже этих
домыслов а тоже запишет это как NoLog, согласившись с железным мозгом. то есть пример притянут за уши.

Я скажу больше - автор может сделать эти домыслы по причине того что у
него в руках десяток логов и он их всех в состоянии анализировать.
Подобный трюк с 1000 логов он сделать не сможет.

Это вполне успешно делается с 3500 логами в RussianDX Contest.

Сообщение от RV3YR

Андрей выбил главную мысль: готова версия 23, в которой появилось разделение на "Протокол" и "UBN".

Не проведя анализа по ошибкам приема позывных, как Вы собираетесь делать UBN?

Сообщение от RV3YR

Придётся перебирать ВСЕ QSO ВСЕХ участников и искать ту, которая КАЖЕТСЯ ПОХОЖА на подтверждающую.

Против этого:

1. Начнём с того, что это НЕ НАДО подавляющему большинству соревнований - на их результат не влияет, по какой причине будет забанена связь, -по ноулог или ошибке приёма, - она просто снимается обоим или тому кто ошибся и всё.

Kaк делать UBN? Или в UBN будут только ошибки приема номеров?

Сообщение от RV3YR

2. Это катастрофически скажется на производительности - время расчёта превратится из секунд в ЧАСЫ и СУТКИ только ради того, чтобы ПО НЕКОТОРЫМ записям, ЕСЛИ ПОВЕЗЁТ, вместо ноулог стояла ошибка приёма. На результат, повторяю, это НЕ ВЛИЯЕТ, - т.е. это бесполезно потраченное время.

Let's let the computers compute

Сообщение от RV3YR

3. Если я, все-таки, переработав тучу данных, нашел ПОХОЖУЮ запись и засчитал ошибку приёма, и если я ошибся (ведь кроме моих домыслов и критериев "похожести" записи ничего нет, это чисто субъективный выбор), то я НЕ ЗАЧТУ эту найденную запись тому, кому положено (одна запись подтверждает одну связь), т.е. я испорчу связи кому-то только потому, что не непонятно зачем полез искать вероятное подтверждение чужой связи.

Не надо перебирать весь лог, есть еще время и диапазон, вполне можно организовать проверку позывных на глубину ошибочно принятых знаков, количество которых задается пользователем.

А вообще отлично, реально нужная программа, первое предложение подобного рода.

**EW4DX** · 27.06.2009, 22:53

Сообщение от RW3VZ

Аналогичная ситуация:
2008 RV9LM 599 46 RZ9HWA 599 26 - - - NoLog [RZ9HWA]
RZ9HWA в отчете RV9LM засвечен аж 8 раз. При этом рядышком лежит отчет RZ9SWA, где значится:
2008 RZ9SWA 599 26 RV9LM 599 46 - - - NotInLog [RV9LM]
и те же самые 8 связей.

Интересная, кстати, ситуация. Обычно в положении сказано - если позывной встречается в ... отчетах, связи с ним засчитываются. То есть эти ошибочные позывные, по логике, должны засчитываться, если удовлетворяют такому критерию?

**R8TX** · 28.06.2009, 07:24

Сообщение от RV3YR

Придётся перебирать ВСЕ QSO ВСЕХ участников и искать ту, которая КАЖЕТСЯ ПОХОЖА на подтверждающую.

Не все так печально

Количество ЩСО с ошибками обычно составляет около 5%, не так много, дальше дело только в правильном алгоритме. Допустим сначала проверяются все подтвердившиеся ЩСО, им ставится некий флаг, в дальнейшей проверке они больше не участвуют. Следующие действия совершаются только над записями, не имеющими такого флага, задача сильно упрощается, можно даже такие связи вынести в отдельную базу и работать только с ней.

Кстати в некоторых тестах, например RDXC, RDAC, IOTA, для каждого участника создаются списки сработанных областей, RDA, островов, было бы тоже неплохо предусмотреть такую возможность. Как именно это выглядит можно посмотреть на их сайтах.

**RV3YR** · 28.06.2009, 16:58

Сообщение от RX9TX

Не проведя анализа по ошибкам приема позывных, как Вы собираетесь делать UBN?
Kaк делать UBN? Или в UBN будут только ошибки приема номеров?

Да, как ошибки приёма, в UBN идут только ошибки приёма номеров. Ошибки приёма позывного
идут в UBN как NoLog (разумеется не трудно это писать как "NoLog or receive error") Hi!

Добавлено через 2 минуты

Сообщение от RX9TX

Не надо перебирать весь лог, есть еще время и диапазон, вполне можно организовать проверку позывных на глубину ошибочно принятых знаков, количество которых задается пользователем.

Это уже вопросы оптимизации производительности, понятно, что мрачную задачу поиска похожих связей, НЕ ЗНАЯ позывного, придётся как-то вытягивать. Никакой "глубиной" знаков тут не отделаешься! А все остальные поля записи (время, номера) тоже могут быть с ошибками.
Думать об этом есть смысл только тогда, когда дело дойдёт до обработки реального теста, для которого это будет реально необходимо!

Добавлено через 4 минуты

Сообщение от RX9TX

Это вполне успешно делается с 3500 логами в RussianDX Contest.

Вот не верю и все!!! Хоть убейте!!! Можите доказать??? Или сказано просто так, для юмора...

Добавлено через 14 минут
Уважаемы друзья! Программа развивается и вполне возможно, что когда нам
придётся судить соревнование для которого все перечисленное будет, ну очень важно, - мы что-нибудь уже придумаем, ведь жизнь не стоит на месте. И подобный поиск, о чем шла речь реализуем.

Я в параллельной ветке на CQHAM уже спросил, хочу спросить и тут: а что, есть какая-то альтернатива??? Есть ли еще хоть что-то, что можно использовать для судейства??? (Не имел ввиду карандаш, счеты и прочее...).
Логов разных (и хороших и не очень полно!), а вот судим пока карандашом, а время-то не 1960 год. Скоро и бумажные отчеты полностью не будут приниматься... :feminist:

А пока, самым дружеским образом благодарю всех, кого мы с автором втянули в дискуссию, - за прекрасную и конструктивную критику. Огромное спасибо от меня лично и от автора также. Он с огромным удовольствием все также прочел.

**RW3VZ** · 29.06.2009, 10:13

Сообщение от RV3YR

TO: RW3VZ:::
Андрей, могу ошибиться, но Вы, по-видимому, сами занимались чем-то подобным и наступили на эту тему (невозможности определения ошибки приёма позывного), поэтому сразу привели заранее не решаемый тест, чтобы убедиться, что не только Вам это не под силу,-и радостно это описали.

Да, я уже достаточно занимаюсь судейством, используя софт DL6RAI, применяемый для крупных еропейских соревнований (WAE, WAG и т.д.).

То, что вы называете нерешаемым тестом, в данном случае делается элементарно, поскольку ИМЕЮТСЯ отчеты участников, чьи позывные приняты неправильно. А программа не хочет в них ковыряться, проставляя NoLog.
Такое "упрощение" в серъезных соревнованиях просто недопустимо.
А есть ведь и еще более сложные ситуации, реально возникающие при судействе.

----------------

Так что Виктор, не обижайтесь. Это конструктивная критика. Программа действительно нужна. И очень хорошо, что нашлись люди, способные этим заняться. Так давайте же сделаем такой продукт. Наши замечания - только вам на пользу. Не надо встречать их в штыки. Я готов предоставить вам софт, которым пользуется DARC, чтоб вы смогли уяснить алгоритм, применяемый там (в том числе и для разрешения указанных инцидентов).

**R8TX** · 29.06.2009, 19:52

Сообщение от RV3YR

Цитата:
Сообщение от RX9TX Посмотреть сообщение
Это вполне успешно делается с 3500 логами в RussianDX Contest.
Вот не верю и все!!! Хоть убейте!!! Можите доказать??? Или сказано просто так, для юмора...

Aга, для юмора

-----------------------------------
RDXC-2009 RECEIVED LOGS

Received logs total: 3637. Processed - 3622, not yet processed - 15. Last updated 15.05.2009 15:00:00 UTC
-----------------------------------

Лог RW4AA/9, из ContestRU:

IS> Band Mode UTC Station Sent Rcvd
IS>
IS> 1.8 CW 16:48 JT1CO YN 359 Ваш позывной записан как RA4AA/9
IS> 7 CW 13:57 UA0OA YN BU Ваш позывной записан как RW4AA
IS> 7 CW 14:31 RX9AF YN CB Ваш позывной записан как RW4AAB/9
IS> 14 CW 12:03 RK3DK YN MO Ваш позывной записан как RW4AA/9T
IS> ............... YN MO Ваш номер записан как YT
IS> 14 CW 03:02 BD3APX YN 159 Ваш позывной записан как RW9AA/9
IS> 14 CW 03:30 UA4PWR YN TA Связь не подтверждена UA4PWR
IS> 14 CW 04:00 UN7PV YN 530 Ваш номер записан как KN
IS> 14 CW 04:59 RU9SL YN OB Ваш позывной записан как RW4AA/9T
IS> ............... YN OB Ваш номер записан как OB
IS> 14 CW 05:37 RW4HT YN SR Ваш номер записан как MV
IS> 14 CW 09:15 RT4M YN UL Ваш позывной записан как RW4AA
IS> ............... YN UL Ваш номер записан как VG
IS> 14 CW 09:46 IK6MNB YN 669 Ваш номер записан как CB
IS> 14 CW 09:50 OH0R YN 1988 Ваш позывной записан как RW4AW/9
IS> 14 CW 09:56 HG4F YN 663 Ваш номер записан как YR
IS> 14 CW 10:11 OM3LA YN 2437 Ваш позывной записан как RW4AA/8
IS> 14 CW 10:20 RK3MWU YN YR Связь не подтверждена RK3MWU
IS> 14 CW 10:46 5B4AII YN 2963 Ваш номер записан как CB
IS> 14 CW 11:17 5B/W0DKA YN 2046 Вам передан номер 2047
IS> 14 CW 11:53 RK1NA YN KL Ваш позывной записан как RW4AAC/9
IS>
IS> ............... означает двойную ошибку в одной и той же связи
IS> --------------------------------------------------------------------------
IS> UA1AAF soft

-------------------------------

Позывной: RX9TX

ОБЛАСТИ, ПОДТВЕРЖДЕННЫЕ В "RUSSIAN DX CONTEST" 2008 ГОДА
НА ДИПЛОМ "РОССИЯ"
--------------------------------------------------------------------------------
1.8 3.5 7 14 21 28 Total
CW SSB CW SSB CW SSB CW SSB CW SSB CW SSB CW SSB All

R1A - - 1 - 1 - 1 - - - - - 3 0 3
R1C - - 1 - 1 - 1 - 1 - - - 4 0 4
R1N - - 1 - 1 - 1 - - - - - 3 0 3
R1O - - 1 - 1 - 1 - - - - - 3 0 3
R1P - - - - - - 1 - - - - - 1 0 1
R1Q - - 1 - 1 - 1 - - - - - 3 0 3
R1T - - 1 - 1 - - - - - - - 2 0 2
R1W - - 1 - 1 - 1 - - - - - 3 0 3
R1Z - - 1 - 1 - 1 - - - - - 3 0 3
R2F - - 1 - 1 - 1 - - - - - 3 0 3
R3A - - 1 - 1 - 1 - - - - - 3 0 3
R3D - - 1 - 1 - 1 - - - - - 3 0 3
R3E - - 1 - 1 - 1 - - - - - 3 0 3
R3G - - 1 - 1 - - - - - - - 2 0 2
R3I - - 1 - 1 - - - - - - - 2 0 2
R3L - - 1 - 1 - 1 - - - - - 3 0 3
R3M - - 1 - 1 - - - - - - - 2 0 2
R3N - - 1 - 1 - - - - - - - 2 0 2
R3P - - 1 - 1 - - - - - - - 2 0 2
R3Q - - 1 - 1 - - - 1 - - - 3 0 3
R3R - - 1 - 1 - - - - - - - 2 0 2
R3S - - 1 - 1 - - - - - - - 2 0 2
R3T - - 1 - 1 - 1 - - - - - 3 0 3
R3U - - 1 - 1 - 1 - - - - - 3 0 3
R3V - - 1 - 1 - - - - - - - 2 0 2
R3W - - 1 - 1 - 1 - - - - - 3 0 3
R3X - - 1 - 1 - 1 - - - - - 3 0 3
R3Y - - 1 - 1 - 1 - - - - - 3 0 3
R3Z - - 1 - 1 - - - - - - - 2 0 2
R4A - - 1 - 1 - - - - - - - 2 0 2
R4C - - 1 - 1 - - - - - - - 2 0 2
R4F - - 1 - 1 - - - - - - - 2 0 2
.............................
.............................
--------------------------------------------------------------------------------
Sum: 0 0 64 0 63 0 47 0 6 0 0 0 180 0 180

* UA1AAF soft

**RV3YR** · 29.06.2009, 21:39

Сообщение от RW3VZ

Такое "упрощение" в серъезных соревнованиях просто недопустимо.
А есть ведь и еще более сложные ситуации, реально возникающие при судействе.

Андрей, ни в коем случае!!!
Все воспринято, ка дельный совет, а это привело в тому, что автор попытался решить то, о чем писалось, итак...

Добавлено через 11 минут
Высказанные конструктивные замечания учтены:
24-я сборка обнаруживает и диагностирует ошибки приёма позывного за счёт увеличения времени обработки данных. Это поведение вынесено в настройку "Обнаруживать ошибки приёма позывного" и, по умолчанию, включена для всех соревнований. Ошибки приёма обнаруживаются и пишутся в UBN.

Элемент настройки "Обнаруживать ошибку приёма позывного" влияет на точность диагностики ошибки, связанной с позывным корреспондента. Если значение свойства Value = False ошибочный (или отсутствующий) позывной диагностируется как NoLog ("лог отсутствует"), и эта запись может означать как отсутствие лога корреспондента, так и ошибку приёма позывного. В этом режиме обеспечивается максимальная скорость обработки данных.

Если значение свойства Value = True (по умолчанию), программа попытается найти корреспондирующую запись для проверяемой связи, и, по результатам проверки, диагностируется ошибка приёма позывного (Callsign error) отдельно от NoLog. В этом режиме обеспечивается точность диагностики за счёт существенного снижения скорости обработки данных. Подробно тема изложена на сайте:
http://msft.net.ru/qsot/articles/call_chk.php

По производительности, просто для оценки факта насколько всё плохо в этом случае:
-соревнование ШЧ-2009, отчёт: турнирная таблица, для папки ALL_MEMBERS и вообще для всех участников
-без обнаружения ошибок:
88 участников - 3600 мсек. 193 участника - 4800 мсек.
-с обнаружением ошибок:
88 участников - 12000 мсек. 193 участника - 25000 мсек.
вот что получилось...

**R8TX** · 30.06.2009, 05:25

Сообщение от RV3YR

Высказанные конструктивные замечания учтены:
24-я сборка обнаруживает и диагностирует ошибки приёма позывного за счёт увеличения времени обработки данных. Это поведение вынесено в настройку "Обнаруживать ошибки приёма позывного" и, по умолчанию, включена для всех соревнований. Ошибки приёма обнаруживаются и пишутся в UBN.

Это правильно

Сообщение от RV3YR

По производительности, просто для оценки факта насколько всё плохо в этом случае:
-соревнование ШЧ-2009, отчёт: турнирная таблица, для папки ALL_MEMBERS и вообще для всех участников
-без обнаружения ошибок:
88 участников - 3600 мсек. 193 участника - 4800 мсек.
-с обнаружением ошибок:
88 участников - 12000 мсек. 193 участника - 25000 мсек.
вот что получилось...

Критерий не время обработки, а корректный UBN

**RW3VZ** · 30.06.2009, 08:41

Сообщение от RV3YR

24-я сборка обнаруживает и диагностирует ошибки приёма позывного за счёт увеличения времени обработки данных.

Хотелось бы пощупать эту сборку.

Сообщение от RV3YR

По производительности, просто для оценки факта насколько всё плохо в этом случае

Ну а это на самом деле такая ерунда.
2 секунды, 5, 10 или 20, или даже пол-часа - это мелочи.
Плохо может быть только в случае, когда не получим достоверного результата.

-----

В продолжение темы.
UBN = Unique, Bad, Nil.
Bad и Nil программа делать научилась. Это хорошо. А как дела обстоят с уникальными позывными в отчетах? Будет ли возможность их обработки?
Для тестов, где судейство идет на основе только полученных отчетов, это неактуально.
А там, где процент непосредственно проверяемых перекрестной проверкой связей небольшой, без учёта "юников" никак не обойтись.
Вот, в частности:

Сообщение от RA4ST

получил 21-ю версию замечательного инструмента для судейства соревнований.
До этого мы судили Открытый чемпионат Поволжья кустарными .....
.....
Олег Шишкин
RA4ST

В этих соревнованиях имеющиеся отчеты позволят проверить напрямую только 10-15% QSO (а может, и меньше). Если не анализировать неподтверждённые связи, достоверность будет очень низкой.

Какие предполагаются алгоритмы анализа?

**RW3VZ** · 30.06.2009, 14:00

В продолжение.
Ещё одна подсказка для разработчиков.
Просматривая в примере "ЩЧ" список неполученных отчетов, обнаружил позывной "074".
Понятно, это косяк в логе участника, однако программа тоже считает его как NoLog. Подход формальный. Но такой ошибки избежать можно, включив алгоритм проверки позывных на "вшивость". Достаточно простого шаблона: указать количество и последовательность различных вариантов следования букв и цифр.
Все, что в шаблоны не укладывается, либо автоматически становится BadCall, либо программа спрашивает у судьи, а может ли в принципе быть такой позывной (не по шаблону, например: RAEM). На основании диалога с судьёй формируется конкретный служебный файл (для конкретного теста, где выскочили такие кривые позывные). Этот файл используется при всех дальнейших манипуляциях с отчетами.
При судействе КВ Полевого Дня у меня такой файл содержит более сотни позывных.

**RK1AA** · 01.07.2009, 11:13

1. Такую ерунду логичнее отбрасывать на входе, т. е. при приемке отчетов.
Конкретнее, почтовым роботом, если он есть.

2. Замечание: достоверность не может быть низкой. Вероятность достоверности равна единице по определению. Достоверность судейства - глупейший, безграмотный термин.

3. Хотелось бы узнать, есть ли алгоритм распознавания систематических ошибок, контролируется ли при проверке совпадение видов работы и диапазона и как учитывается время связей (с учетом даты или без, разница в минутах, разница в часах при близких минутах и т. п.).

Добавлено через 9 минут
Об ошибках приема позывного: точная идентификация подобной ошибки требуется при наличии в положении штрафов за подобные ошибки. Иначе теряется смысл точной идентификации - ошибка есть ошибка, связь все равно будет не засчитана.

Однако, определение такой ошибки не требует слишком большого вычислительного времени, существует множество алгоритмов сравнения строк. Поэтому лично мне не ясно, почему часто в UBN-файлах (не своих!

) я вижу ошибки No Log при явной ошибке приема позывного.

**RW3VZ** · 01.07.2009, 13:52

Сообщение от RK1AA

1. Такую ерунду логичнее отбрасывать на входе, т. е. при приемке отчетов. Конкретнее, почтовым роботом, если он есть.

Это каким образом?
Позволить роботу футболить отчет из-за битого позывного?

Сообщение от RK1AA

2. Замечание: достоверность не может быть низкой. Вероятность достоверности равна единице по определению. Достоверность судейства - глупейший, безграмотный термин.

Давайте не будем о терминологии, смысл понятен.
Могу процитировать:
Достоверность есть величина обратно пропорциональная вероятности возникновения ошибки. Достоверность есть степень надежности информации, в идеальном случае означающая отсутствие ошибок и отклонений.
---

В нашем случае задача состоит в том, чтоб добиться при судействе минимального количества ошибок.

**RV3YR** · 01.07.2009, 20:35

Сообщение от RW3VZ

Хотелось бы пощупать эту сборку.

Андрей, отправил Вам уже 26-ю сборку.

Сообщение от RW3VZ

В этих соревнованиях имеющиеся отчеты позволят проверить напрямую только 10-15% QSO (а может, и меньше). Если не анализировать неподтверждённые связи, достоверность будет очень низкой. Какие предполагаются алгоритмы анализа?

С Чемпионатом Поволжья кажется вопрос должен быть закрыт, более конкретно скажет Олег. В 26-й сборке также вопрос должен быть решен.

Добавлено через 6 минут
Включение режима точной диагностики увеличивает время формирования итогового
отчёта "Турнирная таблица", но практически не влияет на время формирования UBN, то есть заметно всё это только в сводном отчёте.

Использование элемента настройки "Обнаруживать ошибку приёма позывного" позволяет использовать максимальную производительность (например для предварительных расчётов итога) или точность (для окончательных итогов и получения UBN). Пользователь имеет возможность выбирать точность диагностики ошибок приёма соразмерно с условиями соревнования.
Спасибо всем, кто вернулся в тему форума и помог советом...