Чего-то мне в майнкрафте совсем не везёт, пока что не буду в него играть больше. Устал от того, что каждый раз теряю все айтемы.

Оказывается, на столике картографа можно расширять карту только за один листик, поэтому я максимально увеличил масштаб карты и пошёл понемногу её открывать. Успешно реаибилитировался в плане ископаемых ресурсов: утащил довольно много железа и угля, апнул 30 лвл, но вот алмазов не нашёл. Нашёл относительно недалеко деревню, из которой утащил несколько книжек и картофель. Отметил её на карте, так что можно будет потом вернуться и выкрасть жителей (там она довольно удобно расположена около большого водоёма, из которого можно добраться до моего дома).

30 лвлов и 7 книжных полок хватило на то, чтобы сделать железную кирку на анбрейкинг 3 и эффективность 3, но я так её толком и не протестировал, потому что спалил её в лаве в аду, пока пытался найти там крепость.

А ещё, когда я только зашёл в портал, оказалось, что патруль то ли заспавнился там, то ли заспавнился снаружи, а потом попал в ад, но интересно было, что когда они, атаковав меня, случайно попали в зомби пигманов, то зомби начали агриться не только на них, но и на меня тоже.

>>341227

>Заведи ферму коров и размножай их

Да, я уже, но пока что там маловато коров, чтобы их можно было начать убивать.

>Сделай эндер-сундук

У меня какая-то беда с эндерменами: не хотят спавниться. В этом мире вообще видел только двух-трёх. В каком-то спидране майнкрафта я видел, как игрок сделал высокую башню посреди пустыни, а внизу сделал сетап, чтобы можно было удобно убивать эндерменов. И в самом верху он поставил спавн поинт. И ночью он забирался на башню, видимо, чтобы реролльнуть враждебных мобов внизу (как я понял, враждебные мобы спавнятся и рандомно деспавнятся снаружи сферы в 32 блока вокруг игрока и гарантированно деспавнятся снаружи сферы в 128 блоков), и, если находил среди них эндерменов, то агрил их, забирался в коробку внизу и убивал их. А потом топился в лаве, респавнился на вершине башни и так по кругу.

>5. Делаешь афк-рыбалку (норм способ, если уходишь куда-то)

Я так понял, там нужно ставить какой-то автокликер, не хочется и лень таким заниматься. А из остальных способов, видимо, самый эффективный - это добыча кварца.

Спасибо за советы.

В секиро прошёл до конца воспоминания из поместья Хирата. Убил какого-то сильного самурая в синем около трёхэтажной пагоды, которую упоминал вор-торговец, и достал крутой инструмент для протеза, позволяющий уклониться от атаки и мгновенно переместиться за спину врагу или появиться прямо в воздухе над ним.

Еле-как, на самом деле, убил сумоиста-пьяницу, потратил на это слишком много попыток, возможно, отчасти из-за того, что позвонил в тот колокол. В основном фейлился из-за того, что попадал под его мощный одиночный удар ладонью, который легко предсказать, но я постоянно лез на рожон, так что не всегда удавалось вовремя отойти.

Так и не смог по-честному прикончить госпожу бабочку: в первый раз снёс ей почти всё здоровье во второй фазе, но случайно попался в захват, и она меня ваншотнула. А в последующие разы дела шли постепенно всё хуже и хуже. Я пытался терпеливо ждать её атак, когда она подлетает в воздух и тогда её можно сбить сюрикеном и нанести удар, но эти успешные атаки наносили так мало урона, что только на первую её фазу у меня уходило минут 5. А потом надо было проделать то же самое с её второй, почти идентичной, фазой. Пробовал использовать тот инструмент, который телепортирует тебя за спину, но у неё слишком мало предсказуемых медленных ударов, чтобы этот трюк гарантированно получился.

А по-другому я просто не знаю, как ей можно нанести урон, потому что она блокирует все атаки и слишком быстро восстанавливает концентрацию даже с половиной хп. Короче, в итоге мне надоело и я просто заспамил её уклонением-в-сторону-атакой-уклонением-в-сторону-атакой-... Не знаю, почему, но на ней это работает и она практически не может пошевелиться, так что за одну серию таких ударов можно снести ей половину хп.

Прошёл дальше мимо гигантского белого змея, убил самурая Гёбу, который оказался довольно простым, у него куча слабостей: во-первых, его конь боится петард, а, во-вторых, иногда открывается возможность зацепиться за него крюком, быстро сократить расстояние и нанести удар, от которого он с большой вероятностью станнится на некоторое время.

