Ну так направленный перебор. Грубо говоря, чем это принципиально отличается от того, что мы генетическими алгоритмами условными будем пруф на лине искать?
А программируют обычно не перебором "пока тесты не сойдуться".
Увы, кажется современные модели не умеют использовать такую структурированную информацию. Пока мы свернули на дорожку, где всю семантику выбросили, оставили только текст да grep.
Хотя, кмк, как минимум для edit prediction подход через семантику и умный extraction из миниатюрной (локальной) модели — более жизнеспособен, чем то чудо, которое предлагают сейчас.
Этот предел является вычислимым числом. Хотя и не факт что рациональным. Как и значение функции в этой предельной точке (оно равно нулю). Поэтому эта теорема верна в конструктивной математике (о которой речь в этом среде)
Двояко. В процессе проверки гипотез часто находиться много нового. Чтоьы отвергнуть гипотезу, нужно что-то понять про задачу. И так далее.
Когла опровергают какие-то гипотезы через контрпример, сам контрпример выглядит взятым с потолка. Но на самом же деле, чтобы этот контрпример построить, нужно довольно хорошее понимание, почему эта гипотеза ложна, чего ей не хватает.
... причем в исходной модели есть на данном интервале, когда исходная модель не определена
Не очень понимаю, к чему это. Я не говорю, что Ваш метод плохой сам по себе. Я лишь говорю, что он не решает проблемы, которую Вы же сами и обозначили: как нарисовать кривую на компьютере.
Точнее сказать, в данном конкретном случае он её решает, но это вопрос чисто совпадения, а не общей закономерности. В общем случае нужно идти через анализ кривой, как я писал выше.
P.S. ну неопределена и неопределена — это же исходная постановка задачи. Если она так исходно была поставлена, значит скорее всего, это никого особо не волнует.
Вообще говоря, конечная формула более подвержена погрешностям, чем исходный вариант. Банальнопрям классический кандидат на catastrophic cancellation. С другой стороны, косинус можно посчитать довольно точно. С корнем, конечно, будет потеря точности, но он в обоих вариантах присутствует. И разумеется потеря точности с корнем не такая сильная, как в случае catastrophic cancellation.
Реальная причина, почему график стал лучше в том, что Вы разбили кривую на два лепестка. У кривой есть особая точка в (0, 0) и по сути Вы искусственно добавили контрольную точку, чтобы корректно обработать эту особенность.
Аналогичного результата можно добиться если в исходном подходе просто к списку точек взять и добавить точки.
И это собственно показывает путь к рисованию произвольных кривых. Вместо того, чтобы искать какую-то специфичную параметризацию, нужно искать особые точки: экстремумы, точки перегиба, самопересечения и прочее. И дальше рисовать сегменты между особыми точками наивным подходом.
Не очень понятна мотивация статьи и аппроксимации. Такая аппроксимация не особо лучше чем просто константа. Она работает исключительно потому, что Гауссов интеграл сходится невероятно быстро.
Но никому особо не нужна аппроксимация вида, гдемало. Обычно нужна аппроксимация вида гдемало. И со вторым Ваша аппроксимация вряд ли справится, по очевидным причинам.
Если же нужна грубая аппроксимация, то проще просто аппроксимировать константой при хоть сколько-то значимых значениях x.
Не очень понятно зачем. Выглядит так, будто нужно ручками следить за жизненным циклом. Но тогда можно и ручками дёргать createRoot/render/unmount.
Имело бы смысл, если бы библиотеку один раз можно было повесить на странице, и дальше она бы сама следила за добавлением и уничтожением узлов. В таком виде это имеет больше смысла.
Вообще вопрос проверки ассимптотики в тестах довольно важен и мало освещён. Хотя соглашусь, что пример в статье довольно неудачен.
На эту тему есть интересные тесты в rust-analyzer: раз, два. Они собирают статистику времени исполнения из 5-10 разных размеров для входа. На этой статистике строят регрессии. И если регрессия не выглядит линейной — тест считается упавшим (чуть сложнее, но суть такая).
Задача не найти ошибку, а угадать, куда указал анализатор. И анализатор не всегда указывает на место ошибки — вместо этого он указывает на "подозрительное место". Это не одно и то же.
А здесь довольно много разных факторов. Перечислю их безотносительно их критичности.
Для начала встаёт вопрос а что именно шифровать. Шифровать всё затея не лучшая (и непонятно что делать с джоинами). В идеале шифровать только собственно пд. Но тогда проблема в том, что пользователи любят указывать свои пд в условных комментариях или описаниях.
Дальше вопрос а как часто эти пд расшифровуются. Если на каждый запрос, то встаёт риск, что они куда-нибудь утекут после расшифровки: в логи, при ошибке, в другой микросервис, во внешнюю систему, в отчёт и прочее. Чтобы их расшифровывать пореже нужно аккуратно понять, а что именно шифровать, что нет. И дальше нужно очень аккуратно писать код, чтобы он мог работать с шифрованными данными.
Аналогичный вопрос, что с пд происходит до шифрования. Здесь тоже полно мест для утечки.
Ну и сама работа с ключами тоже весёлая. Ключи могут утечь из памяти в своп или кордамп. ВМ могут заснапшотить с памятью — тогда ключи можно достать из снапшота. К счастью, в логи обычно ключи не пишут (хотя бывает =().
Плюс ключи ведь нужно где-то хранить, в отдельном микросервисе например. И этот микросервис тоже нужно бэкапить. В нём тоже нужно как-то реализовывать физическое удаление и всё прочее.
С бэкапами тоже интересно. По-хорошему бэкапы должны быть иммутабельными и храниться где-нибудь отдельно. В частности их могут хранить на каком-нибудь (внешнем) s3 — а как оно там мутируется и удаляется никто не знает. Ну и при мутации бэкапов есть риск сломать его...
Здесь также есть всякая экзотика, что даже перезапись данных нулями не гарантирует их полного удаления. WAL может довольно долго не транкатиться (особенно в условном mssql). Есть всякие CoW фс по типу btrfs, которые при перезаписе создадут копию. А при прямом доступе к диску, бывает можно восстановить часть данных даже после перезаписи. Например всякий page redirect на ssd.
Короче говоря, рисков очень много разных. И самый главный вопрос: "а оно Вам надо"? ** Чаще всего удаление ПД подразумевает "к данным нельзя обратиться штатными средствами и они не используются при штатной обработке". В частности, формально даже soft delete является корректной мерой. Поэтому меры против такой вот археологии нужно отдельно обосновывать в рамках Вашей модели угроз.
**не является юридическим советом, проконсультируйтесь с юристом.
P.S. Я уже не говорю о том что шифрование, а тем более шифрование в бд довольно сложное (легко сделать неправильно). Многие программисты могут просто захардкодить ключ шифрования...
secure_delete это миф. И даже шифрование не всегда спасает. Если вам реально важно удаление пд, то это большая инженерная и аналитическая работа. Никаких волшебных палочек здесь нет.
Разделение моделей "Шаблон" и "Событие": Диапазоны идеальны для сущности Booking (где есть конкретная привязка к календарной дате). Но они плохо подходят для таблицы базового расписания (resource_availability_intervals), которая хранит циклические правила: “каждый понедельник с 09:00 до 13:00”. Хранить расписание в виде tstzrange заставило бы нас заниматься бесконечной генерацией (seeding) явных диапазонов на годы вперед для каждого ресурса, что раздуло бы БД. А скрещивать циклический LocalTime с tstzrange в рамках одного запроса — сомнительное удовольствие.
У Вас все запросы сравнивают колонку в бд с параметрами запроса. Там концептуально джоины по tsrange в бд делать никогда не нужно. А если их и делать, то это будет больно в любом формате хранения =/ Поэтому, кмк, эта причина не очень обоснована.
Вендоронезависимость (Vendor Lock-in): Типы range — это крутая, но чисто «постгресовая» фича. Использование стандартных типов позволяет при необходимости мигрировать b2b-платформу на любой другой диалект (MS SQL, MySQL, Oracle) силами изменения одной строки в конфиге.
На моём опыте, любая система с более менее нормальной нагрузкой гвоздями прибита к конкретной бд. Иногда бывает пара субд - но это отдельная, довольно большая инженерная работа.
Чтобы "поменять строку в конфиге" и оно запустилось на другой субд - такое не встречается. Обычно там либо баги всякие странные начинают лезть, либо производительность просаживается. Банально, в том же postgresql и ms sql разные подходы к блокировкам и конкуретности - ms sql может чаще выдавать LOCK_ERROR чем postgresql (и это нужно будет обрабатывать в приложении).
Ну и планировщики у субд сильно разные. Поэтому обычно под разные субд нужно писать разные запросы с разными индексами. Иначе производительность обычно получается довольно скудная.
Поэтому эта причина тоже кмк не обоснована.
И единственная причина, почему можно согласиться - это поддержка в hibernate.
Не совсем, -2^2 = -4 (mod 8). Впрочем, я не уверен, на какую часть статьи отсылка: там где ещё в целых, или уже в mod 8 считали.
Ну так направленный перебор. Грубо говоря, чем это принципиально отличается от того, что мы генетическими алгоритмами условными будем пруф на лине искать?
А программируют обычно не перебором "пока тесты не сойдуться".
Не, там как раз проблема, что в текущие модели, насколько мне известно, вся эта умная штука встраивается крайне плохо. Для неё нужны другие модели
А, понятно. Было такое подозрение. То есть измеряют тангенс по сути...
Увы, кажется современные модели не умеют использовать такую структурированную информацию. Пока мы свернули на дорожку, где всю семантику выбросили, оставили только текст да grep.
Хотя, кмк, как минимум для edit prediction подход через семантику и умный extraction из миниатюрной (локальной) модели — более жизнеспособен, чем то чудо, которое предлагают сейчас.
Если дистанция меряется как перемещение центра велосипеда, то здесь же буквально 5% и есть синус угла, разве нет? (как в рациональной тригонометрии)
А что это как не перебор?
Если функция вычислима, и конструктивно непрерывна, то хоть одна точка пересечения нуля является вычислимой.
Этот предел является вычислимым числом. Хотя и не факт что рациональным. Как и значение функции в этой предельной точке (оно равно нулю). Поэтому эта теорема верна в конструктивной математике (о которой речь в этом среде)
Двояко. В процессе проверки гипотез часто находиться много нового. Чтоьы отвергнуть гипотезу, нужно что-то понять про задачу. И так далее.
Когла опровергают какие-то гипотезы через контрпример, сам контрпример выглядит взятым с потолка. Но на самом же деле, чтобы этот контрпример построить, нужно довольно хорошее понимание, почему эта гипотеза ложна, чего ей не хватает.
Нет, такая запись не используется. Традиционный способ записать подобное высказывание выглядит как-то так:
Всё же, предел, это число. Для "равенств в пределе" используют символику Ландау.
Не очень понимаю, к чему это. Я не говорю, что Ваш метод плохой сам по себе. Я лишь говорю, что он не решает проблемы, которую Вы же сами и обозначили: как нарисовать кривую на компьютере.
Точнее сказать, в данном конкретном случае он её решает, но это вопрос чисто совпадения, а не общей закономерности. В общем случае нужно идти через анализ кривой, как я писал выше.
P.S. ну неопределена и неопределена — это же исходная постановка задачи. Если она так исходно была поставлена, значит скорее всего, это никого особо не волнует.
Вообще говоря, конечная формула более подвержена погрешностям, чем исходный вариант. Банально
прям классический кандидат на catastrophic cancellation. С другой стороны, косинус можно посчитать довольно точно. С корнем, конечно, будет потеря точности, но он в обоих вариантах присутствует. И разумеется потеря точности с корнем не такая сильная, как в случае catastrophic cancellation.
Реальная причина, почему график стал лучше в том, что Вы разбили кривую на два лепестка. У кривой есть особая точка в (0, 0) и по сути Вы искусственно добавили контрольную точку, чтобы корректно обработать эту особенность.
Аналогичного результата можно добиться если в исходном подходе просто к списку точек взять и добавить точки
.
И это собственно показывает путь к рисованию произвольных кривых. Вместо того, чтобы искать какую-то специфичную параметризацию, нужно искать особые точки: экстремумы, точки перегиба, самопересечения и прочее. И дальше рисовать сегменты между особыми точками наивным подходом.
Не очень понятна мотивация статьи и аппроксимации. Такая аппроксимация не особо лучше чем просто константа. Она работает исключительно потому, что Гауссов интеграл сходится невероятно быстро.
Но никому особо не нужна аппроксимация вида
, где
мало. Обычно нужна аппроксимация вида
где
мало. И со вторым Ваша аппроксимация вряд ли справится, по очевидным причинам.
Если же нужна грубая аппроксимация, то проще просто аппроксимировать константой при хоть сколько-то значимых значениях x.
Не очень понятно зачем. Выглядит так, будто нужно ручками следить за жизненным циклом. Но тогда можно и ручками дёргать createRoot/render/unmount.
Имело бы смысл, если бы библиотеку один раз можно было повесить на странице, и дальше она бы сама следила за добавлением и уничтожением узлов. В таком виде это имеет больше смысла.
Вообще вопрос проверки ассимптотики в тестах довольно важен и мало освещён. Хотя соглашусь, что пример в статье довольно неудачен.
На эту тему есть интересные тесты в rust-analyzer: раз, два. Они собирают статистику времени исполнения из 5-10 разных размеров для входа. На этой статистике строят регрессии. И если регрессия не выглядит линейной — тест считается упавшим (чуть сложнее, но суть такая).
Edit: хабр съел первый абзац =/
Задача не найти ошибку, а угадать, куда указал анализатор. И анализатор не всегда указывает на место ошибки — вместо этого он указывает на "подозрительное место". Это не одно и то же.
А здесь довольно много разных факторов. Перечислю их безотносительно их критичности.
Для начала встаёт вопрос а что именно шифровать. Шифровать всё затея не лучшая (и непонятно что делать с джоинами). В идеале шифровать только собственно пд. Но тогда проблема в том, что пользователи любят указывать свои пд в условных комментариях или описаниях.
Дальше вопрос а как часто эти пд расшифровуются. Если на каждый запрос, то встаёт риск, что они куда-нибудь утекут после расшифровки: в логи, при ошибке, в другой микросервис, во внешнюю систему, в отчёт и прочее. Чтобы их расшифровывать пореже нужно аккуратно понять, а что именно шифровать, что нет. И дальше нужно очень аккуратно писать код, чтобы он мог работать с шифрованными данными.
Аналогичный вопрос, что с пд происходит до шифрования. Здесь тоже полно мест для утечки.
Ну и сама работа с ключами тоже весёлая. Ключи могут утечь из памяти в своп или кордамп. ВМ могут заснапшотить с памятью — тогда ключи можно достать из снапшота. К счастью, в логи обычно ключи не пишут (хотя бывает =().
Плюс ключи ведь нужно где-то хранить, в отдельном микросервисе например. И этот микросервис тоже нужно бэкапить. В нём тоже нужно как-то реализовывать физическое удаление и всё прочее.
С бэкапами тоже интересно. По-хорошему бэкапы должны быть иммутабельными и храниться где-нибудь отдельно. В частности их могут хранить на каком-нибудь (внешнем) s3 — а как оно там мутируется и удаляется никто не знает. Ну и при мутации бэкапов есть риск сломать его...
Здесь также есть всякая экзотика, что даже перезапись данных нулями не гарантирует их полного удаления. WAL может довольно долго не транкатиться (особенно в условном mssql). Есть всякие CoW фс по типу btrfs, которые при перезаписе создадут копию. А при прямом доступе к диску, бывает можно восстановить часть данных даже после перезаписи. Например всякий page redirect на ssd.
Короче говоря, рисков очень много разных. И самый главный вопрос: "а оно Вам надо"? ** Чаще всего удаление ПД подразумевает "к данным нельзя обратиться штатными средствами и они не используются при штатной обработке". В частности, формально даже soft delete является корректной мерой. Поэтому меры против такой вот археологии нужно отдельно обосновывать в рамках Вашей модели угроз.
**не является юридическим советом, проконсультируйтесь с юристом.
P.S. Я уже не говорю о том что шифрование, а тем более шифрование в бд довольно сложное (легко сделать неправильно). Многие программисты могут просто захардкодить ключ шифрования...
secure_delete это миф. И даже шифрование не всегда спасает. Если вам реально важно удаление пд, то это большая инженерная и аналитическая работа. Никаких волшебных палочек здесь нет.
У Вас все запросы сравнивают колонку в бд с параметрами запроса. Там концептуально джоины по tsrange в бд делать никогда не нужно. А если их и делать, то это будет больно в любом формате хранения =/
Поэтому, кмк, эта причина не очень обоснована.
На моём опыте, любая система с более менее нормальной нагрузкой гвоздями прибита к конкретной бд. Иногда бывает пара субд - но это отдельная, довольно большая инженерная работа.
Чтобы "поменять строку в конфиге" и оно запустилось на другой субд - такое не встречается. Обычно там либо баги всякие странные начинают лезть, либо производительность просаживается. Банально, в том же postgresql и ms sql разные подходы к блокировкам и конкуретности - ms sql может чаще выдавать LOCK_ERROR чем postgresql (и это нужно будет обрабатывать в приложении).
Ну и планировщики у субд сильно разные. Поэтому обычно под разные субд нужно писать разные запросы с разными индексами. Иначе производительность обычно получается довольно скудная.
Поэтому эта причина тоже кмк не обоснована.
И единственная причина, почему можно согласиться - это поддержка в hibernate.