6014

Продолжение поста «Сколько выиграют 100500 билетов известной российской лотереи?»4

Провел свой эксперимент. Давайте еще раз проговорим в чем он заключался.

1. Я не покупал эти билеты - я спарсил их. Это как зайти на сайт лотереи и выписать все билеты. Но программисты ленивые (привет ЛЛ) и поэтому я написал программу, которая их выписала за меня.

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

3. Я хочу посмотреть имеет ли смысл покупать больше билетов, чтобы увеличить шанс выиграть.

Я спарсил 100500 билетов, что эквивалентно 15+ млн. рублей. Проверил их в очередном розыгрыше, посчитал солько бы выиграл, если бы реально их купил.

В первом туре не выиграл ни один билет, как во втором, третьем и четвертом. А потом как поперло )). И куча билетов оказались выиграшными. И в итоге я бы выиграл 3 702 464 руб, если бы купил все эти билеты. Математика такая: около 25% затраченных средств я вернул бы обратно.

Вывод: Покупать больше билетов не имеет смысла!

Тут все выпавшие бочонки и сколько билетов выиграло на каком из них: https://github.com/oparinpv/stoloto/blob/main/Выпавшие бочонки.xlsx

Тут все билеты, которые могли бы выиграть с номерами и суммами: https://github.com/oparinpv/stoloto/blob/main/Выигравшие билеты.xlsx

Далее пойдет техническая часть. Если вам интересен сам код и проблемы, с которыми я столкнулся при написании кода - читайте далее.

Писал весь код на 1С. Конечно мог писать и на java и на php, но на 1С мне было проще и быстрее. И исходники приложу ниже в виде расширения для 1С.

Проблема №1.

Когда парсишь билеты - сайт отдает примерно 25 000 билетов относительно легко, а дальше начинает отдавать те билеты, которые были ранее. Хотя алгоритм повторяет поведении кнопки "Другие билеты" на сайте. Спустя сутки проблема уходит и опять парсишь 25 000 билетов.

Проблема №2.

Между вытаскиванием бочонков в третьем туре проходит 5-10 сек, а у меня запрос отрабатывал 12-25 сек. на проверку соответствия всех вытащенных бочонков билетам в базе данных. В итоге после 50 бочонков я не успел их проверить в режиме онлайн и пришлось ждать выложенных результатов, чтобы проверить их все. А я проверял всего 100к билетов. Сейчас-то понятно, что там стоит сервер гораздо мощнее моего бука, но как они выходили из этой ситуации в 90-х? Я предполагаю, что там работал целый отдел из 50-100 человек. И все проданные билеты делились между этими людьми. И каждый проверял свой список билетов, вводя выпавший номер в его ЭВМ.

Для тех, кому интересно повторить эксперимент - расширение для 1С, которое парсит, хранит и проверяет результаты: https://github.com/oparinpv/stoloto/blob/main/РусскоеЛото.cfe

Для тех, кто хочет проверить корректность моих подсчетов и/или составить более оптимальный запрос проверки - база данных 1С с билетами, которые я спарсил: https://github.com/oparinpv/stoloto/blob/main/Билеты Столото 18.02.24.dt

3
Автор поста оценил этот комментарий

У тебя просто алгоритмы говно. 100k билетов - ерунда, алгоритм должен отрабатывать мгновенно

раскрыть ветку (1)
8
Автор поста оценил этот комментарий

Напишите ответным постом как надо

показать ответы
2
Автор поста оценил этот комментарий

12 секунд выборка из базы в 100к записей?)))

раскрыть ветку (1)
7
Автор поста оценил этот комментарий

Выборка из таблицы в 3млн. записей. Каждый билет содержит 30 чисел.

показать ответы
74
Автор поста оценил этот комментарий

Интереснее по диапазонам посмотреть:

До 100 рублей - столько-то билетов

от 100 до 500 - столько-то билетов

...

От 100500 мильёнов рублей - 49,5 билетов

раскрыть ветку (1)
23
Автор поста оценил этот комментарий