Пока что остановился на быке с привязанным к рогам горящим стогом сена.

В секиро прошёлся по главной башне замка Ашина. Там внутри особо ничего интересного, просто куча одинаковых самураев, впрочем, относительно сильных, особенно, когда нападают несколько таких. Но они обычно не лезут на рожон, так что надо просто держать дистанцию и контрить их колющие выпады. Там же был мини-босс, по внешнему виду почти такой же самурай, но этот, внезапно, имеет гораздо менее разнообразный набор ударов, чем те рядовые воины, что были перед ним. Как правило, он просто резко сокращает дистанцию и делает два взмаха мечом, причём только одного попадания достаточно, чтобы снести мне почти всё здоровье. И, несмотря на то, что в остальном он очень простой и достаточно просто уклоняться от его однообразных атак и контратаковать, он всё же смог несколько раз меня убить, когда я ошибался всего лишь один раз за весь бой и не успевал уклоняться.

Это всё довольно тупо и странно, но немного перекликается с тем, что самурай Тэнгу говорил про стиль боя Ишшины Ашина (который эти самураи используют), что самое главное правило в нём - это побеждать врагов, а самый эффективный способ это делать - наносить точечные фатальные удары, что и делает вот тот мини-босс. Так что ето ни в коем случае не очередной мусорный мини-босс, которого впихнули туда, чтобы мне было, откуда достать бусинку для апгрейда здоровья. Нет-нет, конечно, нет.

Победил Геничиро, но он воскрес и сбежал, потому что предварительно наглотался неких вод молодости, которые частично лишили его человеческого облика, чтобы это ни значило на практике, единственное - у него торс выглядит немного то ли подгнившим, то ли обожжённым из-за молний, которые он кастует. Кстати, так и не понял тайминги того, как отражать эти молнии. В теории надо подпрыгнуть в воздух чуть позже, чем он, принять удар молнией на себя, пока находишься в воздухе, а потом перенаправить молнии в него, когда он будет уже на земле, а ты ещё в воздухе. Но как-то у меня слишком непостоянно получалось это делать, только из-за этого пришлось несколько раз перепроходить его долгую первую фазу. А так он относительно простой, только одну атака стрелами его немного непонятно, как избегать. Он как-то внезапно иногда подпрыгивает и осыпает тебя градом стрел, находясь сам в воздухе, и в большинстве случаев он ловил меня на этом.

Как оказалось, Геничиро хотел связать себя с Куро узами бессмертия, но сам Куро не хотел этого делать, потому что драконье поветрье + он находит это бесчеловечным. А сам Геничиро хотел себе бессмертие вроде как, чтобы защищать Ашину. Эмма служит Ишшину Ашина, и это он приказал ей помочь со спасением Куро, потому как не хотел использовать силу наследия дракона для ведения войны. И ещё оказалось, что протез сделал отец Эммы для резчика, а руку резчику отрубил Ишшин, по словам резчика, для его же блага. И Куро теперь хочет разрубить узы бессмертия, а для этого нужен специальный клинок и какие-то ещё штуки, которые, видимо, теперь надо будет искать до конца игры.

А демон колокола действительно неплохо помогает, по крайней мере недостатка в ресурсах для апгрейда инструментов протеза у меня нет. Другое дело - это, что апгрейды какие-то немного бесполезные.

>>355302

>Более идиоматично сделать это итератором, но они вроде как не умеют rewind

Хмм, да. Вроде как в джавумандже есть ListIterator, который умеет ходить и вперёд, и назад, но произвольного доступа да, нет. Да и вернуться назад в начало тоже нельзя сделать в одну строку.
Нет, не это, было бы тупо до подобной мелочи докапываться. Да, мне изначально было интересно, почему не список, но ты уже >Бонус ответил. По нятно, прикольно, да, мда, буду иметь это в голове.

>Node — внутренний класс, его не предполагается выдавать пользователю. Может, ещё через геттеры и сеттеры с ним работать?

Ну, нет, но просто, по-моему, это немного error-prone вручую выставлять поля вместо того, чтобы сделать конструктор. Я бы точно постоянно забывал что-нибудь так выставить, если бы так делал.

>пока возможно, не new'аем узлы, а достаём из этого списка и используем снова

Они ведь уже вторичные, ими неприятно пользоваться, надо просто убить их.

>Я не знаю, не возникнет ли конфликтов, когда в области видимости есть и тип, и метод, названные одинаково

