Например, on-prem виртуальное железо для dev (!) с ресурсами почти как в ноутбуке младшего помощника бухгалтера оценено в 2,5 ляма.
С другой стороны - железо посчитано только "за сервера". А тут вроде минимум на пару стоек: надо уже инфраструктуру так или иначе просчитывать.
Или вот строчка: "24 x 1.6 TB SAS12G SSD MixedUse RAID0". Я даже не знаю... А почему не отдельный SAN? А почему RAID0? А почему именно такие SSD?
Почему надо все сервера сразу ставить?
А почему именно Arenadata DB и почему больше ничего? Ни ETL, ни какой другой интеграции, ни уровня приложений. Останутся ли выводы в силе если посчитать проект целиком?
Без конкретной задачи и стратегии сложно сказать, что лучше подойдёт - облако или своёродное, но точно можно сказать, что принимать решение по такой статье - хуже.
У меня сын в 6 классе, увлекается математикой и программированием и иногда мы из интереса пробуем заставить решить задачи с олимпиад (после этих олимпиад, конечно). Какие-то совсем простые и очевидные с простых олимпиад - решаются. В решении много воды и лишнего, но в целом можно засчитать. Сложные задачи с простых олимпиад (ну типа московского матпраздника и подобный уровень) - можно получить правильный ответ, но скорее всего будет неправильное или неполное решение. Причем три нейросетки дадут три разных ответа, если повезёт - один правильный. Но польза тут может быть такая: обычно есть решение "своё", есть решение "от автора", а нейросети могут подсказать еще один путь. Но идти этим путём придётся самому. На более сложных задачах (уровень региона или олимпиада Эйлера или подобные) - просто мусор. Deepseek еще и часто "зацикливается" в своих рассуждениях. Геометрию и логические рассуждения часто сливает даже на простых задачах. Задачи из домашних заданий по олимпиадной математике - сливает (простые решаются в классе, а на дом остаётся на "погрызть гранит").
А еще у меня жена преподаёт в вузе, так вот сейчас стали часто пытаться решения контрольных сделать через нейросети. Такие решения всегда видны (вода, лишние пункты, лишние и неверные рассуждения, отсылка к фактам, которых не было в курсе, решение принципиально другим способом) и очень часто не верны.
По олимпиадному программированию ситуация похожая, но за счет автоматизации проверки и петель обратной связи (это не просто скармливание задачи чату) в принципе получается решить относительно сложные задачи. Но тоже есть много случаев, когда нейросети делают ерунду, например, если задача похожа на классическую, но другая. Задачи регионального этапа нейросети решили хуже шестиклассника, который даже не стал призёром.
Совет: Если вот прям эту статью или хотя бы ссылку (но это не надёжно) положить в README.md репозитория, то через пару-тройку лет будет проще вспомнить "што эта за скрипт-а-а-а" :) А скрипт querypig.ps1 наоборот, кажется, можно убрать (по крайней мере для этой задачи).
Т.е. типа раз дерево сбалансированное (а оно такое), то взять лимитом логарифм с хвостиком и при его достижении в глубину сказать "лапки"? Тогда да, хранимых счётчиков избежим.
Проблема не вывести формулу. Проблема написать код. Это лишь кажется, что явную формулу проще написать, чем численный метод. Дихотомию, вон, мой сын шестикклассник на "олимпиадном C++" или на Python напишет, я в 9 классе и выше точно мог метод секущих написать (знаю, потому что писал), в выпускном классе Ньютона мог. А вот написать явную формулу (в BASIC-коде) для корня при отрицательном дискриминанте уже совсем не так просто. (Дата рождения в профиле есть)
Ну да, ну да, я очень плохо их себе представляю. :) На самом деле, конечно, представляю: пусть сам я даже на зональные не прошёл, да и число пи помнил только до 80-го знака (сейчас уже до 40 знаков еле вспомню), но участников всероссийских и некоторых национальных олимпиад знаю достаточно.
Если заменить задачу, то и решение будет другим. Уверен, что средний участник всесоюзной олимпиады на память написать формулы Кардано и корректно запрограммировать их не смог бы. Там кроме очевидной проблемы - помнить алгоритм и формулы - достаточно относительно небольших, но хлопотных граблей: нужно привести уравнение к каноническому заменой (а потом обратно), возникают квадратные корни из отрицательных чисел (которые потом уходят, но в коде придётся их хранить аккуратно отдельно), нужно кубический корень считать через степень с учетом знака (что-то типа SGN(X)*(ABS(X)^(1/3))). Причем тут же еще такой момент: 1988 год, компьютеров еще почти нигде и никаких нет. Если хоть какие-то есть, в школе то это уже очень продвинутая школа. И скорее всего это были другие компьютеры, тогда был жуткий зоопарк в школах: ДВК, УКНЦ, БК, Корветы, Агаты и прочее. Ямахи с MSX были крутыми и редкими, BASIC между всеми этими компьютерами отличался, да и писать на нём менее удобно, чем в современных IDE. А численные алгоритмы достаточно простые. Если совсем лень думать, то и дихотомия сойдёт. Чуть сложнее методом секущих (хорд) - но там надо убедиться, что корень не кратный. Еще чуть сложнее (надо еще выражение производной написать) метод Ньютона. Но в любом случае все эти методы пишутся достаточно просто.
Никогда не поверю, что участники всесоюзной олимпиады по математике решали эту «задачу» численно
А в чём проблема считать численно? Если отбросить константную часть с определением границ интервалов и вычислением коэффициентов, то искать корень кубического многочлена даже с дихотомией уйдёт не больше нескольких десятков итераций.
Хм, не знаю, как решали тогда, но я бы попробовал считать так.
Считаем коэффициенты первой и второй производной. Но, да, формулы Кардано я на память не готов воспроизводить, поэтому пойдём другим путём. Нули второй производной дадут нам точки перегиба исходного многочлена и потенциальные экстремумы производной. Отдельно обрабатываем случай 1 корня второй производной и отсутствия корней второй производной (расписывать в комментарии лень). Один из нулей первой производной будет между точками перегиба (пусть это x1 и x2). Из исходного многочлена нетрудно найти такие x0 и x3, что все экстремумы будут лежать в этих границах (как только x^4 становится больше остальной части многочлена). Искать можно как в лоб по формулам, так и просто удвоением шага. Теперь, считая, что мы уже разобрали особые случаи, у нас нули первой производной между точками x0, x1, x2, x3. Всего 3 интервала. Можно считать в лоб дихотомией - даже сейчас не более 64 итераций на каждый (около 10 FP операций каждая). Т.е. "на круг" можно уложиться условно в тысячи FP операций. Даже на процессоре частотой около 1 миллиона восьмибитных операций в секунду (а в Ямахах был именно такой - Z80, у него частота была около 3 МГц и минимум 4 такта на инструкцию), даже с интерпретируемым BASIC есть все шансы спокойно уложиться в минуту. Если дихотомия лишком долго, то можно по-быстрому метод Ньютона или метод секущих запилить - они сходятся быстрее. За два часа любое из этих решений вроде посильно набрать. Даже на MSX (я как-то больше на Корветах и Спектруме писал, но в целом специфику представляю).
В качестве положительного ориентира я бы назвал YouTube.
Я сильно надеюсь, что этого никогда не случится. У меня (как у читателя и изредко как писателя) есть много пожеланий к Хабру, но я очень не хочу, чтобы Хабр перенимал практики ранжирования у YouTube, и уж точно "архаичная" система ранжирования лучше "напёрстничестка" YouTube.
Там много к чему вопросы возникают.
Например, on-prem виртуальное железо для dev (!) с ресурсами почти как в ноутбуке младшего помощника бухгалтера оценено в 2,5 ляма.
С другой стороны - железо посчитано только "за сервера". А тут вроде минимум на пару стоек: надо уже инфраструктуру так или иначе просчитывать.
Или вот строчка: "24 x 1.6 TB SAS12G SSD MixedUse RAID0". Я даже не знаю... А почему не отдельный SAN? А почему RAID0? А почему именно такие SSD?
Почему надо все сервера сразу ставить?
А почему именно Arenadata DB и почему больше ничего? Ни ETL, ни какой другой интеграции, ни уровня приложений. Останутся ли выводы в силе если посчитать проект целиком?
Без конкретной задачи и стратегии сложно сказать, что лучше подойдёт - облако или своёродное, но точно можно сказать, что принимать решение по такой статье - хуже.
А ситуация нескольких планов к одной строке как обрабатывается? Один из важных плюсов QS - он умеет показывать, какие разные планы были по выражению.
Пока не решает.
У меня сын в 6 классе, увлекается математикой и программированием и иногда мы из интереса пробуем заставить решить задачи с олимпиад (после этих олимпиад, конечно).
Какие-то совсем простые и очевидные с простых олимпиад - решаются. В решении много воды и лишнего, но в целом можно засчитать.
Сложные задачи с простых олимпиад (ну типа московского матпраздника и подобный уровень) - можно получить правильный ответ, но скорее всего будет неправильное или неполное решение. Причем три нейросетки дадут три разных ответа, если повезёт - один правильный. Но польза тут может быть такая: обычно есть решение "своё", есть решение "от автора", а нейросети могут подсказать еще один путь. Но идти этим путём придётся самому.
На более сложных задачах (уровень региона или олимпиада Эйлера или подобные) - просто мусор. Deepseek еще и часто "зацикливается" в своих рассуждениях. Геометрию и логические рассуждения часто сливает даже на простых задачах. Задачи из домашних заданий по олимпиадной математике - сливает (простые решаются в классе, а на дом остаётся на "погрызть гранит").
А еще у меня жена преподаёт в вузе, так вот сейчас стали часто пытаться решения контрольных сделать через нейросети. Такие решения всегда видны (вода, лишние пункты, лишние и неверные рассуждения, отсылка к фактам, которых не было в курсе, решение принципиально другим способом) и очень часто не верны.
По олимпиадному программированию ситуация похожая, но за счет автоматизации проверки и петель обратной связи (это не просто скармливание задачи чату) в принципе получается решить относительно сложные задачи. Но тоже есть много случаев, когда нейросети делают ерунду, например, если задача похожа на классическую, но другая. Задачи регионального этапа нейросети решили хуже шестиклассника, который даже не стал призёром.
Совет: Если вот прям эту статью или хотя бы ссылку (но это не надёжно) положить в README.md репозитория, то через пару-тройку лет будет проще вспомнить "што эта за скрипт-а-а-а" :)
А скрипт
querypig.ps1наоборот, кажется, можно убрать (по крайней мере для этой задачи).Хм. Скорее всего быть в обиде на прокуратуру было бы еще одной фатальной ошибкой.
По этой логике надо забрать браузер и командную строку (впрочем, командную строку-то как раз забрали).
Смещение-то есть вроде.
Extended events и Query Store позволяют собрать сильно больше данных, например, типы ожиданий waitstats. Но пример интересный, конечно.
Зачем Borland?
copy con wordle.comТ.е. типа раз дерево сбалансированное (а оно такое), то взять лимитом логарифм с хвостиком и при его достижении в глубину сказать "лапки"? Тогда да, хранимых счётчиков избежим.
А это сработает? Вроде как такие механизмы счётчиков, которые для CME используются сами тоже не защищены от гонки.
Чтобы плитку Windows 8 можно было выкинуть на 30 лет раньше :)
Проблема не вывести формулу. Проблема написать код. Это лишь кажется, что явную формулу проще написать, чем численный метод. Дихотомию, вон, мой сын шестикклассник на "олимпиадном C++" или на Python напишет, я в 9 классе и выше точно мог метод секущих написать (знаю, потому что писал), в выпускном классе Ньютона мог. А вот написать явную формулу (в BASIC-коде) для корня при отрицательном дискриминанте уже совсем не так просто.
(Дата рождения в профиле есть)
Ну да, ну да, я очень плохо их себе представляю. :) На самом деле, конечно, представляю: пусть сам я даже на зональные не прошёл, да и число пи помнил только до 80-го знака (сейчас уже до 40 знаков еле вспомню), но участников всероссийских и некоторых национальных олимпиад знаю достаточно.
Если заменить задачу, то и решение будет другим.
Уверен, что средний участник всесоюзной олимпиады на память написать формулы Кардано и корректно запрограммировать их не смог бы. Там кроме очевидной проблемы - помнить алгоритм и формулы - достаточно относительно небольших, но хлопотных граблей: нужно привести уравнение к каноническому заменой (а потом обратно), возникают квадратные корни из отрицательных чисел (которые потом уходят, но в коде придётся их хранить аккуратно отдельно), нужно кубический корень считать через степень с учетом знака (что-то типа
SGN(X)*(ABS(X)^(1/3))).Причем тут же еще такой момент: 1988 год, компьютеров еще почти нигде и никаких нет. Если хоть какие-то есть, в школе то это уже очень продвинутая школа. И скорее всего это были другие компьютеры, тогда был жуткий зоопарк в школах: ДВК, УКНЦ, БК, Корветы, Агаты и прочее. Ямахи с MSX были крутыми и редкими, BASIC между всеми этими компьютерами отличался, да и писать на нём менее удобно, чем в современных IDE.
А численные алгоритмы достаточно простые. Если совсем лень думать, то и дихотомия сойдёт. Чуть сложнее методом секущих (хорд) - но там надо убедиться, что корень не кратный. Еще чуть сложнее (надо еще выражение производной написать) метод Ньютона. Но в любом случае все эти методы пишутся достаточно просто.
А в чём проблема считать численно? Если отбросить константную часть с определением границ интервалов и вычислением коэффициентов, то искать корень кубического многочлена даже с дихотомией уйдёт не больше нескольких десятков итераций.
Хм, не знаю, как решали тогда, но я бы попробовал считать так.
Считаем коэффициенты первой и второй производной. Но, да, формулы Кардано я на память не готов воспроизводить, поэтому пойдём другим путём.
Нули второй производной дадут нам точки перегиба исходного многочлена и потенциальные экстремумы производной. Отдельно обрабатываем случай 1 корня второй производной и отсутствия корней второй производной (расписывать в комментарии лень). Один из нулей первой производной будет между точками перегиба (пусть это x1 и x2).
Из исходного многочлена нетрудно найти такие x0 и x3, что все экстремумы будут лежать в этих границах (как только x^4 становится больше остальной части многочлена). Искать можно как в лоб по формулам, так и просто удвоением шага.
Теперь, считая, что мы уже разобрали особые случаи, у нас нули первой производной между точками x0, x1, x2, x3. Всего 3 интервала. Можно считать в лоб дихотомией - даже сейчас не более 64 итераций на каждый (около 10 FP операций каждая). Т.е. "на круг" можно уложиться условно в тысячи FP операций. Даже на процессоре частотой около 1 миллиона восьмибитных операций в секунду (а в Ямахах был именно такой - Z80, у него частота была около 3 МГц и минимум 4 такта на инструкцию), даже с интерпретируемым BASIC есть все шансы спокойно уложиться в минуту.
Если дихотомия лишком долго, то можно по-быстрому метод Ньютона или метод секущих запилить - они сходятся быстрее. За два часа любое из этих решений вроде посильно набрать. Даже на MSX (я как-то больше на Корветах и Спектруме писал, но в целом специфику представляю).
Я сильно надеюсь, что этого никогда не случится. У меня (как у читателя и изредко как писателя) есть много пожеланий к Хабру, но я очень не хочу, чтобы Хабр перенимал практики ранжирования у YouTube, и уж точно "архаичная" система ранжирования лучше "напёрстничестка" YouTube.
Junior++ Max v2.5
В нашей вселенной Йозеф Кнехт стал бы демосценером.