Это все есть в приложенном файле xlsx

показать ответы
31
Автор поста оценил этот комментарий

Кстати 1с не сильно проигрывает ms sql, т.к. по сути просто преобразует свои запросы в ms sql

Чтобы обработать 100500 билетов по 30 цифр не нужны никакие ms sql. Это всё загоняется в массив в памяти и там же обрабатывается, БД нужна только для хранения билетов до розыгрыша. Если вы проверку билетов осуществляли через запросы к БД по каждому выпавшему номеру, то это многое объясняет. Тогда даже удивительно что успевали проверять так быстро.

раскрыть ветку (1)
13
Автор поста оценил этот комментарий

Ну так напишите ответным постом как надо это делать.

показать ответы
0
Автор поста оценил этот комментарий

Сейчас-то понятно, что там стоит сервер гораздо мощнее моего бука, но как они выходили из этой ситуации в 90-х? Я предполагаю, что там работал целый отдел из 50-100 человек

Нет, там использовалась нормальная БД и нормальные алгоритмы.

Запрос к таблице из 100500 значений, работающий 20 секунд... это 1С, больше сказать нечего.

Там 0.2с - и то долго. Даже для 90х годов. Тупой скан без индексов и кеширования - и тот должен отрабатывать 100к записей менее секунды даже на оборудовании 90х.

раскрыть ветку (1)
2
Автор поста оценил этот комментарий

100к билетов. По 30 чисел в каждом. Итого 3млн записей. И 1с тут не решающий фактор.

Просто сделайте это, а потом критикуйте.

2
Автор поста оценил этот комментарий

Смысл? Эксперимент ты уже провёл, я просто написал как можно оптимизировать процесс, чтобы проверка занимала меньше времени. Я хз умеет ли 1С работать с массивами, но ява и пхп явно умеют.

раскрыть ветку (1)
10
Автор поста оценил этот комментарий

Есть смысл только в том, чтобы сказать как все делают неправильно и только лишь особо одаренным известно как надо?

показать ответы
82
Автор поста оценил этот комментарий

Сейчас-то понятно, что там стоит сервер гораздо мощнее моего бука, но как они выходили из этой ситуации в 90-х?

Очевидно, что не писали программу проверки на 1С, которая любой современный комп низводит до производительности компов 90х годов 😁


Конечно мог писать и на java и на php, но на 1С мне было проще и быстрее.

Если бы код был на нормальном языке (компилирующимся в машинный код, например C++), то он бы проверял все билеты за 0.5 секунд и остальное время курил.

раскрыть ветку (1)
8
Автор поста оценил этот комментарий

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

показать ответы
0
Автор поста оценил этот комментарий

Автор, а какой выигрыш максимальный из 100500 билетов? Можно тоже статистику по сумме сделать?

раскрыть ветку (1)
1
Автор поста оценил этот комментарий
2
Автор поста оценил этот комментарий

"расширение для 1С, которое парсит, хранит и проверяет результаты"


о_0

Мусье знает толк в извращениях...

Стесняюсь спросить, а почему не использовали excel?

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

На других языках - дольше, т.к. надо рисовать интерфейс (1с рисует интерфейс почти сама). В Excel дольше, т.к. надо vba вспоминать и как запросы через odbc драйвер делать.

показать ответы
1
Автор поста оценил этот комментарий

Лови готовый

SELECT analbase.VinTicket as ОхуетьЯВыиграл

FROM ARMENIANLOTOMEGABASE as analbase

WHERE analbase.LOSHARAWIN = TRUE

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Название поля заглавными буквами в запросе? Фу таким быть ))

1
Автор поста оценил этот комментарий

Вам уже написали, хранить все в памяти на время отработки, тут не требуются никакие свойства БД (для обработки). Я не просто рассуждаю, я могу оценивать время работы алгоритма. А если у вас какие-то сомнения, я могу закодить обработку и выложить, тут действительно ничего сложного нет.

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Буду очень признателен, т.к. хотел бы научиться этому. Все время казалось, что путь работы с большим набором данных только через запросы к БД. Что от меня требуется? В каком виде предоставить начальные данные?