Нетт, так можно. Я поэтому и указал это, потому что ето выглядело так, как будто ты купил велосипед, но вместо того, чтобы кататься на нём, таскаешь его сзади на верёвочке.

>Но как вы распознаете этот случай без кросс-морепродуктов

А, я, наверное, не так сказал, я не в целях оптимизации это предлагал, а, чтобы в теории была получше точность? меньше вероятность ошибки из-за floating point вычислений? надёжнее? И я буквально просто хотел заменить строку "o1 != o2 && o3 != o4" на "o1 ∗ o2 < 0 && o3 ∗ o4 < 0", чтобы, например, если o1 == 0 и o2 != 0, то проверка принадлежности точки на продолжении отрезка делалась не через кросс-продукты (o3 != o4), а просто сравнениями (o1 == 0 && onSegment(a0, a1, b0)). В кросс-продуктах, наверное, есть шанс того, что-то переполнится, ну и просто там чуть больше вычислений, а значит, больше погрешность, но я сейчас даже не знаю, имеет ли это хотя бы какой-то смысл.

>reciprocal throughput

Хм, ето интересно.

>...И тут я впервые увидел вашу закоммиченную реализацию segmentsIntersect. Как у вас только язык поднимается. Снимайте штаны. ;P

Даа, я уже понял, как это всё лучше сделать, дда.

>Разделим сцену вертикально, на левую и правую половинки. Если точки находятся в разных половинках, то та, что в правой — больше.

Хм, по нятно.

>страшилка на ночь

>04:33:13

Так вот я и не уснул.

Кстати, наконец-то побил мега сатану за лоста, но это исключительно из-за того, что мне внезапно, после кучи неудачных попыток, выпал супер-крутой сид 3YHF 2CZF, в котором на первом же этаже выпал мощный предмет на урон, на втором - четверной выстрел, на третьем - плюс девять жизней, а дальше всё было примерно в таком же духе, при этом не надо было даже стараться играть. И в конце ещё появился портал в эту, последнюю гигантскую финальную локацию. Я не помню, как она называется. Но просто забавно, по сути это идеальный сид, который только может выпасть для лоста.

Единственное - мне опять никак не хотела выпадать вторая комната с ангелом. Если честно, я так и не понял, как работают шансы на выпадение этих комнат после босс-файта, хотя я лениво играю в это прямо с первого дня выхода ремастера айзека. Я всегда думал, что в первую очередь спавнится комната дьявола, и, если она не заспавнилась, то тогда есть шанс на комнату ангела. И я не помню точно, были ли у меня подозрения на то, что я тут в чём-то не прав, но в интернете как-то я нигде не нашёл нормального объяснения того, как зависят спавны этих комнат.

Проблема с лостом в том, что ты никак не можешь понизить шансы на выпадение комнаты дьявола, потому что по сути не можешь получить урон, только умереть. И ты можешь разве что повысить шансы на комнату ангела, но, если шансы на комнату дьявола 100%, то ты по сути ничего не можешь сделать: ты оберчён на то, чтобы получить эту комнату. И ты даже не можешь ничего взять оттуда, потому что тогда ты точно не сможешь потом получить комнату ангела.

И ещё я понял, что за лоста невозможно использовать комнату для жертвоприношений, потому что если ты умираешь в ней, то ты респавнишься в предыдущей комнате. И даже, если зайти в комнату жертвоприношений, выйти, коммитнуть судоку бомбами, зареспавниться в комнате жертвоприношений и наступить на шипы, то всё равно респавнишься в соседней комнате. То есть даже, если бы я в теории наступил на шипы достаточное количество раз и заспавнил босса-ангела, то меня бы сразу после этого выбросило из комнаты и босс бы задеспавнился.

И ещё я понял, что для того, чтобы собрать ключ, нужны две разные половинки, так что просто продублировать одну половинку не прокатит.

Короче, в итоге я дошёл до сундука с двумя одинаковыми половинками ключа, с не особо крутым, то достаточно сильным комбо, уже приготовился смириться с тем, что я потратил эти сорок минут в никуда, как жесть внезапно в секретной секретной комнате оказывается статуя ангела, и, да, я дальше, наконец-то, попадаю к мега сатане и прохожу его. И мне за это даже ничего не дали, только анлокнулся какой-то бэбик для мультиплеера, в который мне не с кем (да и не сильно хочется) играть, мда.

Я чувствую, что такими темпами я никогда не закончу проходить это, особено с учётом того, что я играю в это не то чтобы много. Мне всё ещё остаётся пройти кучу всего за кипера, грид мод за лоста и примерно все челленджи, чтобы по крайней мере пройти всё, что можно. Но я как бы и не тороплюсь никуда, ещё лет шесть, и я точно закончу.

