А почему на сглаженной сфре со 288-ю полигонами не видно угловатости огибающей окружности? То есть, нормали нормалями, а внешний контур поменяться был не должен…
Вообще, идея упаковать элементы списка в массив и использовать индексы вместо указателей довольно древняя. Эта структура хороша как пул объектов, которые используются в виде списка. Например, так можно выделять объекты задач для диспетчера процессов.
Такой список с одной стороны имеет достоинство (он не фрагментирован), а с другой недостаток, поскольку, как тут заметили, свыше cap выделить память можно только если пул работает в страничном режиме, а индексы работают по принципу «страница-смещение».
Приём вынесения индексов next/prev за пределы пула объектов довольно интересен. Поскольку позволяет работать над индексами как отдельной сущностью без итерирования по коллекции. Спасибо. Сомнительно конечно, но это может быть полезным.
Несовсем.
При удалении элемента целесообразно свопать его с последним элементом массива (и пересчетом next/prev индексов соседних элементов списка). Тогда операция будет О(1). В реализации автора это вполне возможно.
Если udp датаграмму послать, то да, она физически уйдёт в сеть, независимо от того, есть ли у нее получатель. Собственно, отправитель даже не узнает, получил ее кто-то или нет.
И да, если много получателей то экономичнее бросать широковещательными, но это только в рамках локалки. Фильтры броадкасты в глобальную сеть не выпустят.
Идея с биометрией плохо применима в интернете. Нужно передавать биометрические характеристики в сеть. Любой, кто завладеет характеристиками может их запомнить и логиниться на всех сайтах, куда мы ходим. Тоесть биометрия может выступать разве что дополнением к какому-то другому средству аунтефикации.
Вопрос: «Аффинное преобразование по трем точкам на плоскости»
А почему получается, что для выполнения алгоритма нужны три точки, Ведь для восстановления преобразования достаточно двух? Что будет, если выходной треугольник, который я задам будет неравен/неподобен входному?
В этой статье присутствует ложная дихотомия функционального программирования и ООП. Эти подходы совершенно не исключают друг-друга.
Совсем непонятно про наследование. В каком месте функциональное программирование отменяет концепцию наследования???
Функциональное программирование позволяет получить строгий вывод в терминах объектов. Функциональная парадигма в части своей основной идеи интуитивна ничуть не менее кошечек и собачек.
Я думаю, в конечном итоге zencad тоже будет сопрягать два изделия, совмещая определенные ЛСК (собственно, он уже почти так делает). Но конечно, вместо названий будет прямое указание, что и куда ставить. Названия — это не для скриптов.
По поводу np.array: В дальнейшем я вообще постараюсь убрать или спрятать поглубже слассы vector и point. Будем как раз с np.array работать. Мне кажется, это в духе питона и удобно для использования стороннего софта.
Язык си может быть обработан интерпретатором.
И это не будет нарушением стандарта.
Собственно, я думаю, причина всех этих минусов в том, что вы в своём посте включили компилятор в язык.
Язык он сферический в вакууме. Стандарт создан, конечно, с расчетом на то, как именно язык будут использовать, но записан он очень оторвано от реализации.
Завтра у нас появится транслятор, скармливающий программы на языке в надмашинный мирровой квазигипермозг, который посмотрев на код будет без всякой компиляции сразу выдавать результат выполнения…
Так все и было. Сначала был один компилятор. Потом их стало три. Каждый со своими правилами. И тогда вместо одного языка стало три. Умные дяди почесали затылки и выкатили стандарт на язык. Именно на язык, а не на конкретный компилятор.
И сказали так: О, Компиляторы! Вы цари и боги, и вольны делать все что хотите, покуда не нарушаете стандарт, иначе несоответствующими стандарту заклеймлены будете.
Таким образом, стандарт — это, конечно, просто бумажка. Но компилятор должен этой бумажке соответствовать. Для того она и существует.
Я имею сказать по этому поводу. Эволюции надо рассматривать в долгосрочной перспективе. Неэфективные решения эволюционно нестабильны. Через миллион лет все может поменяться.
Или это оптическая иллюзия?
Такой список с одной стороны имеет достоинство (он не фрагментирован), а с другой недостаток, поскольку, как тут заметили, свыше cap выделить память можно только если пул работает в страничном режиме, а индексы работают по принципу «страница-смещение».
Приём вынесения индексов next/prev за пределы пула объектов довольно интересен. Поскольку позволяет работать над индексами как отдельной сущностью без итерирования по коллекции. Спасибо. Сомнительно конечно, но это может быть полезным.
При удалении элемента целесообразно свопать его с последним элементом массива (и пересчетом next/prev индексов соседних элементов списка). Тогда операция будет О(1). В реализации автора это вполне возможно.
Системы стабилизации, алгоритмы?
Можно ли надеяться найти в свободном доступе?
И да, если много получателей то экономичнее бросать широковещательными, но это только в рамках локалки. Фильтры броадкасты в глобальную сеть не выпустят.
Идея с биометрией плохо применима в интернете. Нужно передавать биометрические характеристики в сеть. Любой, кто завладеет характеристиками может их запомнить и логиниться на всех сайтах, куда мы ходим. Тоесть биометрия может выступать разве что дополнением к какому-то другому средству аунтефикации.
Не могу не поделиться этой видюшкой :):
Это, конечно, вообще не основное назначение zencad, но такое тоже можно.
P.S. Версия zencad 1.0 постепенно выходит на финишную прямую. Месяца через два-три, полагаю, можно будет торжественно объявить релиз.
Выглядит впринципе неплохо, но все равно не взлетит.
А почему получается, что для выполнения алгоритма нужны три точки, Ведь для восстановления преобразования достаточно двух? Что будет, если выходной треугольник, который я задам будет неравен/неподобен входному?
Совсем непонятно про наследование. В каком месте функциональное программирование отменяет концепцию наследования???
Функциональное программирование позволяет получить строгий вывод в терминах объектов. Функциональная парадигма в части своей основной идеи интуитивна ничуть не менее кошечек и собачек.
По поводу np.array: В дальнейшем я вообще постараюсь убрать или спрятать поглубже слассы vector и point. Будем как раз с np.array работать. Мне кажется, это в духе питона и удобно для использования стороннего софта.
И это не будет нарушением стандарта.
Собственно, я думаю, причина всех этих минусов в том, что вы в своём посте включили компилятор в язык.
Язык он сферический в вакууме. Стандарт создан, конечно, с расчетом на то, как именно язык будут использовать, но записан он очень оторвано от реализации.
Завтра у нас появится транслятор, скармливающий программы на языке в надмашинный мирровой квазигипермозг, который посмотрев на код будет без всякой компиляции сразу выдавать результат выполнения…
И это никак не повлияет на сам язык.
Так все и было. Сначала был один компилятор. Потом их стало три. Каждый со своими правилами. И тогда вместо одного языка стало три. Умные дяди почесали затылки и выкатили стандарт на язык. Именно на язык, а не на конкретный компилятор.
И сказали так: О, Компиляторы! Вы цари и боги, и вольны делать все что хотите, покуда не нарушаете стандарт, иначе несоответствующими стандарту заклеймлены будете.
Таким образом, стандарт — это, конечно, просто бумажка. Но компилятор должен этой бумажке соответствовать. Для того она и существует.