Нужно доказать используя данные с интерфейса не вникая в тонкости алгоритма, почему корень найден с такой погрешностью.
Другие формулировки: почему корень найден с заданной погрешностью, почему корень найден именно с такой погрешностью.
Как разработчику мне непонята суть вопроса. На погрешность влияет много факторов.
Реализация алгоритма. Как выглядит последняя итерация например. И выбранный тип
данных.
Как будет угодно. Я не против SVG. Но SVG не ставит перед собой задачу хранения
данных. Он - только визуализирует. Так-же как и Adobe PDF не обязан например
предоставлять контент. Он может менять кодировки символов или заменять текст
картинкой.
Вобщем такова моя философская идея. SVG - для отображения.
Ctrl + F тебе найдет много мусора. Например ты захотел найти вершину в составе со словом "points",
но points является служебным тегом для <polyline points="50,150 50,200 200,
и дальше я посмотрю как ты будешь искать и какова будет твоя продуктивность.
Наверное Акрониса будет недостаточно. Ну я-бы посмотрел как выглядит /etc/fstab
в исходной системе. Возможно там mount прописан по UUID, и их надо будет
обновить после подключение к железу SSD.
Кafka Connect - под крышечкой содержит различные имплементации синков и драйверов.
В данном случае вы используете s3. Поэтому ответы на вопросы надо искать в s3.
У меня есть личное неприятное воспоминание по поводу s3. Кажется его API может потреблять
чуть больше памяти чем вы думаете. Посмотрите какого размера файлы вы пишете в синк.
И сколько висят у вас в пуле в ожидании записи. Возможно требуется тюнинг.
Вообще бизнес смотрит на проблемы памяти с безразличием. Цена памяти в наше время дешевая.
Дешевле купить более толстую виртуалку +32Гб чем оплачивать 1 месяц работы для синьор-девелопер
или девопс.
Если вам сильно-сильно интересно - сделайте дамп памяти и посмотрите. Java, в отличие от других
runtime хранит очень много сведений о куче. Сможете понять что за бизнес-объекты у вас сожрали все.
Да я тоже подумал о graphviz. Но он часто рисует графы, которые на некотором объеме данных
(более 500 тыщ вершин) выглядят просто ужасно. И labels перекрываются. И количество ручной
работы по доводке такого графа до нормального просто чудовищна. В некоторых случаях
утилиты dot, twopi просто намертво зацикливаются и приходится их снимать через kill.
Тоесть graphviz - это хороший тул но для небольших объемов данных.
По поводу "делать текстовый поиск". Тут к сожалению SVG таких услуг не предлагает.
Да и я думаю любые форматы векторной графики ничего такого не имеют. Текстовый
поиск это непростая опция и ее надо уметь готовить.
Добавлю что современные библиотеки хеширования могут использовать команды SSE,
где уже расчет некоторых частей конечного автомата SHA-1 реализован в процессоре.
И это может быть быстрее чем CRC32. В основном за счет обработки более длинной пачки байт.
Как оно сейчас реализовано внутри крипто-библиотек java или bouncy-castle - я не знаю
я давно туда не заглядывал. Но я-бы сразу брал DigestInputStream без лишних сомнений.
Возможно длинные фреймы имеют значение для загрузки ресурсов (текстур и звуков).
А во время сетевой игры это не дает никакого преимущества т.к. игровой сервер обычно
передает очень короткие клавиатурные событие и update координат всех движущихся
сущностей игрового мира. И эти события вряд-ли будут больше 1500 bytes.
Поэтому в целом такая оптимизация для игры скорее всего ничего не даст. Риск словить
побочку как выше люди пишут - точно повышается.
PBT - фреймворки сразу посылают на вход корнеркейсы.
Например если у тебя 3 мерная функция - с вещественными аргументами
то первым делом будут протестированы 0, +1, -1.... числа Фибоначии, +MAX_INT, +INFINITY, NaN
а потом уже на вход пойдет шум из рандомных значений.
Я трассировал работу jqwick он так работает.
Кроме того тестовые фреймворки позволяют создать свой генератор значений и там уже
можно учеть какие-то преференции. Например все четные числа.
Шикин и Боресков - Компьютерая Графика (желтая обложка обычно) Т.Павлидис "Алгоритмы машинной графики и обработки изображений" (старая книга где-то 1980 но еще полезная)
Alex XYZ , я не понимаю при чем здесь фигура Straight Skeleton? Каким образом это меняет задание?
Обращу внимание на терминологию.
Вообще в компьютерной графиге и графическом моделировании (ГИГМ) различают следующие
операции над полигонами (многоугольниками в твоей терминологии):
- объединение
- пересечение
Ты делаешь пересечение. И никакого разрезания.
Непонятно, почему ты пишешь что нельзя вращать? Можно вращать. Если это приносит пользу
для алгоритма. Это - линейное преобразование. Про точность - слабая аргументация? Что там
у тебя? Только целые числа?
Почитай Павлидиса, Эгрона, Шикина и Борескова по ГИГМ.
Напитайся правильной терминологией. Там и алгоритмы описаны и подходы.
Как разработчику мне непонята суть вопроса. На погрешность влияет много факторов.
Реализация алгоритма. Как выглядит последняя итерация например. И выбранный тип
данных.
- flot
- double
- extended