Кстати, забавный момент в том, что у меня не пройден ни один челлендж, так что у меня из всех рун открыта только void rune, так что если мне попадается мешочек с рунами, тоо я просто гарантированно получаю миллирад воид рун, которые, на самом деле, довольно неплохие, особенно, когда играешь за лоста, которому не нужны всякие HP-апы и айтемы на полёт (только этих айтемов довольно много). Но почему-то вот в какой-то из последних разов, в который я играл, и мне выпал мешочек с рунами, тогда мне ни одна руна не выпала, это странно.

Аа, я как-то не знаю, во что можно поиграть. Я вроде хотел пройти дополнения второго дарк солса, ниер автомату, заброшенного якудзу зиро, заброшенные ремастеры креша и спайро, плейстейшн версии первых трёх игр по гарри поттеру. Но как-то ничего из этого особо сильно не привлекает, в особенности второй дарк соулс. Я как бы чувствую необходимость в том, чтобы пройти его полностью, потому что первый, третий и секиро я уже прошёл, а плейстейшена у меня нет, так что это единственная непройденная доступная мне соулс игра. Но, с другой стороны, это второй дарк, он играется ужасно, там странные тайминги перекатов, он весь какой-то обесцвеченный, скучный и безжизненный. И ниер автомату тоже не особо так хочется играть. Не знаю, корочее.

В манкрафт тоже не хочется, кстати: я так и не смог сделать ту ферму жителей: сначала они почему-то постоянно сбегали из клетки, а потом отказывались делать детей. Не исключено, что из-за того, что рядом были три жителя, которых они-таки смогли сделать, но у меня уже нет шанса, чтобы проверить это: я случайно упал к ним в клетку, и не смог выбраться. Пришлось всех прикончить. После этого абсолютно нет желания продолжать играть. Нет, это не как в прошлый раз, я уже не запускал игру недели полторы и до сих пор не тянет.

А я даже не знаю, что хотел сказать, я растянул на кучу символов то, как я прошёл босса в айзеке и то, как мне лень играть в игры.

Немного почитал алгебру
https://poppyfanboy.github.io/2020/04/08/Matrices-3.html

В прошлый раз я там остановился не определении произведения матриц как матрицы композиции отображений, а теперь там сначала была формула для оценки ранга произведения матриц, а потом, наконец-то, было про квадратные матрицы и всякие штуки с ними связанные.

У меня никогда не было интуиции относительно того, какой размерности получится произведение матриц, и вообще оно меня постоянно сбивает с толку, в частности, как-то не думал о том, что строка умноженная на матрицу - это снова строка, потому что высота результирующей матрицы берётся из первой матрицы в произведении, и, аналогично, матрица, умноженная на столбец - это снова столбец. И вот так можно расписать произведение матриц (квадратные скобки - вертикальная ориентация, круглые - горизонтальная, андерскор - строка, крышечка - столбец):

> A x B = [A_1, ..., A_n] x (B^1, ..., B^m) = [A_1 x B, ..., A_n x B] = (A x B^1, ..., A x B^m)

Кстати, как раз вот эти два представления произведения (набор строк и набор столбцов) используются в доказательстве того, что при умножении матрицы на другую ранг не увеличивается: из этого представления видно соответствие между столбцовым/строковым базисами результата произведения и соответствующими базисами матриц A и B.

Ещё я совсем не знал, что из всех квадратных матриц коммутативностью со всеми остальными квадратными матрицами обладают только скалярные матрицы (это те, в которых по диагонали размазано одно число, а остальные элементы нулевые). Это доказывается, если взять произвольную матрицу в теории коммутативную с другими квадратными матрицами, и попробовать умножить её слева и справа на матрицу, в которой только один элемент выставлен в единицу, и приравнять результаты.

Про обратные матрицы я тоже всё забыл. Матрица обратимо только, когда она невырожденна. Необходимость этого условия легко следует из того, что n = rank(E) = rank(AB) ≤ rank(A) ≤ n. А для достаточности надо вывести обратную для произвольной невырожденной. Для этого берётся столбцовый базис исходной матрицы, через него выражается стандартный базис (который [ 1, 0, 0, ... ], [ 0, 1, 0, ... ]) и столбцы координат составляются в матрицу, которая окажется правой обратной к исходной матрице.