показать ответы
0
Автор поста оценил этот комментарий

Ничего не требуется, данные для тестов сгенерировать несложно.


https://gist.github.com/diverru/7b345890164625124dfdc9e4face...


Вот, набросал код. Код с некоторыми упрощениями, но на общую скорость это не повлияет. Например, я считаю только билеты, которые выиграли при зачеркивании всех чисел. Число билетов для примера взял 5млн (теоретически в моем коде они могут повториться, но вероятность ничтожно мала).

Вот что вышло (я там два способа привел, оба не очень быстрые, можно сильно быстрее). И еще стоит учесть, что это python, на c++ было бы еще быстрее. Одно ядро, mac pro m1.


stupid array took: 99.98s, avg per round: 1.12s

bit_array took: 21.44s, avg per round: 0.24s.

Т.е. самый тупой способ на раунд (проверка очередного числа) тратит в среднем 1.1 секунды, немного поумнее - 0.2с. Для 5млн билетов.

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Спасибо.

Кодом действительно в этой задаче быстрее и проще, чем запросом. Переписал на массивы с 89 элементами и вышел из 1 сек. на проверку.

Вряд-ли у 1с получится быстрее.

показать ответы
0
Автор поста оценил этот комментарий
Проблема 2 прямое следствие использования 1с. Асинхронное программирование? Нет не слышали
раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Зачем вот говорить то, что не знаешь.

Есть в 1с фоновые задания. Что дальше?

показать ответы
0
Автор поста оценил этот комментарий

Ну все равно долго, как мне кажется ))

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

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

0
Автор поста оценил этот комментарий

Да тут не обязательно даже компилируемый, у автора работа с БД, где она не нужна и плюс непонятно, какой сам запрос и насколько он оптимизирован.

Так-то вообще можно просто запихнуть билеты в массив, каждый билет - это две битовые маски 1..99 (два поля, для оценки первого тура правда ещё потребуются, но не суть). С каждым выпавшим бочонком просто пробегается по массиву и биты проставляем, это очень быстро. Даже на питоне будет в пределах сотен мс для миллионов билетов. Ну а если вдруг не хватает мощностей, всегда можно тираж на несколько машин поделить.

раскрыть ветку (1)
Автор поста оценил этот комментарий

А как без базы данных хранить билеты и их номера? В целом конечно я тоже так могу рассуждать (не делая этого лично): да там пара запросов с внутренним соединением на 0,5 сек. максимум. Просто автор любит запросы в циклах писать и вообще не знает что такое индексы. А если индекс добавить, так и вообще за 0,2 сек. отработает.

показать ответы

Темы

Политика

Теги

Популярные авторы

Сообщества

18+

Теги

Популярные авторы

Сообщества

Игры

Теги

Популярные авторы

Сообщества

Юмор

Теги

Популярные авторы

Сообщества

Отношения

Теги

Популярные авторы

Сообщества

Здоровье

Теги

Популярные авторы

Сообщества

Путешествия

Теги

Популярные авторы

Сообщества

Спорт

Теги

Популярные авторы

Сообщества

Хобби

Теги

Популярные авторы

Сообщества

Сервис

Теги

Популярные авторы

Сообщества

Природа

Теги

Популярные авторы

Сообщества

Бизнес

Теги

Популярные авторы

Сообщества

Транспорт

Теги

Популярные авторы

Сообщества

Общение

Теги

Популярные авторы

Сообщества

Юриспруденция

Теги

Популярные авторы

Сообщества

Наука

Теги

Популярные авторы

Сообщества

IT

Теги

Популярные авторы

Сообщества

Животные

Теги

Популярные авторы

Сообщества

Кино и сериалы

Теги

Популярные авторы

Сообщества

Экономика

Теги

Популярные авторы

Сообщества

Кулинария

Теги

Популярные авторы

Сообщества

История

Теги

Популярные авторы

Сообщества