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

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

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

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


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

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

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

>> о он бы проверял все билеты за 0.5 секунд и остальное время курил.


А зачем? Ты очередной мамкин оптимизатор? Для оптимизации нужные бизнес-основания, функциональные требования и тд, тут просто чувак сделал разовую задачу, пусть хоть на абаке, глубоко насрать

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

Ну вот ТС пишет что не успевал проверять онлайн, так бы успевал.

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

Зачем? Реальной проблемы ни для кого не существует, ни для него (он уже получил очевидный результат, еще раз он это уже делать не будет), ни для кого-то другого (никто не будет тянуть его 1с-ный код с гитхаба, ставить себе 1с-платформу и проверять это)

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

Так и не существовало проблемы. Не нужно ни считать ни симулировать, чтобы понимать что на достаточно больших числах любое число билетов будет приводить к минусу. А насколько большому и как быстро - да неважно.


А так ТС говном в говне из говна покопался. Но молодец что применил навык "парсить".

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

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

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

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

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

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

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

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

Самое простое это хранить билеты в префиксом дереве

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

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

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

Умеет, умеет.

И да, навскидку цифры 12-25 секунд это реально очень много для такой задачи и объема данных.

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

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

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

Ты спросил:

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

Я ответил.

2
Автор поста оценил этот комментарий
Блять... ты красава. Забей хуй на этих (а можно было так, но я сам не буду). Оно сейчас пытается выебнуться уже после всего сделанного, на что у него не встанет
0
Автор поста оценил этот комментарий

Ты лучше мне лотерею напиши, поделюсь пабрацки

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

В 90-е в русском лото в тиражах, помню, продавалось по 5+ миллионов билетов поначалу. На таких объемах данных потестить надо

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

5 миллионов билетов, по 30 номеров (если это лото) - это всего ~150 мегабайт. Ну вообще ни о чём с точки зрения хранения в массиве. Дальше индексный массив по номерам бочёнков - и даже искать в этом массиве ничего не придётся, тупо обращаешься по индексу выпавшего числа ко всем билетам с этим числом и делаешь с ним всё что тебе надо.


P.S: А в 90х не удивлюсь если руками проверяли 😁 Хотя компы тогда уже были.

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

на столе тиражной комиссии один точно стоял, камера на него наводилась и там вылетало окно когда "стоп-игра". и еще было обычно 9 невыпавших бочонков

0
Автор поста оценил этот комментарий
а вдруг свет выключат и все пропало? А так данные сохраняются. 🫡
раскрыть ветку (1)
0
Автор поста оценил этот комментарий

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

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

Поиск по массиву крайне медленный

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

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

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

ну так зачем писать свой алгоритм, если в скл он уже реализован и отточен? Просто чтобы был?
А если выигрышных комбинаций дохренища, а не одна?

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

В СКЛ нет никаких реализованных и отточенных алгоритмов, они все в запросах, которые пишет программист.

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

серьезно? :-D ну тогда дальше можно не разговаривать

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

О чём не разговаривать? А что не так? Правильно plMex отписал. База - набор релятивистских табличек с плюшками типа хранимых процедур. С любого языка (1С, жаба, удав итд через агента идёт запрос). От уровня его написавшего зависит скорость ответа от базы. Уважаемый, вы точно в теме?

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

С удовольствием послушаю какой алгоритм SQL проверяет билеты русского лото на совпадение выпавшего числа...

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

Вы не в курсе? В каждую версию скуля уже лет 5 как встроен наёб ответа по запросу о выигрышных билетах. Это же азы. Сам бил Гейтс написал хранимую процедурку. Оракул тоже в теме если что

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

Не, задачка очень простая. На sql могу скрипт накидать минут за 10. И работать на таких объемах будет моментально на самом захудалом сервере.

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

Лови готовый

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

FROM ARMENIANLOTOMEGABASE as analbase

WHERE analbase.LOSHARAWIN = TRUE

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

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

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

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

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

Жму руку. Реально. Но как же не обосрать 1Сников, - это ж святое.

2
Автор поста оценил этот комментарий
Так перепиши, раз все так просто.
1
Автор поста оценил этот комментарий

Вы просто не умеете в 1С. И да - на c++ или даже питоне будет быстрее. Но тут вопрос к скулю, - а на чём вы это пишете - дело стодесятое.

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

например C++

А чо не асм сразу? ;-)

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

Если очень хочешь - можешь на асм. Но это извращение.

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

Сам ты извращение, я этим жил когда-то ;-)

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

Писал на асме обработки огромных массивов данных?.. А зачем?

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

Зависит от того что на сервере. Если там идиотская схема "введите номер билета, а мы скажем выиграл он или нет" - это один вариант. Там только многопоточность и большие мощности нужны, потому что ему надо за короткое время сверить некий резуьтат с пулом имеющихся билетов.
Если же сервер выдает в течение 20 минут все выигрышные номера/комбинации, то надо просто записывать их реалтайм, а потом отедльно сверять выиграл или нет.

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

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

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

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

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

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

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

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

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

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

БД скорей для хранения большого набора структурированных данных. Миллионы билетов из цифр можно хранить в обычном бинарном формате и никакая БД не нужна.


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

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млн билетов.

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

Для 100500 (если это не была метафора), будет в 50 раз быстрее все, т.е. даже самым тупым способом за 2 секунды обработаются все бочонки

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

Спасибо.

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

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

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

Ну с битовыми масками точно будет быстрее)

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

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

Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку

Темы

Политика

Теги

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

Сообщества

18+

Теги

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

Сообщества

Игры

Теги

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

Сообщества

Юмор

Теги

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

Сообщества

Отношения

Теги

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

Сообщества

Здоровье

Теги

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

Сообщества

Путешествия

Теги

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

Сообщества

Спорт

Теги

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

Сообщества

Хобби

Теги

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

Сообщества

Сервис

Теги

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

Сообщества

Природа

Теги

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

Сообщества

Бизнес

Теги

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

Сообщества

Транспорт

Теги

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

Сообщества

Общение

Теги

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

Сообщества

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

Теги

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

Сообщества

Наука

Теги

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

Сообщества

IT

Теги

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

Сообщества

Животные

Теги

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

Сообщества

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

Теги

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

Сообщества

Экономика

Теги

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

Сообщества

Кулинария

Теги

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

Сообщества

История

Теги

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

Сообщества