Существование левой обратной матрицы можно доказать, используя только что доказанную штуку: транспонирование матрицы вырожденной её не делает, и это биекцивное отображение множества матриц самого на себя, так что, если сделать так: E = E^T = (AA')^T = (A')^T A^T, то это будет означать существование левой обратной для любой невырожденной.

А дальше, если верно AA' = E и A'' A = E, то из этого будет следовать их равенство:

> A' = E A' = (A'' A) A' = A'' (A A') = A'' E = A''

И из этого всего можно также уже вывести то, что если есть хотя бы левая/правая обратная матрица, то будет и просто обратная, и они будут равны, потому что из существования левой/правой обратной следует невырожденность, а из невырожденности следует существование просто обратной.

И ещё там была теорема о том, что умножение матрицы на невырожденную не меняет её ранга, и это доказывается через довольно странный математический при кол (B - невырожденная):

> rank(AB) ≤ rank(A) = rank(ABB^{-1}) ≤ rank(AB)

И точно так же для умножения слева. Не знаю, какой это имеет практический смысл, вот такие модные доказательства, как мне кажется, иногда скрывают то, какой вообще смысл имеют доказываемые утверждения.

>>362204
Я не умею.

Сегодня снова ничего не делал, не знаю, сколько ещё такое будет продолжаться, но я просто не могу и ничего не выходит заставлять себя делать, и я даже не понимаю, куда уходит время.

Почитал ту книжку по гиту немного, которая на их сайте. Я её, наверное, раза три начинал листать, но дальше объяснения того, что такое version control system, не доходил, потому что мне было лень и нет особой необходимости.
https://poppyfanboy.github.io/git/2020/04/16/Git-1.html
Но, на самом деле, я не думаю, что это так бесполезно, потому что тут как с каким-нибудь вимом с его дефолтным туториалом: там есть слишком много всего и вряд ли хотя бы половина пригодится на практике, но по крайней мере ты знаешь, что он может, и, может быть, среди всех лишних штук ты найдёшь что-то действительно полезное, что сильно упростит тебе всё. К тому же я знаю только, как делать простейшие вещи вроде коммитов и мерджев веток.

Вот тут из полезного я не знал, что
- у git status есть нормальная сокращённая версия (флаг --short)
- git diff может выводить в виме side-by-side код до изменений и после (вернее git difftool). От обычного вывода мне становится плохо, потому что там выводится винегрет из удалённого и добавленного кода
- и ещё я не знал, что в гит командах можно использовать звёздочки, но их надо эскейпить обратным слешем. Если не эскейпить, то звёздочка будет нерекурсивной, то есть "git add ⁎.java" добавит файлы только из текущей директории, а "git add \⁎.java" - из всех. Иногда работает и без эскейпа, но, например, git add у меня никогда не хотел работать с простыми звёздочками, из-за чего я просто писал "git add .", потому что вбивать полный путь до каждого файла слишком долго
- и про git mv и git rm я не знал

Там ещё были какие-то штуки для git log, которые фильтровали его вывод, но они не особо полезны.

https://youtu.be/kma6T8OAQ-Q
Ещё полистал какое-то видео, думал, что там будет про многопоточность в целом, но там было про то, что в джавве, и там в основном было про то, что я как раз недавно сам посмотрел, но просто упорядоченное и в одном месте.

Из чего-то, что я не видел, там были только две какие-то функции (закон амдала и универсальный закон масштабируемости). Первая функция - частный случай второй, а вторая - это штука, которая показывает, какой можно ожидать прирост производительности в распараллеленной программе по сравнению с однопоточной, она вот так выглядит: C(N) = N / (1 + α(N - 1) + βN(N - 1)), где альфа - это доля критических секций, как я понял (если α = 1, то программу нельзя распараллелить и она не получает выгоды по сравнению с однопоточным вариантом), N - количество ядер процессора, а β - то, как часто потокам надо взаимодействовать друг с другом, и этот коэффициент вносит больший негативный вклад и может всё заруинить ещё сильнее, потому что количество возможных взаимодействий между потоками растёт квадратично относительно количества потоков. Короче, показывают просто, как может зависеть производительность многопоточной программы в зависимости от каких-то там факторов.

Ещё там был пример того, почему нужно синхронизировать не только запись, но и чтение. Запускаются 10 потоков, каждый из которых делает 100 синхронизированных записей в один и тот же ArrayList, после чего просто делается busy wait с проверкой того, не достиг ли list.size() 1000 элементов, при этом list.size() не синхронизирован.

