Тоже об этом подумал, но потом понял что это всё ещё недостаточно причина. Можно сделать хешмап со сложностью вставки за— нужно просто делать ресайз постепенно. Да и в целом, для большинства структур с аммортизацией можно сделать структуру без аммортизации с сохранением сложности операций: нужно просто размазать аммортизированную работу по всем операциям.
Собственно, например, в го именно так и устроен хешмап: они в момент ресайза просто создают новый массив, но не удаляют старый. Далее, при поиске они проверяют нет ли двух массивов. Если есть два массива, они мигрируют сколько-то элементов из старого в новый, после чего делают лукап в обоих. Таким образом получается честный
Такая схема сильно замедляет операции с хешмапами, конечно. Но деревья поиска прям очень медленные на самом деле. Поэтому стоит их избегать пока есть возможность.
Часть про бинарные деревья не очень хорошая. Если нужно только искать и вставлять бинарные деревья никому не нужны — просто используйте хешмап.
Бинарные деревья нужны, когда нужны всякие нестандартные запросы: lower_bound, range, агрегат на отрезке и прочее.
Ну и про сложность операций не очень удачно выразились: нет никакого лучшего и худшего случая. Либо Вы работаете со сбалансированным деревом и тогда сложностьв худшем случае. Либо Вы делаете что-то сильно нетривиальное и сложность операций зависит от контекста.
Не, там же всё в одном поколении. По крайней мере в оригинальном алгоритме. А судя по [1] сборка по поколения только-только вышла в релиз, но всё ещё даже не дефолт.
Куча не всегда делиться на поколения. Это зависит от выбранного GC. Например, если взять тот же Shenandoah — он выполняет сборку мусора по регионам, без деления на поколения.
Да какая тут автоматизация? Просто немного другой синтаксис и немного другие умолчания. Типа того, что помечаем inner class-ы, вместо того чтобы помечать static class-ы. Аналогичная история с компаньонами и просто объектами.
Технически любая запись в волатильное поле происходит до каждого последующего чтения этого же поля
Нет, вообще не гарантируется. Гарантируется SeqCst, что позволяет в среднем притвориться, что эффектов кеша для данной переменной не существует. А вот каких либо гарантий на то, через какое время остальные потоки увидят данное изменение — таких гарантий нигде в jvm получить нельзя.
У Вас элементами множества точек являются точки. А элементами множества множеств — множества. Поэтому это множество множеств не содержит себя как элемент — иначе его элементами должны бы быть точки.
Не даёт в том же смысле, в котором определение предела как линейная часть приращения не даёт способ вычисления. Понятное дело, что вывести формулу через предел — тривиально.
Ну и плюс с делением есть всякие неприятные моменты когдаимеет слишком много корней. Впрочем это экзотика.
А это уже ошибки методов вычисления. Изначально то сформулированна непрерывная задача. То что её потом через Монте-Карло пошли решать — это проблемы решающих.
Имеется ввиду, например следующее: Допустим мы случайным образом выбираем две точки на окружности. Обе точки выбираем равномерно. Какова вероятность того, что это точки будут противоположны (отрезок между ними будет образовывать диаметр). Она равна нулю.
Хотя ещё раз перечитал исходное сообщение. Согласен, выразился там очень неоднозначно.
Задача очень некорректно поставлена, т.к. ничего не сказано о том, что такое случайный набор N. В зависимости от распределения вероятностей ответом может быть любое число от 0 до 1.
И при совпадении с линией диаметра - очень даже "заключает" (чтоб я понимал это слово - если точка на границе области, то область заключает точку или нет?).
Это не важно, поскольку вероятность события что "две точки окажутся на одной прямой" равна нулю. Аналогично, с вероятностью на границе (если у нас вероятность непрерывна).
В общем случае, у Вас открытый и закрытый ключ не взаимозаменяемы. То, что в RSA можно использовать ключи в произвольном порядке — это особенность конкретно RSA.
Для произвольного же асимметричного алгоритма шифрования нельзя гарантировать, что при помощи закрытого ключа вообще получиться зашифорвать сообщение. А если попробовать поменять ключи местами: закрытый ключ распространять публично, а открытый ключ держать в секрете, — то здесь может возникнуть проблема, что у некоторых алгоритмов шифрования из закрытого ключа можно без проблем получить открытый ключ.
Поэтому нет, вообще говоря, асимметричное шифрование и подписи не взаимозаменяемы. Так работает только в некоторых частных случаях.
Кажется формулировка задачи слишком сильно привязана к классовой модели. Есть также и другие подходы к моделированию. Это сильно сужает полезность данного теста.
Например, взять ту же Julia. Опыт показывает что на ней прекрасно пишется моделирование и довольно нетривиальные взаимодействия. Но при этом, кажется, конкретно Ваш тест она завалит.
Базы данных: записи и документы, вложенные в таблицы и коллекции и связанные ключами.
Не буду говорить об остальных пунктах, но конкретно в реализации баз данных никакого dom нет. Там сильно по-другому строиться архитектура.
Тоже об этом подумал, но потом понял что это всё ещё недостаточно причина. Можно сделать хешмап со сложностью вставки за
— нужно просто делать ресайз постепенно. Да и в целом, для большинства структур с аммортизацией можно сделать структуру без аммортизации с сохранением сложности операций: нужно просто размазать аммортизированную работу по всем операциям.
Собственно, например, в го именно так и устроен хешмап: они в момент ресайза просто создают новый массив, но не удаляют старый. Далее, при поиске они проверяют нет ли двух массивов. Если есть два массива, они мигрируют сколько-то элементов из старого в новый, после чего делают лукап в обоих. Таким образом получается честный
Такая схема сильно замедляет операции с хешмапами, конечно. Но деревья поиска прям очень медленные на самом деле. Поэтому стоит их избегать пока есть возможность.
Я скорее ожидал что они увеличат количество ключей и внедрить пороговую схему. А втором виде выглядит как что-то мутное, какой-то спектакль.
Часть про бинарные деревья не очень хорошая. Если нужно только искать и вставлять бинарные деревья никому не нужны — просто используйте хешмап.
Бинарные деревья нужны, когда нужны всякие нестандартные запросы: lower_bound, range, агрегат на отрезке и прочее.
Ну и про сложность операций не очень удачно выразились: нет никакого лучшего и худшего случая. Либо Вы работаете со сбалансированным деревом и тогда сложность
в худшем случае. Либо Вы делаете что-то сильно нетривиальное и сложность операций зависит от контекста.
Не, там же всё в одном поколении. По крайней мере в оригинальном алгоритме. А судя по [1] сборка по поколения только-только вышла в релиз, но всё ещё даже не дефолт.
Может Вы с чем-то спутали?
[1]: https://openjdk.org/jeps/521
Куча не всегда делиться на поколения. Это зависит от выбранного GC. Например, если взять тот же Shenandoah — он выполняет сборку мусора по регионам, без деления на поколения.
Да какая тут автоматизация? Просто немного другой синтаксис и немного другие умолчания. Типа того, что помечаем inner class-ы, вместо того чтобы помечать static class-ы. Аналогичная история с компаньонами и просто объектами.
JVM для любой записи гарантирует, что когда её увидят — она будет правильной. Более того, в рамках любой ячейки есть seqcst.
Вопрос именно в том, как порядки модификаций/чтений для разных ячеек связаны между собой. Именно здесь становиться важно volatile, атомики и прочее.
Нет, вообще не гарантируется. Гарантируется SeqCst, что позволяет в среднем притвориться, что эффектов кеша для данной переменной не существует. А вот каких либо гарантий на то, через какое время остальные потоки увидят данное изменение — таких гарантий нигде в jvm получить нельзя.
У Вас элементами множества точек являются точки. А элементами множества множеств — множества. Поэтому это множество множеств не содержит себя как элемент — иначе его элементами должны бы быть точки.
Не очень внятно сформулированно, но не включает.
Когда я учился, нам тоже давали оба определения предела.
Отдельного курса теории множеств, или культуры доказательств не было. Давали по месту на разных курсах.
А с каких пор математика стала наукой?;)
Не даёт в том же смысле, в котором определение предела как линейная часть приращения не даёт способ вычисления. Понятное дело, что вывести формулу через предел — тривиально.
Ну и плюс с делением есть всякие неприятные моменты когда
имеет слишком много корней. Впрочем это экзотика.
Есть хорошее определение в стиле:
Хотя кажется немного странным на первый взгляд (поскольку оно не даёт способ проверки), оно гораздо естественнее выражает смысл символов Ландау.
А это уже ошибки методов вычисления. Изначально то сформулированна непрерывная задача. То что её потом через Монте-Карло пошли решать — это проблемы решающих.
Имеется ввиду, например следующее: Допустим мы случайным образом выбираем две точки на окружности. Обе точки выбираем равномерно. Какова вероятность того, что это точки будут противоположны (отрезок между ними будет образовывать диаметр). Она равна нулю.
Хотя ещё раз перечитал исходное сообщение. Согласен, выразился там очень неоднозначно.
Задача очень некорректно поставлена, т.к. ничего не сказано о том, что такое случайный набор N. В зависимости от распределения вероятностей ответом может быть любое число от 0 до 1.
Это не важно, поскольку вероятность события что "две точки окажутся на одной прямой" равна нулю. Аналогично, с вероятностью на границе (если у нас вероятность непрерывна).
В общем случае, у Вас открытый и закрытый ключ не взаимозаменяемы. То, что в RSA можно использовать ключи в произвольном порядке — это особенность конкретно RSA.
Для произвольного же асимметричного алгоритма шифрования нельзя гарантировать, что при помощи закрытого ключа вообще получиться зашифорвать сообщение. А если попробовать поменять ключи местами: закрытый ключ распространять публично, а открытый ключ держать в секрете, — то здесь может возникнуть проблема, что у некоторых алгоритмов шифрования из закрытого ключа можно без проблем получить открытый ключ.
Поэтому нет, вообще говоря, асимметричное шифрование и подписи не взаимозаменяемы. Так работает только в некоторых частных случаях.
Кажется формулировка задачи слишком сильно привязана к классовой модели. Есть также и другие подходы к моделированию. Это сильно сужает полезность данного теста.
Например, взять ту же Julia. Опыт показывает что на ней прекрасно пишется моделирование и довольно нетривиальные взаимодействия. Но при этом, кажется, конкретно Ваш тест она завалит.
Не буду говорить об остальных пунктах, но конкретно в реализации баз данных никакого dom нет. Там сильно по-другому строиться архитектура.