Теперь мы хотим вычислить вероятности того, что человек, живущий в каждом из регионов, владеет автомобилем.
в задачах такого рода желательно аккуратно использовать слово "каждый". Из этой формулировки следует, что существует как минимум один человек, живущий в каждом из регионов. Это может существенно повлиять на дальнейшие вычисления.
Затем мы можем вычислить вероятность владения автомобилем в каждом из регионов
ну, ок
Далее мы можем применить формулу Байеса, чтобы вычислить вероятность владения автомобилем в каждом из регионов
вроде, в предыдущем пункте уже выяснили именно это
Таким образом, мы можем сделать вывод, что процент владельцев автомобилей в Регионе 2 выше, чем в других регионах
неправильно - по условиям задачи априорный процент владельцев автомобилей одинаков в регионах 1 и 2 (0,15).
Уважаемому автору лучше в дальнейшем не списывать у Артема Михайлова (я так понимаю, это он заминусовал).
Познавательная статья - можно представить, как работает ВЦИОМ:
"Ну и по моим майским указам, говорить придется обстоятельно и подробно, в первую очередь, для понимания того что происходит хочу обратить внимание, что несмотря на меры поддержки отечественного производителя и серьезные, я бы даже сказал, беспрецедентные успехи в импортозамещении, пока мы по показателю владения автомобилем по каждому отдельному региону не дотягиваем до наших зарубежных партнеров. Как западных, так и в последнее время, восточных, хочу отметить, что говорю не только о ближнем востоке, но и что называется, дальнем. Несмотря на это, и хочу подчеркнуть - мы все это видим, по общему уровню автомобилизации наша страна среди мировых лидеров..."
Вот я и предлагаю посчитать стоимость доставки стиралки вертолетом (хотя бы) из Тикси на остров Котельный.
и сравнить со стоимостью доставки Caterpillar или жилых модулей (хотя бы)...
Такая проблема при любом промышленном строительстве: стоимость обеспечения хороших бытовых условий - доли процента от общей стоимости строительства. Но любому дилетанту она понятна - он может себе представить стоимость стиральной машинки или унитаза, или сушильного шкафа (очень полезная вещь если снег или влажная погода) и решить дорого это или нет. И, конечно же, предложить экономить...
Эта стоимость - на уровне погрешности округления до трех знаков после запятой в общей стоимости строительства объекта такого масштаба.
Ошибаетесь. Перечитайте предыдущие серии цикла.
Ну, может "Бургомистр" != "Бургер". Тогда насчет стиралки ошибся. Остальные факты на фото
В п.3.3. в качестве иллюстрации вы использовали часть схемы реального бизнес-процесса из вашего реального проекта, насколько я понял, проект заключался в автоматизации этого бизнес-процесса:
вот кусок бизнес-процесса в Camunda из нашего реального проекта. Есть в нём дублирование?
вы противопоставили сложность его анализа простоте поиска в IDE.
Если в обычной IDE мы можем довольно легко отыскать дублирование и убрать его, то в визуальном редакторе это сделать невозможно
На мой взгляд, реализации бизнес-логики на любой платформе (неважно, с кодом или без) должно предшествовать ТЗ на АСУ, которое надо согласовывать со всеми участниками в понятном для них виде, например, в BPMN или любом другом.
Таким образом, ваше противопоставление как минимум неочевидное - процесс анализа схемы BPMN происходит на этапе ТЗ и ПСИ, а процесс анализа кода - на этапе реализации и сопровождения.
При модернизации примерно также - сначала ТЗ, пусть на уровне текущего понимания, потом кодирование. По крайней мере, надо к этому стремиться.
Если разработчик без анализа сразу стал реализовывать бизнес-логику, то результат очевиден независимо от выбранного инструмента.
В п.3.3. "Дублирование в «нарисованном»" вы пишете о возможностях текстовых IDE по поиску повторов кода, противопоставляя их визуальному поиску на картинке. Прошу пояснить, в каком виде утверждается ТЗ на подобные бизнес-системы?
Предлагается сразу писать код без согласования логики с "не-программистами"?
это блок мембранный измерительный https://rizur.ru/catalog/silfony/membrany-korobki-i-bloki-membrannye-izmeritelnye-metallicheskie/
полегче, так и до 60 коп. дойти можно...
мне и 35 было норм
а что случилось?
есть версия получше:
Мудрые учатся на чужих ошибках, умные - на своих.
Дураки не ошибаются
(79,78% + 38,81% + 28,17%) - 146% = ~2% !
вы правы, показатели выросли
в задачах такого рода желательно аккуратно использовать слово "каждый". Из этой формулировки следует, что существует как минимум один человек, живущий в каждом из регионов. Это может существенно повлиять на дальнейшие вычисления.
ну, ок
вроде, в предыдущем пункте уже выяснили именно это
неправильно - по условиям задачи априорный процент владельцев автомобилей одинаков в регионах 1 и 2 (0,15).
Уважаемому автору лучше в дальнейшем не списывать у Артема Михайлова (я так понимаю, это он заминусовал).
там не только в этом ошибка, там гипотеза некорректно сформулирована
Познавательная статья - можно представить, как работает ВЦИОМ:
"Ну и по моим майским указам, говорить придется обстоятельно и подробно, в первую очередь, для понимания того что происходит хочу обратить внимание, что несмотря на меры поддержки отечественного производителя и серьезные, я бы даже сказал, беспрецедентные успехи в импортозамещении, пока мы по показателю владения автомобилем по каждому отдельному региону не дотягиваем до наших зарубежных партнеров. Как западных, так и в последнее время, восточных, хочу отметить, что говорю не только о ближнем востоке, но и что называется, дальнем. Несмотря на это, и хочу подчеркнуть - мы все это видим, по общему уровню автомобилизации наша страна среди мировых лидеров..."
какая-то странная арифметика у вашего Байеса
неплохо, FoxPro в свое время был очень популярен...
Признаю Вашу правоту - если бытовые удобства каждый себе обеспечивает сам, то это выходит существенно дороже.
Вы аргументированно показали обоснованность экономии средств работодателя за счет бытовых условий сотрудников.
В статье странная подборка частных случаев.
На все эти pro и contra могут быть такие же ответы: "я пробовал что-то, у меня установилось/не установилось на Win/Linux".
Никто не спорит, что Linux развивается, но отказ от западного ПО такой отказ...
и сравнить со стоимостью доставки Caterpillar или жилых модулей (хотя бы)...
Такая проблема при любом промышленном строительстве: стоимость обеспечения хороших бытовых условий - доли процента от общей стоимости строительства. Но любому дилетанту она понятна - он может себе представить стоимость стиральной машинки или унитаза, или сушильного шкафа (очень полезная вещь если снег или влажная погода) и решить дорого это или нет. И, конечно же, предложить экономить...
Эта стоимость - на уровне погрешности округления до трех знаков после запятой в общей стоимости строительства объекта такого масштаба.
Ну, может "Бургомистр" != "Бургер". Тогда насчет стиралки ошибся. Остальные факты на фото
Не думаю, что таким образом можно существенно сэкономить.
Скорее, просто не озаботились о нормальных условиях для персонала - нормам и правилам соответствует и ОК.
А так - баня "не для всех", стиралка у начальника, сушилка из койки.
Экономия ресурсов, ага.
Думаю, пользователи Битрикс-24 не согласятся с таким категоричным высказыванием.
В п.3.3. в качестве иллюстрации вы использовали часть схемы реального бизнес-процесса из вашего реального проекта, насколько я понял, проект заключался в автоматизации этого бизнес-процесса:
вы противопоставили сложность его анализа простоте поиска в IDE.
На мой взгляд, реализации бизнес-логики на любой платформе (неважно, с кодом или без) должно предшествовать ТЗ на АСУ, которое надо согласовывать со всеми участниками в понятном для них виде, например, в BPMN или любом другом.
Таким образом, ваше противопоставление как минимум неочевидное - процесс анализа схемы BPMN происходит на этапе ТЗ и ПСИ, а процесс анализа кода - на этапе реализации и сопровождения.
При модернизации примерно также - сначала ТЗ, пусть на уровне текущего понимания, потом кодирование. По крайней мере, надо к этому стремиться.
Если разработчик без анализа сразу стал реализовывать бизнес-логику, то результат очевиден независимо от выбранного инструмента.
Еще раз - статья замечательная.
Очень интересная и полезная статья, спасибо.
В п.3.3. "Дублирование в «нарисованном»" вы пишете о возможностях текстовых IDE по поиску повторов кода, противопоставляя их визуальному поиску на картинке. Прошу пояснить, в каком виде утверждается ТЗ на подобные бизнес-системы?
Предлагается сразу писать код без согласования логики с "не-программистами"?
Зачем так экономить на бытовых условиях?
В чем профит?
На мой взгляд, статья - классическая ошибка проектирования.
Преждевременная оптимизация.
ну а реактор-то? Реактор-то видели?