Из-за того, что list.size() просто возвращает значение поля size внутри листа и это поле не помечено как volatile, то вот это:

> while (list.size() < 1000);

Может оптимизироваться вот так:

> int size = list.size;

> if (size < 1000) while (true);

Потому что компилятор не предполагает, что size может быть изменён из другого потока, это справедливое применение out-of-order-execution. Так что тут всё может зависнуть.

Ещё там было про double checked locking, который очень легко сделать неправильно, если не пометить поле с целевым вот этим целевым объектом как volatile, и про то, как в теории операция записи в поле объекта может быть неатомарной (но на деле в джавваве она атомарна за счёт выравнивания полей объекта, как я понял): если адрес объекта лежит на стыке кэш-линий и, если только одна из этих кэш-линий загружена, то процессор берёт значение из первой кэш-линии, загружает вторую кэш-линию, берёт значение из второй. Из-за этого можно было бы в теории наблюдать бессмысленное значение в переменной для адреса объекта, data race, всё плоххо. Но в дажваве вроде как благодаря выравниванию такого нет и запись в поле объекта всегда атомарна. Но я не особо вообще понимаю, как это всё работает, главное, что атомарна, да.

И ещё понял, что я неправильно у себя в голове произносил volatile и concurrency. И что у concurrency различаются британское и американское произношения. И, оказывается, да, то, что любой объект может в джавве использоваться как лок, влияет на производительность JVM, это очевидно, но просто он явно сказал это. И изначально так делалось из предположения о том, что локи - это мега круто.

Хотел ещё дальше почитать, но не почитал, а только понабрал побольше ссылок с википедии, которые можно посмотреть. Посмотрел только про дедлоки немного, что это формально и как с ними справляются операционные системы
https://poppyfanboy.github.io/java concurrency/2020/04/20/Java-Concurrency-4.html
И больше ничего, короче, по сути ничего не посмотрел.

>>366219

>Я как-нибудь потом почитаю.

