Большие надежды у меня на специализированные смешанные системы. Т.е. например берёте разворачиваете локальную LLM в вашей инфраструктуре, пишете скрипты-обвязки вокруг LLM (ну наверное потом и коммерческие продукты будут с такой обвязкой), и потом LLM вам не просто пишет код; она же его вашим же сборочным скриптом компилирует, читает сообщения об ошибках, правит их, потом запускает это всё на вашем дженкинсе, читает сообщения об ошибках в тестах, правит код... И да, ещё чтобы под это не приходилось отдельное здание датацентра со своей электростанцией строить. Ждём :)
Подождать-то подождём, чего не подождать. Только мне кажется не починят, т.к. ИИ подражает не компилятору, а наоборот, человеку. А для человека ошибки скорее норма, чем исключение. Но да, подождём, посмотрим.
В такой аналогии есть смысл, но всё-таки есть большая разница между компилятором с высокоуровневого языка (сколь угодно высокоуровневого, хоть пролог, хоть хаскель) и LLM как транслятором с "человеческого" языка на ЯВУ. С компилятором ЯВУ вы хотя в деталях и не контролируете машинный код, который будет сгенерирован, но точно знаете, что сгенерированный машинный код делает в точности то что вы описали на ЯВУ (исключения — баги компилятора, которые в последние 30-40 лет большая редкость, или UB в C++, над которым смеются не хуже чем над вайб-кодерами). LLM как транслятор... ну, можно встретить единичные истории, как 60+ лет назад люди писали на фортране, а потом перепроверяли ассемблерный выхлоп, "потому что мало ли что".
С одной стороны да, а с другой стороны, тут что-то наподобие старого-доброго "как правильно задавать вопросы". Если разработчик завален задачами, то он скорее возьмётся за те задачи, в которых ему всё понятно. Особенно большой шанс попасть на игнор, если этот разработчик этому заказчику уже неоднократно объяснял, что именно нужно описывать в постановке задачи, но заказчик продолжает писать задачи вида "сделайте хорошо".
Гм, начнём с вопроса, а что у вас считает count(*)?
В исходном запросе оно у вас посчитает для каждого юзера количество строк во всех связанных таблицах, 30 x 500 x 20 = 300000. Да и соответственно прочие перечисленные агрегатные функции считают среднее / максимум среди этих 300 тыс строк. Для максимума результат от этого не меняется, а вот для среднего, если в реальных данных будет не строго по 30 / 500 / 20 записей на юзера, а колеблющееся количество - среднее значение будет меняться в зависимости от количества соответствующих строк в декартовом произведении (table1 x table2 x table3 where userid = u.id).
В конечном запросе в колонке count для каждого юзера будет 1, и агрегатная функция max будет искать максимум только среди 500 соответствующих строк. Для максимума не важно, но для других агрегатных функций это не эквивалентная замена.
Т.е. в данном случае имеет место не оптимизация, а замена запроса на другой, возвращающий, вообще говоря, другие результаты. Какой из них в вашем приложении более правилен - ещё вопрос.
По-моему, это не новое ощущение. Раньше то же самое ощущение вызывали фотографии со стоков. Но на стоках фотографий хотя и много, но ограниченное количество, плюс они чего-то стоят, поэтому всё-таки часто использовали нестоковые фотографии. Нейросети же явно натренированы в первую очередь именно на содержимом стоков; при их способности компоновать "нос ивана иваныча с усами ивана никитича", получаем нескончаемое количество изображений, по стилистике неотличимых от стоковых.
Если такие штуки нравятся, см. обязательно книку "Конкретная математика" (Грэхем, Кнут, Поташник). Там много такого и около. В частности, ваша формула там это формула 6.11 :)
Обиднее, что опечатки бывают и в оригиналах (и в книгах, и в научных статьях). При этом, бывает что формула приведена с выводом / доказательством, тогда понять, есть ли опечатка и как должно быть правильно — можно, повторив вывод. А бывает что вместо вывода написано классическое "очевидно" или приведена ссылка на библиографическую редкость, которую нигде не найти. Пытаешься считать по формуле — получается ерунда, понятно что в формуле ошибка, но как правильно-то?...
тут кажется произошла путаница понятий "сингулярность" и "горизонт событий". Сингулярность — это место с бесконечным гравитационным потенциалом (грубо говоря, там при вычислении физических параметров по формулам из учебников приходится делить на ноль, поэтому непонятно что там на самом деле происходит). В классической ЧД Шварцшильда сингулярность — это одна точка (центр ЧД). В каких-то моделях вращающихся ЧД сингулярность имеет форму маленького колечка вокруг центра ЧД. И наличие сингулярности — это собственно определяющий признак ЧД. А горизонт расположен довольно далеко от сингулярности (у сверхмассивных ЧД - очень далеко). У вращающихся ЧД с ним происходят всякие интересные вещи. И из общих соображений получается что ЧД можно раскрутить так сильно, что горизонт вообще исчезнет, т.е. эффекта "невозврата из ЧД" вообще не будет. А сингулярность вполне себе останется. Есть предположение, что таких "голых сингулярностей" в природе на самом деле не бывает.
Я вот правда не понял, в статье под "экстремальными ЧД" имеются ввиду ЧД без горизонта ("голые сингулярности") или что-то несколько другое.
– Все вам нужно объяснять?! Газет не читаете? Все звезды!.. Ну? Что звезды?! Что делают? Ну! – Светят, – неуверенно произнес я. – И это – агент! Светят! Ба! Как светят? Ну! Что? И при этом подавал мне знаки веками. – Мигают, – сказал я, ничего на самом деле не понимая. – Какая догадливость! Наконец-то! Мигают! Да! Подмигивают! А когда? Что? Не знаете? Ну естественно! Какой материал мне присылают! Ночью! Мигают, прячутся в темноте! Что это значит? Кто мигает? Кто ночью? Кто трясется? Он ревел, а я чуть не трясся, надеясь, что буря пройдет, но она не проходила. Кашебладе, посиневший, обрюзгший, с покрытой по'том лысиной, гремел на весь кабинет, на все Здание: – А разбегание галактик? Что? Не слышали? Разбегание! Что это значит? Кто-то убегает? Это подозрительно, более того – это признание собственной вины!
Зависит от задач. Во многих задачах важен throughput (самое простое что приходит в голову: файл с тысячами записей нужно обработать во много потоков за минимальное время). В таких случаях правильнее смотреть именно на average time. Но в других задачах, типа того же веба, важно latency. Тогда надо смотреть на процентили: медиану P50 или там P95. Бывает также важно и то и другое, поэтому приходится выводить и avg, и P95.
"более быстрый компьютер глючит быстрее и сильнее" (с) было бородатым бояном в нулевых...
Хорошо, avg может и не меняется, но какое-нибудь stddev уже поменяется :)
Большие надежды у меня на специализированные смешанные системы. Т.е. например берёте разворачиваете локальную LLM в вашей инфраструктуре, пишете скрипты-обвязки вокруг LLM (ну наверное потом и коммерческие продукты будут с такой обвязкой), и потом LLM вам не просто пишет код; она же его вашим же сборочным скриптом компилирует, читает сообщения об ошибках, правит их, потом запускает это всё на вашем дженкинсе, читает сообщения об ошибках в тестах, правит код... И да, ещё чтобы под это не приходилось отдельное здание датацентра со своей электростанцией строить. Ждём :)
Подождать-то подождём, чего не подождать. Только мне кажется не починят, т.к. ИИ подражает не компилятору, а наоборот, человеку. А для человека ошибки скорее норма, чем исключение. Но да, подождём, посмотрим.
В такой аналогии есть смысл, но всё-таки есть большая разница между компилятором с высокоуровневого языка (сколь угодно высокоуровневого, хоть пролог, хоть хаскель) и LLM как транслятором с "человеческого" языка на ЯВУ. С компилятором ЯВУ вы хотя в деталях и не контролируете машинный код, который будет сгенерирован, но точно знаете, что сгенерированный машинный код делает в точности то что вы описали на ЯВУ (исключения — баги компилятора, которые в последние 30-40 лет большая редкость, или UB в C++, над которым смеются не хуже чем над вайб-кодерами). LLM как транслятор... ну, можно встретить единичные истории, как 60+ лет назад люди писали на фортране, а потом перепроверяли ассемблерный выхлоп, "потому что мало ли что".
С одной стороны да, а с другой стороны, тут что-то наподобие старого-доброго "как правильно задавать вопросы". Если разработчик завален задачами, то он скорее возьмётся за те задачи, в которых ему всё понятно. Особенно большой шанс попасть на игнор, если этот разработчик этому заказчику уже неоднократно объяснял, что именно нужно описывать в постановке задачи, но заказчик продолжает писать задачи вида "сделайте хорошо".
Гм, начнём с вопроса, а что у вас считает count(*)?
В исходном запросе оно у вас посчитает для каждого юзера количество строк во всех связанных таблицах, 30 x 500 x 20 = 300000. Да и соответственно прочие перечисленные агрегатные функции считают среднее / максимум среди этих 300 тыс строк. Для максимума результат от этого не меняется, а вот для среднего, если в реальных данных будет не строго по 30 / 500 / 20 записей на юзера, а колеблющееся количество - среднее значение будет меняться в зависимости от количества соответствующих строк в декартовом произведении (table1 x table2 x table3 where userid = u.id).
В конечном запросе в колонке count для каждого юзера будет 1, и агрегатная функция max будет искать максимум только среди 500 соответствующих строк. Для максимума не важно, но для других агрегатных функций это не эквивалентная замена.
Т.е. в данном случае имеет место не оптимизация, а замена запроса на другой, возвращающий, вообще говоря, другие результаты. Какой из них в вашем приложении более правилен - ещё вопрос.
Чип вполне себе изнашивается чисто механически (контактные площадки стираются и загрязняются).
Боюсь, для предотвращения таких штук нужно оборудование примерно из разряда tardis...
По-моему, это не новое ощущение. Раньше то же самое ощущение вызывали фотографии со стоков. Но на стоках фотографий хотя и много, но ограниченное количество, плюс они чего-то стоят, поэтому всё-таки часто использовали нестоковые фотографии. Нейросети же явно натренированы в первую очередь именно на содержимом стоков; при их способности компоновать "нос ивана иваныча с усами ивана никитича", получаем нескончаемое количество изображений, по стилистике неотличимых от стоковых.
Если такие штуки нравятся, см. обязательно книку "Конкретная математика" (Грэхем, Кнут, Поташник). Там много такого и около. В частности, ваша формула там это формула 6.11 :)
а как же задача про яйцо, бросаемое из окна небоскрёба!?
;)
Эта база ведь прибавляется и к xmin, и к xmax всех туплов на этой странице?
А если разница между xmin и xmax туплов на одной странице вдруг станут отличаться больше чем на 4млрд? :) понятно что маловероятная ситуация...
Ошибки в формулах в переводе — это ещё ладно.
Обиднее, что опечатки бывают и в оригиналах (и в книгах, и в научных статьях). При этом, бывает что формула приведена с выводом / доказательством, тогда понять, есть ли опечатка и как должно быть правильно — можно, повторив вывод. А бывает что вместо вывода написано классическое "очевидно" или приведена ссылка на библиографическую редкость, которую нигде не найти. Пытаешься считать по формуле — получается ерунда, понятно что в формуле ошибка, но как правильно-то?...
тут кажется произошла путаница понятий "сингулярность" и "горизонт событий". Сингулярность — это место с бесконечным гравитационным потенциалом (грубо говоря, там при вычислении физических параметров по формулам из учебников приходится делить на ноль, поэтому непонятно что там на самом деле происходит). В классической ЧД Шварцшильда сингулярность — это одна точка (центр ЧД). В каких-то моделях вращающихся ЧД сингулярность имеет форму маленького колечка вокруг центра ЧД. И наличие сингулярности — это собственно определяющий признак ЧД. А горизонт расположен довольно далеко от сингулярности (у сверхмассивных ЧД - очень далеко). У вращающихся ЧД с ним происходят всякие интересные вещи. И из общих соображений получается что ЧД можно раскрутить так сильно, что горизонт вообще исчезнет, т.е. эффекта "невозврата из ЧД" вообще не будет. А сингулярность вполне себе останется. Есть предположение, что таких "голых сингулярностей" в природе на самом деле не бывает.
Я вот правда не понял, в статье под "экстремальными ЧД" имеются ввиду ЧД без горизонта ("голые сингулярности") или что-то несколько другое.
// ненастоящий сварщик^Wфизик
у таких людей должность часто так и называется, "программист". Это который "1С программирую, розетки паяю, принтеры починяю"...
старый мем на скамейке в парке. "но ведь оно работало на моей машине..." — "ладно, будем поставлять всем твою машину в докере"...
все синие?
– Все вам нужно объяснять?! Газет не читаете? Все звезды!.. Ну? Что
звезды?! Что делают? Ну!
– Светят, – неуверенно произнес я.
– И это – агент! Светят! Ба! Как светят? Ну! Что?
И при этом подавал мне знаки веками.
– Мигают, – сказал я, ничего на самом деле не понимая.
– Какая догадливость! Наконец-то! Мигают! Да! Подмигивают! А когда?
Что? Не знаете? Ну естественно! Какой материал мне присылают! Ночью!
Мигают, прячутся в темноте! Что это значит? Кто мигает? Кто ночью? Кто
трясется?
Он ревел, а я чуть не трясся, надеясь, что буря пройдет, но она не
проходила. Кашебладе, посиневший, обрюзгший, с покрытой по'том
лысиной, гремел на весь кабинет, на все Здание:
– А разбегание галактик? Что? Не слышали? Разбегание! Что это значит?
Кто-то убегает? Это подозрительно, более того – это признание
собственной вины!
Зависит от задач. Во многих задачах важен throughput (самое простое что приходит в голову: файл с тысячами записей нужно обработать во много потоков за минимальное время). В таких случаях правильнее смотреть именно на average time. Но в других задачах, типа того же веба, важно latency. Тогда надо смотреть на процентили: медиану P50 или там P95. Бывает также важно и то и другое, поэтому приходится выводить и avg, и P95.