1. 80% как минимум мне уже не кажутся чем-то нереальным. (Если я исправлю баги в построителе решения, я ожидаю получить где-то 78%, а если добавить новых фич (сейчас всего 50), то результат тоже может быть неплохой)
2. С другой стороны я считаю, что как минимум половина достижений написанных тут при кроссвалидации покажет другую цифру. (для некоторых моих решений это было справедливо)
3. Я свои решения не кроссвалидировал (исправляюсь, сейчас начну)
4. Но я все-равно уверен в своих цифрах т.к. 75.19% это по тем блокам, что я выкачал, а по словарю words.txt у меня 85%. Т.е. мне стоило бы задуматься, если у меня было бы решение 75%, а на словаре 60%. Значит заменив выборку результат может быть хуже с большой вероятностью.
Итак. Есть две новости.
1.
75.57-75.36 % (Реально если протестировать на большой выборке будет где-то 75%, ИМХО)
59989 байт
Решение подобрано используя OpenCL
2. Решение ломает ЛЮБОЙ скрипт тестирования где-то на 18-й 23-й тысяче запросов.
Воспроизводится на 6.0.0 и на 6.1.0
Ломает в смысле вызов функции приводит к зависанию. Тестовый console.log внутри функции даже не вызывается.
Спустя 2 недели должен сказать, что подход по которому работает данный скрипт тестирования неправильный. Когда я выкачал ~500 Мб выборки с сервера hola я начал замечать, что результаты как-то отличаются от ожидаемых. Еще раз посмотрев комментарии я, кажется, понял откуда у народа берутся такие большие проценты. Ребята, мой вам человеческий совет — очень-очень внимательно смотрите на код, который выдает % успешного распознавания. Это ключевой момент построения хорошего решения.
Если тестировать более правильным скриптом мое 70+% решение превратилось в 62.9%. Благо решений у меня было много, потому я переsubmit'ил одно 70% решение на другое, которое дает уже честные 69.8%. Но даже после этого я не уверен, что методология тестирования у меня правильная. Более того, я не уверен, что она будет совпадать с тем как будут тестировать организаторы.
Новый скрипт выкладывать не буду и объясню почему. ИМХО придумать идею, которая даст хороший процент — не проблема. Более того, большинство годных идей уже и так упомянуты в комментариях. А вот построить рабочее решение — это всё-таки то, за что тут дают деньги. Всё-таки я потратил на это 2 недели свободных вечеров и выходных, потому я, конечно, выложу наработки, но после конкурса.
Проверил. В списке нету слов из words.txt.
Совпадения с моим списком 55012
Различия 614277 (т.е. в 11 раз больше)
Список претендует на то, что он был получен честным способом.
Я уже организаторам говорил «а давайте всё-таки один общий false dataset». Ну вот. Теперь есть как минимум 2 dataset'а, которые отличаются друг от друга.
Получается немного нечестная ситуация. Я имею одну выборку, а другие участники — другую выборку. И тут смотря как кому повезло. А если есть одна выборка на всех, то тут ни у кого нет особых преимуществ.
Присоединяюсь к писавшим выше про список ложных срабатываний. Т.е. должен быть выделен training set и verification set. Это стандарт для задач машинного обучения. Пока я не вижу, чтобы эти выборки были зафиксированы.
У меня получилось решение, которое на диапазоне сидов 0-1000 работало хорошо, расширил диапазон, упало ниже 65%. Тестовый dataset странный предмет, вроде он есть, но на самом деле он бесконечный.
Всё-таки очень нужно чтобы можно было проверить рабочий ли submission на конечной машине. Я уже 2 решения отослал с переоптимизацией от closure compiler. Только сейчас заметил когда ужимал мини-решение.
BTW. Тем временем 60,11% в 683 байта и 82.82% в 62464 байт.
Теоретически существует решение в как минимум 90%. Возможно, даже есть 95%.
Как ни странно, подход не работает. Второе префиксное дерево очень плохо режет. Т.е. почти нет улучшений точности по сравнению с отдельно взятым первым деревом.
2. С другой стороны я считаю, что как минимум половина достижений написанных тут при кроссвалидации покажет другую цифру. (для некоторых моих решений это было справедливо)
3. Я свои решения не кроссвалидировал (исправляюсь, сейчас начну)
4. Но я все-равно уверен в своих цифрах т.к. 75.19% это по тем блокам, что я выкачал, а по словарю words.txt у меня 85%. Т.е. мне стоило бы задуматься, если у меня было бы решение 75%, а на словаре 60%. Значит заменив выборку результат может быть хуже с большой вероятностью.
75.19%
На 8684372 слов время тестирования 03:57:45
Эта скорость еще приемлема для решения?
1.
75.57-75.36 % (Реально если протестировать на большой выборке будет где-то 75%, ИМХО)
59989 байт
Решение подобрано используя OpenCL
2. Решение ломает ЛЮБОЙ скрипт тестирования где-то на 18-й 23-й тысяче запросов.
Воспроизводится на 6.0.0 и на 6.1.0
Ломает в смысле вызов функции приводит к зависанию. Тестовый console.log внутри функции даже не вызывается.
Потому вопрос к организаторам. Как быть?
Т.к. организаторы не делают честный require
Самый минимум 18 байт
module.exports=/!/
Т.к. Регулярка имеет функцию test, то всё пройдет нормально
Так бы можно было запостить решение на 66.978 % в 1714 байт
Или 66.093 % в 979 байт
Если тестировать более правильным скриптом мое 70+% решение превратилось в 62.9%. Благо решений у меня было много, потому я переsubmit'ил одно 70% решение на другое, которое дает уже честные 69.8%. Но даже после этого я не уверен, что методология тестирования у меня правильная. Более того, я не уверен, что она будет совпадать с тем как будут тестировать организаторы.
Новый скрипт выкладывать не буду и объясню почему. ИМХО придумать идею, которая даст хороший процент — не проблема. Более того, большинство годных идей уже и так упомянуты в комментариях. А вот построить рабочее решение — это всё-таки то, за что тут дают деньги. Всё-таки я потратил на это 2 недели свободных вечеров и выходных, потому я, конечно, выложу наработки, но после конкурса.
https://habrahabr.ru/post/267697/#comment_8591149
https://gist.github.com/vird/453a86cf16903c017b060cdd457baf86
Это просто верификатор. 100% выходит где-то в 300 Кб-1 Мб смотря как упаковывать.
626919 — без дубликатов
669289 — с дубликатами
Некоторые по несколько раз, например, overwort
Совпадения с моим списком 55012
Различия 614277 (т.е. в 11 раз больше)
Список претендует на то, что он был получен честным способом.
Я уже организаторам говорил «а давайте всё-таки один общий false dataset». Ну вот. Теперь есть как минимум 2 dataset'а, которые отличаются друг от друга.
У меня получилось решение, которое на диапазоне сидов 0-1000 работало хорошо, расширил диапазон, упало ниже 65%. Тестовый dataset странный предмет, вроде он есть, но на самом деле он бесконечный.
Решение откатил. Качаю dataset по-больше.
BTW. Тем временем 60,11% в 683 байта и 82.82% в 62464 байт.
Теоретически существует решение в как минимум 90%. Возможно, даже есть 95%.
Пользуйтесь.
Решение должно лежать в solution.js
Проверочные данные в validation.json
Сжатый словарь в serialize.gz
node script.js > list
mkdir solution_list
cd solution_list
wget -i ../list
Склеивание результатов, думаю, понятно как реализовать.