Чел, я сейчас тёщу убью (https://vk.com/wall-48287065_6402). А ну читай, сидит деревья крутит.

>Откуда конкретно эти смешные формулы с синусами берутся - понятия не имею.

Читай: http://allenchou.net/2018/05/game-math-deriving-the-slerp-formula/.
Но я их до сих пор использовала как чёрный ящик, и тебе тоже не предполагалось об этом задумываться, потому что пост был не про slerp. Ты бы ещё к формулам двойных углов прицепился — я же их тоже без вывода привела!

Да, тут кое-какие очевидные опечатки/ошибки (о неочевидных я сама не знаю):
— 100° — это, разумеется, Ⅱ квадрант, я просто набирала пост в блокноте, который отображал квадратик вместо римской цифры, а саму цифру вводила Alt-кодом. Римские цифры есть в японской IME, но тупой файрфокс, если его неделю не перезапускать, начинает тупить по 10 секунд в момент переключения на IME, поэтому я избегала её использовать. Вводить же римские цифры латинскими буквами как-то неинтересно.

— По качественному и количественному составу операций применение Rotation2D к вектору абсолютно идентично комбинациям ротейшнов или спиннеров друг с другом (два сложения и четыре умножения), и результаты по времени тоже были ожидаемо идентичными, просто я в одном случае округлила до десятков миллионов, а в другом — нет, поэтому и получились «320 и 325 млн».

— Формула MIP-уровня на основании длины градиента — clamp(last_level + log₂(grad.len), 0, last_level), логарифм длины градиента практически всегда отрицателен (⇔ длина градиента практически всегда меньше единицы, ⇔ MIP-уровень практически всегда крупнее 1×1). Я изначально написала верно, но когда перечитывала пост перед отправкой, о чём-то замечталась.

И можно кое-что уточнить:
— Slerp схлопывается, потому что предполагает, что результат может быть выражен линейной комбинацией входных векторов, а для коллинеарных векторов это не выполняется.

— Дуга между противоположными поворотами будет непредсказуемой не только из-за погрешности, но и из-за того, что один и тот же поворот может быть выражен двумя противонаправленными спинорами (r и ‒r), которые стали таковыми в ходе своих неизвестных приключений (например, если жук с УЗОРОМ НА ЖОПЕ постепенно развернулся на 360°, он переведёт свой спинор в противоположное состояние, а прокрутившись ещё кружок, т. е. в сумме 720° — вернёт в исходное) и к которым, несмотря на то, что они выражают одинаковый поворот, некоторый спинор V будет (без проверки dot ≥ 0) интерполироваться по комплементарным дугам:
(V → r)
(V → ‒r)
Условие dot ≥ 0 выбирает из этих дуг меньшую, но в крайнем случае, когда дуги (почти) равны и соответствующие им повороты отстоят на 180°, однозначной меньшей дуги не будет. На практике от этого не жарко и не холодно и ты всё равно не захочешь разворачиваться на 180°, не уточнив направление — например, путём вставки промежуточного ключевого кадра с поворотом на 90°.

https://youtu.be/B0fiPx6SlAo

Thu May 14, 15:01
Не знаю, почему-то стало ещё хуже, чем было. Идея с таймстемпами глупая, к чему они вообще нужны тут? Разве что для того, чтобы как-то разграничивать куски текста плюс они смотрятся неплохо. Может, всё же оставить. Не понимаю, почему меня так сильно выворачивает наизнанку и кушает изнутри, не знаю, как иначе описать, не знаю, что делать.

Максимально наивная идея - вкатываться вайти, но для этого надо будет как минимум нормально доразобраться с Core Java, вспомнить, как писать SQL-запросы, посмотреть, что такое Spring Framework и Hibernate, посмотреть немного про паттерны. И ещё кое-какие не такие важные в этом контексте штуки. Но вообще стоит ли пробовать с моими безумными социальными умениями, если мне страшно даже о мысли об интервью и у меня нет ни малейшего представления о том, что такое работа.

???
Посмотрю немного общих штук про многопоточность, чтобы примерно знать.

Critical Sections
Очевидно, для них нужно свойство mutual exclusion, но также нужно, чтобы была свобода от дедлоков, то есть, чтобы если в любой момент времени несколько потоков хотят войти в критическую секцию, то рано или поздно по крайней мере один из них пройдёт дальше (при условии, что критическая секция гарантированно проходится за конечное время, конечно). Вообще freedom from deadlock - это самая слабая из форм liveness - то, насколько concurrent система живая, гарантия того, что произойдёт что-то благоприятное (в этом случае это гарантия, что произойдёт что-то хорошее хотя бы для кого-то).

Более сильное условие живучести - это lockout-freedom или свобода от голодования. Гарантия того, что если поток ждёт, то рано или поздно ему дадут войти в критическую секцию. Голодание может быть вызвано утечкой ресурсов (resource leak): когда какие-то ресурсы (например, память, file handles, те же lock'и) не отпускаются после того, как он были захвачены, из-за чего никто не может воспользоваться ресурсом. Как правило эти проблемы связаны с процессами, работающими достаточно долгое время, потому что операционная система автоматически освобождает ресурсы завершённых процессов, что частично предотвращает проблемы с утечками ресурсов.

Также голодание может иметь место для процессов в scheduling системах, когда потоку очень долго не достаётся ресурс (CPU time) и нет никакой гарантии, что в итоге когда-то потом ему вообще он достанется. Частный пример для priority-based scheduling систем - это priority inversion: если, допустим, low priority процесс L захватывает ресурс R, то high priority процесс, который тоже хотел бы воспользоваться ресурсом R, не может продолжить своё выполнение, пока L не закончит работу с ресурсом. Возможное простое решение - если два процесса используют один ресурс и более приоритетный прерывает выполнение менее приоритетного, то scheduling система освобождает общий ресурс и отдаёт его high priority процессу. Но это всё довольно легко ломается тем, если бы L сначала прервался процессом M (middle priority), который бы не пользовался ресурсом R, а потом M прервался бы процессом H. И там вроде как есть другие решения, но я как-нибудь потом посмотрю про планировщики.

Максимально мощное условие живучести - bounded waiting: время ожидания не только в теории конечно, но ещё и ограничено (функцией от количества потоков).

Mutex Hardware Solutions
Наиболее простой и очевидный способ реализации критической секции на уровне железа в случае с одним процессором - выключить прерывания во время того, как выполняется критическая секция, тогда, очевидно, во время критической секции не будут выполняться никакие обработчики прерываний, так что процесс не сможет быть прерван физически. В этом же и минус. >Also, if a process halts during its critical section, control will never be returned to another process, effectively halting the entire system. Как бы интуитивно понятно, но не знаю, всё равно не понимаю. Это потому что context switch триггерится, собственно, тоже через прерывания?

>The system clock is typically implemented as a programmable interval timer that periodically interrupts the CPU, which then starts executing a timer interrupt service routine. This routine typically adds one tick to the system clock (a simple coвыставлunter) and handles other periodic housekeeping tasks (preemption, etc.) before returning to the task the CPU was executing before the interruption.

Короче, в любом случае, мне не особо важно это.

Другой подход - использовать спинлоки. Плюс в том, что если использовать из предположения о том, что если известно, что lock отпустится в течение тайм слайса, выделенного потоку, который находится в busy wait, то можно избежать оверхеда контекст свича. Ну а ещё очень легко реализуется. Чаще всего такое используется на уровне ядра ОС и ещё где-то на низком уровне как небольшая оптимизация: немного покрутиться в активном ожидании перед контекст свичем, в остальных же случаях, видимо, это плохая идея, потому что тогда scheduler будет выделять процессорное время на бесполезный busy wait, а это не только трата ресурсов, но ещё и откладывание освобождения lock'а (меньше времени для потока, который удерживает лок, в случае с плохим планировщиком вообще никакого времени для нужного потока). В джавве на эту тему есть java.lang.Thread.onSpinWait(), который можно засунуть внутрь busy wait цикла, чтобы указать виртуальной машине на то, что это действительно busy wait и по возможности лучше выделять больше ресурсов другим потокам. Но опять же, лучше вообще такое не использовать.

Можно было подумать, что спинлок можно реализовать вот так (я не знаю всяких амесблеров, поэтому порядок аргументов какой придётся):

> spin:

> LOAD R0, Lock

> STORE #1, Lock

> CMP R0, #0

> JNZ spin

> # critical section

Но проблема в том, что выполнение потока тут может прерваться после LOAD, из-за чего в регистре будет устаревшая информация. Чтобы всё корректно реализовать, понадобится атомарная инструкция TSL (test and set lock): она загружает в регистр значение по указанному адресу и записывает какое-то ненулевое значение по этому же адресу. В итоге выглядеть будет вот так:

> spin:

> TSL R0, Lock

> CMP R0, #0

> JNZ spin

> # critical section

Самый большой недостаток, как я понял, в том, что эта TSL не всегда может быть реализована на какой-то конкретной архитектуре. Ну и ещё, очевидно, тут может иметь место голодование: другой поток может сколько угодно раз отбирать у тебя флаг Lock. Ещё вроде как проблема в том, что из-за того, что надо поддерживать когерентность кэша, если много потоков одновременно делают TSL, то всё может тормозить. Так что лучше будет, видимо, сделать так:

> do {

> 　　while (lock);

> } while TSL(lock);

В вики это test and test-and-set.

Третий храдварный подход - использовать неблокирующие алгоритмы. Они тоже реализуются с использованием особенных ассемблерных инструкций. Compare-and-swap (CAS) - сравнивает значение по адресу памяти с заданным (old) и, если они совпадают, то записывает туда новое (new). Возвращает то значение, которое она изначально прочитала, чтобы можно было понять, произошла ли запись (или просто boolean, такая вариация обычно называется compare-and-set). Обычно CAS используется вот в таком сценарии: читаем старое значение, вычисляем новое, с помощью CAS пробуем заменить старое на новое. Если не удаётся, то пробуем ещё раз. Очевидно, если много потоков пытаются так обновить, например, какой-нибудь счётчик, то всё будет работать немного медленнее, так что можно делать exponential backoff - экспоненциально увеличивать задержку между запросами (+ возможно, рандомизированная составляющая).

С алгоритмами, использующими CAS, может возникунуть ABA problem - это, когда в промежутке между чтением старого значения и, собственно CAS, значение дважды меняется, второй раз - на то, что было изначально. И вроде значение то же, но оно может быть использовано в другом контексте. Одно из решений - дополнительно вести счётчик количества апдейтов для структуры данных, рассчитывая на то, что за время приостановки выполнения потока счётчик не переполнится. Чтобы уменьшить шансы переполнения, можно вести отдельные счётчики для отдельных элементов внутри структуры данных. Ну, это самый простой способ решения проблемы, там вроде ещё есть какие-то но я потом никогда не посмотрю.

Load-link и store-conditional (LL/SC) - тоже относятся к реализациям lock-free алгоритмов. LL достаёт текущее значение по адресу в памяти, SC после LL пишет туда только, если это место в памяти никем не апдейтилось после LL. Получается, что это как обычное чтение + CAS, только без ABA problem. И вроде это звучит лучше, но, судя по всему судя по википедии если между LL и SC есть достаточно много, то велика вероятность, что SC зафейлится без конкретной причины (ну, то есть в теории всё может работать, а на практике - нет).

И ещё есть fetch-and-add (FAA). По сути это просто атомарный +=a.