Этого треда уже нет.
Это копия, сохраненная 30 июля 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 30 июля 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
100 Кб, 850x1066Хочу съехать от родителей, чтобы ходить по дому в колготках и трахать себя дилдаком в волосатое очко, но я сучий долбаёб войтишник первокурсник, которому нихуя не светит.
>>12083 (OP)
Родоки-бабки-дедки богатые?
Родоки-бабки-дедки богатые?
164 Кб, 1344x2016>>12085
Да.
Какого-то хуя у нас есть русский язык отдельным предметом и на завтра надо подготовить убеждающую речь на произвольную тему. И, сука, лучше бы тема была фиксированной, потому что я вообще не ебу, про что мне придумывать свой монолог обоссанный. Ещё и перед одногруппниками придётся стоять, позориться и читать свой текст, пиздец, я не знаю, как я это завтра переживу. Расплакался сегодня из-за предвкушения этого опыта.
Естественно, я ещё не начал даже писать его. Предварительно придумал тему почему важно вести учёт своих финансов, потому что по крайней мере можно будет напиздить текста из интернета. Но я так не хочу этим заниматься, я, блять, ничего не хочу. Пойду выпью кофе и попробую написать эту ссанину побыстрее.
Да.
Какого-то хуя у нас есть русский язык отдельным предметом и на завтра надо подготовить убеждающую речь на произвольную тему. И, сука, лучше бы тема была фиксированной, потому что я вообще не ебу, про что мне придумывать свой монолог обоссанный. Ещё и перед одногруппниками придётся стоять, позориться и читать свой текст, пиздец, я не знаю, как я это завтра переживу. Расплакался сегодня из-за предвкушения этого опыта.
Естественно, я ещё не начал даже писать его. Предварительно придумал тему почему важно вести учёт своих финансов, потому что по крайней мере можно будет напиздить текста из интернета. Но я так не хочу этим заниматься, я, блять, ничего не хочу. Пойду выпью кофе и попробую написать эту ссанину побыстрее.
>ходить по дому в колготках и трахать себя дилдаком в волосатое
А кто тебе сейчас мешает?
1,3 Мб, 1688x3000>>12090
Очевидно, родители и мешают. Кроме них, в квартире ещё две мои сёстры живут, так что дома почти всегда кто-то да находится. И мой прикид вряд ли кто-то из них оценит. Алсо пришлось бы прятать одежду, дилду и прочее и всегда быть готовым к тому, что их найдут. Шансы этого довольно высоки, потому что моё личное пространство не очень высоко ценится.
Очевидно, родители и мешают. Кроме них, в квартире ещё две мои сёстры живут, так что дома почти всегда кто-то да находится. И мой прикид вряд ли кто-то из них оценит. Алсо пришлось бы прятать одежду, дилду и прочее и всегда быть готовым к тому, что их найдут. Шансы этого довольно высоки, потому что моё личное пространство не очень высоко ценится.
612 Кб, 2560x3840Мать пиздецки поехавшая на всяких походах по врачам. Перед поступлением проходил окулиста, она там увидела какую-то хуету в глазах (сказала, что, наверное, ретиношизис) и выписала направление на обследование. И, сука, за каким-то хуем я, как послушная гиперопекаемая мышь, сказал мельком об этом матери. Пиздос, я не знаю, что у неё происходит в голове, ей как будто постоянно нужна драма, пища для стресса, чтобы было, над чем повздыхать. Она теперь этим сильно обеспокоилась, заставила сходить на это обследование, где мне дали направление на ещё одно.
При этом зрение у меня нормальное, и ретиношизис этот обычно бессимптомно, судя по тому, что в интернете пишут, проходит. И не похуй ли тогда? А для меня каждый поход поликлинику - это ёбаный стресс из-за того, что надо взаимодействовать с людьми и нихуя не понятно. Я скорее ёбнусь головой от походов по врачам, чем потеряю зрение от шизиса этого ебливого.
Блять, всё, сука, сейчас буду писать монолог этот, пиздец, час уже прошёл.
При этом зрение у меня нормальное, и ретиношизис этот обычно бессимптомно, судя по тому, что в интернете пишут, проходит. И не похуй ли тогда? А для меня каждый поход поликлинику - это ёбаный стресс из-за того, что надо взаимодействовать с людьми и нихуя не понятно. Я скорее ёбнусь головой от походов по врачам, чем потеряю зрение от шизиса этого ебливого.
Блять, всё, сука, сейчас буду писать монолог этот, пиздец, час уже прошёл.
118 Кб, 833x1251Сука, я не могу! Каждый ёбаный раз, когда мне приходится писать что-либо похожее на сочинение, я охуеваю от стыда. У меня нет своего мнения ни по каким темам, за меня всяю жизнь всё родители решали, как я могу выдать что-то от себя? Пиздец, какое в пизду слежение за своими расходами, я не знаю, что написать на эту тему.
176 Кб, 960x1280Написал 400 слов. Получилось полнейшее говно с повторами и длинными плохо читаемыми предложениями, на 90% состоящее из воды, но ладно хуй с ним, это хотя бы что-то. Написал, что надо вести учёт, куда тратишь деньги, чтобы их хватало на важные вещи и чтобы можно было их откладывать. Охуенная мысль, напечатанная человеком, который тратит все карманные деньги на колу.
Потом сегодня немного поправлю, чтобы выглядело не так уёбищно. Надеюсь, что завтра всё же не буду рассказывать эту ебанистику.
Теперь можно и пофапать.
Потом сегодня немного поправлю, чтобы выглядело не так уёбищно. Надеюсь, что завтра всё же не буду рассказывать эту ебанистику.
Теперь можно и пофапать.
143 Кб, 1080x1349Хуй знает, что делал полтора часа, явно не всё это время фапал, но время куда-то ушло. Теперь надо посмотреть лекции по физике. Все лекции у нас дистанционные, вроде потому что из-за ковида не дают использовать лекционные аудитории, мол, слишком много людей. С одной стороны, хорошо, потому что можно пересмотреть, с другой - у меня нет никакой мотивации просыпаться рано утром, чтобы посмотреть лекцию, если я могу сейчас поспать, а посмотреть позже. К тому же такое ощущение, что преподы быстрее читают материал, не предполагая, что кто-то может конспектировать за ними. И тем более не предполагая, что среди студентов может быть дегенерат вроде меня, который не воспринимает информацию на слух. Чтобы понять, мне нужно либо 10 раз сказать это, либо мне 5 раз прочитать то же самое в текстовой форме.
По физике ничего не понимаю, знаю только формулу S = S0 + vt + at^2 / 2. Буду сейчас понемногу навёрстывать, что проходили.
По физике ничего не понимаю, знаю только формулу S = S0 + vt + at^2 / 2. Буду сейчас понемногу навёрстывать, что проходили.
211 Кб, 851x1280Послушал про угловую скорость и криволинейное движение (тангенциальное и нормальное ускорения). И про преобразования галилея (то, как связаны перемещения, скорости и ускорения в двух инерциальных системах отсчёта, которые движутся друг относительно друга с постоянной скоростью). Пока что вроде понятно, откуда берутся формулы.
Теперь надо помыться, потому что завтра утром у меня на это сил не хватит. И потом дальше посмотрю ещё физику.
Теперь надо помыться, потому что завтра утром у меня на это сил не хватит. И потом дальше посмотрю ещё физику.
187 Кб, 1278x1920Долго не мог собраться с тем, чтобы пойти помыться, но, в конце концов, заставил себя. Досмотрел лекцию по физике про закон сохранения импульса, про силы, центр инерции для набора материальных точек и как из этого вывести формулу импульса для большого тела. Немного подправил свой кривой монолог и распечатал его, чтобы завтра монотонным голосом с запинками зачитать его.
Блять, сука, пиздец, я нихуя не сделал, я спать. Надеюсь, получится заснуть. Иногда не получается успокоиться и нихуя не можешь уснуть.
Блять, сука, пиздец, я нихуя не сделал, я спать. Надеюсь, получится заснуть. Иногда не получается успокоиться и нихуя не можешь уснуть.
>>12090
Чуть только речь зашла про дилдаки и очко, а пидар уже тут как тут xD
Чуть только речь зашла про дилдаки и очко, а пидар уже тут как тут xD
186 Кб, 810x1080>>12268
Один из трех ДСов.
По информатике сейчас на лекции рассказывают про VBA в экселе, нихуя не понимаю, лектор тупо слайды показывает с разным кодом и методами для разных объектов, а куда этот код в экселе вводится и зачем это надо - непонятно. Вроде им можно делать графический интерфейс для взаимодействия с API экселя и макросами. На практиках мы формулы в таблицах всё ещё проходим. Может, на следующей паре практики будут макросы.
Утром проснулся часов в шесть без будильника в каком-то ебанутом состоянии. Это не тревога и не паника, хуй знает, не могу объяснить.
Короче, нихуя я сегодня этот монолог не сдал, и никто тоже не сдавал, решили в следующий раз, через две недели. Препод рассказала, что конкретно требовалось от монолога, там, оказывается, ещё надо анализ написать и аргументы должны быть желательно сильные. А с моей тупой темой сильных аргументов не напишешь. Наверное, придётся потом выбрать другую тему, только теперь я вообще не знаю, какую. Блять, ну какого хуя.
На первой лабораторной по физике тыкали в секундомер в определённое время, чтобы получить набор значений, для которых надо будет потом посчитать всякие вещи и построить гистограмму распределения значений. Потом сделаю. Только для гистограммы надо будет где-то купить миллиметровую бумагу.
На плюсах рассказывали вроде про тайпдефы и юнионы и немного про области видимости переменных. Но я не очень хорошо понял, потому что половину лекции пришлось смотреть с обоссанного куска пластмассы, пока ехал домой, из-за того, что дистанционная лекция шла сразу после очных занятий.
Один из трех ДСов.
По информатике сейчас на лекции рассказывают про VBA в экселе, нихуя не понимаю, лектор тупо слайды показывает с разным кодом и методами для разных объектов, а куда этот код в экселе вводится и зачем это надо - непонятно. Вроде им можно делать графический интерфейс для взаимодействия с API экселя и макросами. На практиках мы формулы в таблицах всё ещё проходим. Может, на следующей паре практики будут макросы.
Утром проснулся часов в шесть без будильника в каком-то ебанутом состоянии. Это не тревога и не паника, хуй знает, не могу объяснить.
Короче, нихуя я сегодня этот монолог не сдал, и никто тоже не сдавал, решили в следующий раз, через две недели. Препод рассказала, что конкретно требовалось от монолога, там, оказывается, ещё надо анализ написать и аргументы должны быть желательно сильные. А с моей тупой темой сильных аргументов не напишешь. Наверное, придётся потом выбрать другую тему, только теперь я вообще не знаю, какую. Блять, ну какого хуя.
На первой лабораторной по физике тыкали в секундомер в определённое время, чтобы получить набор значений, для которых надо будет потом посчитать всякие вещи и построить гистограмму распределения значений. Потом сделаю. Только для гистограммы надо будет где-то купить миллиметровую бумагу.
На плюсах рассказывали вроде про тайпдефы и юнионы и немного про области видимости переменных. Но я не очень хорошо понял, потому что половину лекции пришлось смотреть с обоссанного куска пластмассы, пока ехал домой, из-за того, что дистанционная лекция шла сразу после очных занятий.
288 Кб, 1000x1494Странная лекция по VBA, из которой я нихуя не понял, закончилась. Надо сделать тест по английскому и потом будет лекция по алгоритмам.
183 Кб, 720x1080Списал ответы Сделал тест по английскому, посидел на алгоритмах и пофапал. Рассказывали немного про разделяй и властвуй, конкретно про алгоритм поиска инверсий (модификация сортировки слиянием). И про динамическое программирование:
- поиск количества последовательностей из 0 и 1 длины n, у которых никакие две единицы не стоят рядом (сводится к вычислению числа фибоначчи)
- задача про лестницу: можно шагнуть на следующую ступеньку или через одну, у каждой ступеньки есть стоимость (может, отрицательная), найти максимальную возможную сумму в конце
- LCS
- рюкзак
- задача про то, какое минимальное количество скобок надо вставить в скобочную последовательность, чтобы сделать её корректной. Тут делается таблица значений d[j] - сколько надо добавить скобок в подстроку str[i, j]. Чтобы вычислить, берём максмум из str[i,k] + str[k+1,j] по всем возможным k. И проходимся по возрастанию длин подстрок.
Я так и не успел пока что сделать домашнее задание с прошлого раза. У нас оно даётся на две недели, так что хуй с ним, сделаю сразу два: на кучи (прошлое) и на динамику.
Преподам походу надоело, что на занятиях на вопросы отвечают только несколько человек, а остальные молчат, поэтому начали рандомно по имени вызывать. Вот вроде сидишь спокойно, а как спросят что-то, так сразу мозг отключается и забываешь все слова.
Надо поесть, а потом меня ждёт физика ночью и пробуждение в шесть утра на ёбаную блять физкультуру в восемь утра. Но если быть честным с самим собой, только благодаря ней я ещё немного двигаюсь.
- поиск количества последовательностей из 0 и 1 длины n, у которых никакие две единицы не стоят рядом (сводится к вычислению числа фибоначчи)
- задача про лестницу: можно шагнуть на следующую ступеньку или через одну, у каждой ступеньки есть стоимость (может, отрицательная), найти максимальную возможную сумму в конце
- LCS
- рюкзак
- задача про то, какое минимальное количество скобок надо вставить в скобочную последовательность, чтобы сделать её корректной. Тут делается таблица значений d[j] - сколько надо добавить скобок в подстроку str[i, j]. Чтобы вычислить, берём максмум из str[i,k] + str[k+1,j] по всем возможным k. И проходимся по возрастанию длин подстрок.
Я так и не успел пока что сделать домашнее задание с прошлого раза. У нас оно даётся на две недели, так что хуй с ним, сделаю сразу два: на кучи (прошлое) и на динамику.
Преподам походу надоело, что на занятиях на вопросы отвечают только несколько человек, а остальные молчат, поэтому начали рандомно по имени вызывать. Вот вроде сидишь спокойно, а как спросят что-то, так сразу мозг отключается и забываешь все слова.
Надо поесть, а потом меня ждёт физика ночью и пробуждение в шесть утра на ёбаную блять физкультуру в восемь утра. Но если быть честным с самим собой, только благодаря ней я ещё немного двигаюсь.
848 Кб, 1440x2160Сука, я снова проебался и нихуя почти не сделал из-за того, что три часа провтыкал в комп прежде, чем сесть за физику. Там вроде было про то, что точка в постоянном однородном поле по параболе движется, блять, я уже забыл ахуенно. И ещё задачи про импульсы, тупо в формулы подставляешь значения и интегрируешь, чтобы выразить что-то другое. Нихуя не поспал из-за этого.
Единственное я не понял, почему, если бросить тело под углом, то перед приземлением у него будет начальная скорость.
На практичкском занятии по физике были задачи на кинетическую энергию и момент инерции, это я ещё не проходил, местами было непонятно.
На физкультуре на 3км прибежал последним из тех, кто плохо бегает. За 18:30, лол. Один раз в середине на шаг перешёл.
Единственное я не понял, почему, если бросить тело под углом, то перед приземлением у него будет начальная скорость.
На практичкском занятии по физике были задачи на кинетическую энергию и момент инерции, это я ещё не проходил, местами было непонятно.
На физкультуре на 3км прибежал последним из тех, кто плохо бегает. За 18:30, лол. Один раз в середине на шаг перешёл.
734 Кб, 1200x1800Блять, ходить по поребрикам - ахуенное развлечение, особенно, когда мимо тебя рядом проезжают машины. Какой же еблан.
До следующей пары ещё полтора часа, хуй знает, чем себя занять без компа. Пойду делать домашку по математике.
Можно было бы сходить поесть, но я боюсь столовых. И общественных туалетов, потому что не умею писать стоя. Блять. Съел шоколадку и изменил коле с фантой. Пиздец.
До следующей пары ещё полтора часа, хуй знает, чем себя занять без компа. Пойду делать домашку по математике.
Можно было бы сходить поесть, но я боюсь столовых. И общественных туалетов, потому что не умею писать стоя. Блять. Съел шоколадку и изменил коле с фантой. Пиздец.
132 Кб, 982x1472Вчера пиздец чуть не сдох из-за того, что слишком мало спал. Домашка по математике совсем небольшой оказалась, там только несколько пределов по демидовичу, но блять, как обычно нихуя не очевидно, какие преобразования надо делать, чтобы привести выражение под пределом к более удобному.
Пара была по микроэлектронике, на ней мы сдаём лабы. Большую часть времени в очереди сидим, я еле вытерпел. Пытался листать книжку, но она никак не лезла в голову. А лаба, которую защищали совсем простая была и она была одной из первых по счёту, но у меня была не сдана вовремя. Там надо было перерисовать из учебника простой генератор импульсов и формирователь импульсов, который по фронту и спаду даёт импульс. И разобраться с тем, как они работают.
Дали банковскую карту для стипендии, но проверить, сколько на ней денег, я не могу, потому что она какого-то хуя не привязяана к моему номеру. Придется, наверное, идти искать банкомат, чтобы это сделать. Карта кажется беспроводная, можно тупа прикладывать, чтобы расплатиться. Интересна, что поддерживается обратная совместимость: на ней есть ещё и контакты наружу как на симкарте, и магнитная полоса.
Сотовый оператор звонит уже дня четыре подряд по несколько раз на дню, блять, ну хули им надо от меня? Может быть из-за того, что я абужу их микрокредит, потому что постоянно забываю попросить родителей скинуть денег на телефон. И я по-хорошему уже должен быть неделю с минусовым балансом. Но, блять, нельзя что ли смску написать, что мол заплати уже, мудила. Сука, я не хочу разговаривать с вами.
Нихуя не делал вчера, боролся со сном до конца дня, потому что спать днём - полная хуйня: потом либо ночью просыпаешься, либо тебя через пару часов сна родители будят, чтобы поужинать, и ты нихуя не понимаешь, что происходит вокруг, кто ты и какого хуя вообще.
Пара была по микроэлектронике, на ней мы сдаём лабы. Большую часть времени в очереди сидим, я еле вытерпел. Пытался листать книжку, но она никак не лезла в голову. А лаба, которую защищали совсем простая была и она была одной из первых по счёту, но у меня была не сдана вовремя. Там надо было перерисовать из учебника простой генератор импульсов и формирователь импульсов, который по фронту и спаду даёт импульс. И разобраться с тем, как они работают.
Дали банковскую карту для стипендии, но проверить, сколько на ней денег, я не могу, потому что она какого-то хуя не привязяана к моему номеру. Придется, наверное, идти искать банкомат, чтобы это сделать. Карта кажется беспроводная, можно тупа прикладывать, чтобы расплатиться. Интересна, что поддерживается обратная совместимость: на ней есть ещё и контакты наружу как на симкарте, и магнитная полоса.
Сотовый оператор звонит уже дня четыре подряд по несколько раз на дню, блять, ну хули им надо от меня? Может быть из-за того, что я абужу их микрокредит, потому что постоянно забываю попросить родителей скинуть денег на телефон. И я по-хорошему уже должен быть неделю с минусовым балансом. Но, блять, нельзя что ли смску написать, что мол заплати уже, мудила. Сука, я не хочу разговаривать с вами.
Нихуя не делал вчера, боролся со сном до конца дня, потому что спать днём - полная хуйня: потом либо ночью просыпаешься, либо тебя через пару часов сна родители будят, чтобы поужинать, и ты нихуя не понимаешь, что происходит вокруг, кто ты и какого хуя вообще.
763 Кб, 1440x2160Прямо сейчас уже успел проебать лекцию по матану, потому что проспал. Через полчаса будет лекция по микроэлектронике, которую лучше всё же послушать.
Перед этим надо умыться, почистить зубы и найти еду. Параллельно лекции нада доделать домашку по html и попробовать сделать домашку по плюсам.
Я думал материться и писать мерзости весело, но нифига чёта чувствую себя грязным себя.
Перед этим надо умыться, почистить зубы и найти еду. Параллельно лекции нада доделать домашку по html и попробовать сделать домашку по плюсам.
Я думал материться и писать мерзости весело, но нифига чёта чувствую себя грязным себя.
320 Кб, 1299x1949Да, блин, опять провтыкал в комп несколько часов.
Лекцию по схемотехнике послушал, ничего не понял. Кажется, про счётчики было. Потом в любом случае придётся перечитывать и вникать, чтобы сделать лабу по этой теме.
Только стоило тут пожаловаться на банковскую карту, так сразу всё исправили. Неудивительно, наверняка мои фио уже привязаны к треду и ко мне приставлен личный товарищ майор для отслеживания всей моей интернетовой активности. Уже лежат пять с половиной тысч, неплохо. Можно было бы за телефон заплатить, чтобы мне перестал названивать оператор, сука, уже три раза звонили за сегодня, мне не по себе но я как образцовый мудак попрошу родителей, чтобы не тратить деньги с карты.
Всё, иду делать домашку по плюсам. По html сделал коммит в пулл-реквест с небольшими изменениями. Там пока что только структура, без стилей. Давно надо было сделать, чтобы препод дал апрув, но я боялся писать комментарии и коммитить, поэтому откладывал. Если Когда заапрувит, надо будет начать писать css.
Лекцию по схемотехнике послушал, ничего не понял. Кажется, про счётчики было. Потом в любом случае придётся перечитывать и вникать, чтобы сделать лабу по этой теме.
Только стоило тут пожаловаться на банковскую карту, так сразу всё исправили. Неудивительно, наверняка мои фио уже привязаны к треду и ко мне приставлен личный товарищ майор для отслеживания всей моей интернетовой активности. Уже лежат пять с половиной тысч, неплохо. Можно было бы за телефон заплатить, чтобы мне перестал названивать оператор, сука, уже три раза звонили за сегодня, мне не по себе но я как образцовый мудак попрошу родителей, чтобы не тратить деньги с карты.
Всё, иду делать домашку по плюсам. По html сделал коммит в пулл-реквест с небольшими изменениями. Там пока что только структура, без стилей. Давно надо было сделать, чтобы препод дал апрув, но я боялся писать комментарии и коммитить, поэтому откладывал. Если Когда заапрувит, надо будет начать писать css.
283 Кб, 1366x2048Я опять хуй знает что делал и нихуя не сделал.
Надо умыться и почистить зубы сейчас.
По плюсам домашку не сделал, но вроде понял, как работают разные массивы, оказывается, они на стеке могут храниться. Домашка сама простая: нужно прочитать один массив из консоли и несколько массивов из файла и переставить в них элементы. Но я не могу понять, как хранить массивы из массивов. Хранить отдельно размеры для каждого из них? Использовать векторы? Через минут пятнадцать занятие по программированию, можно было бы спросить, но боюсь.
И где освобождать память от массивов непонятно: если есть блок try, где выделяется память под массив и в нём же выбрасывается исключение, то в catch же нет доступа к переменным из try. Нужно что ли объявлять указатели на массивы перед try?
Ещё и забыл, что вчера вечером лекция по джаве, пропустил первые минут 20. Было про стандартные фукнциональные интерфейсы, статические удобные методы, связанные с ними, и стрим апи. Внезапно понял, почему внутри лямбд нельзя изменять значения переменных снаружи: потому что в джаве нет замыканий как в js. Про сплитераторы и параллельные стримы только мельком упоминалось, не понял ничего.
Надо умыться и почистить зубы сейчас.
По плюсам домашку не сделал, но вроде понял, как работают разные массивы, оказывается, они на стеке могут храниться. Домашка сама простая: нужно прочитать один массив из консоли и несколько массивов из файла и переставить в них элементы. Но я не могу понять, как хранить массивы из массивов. Хранить отдельно размеры для каждого из них? Использовать векторы? Через минут пятнадцать занятие по программированию, можно было бы спросить, но боюсь.
И где освобождать память от массивов непонятно: если есть блок try, где выделяется память под массив и в нём же выбрасывается исключение, то в catch же нет доступа к переменным из try. Нужно что ли объявлять указатели на массивы перед try?
Ещё и забыл, что вчера вечером лекция по джаве, пропустил первые минут 20. Было про стандартные фукнциональные интерфейсы, статические удобные методы, связанные с ними, и стрим апи. Внезапно понял, почему внутри лямбд нельзя изменять значения переменных снаружи: потому что в джаве нет замыканий как в js. Про сплитераторы и параллельные стримы только мельком упоминалось, не понял ничего.
100 Кб, 868x1472Блядь, ну и нахуя я посмотрел в зеркало на своё ебло, просто пиздец. Испорчено настроение на весь день напоминанием о том, какой я всратый гремлин.
256 Кб, 619x1080>>13177
Ага. Наверное, потому что много людей в одну аудиторию нельзя сейчас.
Ага. Наверное, потому что много людей в одну аудиторию нельзя сейчас.
90 Кб, 880x880>>13143
Очень желательно использовать встроенные средства (vector), либо, если уж работать с памятью и другими ресурсами руками, то либо тоже использовать встроенные средства (shared_ptr), либо делать свои классы, где выделять ресурсы в конструкторах и освобождать в деструкторах. В ванильном C++ нет явного finally, вместо этого каждый объект с деструктором, объявленный в { скоупе }, попадает в персональный неявный try-finally до конца { скоупа } и уничтожается при любом выходе из { скоупа }, в том числе при исключении.
Вот пример ручного 3D-массива: https://ideone.com/gYFb8y. Если массив концептуально представляет собой не jagged array — массив массивов разной длины, а K-мерный прямоугольник — массив массивов одинаковой длины, то можно его вытянуть в одномерный и для доступа к конкретной ячейке вычислять её индекс, типа (x, y) → y × width + x или (x, y, z) → z × height × width + y × width + x. Но тебе, наверное, нужны именно jagged — тогда да, можно хранить массив структур { размер; указатель } или просто использовать vector<vector>. Впрочем, скорее всего, можно вообще не хранить предыдущие массивы, а только текущий, который после обработки и вывода забывать.
Оч крутой тредик и оч красивые девочки, подписался ^__^ Я, кстати, тоже крутой физик и программист: вот здесь >>343734 → я рассказывал другому крутому программисту @PoppyFanboy про формулу >а-икс-квадрат, а вот здесь https://2ch.hk/dr/src/17085/15426096128102.webm (
М) делал игру VISIBLE FIGHTERS, в которой использовал >LCS для сокращения команд. У нас так много общего, давай дружить?
>И где освобождать память от массивов
Очень желательно использовать встроенные средства (vector), либо, если уж работать с памятью и другими ресурсами руками, то либо тоже использовать встроенные средства (shared_ptr), либо делать свои классы, где выделять ресурсы в конструкторах и освобождать в деструкторах. В ванильном C++ нет явного finally, вместо этого каждый объект с деструктором, объявленный в { скоупе }, попадает в персональный неявный try-finally до конца { скоупа } и уничтожается при любом выходе из { скоупа }, в том числе при исключении.
Вот пример ручного 3D-массива: https://ideone.com/gYFb8y. Если массив концептуально представляет собой не jagged array — массив массивов разной длины, а K-мерный прямоугольник — массив массивов одинаковой длины, то можно его вытянуть в одномерный и для доступа к конкретной ячейке вычислять её индекс, типа (x, y) → y × width + x или (x, y, z) → z × height × width + y × width + x. Но тебе, наверное, нужны именно jagged — тогда да, можно хранить массив структур { размер; указатель } или просто использовать vector<vector>. Впрочем, скорее всего, можно вообще не хранить предыдущие массивы, а только текущий, который после обработки и вывода забывать.
Оч крутой тредик и оч красивые девочки, подписался ^__^ Я, кстати, тоже крутой физик и программист: вот здесь >>343734 → я рассказывал другому крутому программисту @PoppyFanboy про формулу >а-икс-квадрат, а вот здесь https://2ch.hk/dr/src/17085/15426096128102.webm (
М) делал игру VISIBLE FIGHTERS, в которой использовал >LCS для сокращения команд. У нас так много общего, давай дружить?
306 Кб, 1280x960>>13179
На парах пока что не проходили это, только векторы, но сказали, короче, надо массивами обычными.
Да, думаю так и сделаю.
Думал об этом. Так проще, но мне хочется массив массивов.
Непонятно нафига в плюсах так много типов данных size_t, ptrdiff_t и прочие и что они все означают и зачем суффикс на конце. Суффикс походу, чтобы не засорять пространство имён. size_t для размеров структур данных, ptrdiff_t для арифметики с указателями, поэтому он допускает отрицательные значения. Но зачем тогда использовать ptrdiff_t в конструкторе строки при создании pad. А, потому что нам нужны в том числе отрицательные зачения.
https://stackoverflow.com/questions/28247733/is-it-safe-to-use-negative-integers-with-size-t
>vector
>shared_ptr
>делать свои классы, где выделять ресурсы в конструкторах и освобождать в деструкторах
На парах пока что не проходили это, только векторы, но сказали, короче, надо массивами обычными.
>массив структур { размер; указатель }
Да, думаю так и сделаю.
>не хранить предыдущие массивы, а только текущий, который после обработки и вывода забывать.
Думал об этом. Так проще, но мне хочется массив массивов.
>Вот пример ручного 3D-массива: https://ideone.com/gYFb8y
Непонятно нафига в плюсах так много типов данных size_t, ptrdiff_t и прочие и что они все означают и зачем суффикс на конце. Суффикс походу, чтобы не засорять пространство имён. size_t для размеров структур данных, ptrdiff_t для арифметики с указателями, поэтому он допускает отрицательные значения. Но зачем тогда использовать ptrdiff_t в конструкторе строки при создании pad. А, потому что нам нужны в том числе отрицательные зачения.
>It's well defined to use unsigned integers (and size_t is unsigned) this way, with wraparound: that behavior is guaranteed by the standard, as opposed to with signed integers, where it's not guaranteed by the standard.
>It is however needlessly clever.
>As a general rule, to avoid problems due to implicit wrapping promotions to unsigned, use unsigned integers for bit-level stuff, use signed integers for numbers. Where you need a signed integer corresponding to size_t there's ptrdiff_t for you.
https://stackoverflow.com/questions/28247733/is-it-safe-to-use-negative-integers-with-size-t
393 Кб, 1024x1535Посидел на занятии по плюсам и на информатике. На плюсах ничего не было, в теории мы должны были задавать вопросы преподу, но никто ничего не спрашивал. Поэтому нам по второму кругу он рассказал про то, что такое структуры и юнионы. Лекции у нас не очень хорошие, на практиках часто проходим то, что было на лекциях заново, потому что много кто так себе понимает. Либо у нас принимают домашки. И потом вместе читали немного запутанный код с поинтерами и ссылками и угадывали значения переменных, но я нифига не понял, потому что путался в названиях переменных.
На информатике опять электронные таблицы. Я так понял самая полезные фукнции это vlookup/hlookup для поиска (по умолчанию двоичный, котоорый возвращет минимальный ключ) и sumif/countif для удобного подсчёта и суммирования.
Апрувнули мой пулл-реквест с html структурой приложения. А сама пара по html уже через час, не хочу сейчас пытаться писать css. Может, на паре расскажут что-нибудь, что я потом использую. На прошлой было про контексты форматирования inline/block/inline-block, но я слабо понял если честно и не удосужился посмотреть за неделю.
Сейчас попробую доделать домашку по плюсам, если останется ещё время, то начну делать старую домашку по алгоритмам про кучи. Потом надо будет ещё английский на завтра сделать.
На информатике опять электронные таблицы. Я так понял самая полезные фукнции это vlookup/hlookup для поиска (по умолчанию двоичный, котоорый возвращет минимальный ключ) и sumif/countif для удобного подсчёта и суммирования.
Апрувнули мой пулл-реквест с html структурой приложения. А сама пара по html уже через час, не хочу сейчас пытаться писать css. Может, на паре расскажут что-нибудь, что я потом использую. На прошлой было про контексты форматирования inline/block/inline-block, но я слабо понял если честно и не удосужился посмотреть за неделю.
Сейчас попробую доделать домашку по плюсам, если останется ещё время, то начну делать старую домашку по алгоритмам про кучи. Потом надо будет ещё английский на завтра сделать.
323 Кб, 720x1080Чёто снова не сильно понял по html ничего. Из контекстов форматирования он рассказывал про флексы и гриды, упомянул про колонки. И ещё рассказал про position, z-index и трансформы. Он много чего показывает на примерах, но все они слишком вырожденные, нагромождение прямоугольников разноцветных, из-за чего вообще нифига не понятно, как что где использовать. Ну, примерно понятно, что но выглядит так, будто там очень много нюансов из-за того, что все эти свойства рандомно комбинируются. Придётся потом самому со всем разобраться и попробовать на практике. Может, его же примеры на jsfiddle пересмотреть.
Домашку по плюсам вроде доделал, но там совсем кошмар получился. Попробовал прогнать её через valgrind, внезапно обнаружил, что забыл удалить массив из указателей на массивы. Полезно. Он ещё умеет находить моменты, когда ты обращаешься к неправильному индексу массива. По алгоритмам домашку не успел даже начать.
Сейчас надо помыться и сделать английский. Потом, может быть, посмотрю-таки домашку по алгоритмам, надо хотя бы начать. Потом спать.
Домашку по плюсам вроде доделал, но там совсем кошмар получился. Попробовал прогнать её через valgrind, внезапно обнаружил, что забыл удалить массив из указателей на массивы. Полезно. Он ещё умеет находить моменты, когда ты обращаешься к неправильному индексу массива. По алгоритмам домашку не успел даже начать.
Сейчас надо помыться и сделать английский. Потом, может быть, посмотрю-таки домашку по алгоритмам, надо хотя бы начать. Потом спать.
1,3 Мб, 1051x1487>>13220
А, я не знал, что ssize_t встроенный, так бы использовал его вместо ptrdiff_t.
Да нет, там проблема хуже и явнее, чем абстрактная неопределённость знакового переполнения: по правилам C++, вычитание, одним из операндов которого является беззнаковый тип, даёт БЕЗЗНАКОВЫЙ результат. Иногда, если ты его интерпретируешь как знаковый ТОГО ЖЕ РАЗМЕРА, всё работает, но в общем случае не будет. Немного переделанное выражение из моего пада: https://ideone.com/2BG3Zw. Второй аргумент оказывается антипереполненным uint32. Если мы переинтерпретируем его как int32 (или просто int), то происходящее при этом второе переполнение скомпенсирует первое и результат окажется правильным; но я специально расширил результат до int64, чтобы второго переполнения не произошло.
Несмотря на это, мне нравятся беззнаковые типы тем, что могут быстрее работать. Особенно сосёт деление знаковых типов на константы: деление беззнаковых на константы компиляторы оптимизируют до умножения со сдвигом (https://zneak.github.io/fcd/2017/02/19/divisions.html, это первая ссылка из гугла, видел статьи по этой теме поконкретнее, вплоть до полной методички по алгоритму), со знаковыми это тоже возможно, но становится настолько сложнее, что может поставить под вопрос само преимущество всех этих финтов ушами относительно прямого IDIV. Даже беззнаковые деления на степени двойки в несколько раз проще знаковых. См. картинку: >>327206 →.
Альтернативное мнение (NVIDIA на это упирает) — поскольку исторически сложилось, что у беззнаковых типов определено поведение при переполнении, а у знаковых не определено, вторые дают компилятору больше свободы для оптимизации. И в целом они удобнее и позволяют избежать проблем с преобразованиями, вроде возникшей у меня (а на это упирает гугловский код конвеншн).
Но какой ценой! Если мы работаем на 32-битной платформе, то, используя знаковые типы, мы теряем возможность работать с 2 гигабайтами адресного пространства из 4. Аналогичная проблема с любыми другими выражениями чего-то неотрицательного, особенно маленькими типами: мы теряем половину пространства, из которого используем в лучшем случае единственное значение −1, роль которого в беззнаковом варианте можно переложить на numeric_limits<>::max. А 90% наших функций работают с неотрицательными числами by design (индексы, количества и проч.), и при использовании знаковых им придётся параноить аргументы на отрицательность, то есть каждый раз снова и снова отсекать эту половину собственными руками. Это как если бы ты запер человека в подвале и заставил отрезать собственные конечности.
Да и неопределённость знакового переполнения может вылезти нам боком: если у нас есть 32-битный миллисекундный таймер, то он переполняется каждые 49,7 дней, но несмотря на это, вычитание из более поздней временной отметки более ранней всегда даст правильную разность (с точностью до периода). В знаковых числах это может сломаться, когда компилятору приспичит соптимизировать код в предположении, что переполнения не происходит.
Много типов — это прекрасно, более того, для каждого своего чиха можно, и нужно, вводить свои. Например, у тебя есть двухмерная сетка. Какой тип использовать для работы с координатами ячеек — ssize_t, int, long, int16_t, int32_t, int64_t? Не, нифига: нужно сделать typedef желаемый_тип coord_t и везде использовать coord_t. Тогда типы твоих переменных становятся наполненными семантикой и смыслом: vector<coord_t> — список не безликих чисел, но координат.
А, я не знал, что ssize_t встроенный, так бы использовал его вместо ptrdiff_t.
Да нет, там проблема хуже и явнее, чем абстрактная неопределённость знакового переполнения: по правилам C++, вычитание, одним из операндов которого является беззнаковый тип, даёт БЕЗЗНАКОВЫЙ результат. Иногда, если ты его интерпретируешь как знаковый ТОГО ЖЕ РАЗМЕРА, всё работает, но в общем случае не будет. Немного переделанное выражение из моего пада: https://ideone.com/2BG3Zw. Второй аргумент оказывается антипереполненным uint32. Если мы переинтерпретируем его как int32 (или просто int), то происходящее при этом второе переполнение скомпенсирует первое и результат окажется правильным; но я специально расширил результат до int64, чтобы второго переполнения не произошло.
Несмотря на это, мне нравятся беззнаковые типы тем, что могут быстрее работать. Особенно сосёт деление знаковых типов на константы: деление беззнаковых на константы компиляторы оптимизируют до умножения со сдвигом (https://zneak.github.io/fcd/2017/02/19/divisions.html, это первая ссылка из гугла, видел статьи по этой теме поконкретнее, вплоть до полной методички по алгоритму), со знаковыми это тоже возможно, но становится настолько сложнее, что может поставить под вопрос само преимущество всех этих финтов ушами относительно прямого IDIV. Даже беззнаковые деления на степени двойки в несколько раз проще знаковых. См. картинку: >>327206 →.
Альтернативное мнение (NVIDIA на это упирает) — поскольку исторически сложилось, что у беззнаковых типов определено поведение при переполнении, а у знаковых не определено, вторые дают компилятору больше свободы для оптимизации. И в целом они удобнее и позволяют избежать проблем с преобразованиями, вроде возникшей у меня (а на это упирает гугловский код конвеншн).
Но какой ценой! Если мы работаем на 32-битной платформе, то, используя знаковые типы, мы теряем возможность работать с 2 гигабайтами адресного пространства из 4. Аналогичная проблема с любыми другими выражениями чего-то неотрицательного, особенно маленькими типами: мы теряем половину пространства, из которого используем в лучшем случае единственное значение −1, роль которого в беззнаковом варианте можно переложить на numeric_limits<>::max. А 90% наших функций работают с неотрицательными числами by design (индексы, количества и проч.), и при использовании знаковых им придётся параноить аргументы на отрицательность, то есть каждый раз снова и снова отсекать эту половину собственными руками. Это как если бы ты запер человека в подвале и заставил отрезать собственные конечности.
Да и неопределённость знакового переполнения может вылезти нам боком: если у нас есть 32-битный миллисекундный таймер, то он переполняется каждые 49,7 дней, но несмотря на это, вычитание из более поздней временной отметки более ранней всегда даст правильную разность (с точностью до периода). В знаковых числах это может сломаться, когда компилятору приспичит соптимизировать код в предположении, что переполнения не происходит.
>Непонятно нафига в плюсах так много типов данных
Много типов — это прекрасно, более того, для каждого своего чиха можно, и нужно, вводить свои. Например, у тебя есть двухмерная сетка. Какой тип использовать для работы с координатами ячеек — ssize_t, int, long, int16_t, int32_t, int64_t? Не, нифига: нужно сделать typedef желаемый_тип coord_t и везде использовать coord_t. Тогда типы твоих переменных становятся наполненными семантикой и смыслом: vector<coord_t> — список не безликих чисел, но координат.
1,3 Мб, 1051x1487>>13220
А, я не знал, что ssize_t встроенный, так бы использовал его вместо ptrdiff_t.
Да нет, там проблема хуже и явнее, чем абстрактная неопределённость знакового переполнения: по правилам C++, вычитание, одним из операндов которого является беззнаковый тип, даёт БЕЗЗНАКОВЫЙ результат. Иногда, если ты его интерпретируешь как знаковый ТОГО ЖЕ РАЗМЕРА, всё работает, но в общем случае не будет. Немного переделанное выражение из моего пада: https://ideone.com/2BG3Zw. Второй аргумент оказывается антипереполненным uint32. Если мы переинтерпретируем его как int32 (или просто int), то происходящее при этом второе переполнение скомпенсирует первое и результат окажется правильным; но я специально расширил результат до int64, чтобы второго переполнения не произошло.
Несмотря на это, мне нравятся беззнаковые типы тем, что могут быстрее работать. Особенно сосёт деление знаковых типов на константы: деление беззнаковых на константы компиляторы оптимизируют до умножения со сдвигом (https://zneak.github.io/fcd/2017/02/19/divisions.html, это первая ссылка из гугла, видел статьи по этой теме поконкретнее, вплоть до полной методички по алгоритму), со знаковыми это тоже возможно, но становится настолько сложнее, что может поставить под вопрос само преимущество всех этих финтов ушами относительно прямого IDIV. Даже беззнаковые деления на степени двойки в несколько раз проще знаковых. См. картинку: >>327206 →.
Альтернативное мнение (NVIDIA на это упирает) — поскольку исторически сложилось, что у беззнаковых типов определено поведение при переполнении, а у знаковых не определено, вторые дают компилятору больше свободы для оптимизации. И в целом они удобнее и позволяют избежать проблем с преобразованиями, вроде возникшей у меня (а на это упирает гугловский код конвеншн).
Но какой ценой! Если мы работаем на 32-битной платформе, то, используя знаковые типы, мы теряем возможность работать с 2 гигабайтами адресного пространства из 4. Аналогичная проблема с любыми другими выражениями чего-то неотрицательного, особенно маленькими типами: мы теряем половину пространства, из которого используем в лучшем случае единственное значение −1, роль которого в беззнаковом варианте можно переложить на numeric_limits<>::max. А 90% наших функций работают с неотрицательными числами by design (индексы, количества и проч.), и при использовании знаковых им придётся параноить аргументы на отрицательность, то есть каждый раз снова и снова отсекать эту половину собственными руками. Это как если бы ты запер человека в подвале и заставил отрезать собственные конечности.
Да и неопределённость знакового переполнения может вылезти нам боком: если у нас есть 32-битный миллисекундный таймер, то он переполняется каждые 49,7 дней, но несмотря на это, вычитание из более поздней временной отметки более ранней всегда даст правильную разность (с точностью до периода). В знаковых числах это может сломаться, когда компилятору приспичит соптимизировать код в предположении, что переполнения не происходит.
Много типов — это прекрасно, более того, для каждого своего чиха можно, и нужно, вводить свои. Например, у тебя есть двухмерная сетка. Какой тип использовать для работы с координатами ячеек — ssize_t, int, long, int16_t, int32_t, int64_t? Не, нифига: нужно сделать typedef желаемый_тип coord_t и везде использовать coord_t. Тогда типы твоих переменных становятся наполненными семантикой и смыслом: vector<coord_t> — список не безликих чисел, но координат.
А, я не знал, что ssize_t встроенный, так бы использовал его вместо ptrdiff_t.
Да нет, там проблема хуже и явнее, чем абстрактная неопределённость знакового переполнения: по правилам C++, вычитание, одним из операндов которого является беззнаковый тип, даёт БЕЗЗНАКОВЫЙ результат. Иногда, если ты его интерпретируешь как знаковый ТОГО ЖЕ РАЗМЕРА, всё работает, но в общем случае не будет. Немного переделанное выражение из моего пада: https://ideone.com/2BG3Zw. Второй аргумент оказывается антипереполненным uint32. Если мы переинтерпретируем его как int32 (или просто int), то происходящее при этом второе переполнение скомпенсирует первое и результат окажется правильным; но я специально расширил результат до int64, чтобы второго переполнения не произошло.
Несмотря на это, мне нравятся беззнаковые типы тем, что могут быстрее работать. Особенно сосёт деление знаковых типов на константы: деление беззнаковых на константы компиляторы оптимизируют до умножения со сдвигом (https://zneak.github.io/fcd/2017/02/19/divisions.html, это первая ссылка из гугла, видел статьи по этой теме поконкретнее, вплоть до полной методички по алгоритму), со знаковыми это тоже возможно, но становится настолько сложнее, что может поставить под вопрос само преимущество всех этих финтов ушами относительно прямого IDIV. Даже беззнаковые деления на степени двойки в несколько раз проще знаковых. См. картинку: >>327206 →.
Альтернативное мнение (NVIDIA на это упирает) — поскольку исторически сложилось, что у беззнаковых типов определено поведение при переполнении, а у знаковых не определено, вторые дают компилятору больше свободы для оптимизации. И в целом они удобнее и позволяют избежать проблем с преобразованиями, вроде возникшей у меня (а на это упирает гугловский код конвеншн).
Но какой ценой! Если мы работаем на 32-битной платформе, то, используя знаковые типы, мы теряем возможность работать с 2 гигабайтами адресного пространства из 4. Аналогичная проблема с любыми другими выражениями чего-то неотрицательного, особенно маленькими типами: мы теряем половину пространства, из которого используем в лучшем случае единственное значение −1, роль которого в беззнаковом варианте можно переложить на numeric_limits<>::max. А 90% наших функций работают с неотрицательными числами by design (индексы, количества и проч.), и при использовании знаковых им придётся параноить аргументы на отрицательность, то есть каждый раз снова и снова отсекать эту половину собственными руками. Это как если бы ты запер человека в подвале и заставил отрезать собственные конечности.
Да и неопределённость знакового переполнения может вылезти нам боком: если у нас есть 32-битный миллисекундный таймер, то он переполняется каждые 49,7 дней, но несмотря на это, вычитание из более поздней временной отметки более ранней всегда даст правильную разность (с точностью до периода). В знаковых числах это может сломаться, когда компилятору приспичит соптимизировать код в предположении, что переполнения не происходит.
>Непонятно нафига в плюсах так много типов данных
Много типов — это прекрасно, более того, для каждого своего чиха можно, и нужно, вводить свои. Например, у тебя есть двухмерная сетка. Какой тип использовать для работы с координатами ячеек — ssize_t, int, long, int16_t, int32_t, int64_t? Не, нифига: нужно сделать typedef желаемый_тип coord_t и везде использовать coord_t. Тогда типы твоих переменных становятся наполненными семантикой и смыслом: vector<coord_t> — список не безликих чисел, но координат.
196 Кб, 1230x1439>>13420
У меня numeric_limits выдаёт одинаковые min/max значения для ssize_t и для ptrdiff_t. Разве что для консистентности названий использовать?
Если честно, я пропустил глазами то, что я скопировал про неопределённость. Не знал про это.
Интересно.
https://codeforces.com/blog/entry/45144?#comment-297001
https://en.cppreference.com/w/cpp/language/ub#Signed_overflow
Тоже не знал про это. https://ideone.com/bZUQmB Кажется побеждает больший по размерности тип, либо беззнаковый, если размерности одинаковые.
Может так.
Два часа потратить на то, чтобы поесть и помыться чек. Два часа потратить на то, чтобы сделать английский чек. Там было немного больше заданий, чем я ожидал. Они все простые, но есть непонятные слова и ещё там были на чтение текста и слушание. Не сделать домашку по алгоритмам чек. Пойти спать поздно ночью ещё раз разочаровавшись с себе чек. Завтра только физкультура и английский будут, надеюсь, на последнем не будут заставлять разговаривать в парах.
Блядь, сука, раздавите меня нахуй самосвалом.
>А, я не знал, что ssize_t встроенный, так бы использовал его вместо ptrdiff_t.
У меня numeric_limits выдаёт одинаковые min/max значения для ssize_t и для ptrdiff_t. Разве что для консистентности названий использовать?
>Неопределённость знакового переполнения
Если честно, я пропустил глазами то, что я скопировал про неопределённость. Не знал про это.
Интересно.
https://codeforces.com/blog/entry/45144?#comment-297001
https://en.cppreference.com/w/cpp/language/ub#Signed_overflow
>вычитание, одним из операндов которого является беззнаковый тип, даёт БЕЗЗНАКОВЫЙ результат
Тоже не знал про это. https://ideone.com/bZUQmB Кажется побеждает больший по размерности тип, либо беззнаковый, если размерности одинаковые.
>vector<coord_t> — список не безликих чисел, но координат
Может так.
Два часа потратить на то, чтобы поесть и помыться чек. Два часа потратить на то, чтобы сделать английский чек. Там было немного больше заданий, чем я ожидал. Они все простые, но есть непонятные слова и ещё там были на чтение текста и слушание. Не сделать домашку по алгоритмам чек. Пойти спать поздно ночью ещё раз разочаровавшись с себе чек. Завтра только физкультура и английский будут, надеюсь, на последнем не будут заставлять разговаривать в парах.
Блядь, сука, раздавите меня нахуй самосвалом.
1,3 Мб, 1190x1505>>13500
Да, они будут одинаковыми. Просто size_t, по своей (((семантике))) — не только тип значения, возвращаемого sizeof, но ещё и тип индексов массивов (и вообще любых коллекций в памяти, по очевидной причине), в таком значении его использует стандартная библиотека и сообщество в целом. Его знаковый эквивалент, если очень надо — ptrdiff_t, однако название делает это неочевидным, ssize_t приятнее. (Но я там неправильно прочитал, ssize_t всё-таки не встроенный, его просто POSIX определяет.)
Да, они будут одинаковыми. Просто size_t, по своей (((семантике))) — не только тип значения, возвращаемого sizeof, но ещё и тип индексов массивов (и вообще любых коллекций в памяти, по очевидной причине), в таком значении его использует стандартная библиотека и сообщество в целом. Его знаковый эквивалент, если очень надо — ptrdiff_t, однако название делает это неочевидным, ssize_t приятнее. (Но я там неправильно прочитал, ssize_t всё-таки не встроенный, его просто POSIX определяет.)
Бля ка уже я жалею, что в свое время не пошёл на погромиста, щас бы не занимался хуйней а уже работал бы где нибудь в гугле
Девочки у тебя в дневнике красивые
Девочки у тебя в дневнике красивые
226 Кб, 1280x853Сходил на физкультуру, в этот раз даже удалось доплестись в конце строя, когда бегали. Обычно я сильно ото всех отстаю, потому что слишком медленно бегу. Кидались какими-то тяжёлыми мячами. На английском ничего особенного.
Пролистал теорию для лабы по микроэлектронике, примерно понял, что нужно и как что работает, но остались пара непонятных моментов. Там т-триггер - это тупо переключатель, но его нельзя сделать на одном RS-триггере, поставив защёлку на входы и завязав выходы на входы, потому что за время импульса RS триггер сможет несколько раз сменить своё состояние. Нужно сделать два соединённых RS-триггера с защёлками на входах, в начале импульса на входе T шла запись на первый, второй защёлкнутый был, а после окончания импульса - запись на второй, при этом первый защёлкивается.
И на т-триггерах, срабатывающих по фронту, можно сделать счётчик, если их последовательно воткнуть, на выходе каждого поставив инвертор. Тогда, подавая тактовые импульсы на первый, он будет переключаться каждый такт, второй т-триггер будет переключаться в два раза реже, третий ещё в два раза и так далее. Получается перебор бинарных чисел, если завязать выходы счётчика на выводы т-триггеров.
С домашкой по алгоритмам слишком туго пока что пошло. Сделаны сейчас только три задачи из пяти, при этом первая тупо на проверку, представляет ли массив кучу. Вторая - написать кучу, а третья - динамическая медиана при потоке добавляющихся элементов. Сделал очень тупо: храню две кучи и текущую медиану, отслеживаю чётность количества введённых чисел и на этом строю логику. Вроде можно условиться, что медиана хранится в одной из куч и не хранить её отдельно, но у меня даже моё простое решение вызвало трудности.
Нужно запомнить, что Ctrl+D - это конец ввода, потому что в некоторых задачах не указывается количество вводимых элементов и они вводятся "пока есть". Не знал, как в консоли сделать так.
Пролистал теорию для лабы по микроэлектронике, примерно понял, что нужно и как что работает, но остались пара непонятных моментов. Там т-триггер - это тупо переключатель, но его нельзя сделать на одном RS-триггере, поставив защёлку на входы и завязав выходы на входы, потому что за время импульса RS триггер сможет несколько раз сменить своё состояние. Нужно сделать два соединённых RS-триггера с защёлками на входах, в начале импульса на входе T шла запись на первый, второй защёлкнутый был, а после окончания импульса - запись на второй, при этом первый защёлкивается.
И на т-триггерах, срабатывающих по фронту, можно сделать счётчик, если их последовательно воткнуть, на выходе каждого поставив инвертор. Тогда, подавая тактовые импульсы на первый, он будет переключаться каждый такт, второй т-триггер будет переключаться в два раза реже, третий ещё в два раза и так далее. Получается перебор бинарных чисел, если завязать выходы счётчика на выводы т-триггеров.
С домашкой по алгоритмам слишком туго пока что пошло. Сделаны сейчас только три задачи из пяти, при этом первая тупо на проверку, представляет ли массив кучу. Вторая - написать кучу, а третья - динамическая медиана при потоке добавляющихся элементов. Сделал очень тупо: храню две кучи и текущую медиану, отслеживаю чётность количества введённых чисел и на этом строю логику. Вроде можно условиться, что медиана хранится в одной из куч и не хранить её отдельно, но у меня даже моё простое решение вызвало трудности.
Нужно запомнить, что Ctrl+D - это конец ввода, потому что в некоторых задачах не указывается количество вводимых элементов и они вводятся "пока есть". Не знал, как в консоли сделать так.
629 Кб, 1300x1733Всё же заставил себя доделать домашку по алгоритмам (у которой дедлайн во вторник на следующей неделе, есть ещё одна, на неё ещё одна неделя есть). Там был ещё тупо бинарный поиск и неочевидная задача про коров и стойла: даны отсортированные по возрастанию координаты стойл (целые числа на прямой) и надо разместить по ним коров так, чтобы максимизировать минимальное расстояние между соседними коровами. Я думал, тут перебор нужен, но нет.
Когда ищешь в отсортированном массиве бинарным поиском это можно представить как вычисление корня непрерывной монотонной фукнции, где фукнция - это зависимость значений элементов массива от индексов. А нет, нихуя она не непрерывная, иначе бы любой (почти) бинарный поиск был бы успешным, ну и ладно. Здесь то же самое, только аргументы - это минимальные расстояния между стойлами, а значений фукнции всего два: false/true. Можно или нет при заданном минимальном расстоянии выбрать стойла, которые бы ему соответствовали. При этом она монотонная: всё, что слева от true - тоже true (расстояние в 1 всегда подойдёт), что справа от false - тоже false.
Для проверки на возможность расстановки можно использовать тупо жадный алгоритм, который берёт первое стойло (потому что нет смысла начинать с любого другого, это только ухудшит результат) и дальше берёт каждое следующее подходящее. Если мы разместим коров прежде, чем кончатся стойла, расположение возможно.
При бинарном поиске, если находим подходящее минимальное расстояние mid, берём left = mid + 1, чтобы найти самое правое значение.
Нефига не очевидно.
Когда ищешь в отсортированном массиве бинарным поиском это можно представить как вычисление корня непрерывной монотонной фукнции, где фукнция - это зависимость значений элементов массива от индексов. А нет, нихуя она не непрерывная, иначе бы любой (почти) бинарный поиск был бы успешным, ну и ладно. Здесь то же самое, только аргументы - это минимальные расстояния между стойлами, а значений фукнции всего два: false/true. Можно или нет при заданном минимальном расстоянии выбрать стойла, которые бы ему соответствовали. При этом она монотонная: всё, что слева от true - тоже true (расстояние в 1 всегда подойдёт), что справа от false - тоже false.
Для проверки на возможность расстановки можно использовать тупо жадный алгоритм, который берёт первое стойло (потому что нет смысла начинать с любого другого, это только ухудшит результат) и дальше берёт каждое следующее подходящее. Если мы разместим коров прежде, чем кончатся стойла, расположение возможно.
При бинарном поиске, если находим подходящее минимальное расстояние mid, берём left = mid + 1, чтобы найти самое правое значение.
Нефига не очевидно.
256 Кб, 1365x2048Какая в пизду непрерывность фукнции, сука, блять, умный дохуя что ли. Спизданул хуйню и рад. Короче, если нормальными словами, всё сводится к тому, что есть массив [0, 0, ..., 0, 1, 1, ..., 1] и надо найти, в каком месте ноль сменяется единицей.
Я сука чёто беззаботный дохуя как будто всё в порядке блядь. А это абсолютно ложное ощущение и оторванность от реальности. Я живу не будущим и не сегодняшним, я нахуй, живу в параллельной вселенной, где я ёбаная волшебная фея. Пойду спать.
Я сука чёто беззаботный дохуя как будто всё в порядке блядь. А это абсолютно ложное ощущение и оторванность от реальности. Я живу не будущим и не сегодняшним, я нахуй, живу в параллельной вселенной, где я ёбаная волшебная фея. Пойду спать.
181 Кб, 1102x1472Добрае утро сейчас надо встать с кровати, умыться и почистить зубы. Потом поесть и сделать лабораторную по микроэлектронике. Я надеюсь в процессе меня раздавит потолок.
179 Кб, 700x1050Всё в порядке, я не потратил сучьи пять часов на простейшую лабу по микроэлектронике, в которой нужно было только нарисовать пару схем и написать пару строк (утрированно, конечно, но там и правда очень немного) на VHDL. Ещё и затупил немного, когда ещё раз разбирался со схемой т-триггера на двух RS-триггерах. Но теперь точно всё понял.
Блять, каждый день так, сука. Я начинаю делать что-то и потом отвлекаюсь и возращаюсь через час или полтора к тому, что делал. Потому что мне нихуя не интересно мне интересно только фапать и смотреть видео на ютубе.
Сейчас надо пофапать, а потом надо будет написать отчёт для домашки по плюсам. Я не знаю нахуя это у нас надо, вроде преподы адекватные, но всё равно требуют писать какую-то странную хуйность с описанием поведения программы. И я хотел её ещё немного поправить, потому что я хоть на словах и сказал, что там буду хранить массивы как структуру из указателя и размера, но на деле нихуя не сделал это и храню их отдельно в разных массивах. И ещё надо чтение из файла поправить.
Блядь какой сука долбаёб я надеюсь я сдохну нахуй скоро, какого хуя меня земля носит. А ещё надо сегодня физику посмотреть, пиздец, уже ведь весь день прошёл.
Блять, каждый день так, сука. Я начинаю делать что-то и потом отвлекаюсь и возращаюсь через час или полтора к тому, что делал. Потому что мне нихуя не интересно мне интересно только фапать и смотреть видео на ютубе.
Сейчас надо пофапать, а потом надо будет написать отчёт для домашки по плюсам. Я не знаю нахуя это у нас надо, вроде преподы адекватные, но всё равно требуют писать какую-то странную хуйность с описанием поведения программы. И я хотел её ещё немного поправить, потому что я хоть на словах и сказал, что там буду хранить массивы как структуру из указателя и размера, но на деле нихуя не сделал это и храню их отдельно в разных массивах. И ещё надо чтение из файла поправить.
Блядь какой сука долбаёб я надеюсь я сдохну нахуй скоро, какого хуя меня земля носит. А ещё надо сегодня физику посмотреть, пиздец, уже ведь весь день прошёл.
731 Кб, 1773x2364Доделал свою йоба программу, которая читает сука массивы пиздец, вот это да. Пиздец, триста строчек какой-та шизы, которая занимается только тем, что читает массивы, что-то делает с ними, а потом избавляется от них. Нахуя я бля живу сука.
3,4 Мб, 2000x3008Ебануться там ротозумы
https://youtu.be/-vtUCTX4qrA
Ебанутсья я два часа нихуя не делал.
Ну всё завариваю кофе и сажусь смотреть физику, сука, как же ничего не хочется, хочется заснуть и не просыпаться, нахуя я живу.
https://youtu.be/-vtUCTX4qrA
Ебанутсья я два часа нихуя не делал.
Ну всё завариваю кофе и сажусь смотреть физику, сука, как же ничего не хочется, хочется заснуть и не просыпаться, нахуя я живу.
189 Кб, 720x1080Пофапал ещё, нихуя не смог пройти по физике. Только три закона ньютона, закон всемирного тяготения. Что такое сила тяжести и вес тела. Не очень понял про инертную и гравитационную массы, вроде в классической механике GM подбирается так, чтобы они были равны. Просто вот в формуле F = mg, m - это вроде тот же коэффициент, который выбран при определении замкнутой системы тел: тот, при котором сумма импульсов постоянна. И он показывает, насколько тело инертно, то есть насколько сложно его двигать. А в формуле F = G Mm / r^2 - это гравитационная масса. И непонятно, одно ли это и то же. Вообще нихуя непонятно откуда эта формула взялась.
Или нет или наоборот это экспериментально выводится, что гравитационная масса и инертная - одно и то же, вернее, что они пропорциональны. Там ньютон какой-то эксперимент проводил с маятником типа на маятник действует сила притяжения, которая пропорциональна гравитационной массе, и центробежная сила (из за вращения земли), пропорциональная инертной массе. И если бы отношение этих масс не было константой, то он бы для разных грузов с разными инертными массами на маятнике получал бы разные отклонения? И видимо эту константу в классической механике выбрали тупо единицей. Не понимаю всё равно нормально.
Я подумал, что это ещё связано с маятником фуко, но наверное нет, потому что маятник фуко просто про вращение земли: если его на полюс земли сверху поставить и толкнуть, то он будет на земле рисовать цветочные узоры, потому что под ним земля проворачивается. И центробежная сила тут ни при чём.
Непонятно, как мерить отдельно массу земли. Есть какой-та эксперимент каведиша и он походу реально смотрел за тем, как маленькие шарики притягиваются к большим.
Не могу, не понимаю, мне ничего не хочется. Пойду спать.
Или нет или наоборот это экспериментально выводится, что гравитационная масса и инертная - одно и то же, вернее, что они пропорциональны. Там ньютон какой-то эксперимент проводил с маятником типа на маятник действует сила притяжения, которая пропорциональна гравитационной массе, и центробежная сила (из за вращения земли), пропорциональная инертной массе. И если бы отношение этих масс не было константой, то он бы для разных грузов с разными инертными массами на маятнике получал бы разные отклонения? И видимо эту константу в классической механике выбрали тупо единицей. Не понимаю всё равно нормально.
Я подумал, что это ещё связано с маятником фуко, но наверное нет, потому что маятник фуко просто про вращение земли: если его на полюс земли сверху поставить и толкнуть, то он будет на земле рисовать цветочные узоры, потому что под ним земля проворачивается. И центробежная сила тут ни при чём.
Непонятно, как мерить отдельно массу земли. Есть какой-та эксперимент каведиша и он походу реально смотрел за тем, как маленькие шарики притягиваются к большим.
Не могу, не понимаю, мне ничего не хочется. Пойду спать.
Красивые картинки, ОПчик.
827 Кб, 2727x4090Блять, ну какого хуя обоссанный майкрософт тимс решил послать меня на хуй именно сегодня и отказался шарить мой экран, чтобы сдать ебучую эту программу на плюсах. Причём это говно (тимс) даже ничего не выводит, ни сообщение об ошибке, ничего. Придётся хуй знает отдельно с преподом договариваться, ПИСАТЬ ему, сука, я не хочу блядь никому писать и ни с кем разговаривать, ну какого хуя.
Реально проще выпилиться.
Реально проще выпилиться.
4 Мб, 1654x2339>>13668
p a r t i t i o n p o i n t
>>13845
Так это целая философская проблема: https://en.wikipedia.org/wiki/AoS_and_SoA. Structure of arrays (SoA) кажется, и обычно является, непривлекательным и неудобным решением, но у него есть специфичные плюсы:
— Дружественность к SIMD, на x86 — SSE/AVX-арсеналу >>412748 →.
— Если часть полей обычно не нужна («обнулить z всем точкам»), работа с SoA будет эффективнее за счёт лучшей пространственной локальности. Если, наоборот, типичная обработка затрагивает несколько полей («посчитать x² + y² + z² для каждой точки»), AoS будет эффективнее... по той же причине :).
— С полями разного размера можно сэкономить на выравнивании. Представь, что у тебя есть энум из 100 форматов картинок: RGB8, RGBA32f и т. д., и ты хранишь в массиве format_info_struct format_info[100] (AoS) метаинформацию о них. Для примера возьмём за эту метаинформацию число каналов (1–4) и указатель на функцию считывания пикселя:
Пусть размер указателя get_pixel — 8, тогда компилятор выровняет его смещение в структуре, и размер самой структуры, на 8-байтовую границу, и структура займёт 16 байт, а 100 структур — 1600. Отключение выравнивания — #pragma pack(1) — сделает структуру 9-байтовой, но замедлит работу с ней.
Если же мы составим отдельные массивы (SoA)
— то выравнивание не понадобится, и наши метаданные займут 100+800 байт. (https://ideone.com/fIk3gd)
РАЗНЫЕ МЕЛОЧИ:
1. В статье в Википедии в недостатки SoA записано «inefficient indexed addressing», но я с этим не согласен. На x86 самая сложная адресация 1 ассемблерной командой — это [регистрА + смещение + регистрБ × красивый_размер], где «красивый_размер» — 1, 2, 4 или 8. Так что доступ к i-му элементу массива примитивных типов с красивыми размерами, как в SoA-варианте, выполняется в 1 действие. Для других размеров доступ усложняется, вплоть до честного умножения — чем не inefficient indexed addressing.
2.
Про это любит писать @oldnewthing.
Для RISC-архитектур, не умеющих читать невыровненные данные, скомпилируется нудная побайтовая сборка значения: https://devblogs.microsoft.com/oldnewthing/20200103-00/?p=103290.
Даже на x86 и других архитектурах с поддержкой невыровненного доступа он будет медленнее — поэтому выравнивание и используется даже для них: https://devblogs.microsoft.com/oldnewthing/20170428-00/?p=96065. TL;DR: сложные комбинации невыровненных операций не очень приятно отслеживать в ходе спекулятивного исполнения.
>>13973
Как раз всё очевидно: закон обратных квадратов (поэтому в знаменателе r²), каждая точка одного тела притягивает каждую точку другого (поэтому m1 × m2), G — коэффициент пропорциональности.
>есть массив [0, 0, ..., 0, 1, 1, ..., 1] и надо найти, в каком месте ноль сменяется единицей
p a r t i t i o n p o i n t
>>13845
>потому что я хоть на словах и сказал, что там буду хранить массивы как структуру из указателя и размера, но на деле нихуя не сделал это и храню их отдельно в разных массивах
Так это целая философская проблема: https://en.wikipedia.org/wiki/AoS_and_SoA. Structure of arrays (SoA) кажется, и обычно является, непривлекательным и неудобным решением, но у него есть специфичные плюсы:
— Дружественность к SIMD, на x86 — SSE/AVX-арсеналу >>412748 →.
— Если часть полей обычно не нужна («обнулить z всем точкам»), работа с SoA будет эффективнее за счёт лучшей пространственной локальности. Если, наоборот, типичная обработка затрагивает несколько полей («посчитать x² + y² + z² для каждой точки»), AoS будет эффективнее... по той же причине :).
— С полями разного размера можно сэкономить на выравнивании. Представь, что у тебя есть энум из 100 форматов картинок: RGB8, RGBA32f и т. д., и ты хранишь в массиве format_info_struct format_info[100] (AoS) метаинформацию о них. Для примера возьмём за эту метаинформацию число каналов (1–4) и указатель на функцию считывания пикселя:
>struct format_info_struct { uint8 channels; get_pixel_func get_pixel; }
Пусть размер указателя get_pixel — 8, тогда компилятор выровняет его смещение в структуре, и размер самой структуры, на 8-байтовую границу, и структура займёт 16 байт, а 100 структур — 1600. Отключение выравнивания — #pragma pack(1) — сделает структуру 9-байтовой, но замедлит работу с ней.
Если же мы составим отдельные массивы (SoA)
>uint8 channels[100];
>get_pixel_func get_pixel[100];
— то выравнивание не понадобится, и наши метаданные займут 100+800 байт. (https://ideone.com/fIk3gd)
РАЗНЫЕ МЕЛОЧИ:
1. В статье в Википедии в недостатки SoA записано «inefficient indexed addressing», но я с этим не согласен. На x86 самая сложная адресация 1 ассемблерной командой — это [регистрА + смещение + регистрБ × красивый_размер], где «красивый_размер» — 1, 2, 4 или 8. Так что доступ к i-му элементу массива примитивных типов с красивыми размерами, как в SoA-варианте, выполняется в 1 действие. Для других размеров доступ усложняется, вплоть до честного умножения — чем не inefficient indexed addressing.
2.
>Отключение выравнивания ... замедлит работу с ней
Про это любит писать @oldnewthing.
Для RISC-архитектур, не умеющих читать невыровненные данные, скомпилируется нудная побайтовая сборка значения: https://devblogs.microsoft.com/oldnewthing/20200103-00/?p=103290.
Даже на x86 и других архитектурах с поддержкой невыровненного доступа он будет медленнее — поэтому выравнивание и используется даже для них: https://devblogs.microsoft.com/oldnewthing/20170428-00/?p=96065. TL;DR: сложные комбинации невыровненных операций не очень приятно отслеживать в ходе спекулятивного исполнения.
>>13973
>Вообще нихуя непонятно откуда эта формула взялась
Как раз всё очевидно: закон обратных квадратов (поэтому в знаменателе r²), каждая точка одного тела притягивает каждую точку другого (поэтому m1 × m2), G — коэффициент пропорциональности.
4 Мб, 1654x2339>>13668
p a r t i t i o n p o i n t
>>13845
Так это целая философская проблема: https://en.wikipedia.org/wiki/AoS_and_SoA. Structure of arrays (SoA) кажется, и обычно является, непривлекательным и неудобным решением, но у него есть специфичные плюсы:
— Дружественность к SIMD, на x86 — SSE/AVX-арсеналу >>412748 →.
— Если часть полей обычно не нужна («обнулить z всем точкам»), работа с SoA будет эффективнее за счёт лучшей пространственной локальности. Если, наоборот, типичная обработка затрагивает несколько полей («посчитать x² + y² + z² для каждой точки»), AoS будет эффективнее... по той же причине :).
— С полями разного размера можно сэкономить на выравнивании. Представь, что у тебя есть энум из 100 форматов картинок: RGB8, RGBA32f и т. д., и ты хранишь в массиве format_info_struct format_info[100] (AoS) метаинформацию о них. Для примера возьмём за эту метаинформацию число каналов (1–4) и указатель на функцию считывания пикселя:
Пусть размер указателя get_pixel — 8, тогда компилятор выровняет его смещение в структуре, и размер самой структуры, на 8-байтовую границу, и структура займёт 16 байт, а 100 структур — 1600. Отключение выравнивания — #pragma pack(1) — сделает структуру 9-байтовой, но замедлит работу с ней.
Если же мы составим отдельные массивы (SoA)
— то выравнивание не понадобится, и наши метаданные займут 100+800 байт. (https://ideone.com/fIk3gd)
РАЗНЫЕ МЕЛОЧИ:
1. В статье в Википедии в недостатки SoA записано «inefficient indexed addressing», но я с этим не согласен. На x86 самая сложная адресация 1 ассемблерной командой — это [регистрА + смещение + регистрБ × красивый_размер], где «красивый_размер» — 1, 2, 4 или 8. Так что доступ к i-му элементу массива примитивных типов с красивыми размерами, как в SoA-варианте, выполняется в 1 действие. Для других размеров доступ усложняется, вплоть до честного умножения — чем не inefficient indexed addressing.
2.
Про это любит писать @oldnewthing.
Для RISC-архитектур, не умеющих читать невыровненные данные, скомпилируется нудная побайтовая сборка значения: https://devblogs.microsoft.com/oldnewthing/20200103-00/?p=103290.
Даже на x86 и других архитектурах с поддержкой невыровненного доступа он будет медленнее — поэтому выравнивание и используется даже для них: https://devblogs.microsoft.com/oldnewthing/20170428-00/?p=96065. TL;DR: сложные комбинации невыровненных операций не очень приятно отслеживать в ходе спекулятивного исполнения.
>>13973
Как раз всё очевидно: закон обратных квадратов (поэтому в знаменателе r²), каждая точка одного тела притягивает каждую точку другого (поэтому m1 × m2), G — коэффициент пропорциональности.
>есть массив [0, 0, ..., 0, 1, 1, ..., 1] и надо найти, в каком месте ноль сменяется единицей
p a r t i t i o n p o i n t
>>13845
>потому что я хоть на словах и сказал, что там буду хранить массивы как структуру из указателя и размера, но на деле нихуя не сделал это и храню их отдельно в разных массивах
Так это целая философская проблема: https://en.wikipedia.org/wiki/AoS_and_SoA. Structure of arrays (SoA) кажется, и обычно является, непривлекательным и неудобным решением, но у него есть специфичные плюсы:
— Дружественность к SIMD, на x86 — SSE/AVX-арсеналу >>412748 →.
— Если часть полей обычно не нужна («обнулить z всем точкам»), работа с SoA будет эффективнее за счёт лучшей пространственной локальности. Если, наоборот, типичная обработка затрагивает несколько полей («посчитать x² + y² + z² для каждой точки»), AoS будет эффективнее... по той же причине :).
— С полями разного размера можно сэкономить на выравнивании. Представь, что у тебя есть энум из 100 форматов картинок: RGB8, RGBA32f и т. д., и ты хранишь в массиве format_info_struct format_info[100] (AoS) метаинформацию о них. Для примера возьмём за эту метаинформацию число каналов (1–4) и указатель на функцию считывания пикселя:
>struct format_info_struct { uint8 channels; get_pixel_func get_pixel; }
Пусть размер указателя get_pixel — 8, тогда компилятор выровняет его смещение в структуре, и размер самой структуры, на 8-байтовую границу, и структура займёт 16 байт, а 100 структур — 1600. Отключение выравнивания — #pragma pack(1) — сделает структуру 9-байтовой, но замедлит работу с ней.
Если же мы составим отдельные массивы (SoA)
>uint8 channels[100];
>get_pixel_func get_pixel[100];
— то выравнивание не понадобится, и наши метаданные займут 100+800 байт. (https://ideone.com/fIk3gd)
РАЗНЫЕ МЕЛОЧИ:
1. В статье в Википедии в недостатки SoA записано «inefficient indexed addressing», но я с этим не согласен. На x86 самая сложная адресация 1 ассемблерной командой — это [регистрА + смещение + регистрБ × красивый_размер], где «красивый_размер» — 1, 2, 4 или 8. Так что доступ к i-му элементу массива примитивных типов с красивыми размерами, как в SoA-варианте, выполняется в 1 действие. Для других размеров доступ усложняется, вплоть до честного умножения — чем не inefficient indexed addressing.
2.
>Отключение выравнивания ... замедлит работу с ней
Про это любит писать @oldnewthing.
Для RISC-архитектур, не умеющих читать невыровненные данные, скомпилируется нудная побайтовая сборка значения: https://devblogs.microsoft.com/oldnewthing/20200103-00/?p=103290.
Даже на x86 и других архитектурах с поддержкой невыровненного доступа он будет медленнее — поэтому выравнивание и используется даже для них: https://devblogs.microsoft.com/oldnewthing/20170428-00/?p=96065. TL;DR: сложные комбинации невыровненных операций не очень приятно отслеживать в ходе спекулятивного исполнения.
>>13973
>Вообще нихуя непонятно откуда эта формула взялась
Как раз всё очевидно: закон обратных квадратов (поэтому в знаменателе r²), каждая точка одного тела притягивает каждую точку другого (поэтому m1 × m2), G — коэффициент пропорциональности.
187 Кб, 720x1265>>14104
Говно какое-то из плюсов.
Не думало том, что могут быть профиты хранить как SoA.
Почему? То есть им лучше, чтобы входные данные были в формате [XYZ][XYZ][XYZ]... Если SIMD инструкция делает операцию над XYZ. Чем хуже, если читать из трёх мест одновременно XXX, YYY, ZZZ по отдельности? В том числе, если XXX не прямо последовательно расположены, а веутри AoS. Тупо продвигать каждый указатель (на X, Y и Z) на одно и то же значение. Если не думать о локальности.
Интересно
Я только слышал, что RISC - это когда мало машинных инструкций, а CISC - много и они вроде частично интерпретируются где-то на низком уровне.
https://youtu.be/2FMx2GDqMo4
Окей
>>14135
Говнопаблики втентакле
>p a r t i t i o n p o i n t
Говно какое-то из плюсов.
> Так это целая философская проблема: https://en.wikipedia.org/wiki/AoS_and_SoA
Не думало том, что могут быть профиты хранить как SoA.
>Дружественность к SIMD
Почему? То есть им лучше, чтобы входные данные были в формате [XYZ][XYZ][XYZ]... Если SIMD инструкция делает операцию над XYZ. Чем хуже, если читать из трёх мест одновременно XXX, YYY, ZZZ по отдельности? В том числе, если XXX не прямо последовательно расположены, а веутри AoS. Тупо продвигать каждый указатель (на X, Y и Z) на одно и то же значение. Если не думать о локальности.
>в ходе спекулятивного исполнения.
>The solution are store buffers: when a store instruction is executed, we do all the necessary groundwork – address translation, access right checking and so forth – but don’t actually write to memory just yet; rather, the target address and the associated data bits are written into a store buffer, where they just sit around for a while; the store buffers form a log of all pending writes to memory. Only after the core is sure that the store instruction will actually be executed (branch results etc. are known and no exceptions were triggered) will these values actually be written back to the cache.
Интересно
>Для RISC-архитектур, не умеющих читать невыровненные данные
Я только слышал, что RISC - это когда мало машинных инструкций, а CISC - много и они вроде частично интерпретируются где-то на низком уровне.
>закон обратных квадратов
https://youtu.be/2FMx2GDqMo4
Окей
>>14135
Говнопаблики втентакле
1,2 Мб, 1600x2400>>14190
Чё охуел!1 Ну, это действительно термин из std, но я говорю, массив, у которого элементы сначала не удовлетворяют некоторому условию, а потом удовлетворяют, называется partitioned (в частности, подзадачу quicksort, которая приводит его в такой вид относительно пивота, часто называют partition), поэтому твою задачу можно по-умному назвать н а х о ж д е н и е м p a r t i t i o n p o i n t.
Скорее будет [XYZхуйня1хуйня2хуйня3][XYZхуйня1хуйня2хуйня3][XYZхуйня1хуйня2хуйня3], а SoA этого даже не заметит.
С SoA мы можем работать так. Пусть SIMD-регистр вмещает 4 числа.
Наконец:
Этот {ш,а,ф,фл} элементов, несмотря на внешнюю громоздкость, выполняется чисто между регистрами и должен быть супер-быстрым — во всяком случае, на GPU он вообще бесплатен. Загрузка из AoS с мешающимися хуйня1хуйня2хуйня3 будет сама по себе печальнее, будет делать обращения по числу структур, а не по количеству компонентов в векторе, и, что самое главное, не будет масштабироваться шириной регистра: представь регистр на 8 или 16 чисел, AoS вообще не сможет этим воспользоваться (нам изначально повезло, что размер вектора близок к ширине регистра), а SoA будет ПРОСТО работать пачками по 8 или 16.
Не совсем, у RISC могут быть сотни инструкций, а у CISC — немного. Особенность CISC — комплексность действий, выполняемых отдельными инструкциями: они могут поддерживать сложные режимы адресации, требовать нескольких обращений к памяти и т. д. Это было удобно, когда программы писали вручную, но с развитием языков высокого уровня оказалось, что важнее простота операций (ведь их можно раскидывать разным, специализированным модулям процессора!) и количество регистров (ведь туда можно ложить локальные переменные!), чем возможность выполнять сложные операции 1 командой. А чем больше регистров и вариантов их использования, тем банально нужно больше бит в машинной команде, чтобы всё это описывать.
Например, в ARMv7 (16 32-битных регистров) трёхоперандные операции вида C←A+B часто в качестве A (и, естественно, C) поддерживают только регистр, а в качестве B — «flexible second operand», являющийся
— либо константой вида ABCDEFGH₂<<2N, N∈[0; 15],
— либо регистром со сдвигом влево/вправо/знаковым вправо/циклическим вправо. Величина сдвига либо является константой из [0; 31], либо берётся из другого регистра.
Посчитаем, сколько этот операнд займёт (вот здесь https://alisdair.mcdiarmid.org/arm-immediate-value-encoding/ или здесь http://users.ece.utexas.edu/~valvano/EE345M/Arm_EE382N_4.pdf на слайде 17 он указан как Operand2, а вот здесь расписаны бинарные представления каждого варианта: https://heyrick.eu/armwiki/Shifts):
1 бит — различие между константой и регистром,
для константы: 8 бит — ABCDEFGH₂, 4 бита — N,
для регистра:
4 бита — номер регистра,
2 бита — вариант сдвига,
1 бит — различие между сдвигом на константу и регистр,
для сдвига на константу [0; 31]: 5 бит — константа,
для сдвига на регистр: 4 бита — номер регистра.
То есть 13 бит — больше 1,5 байт. Причём это всё ещё RISC в плане работы только с регистрами и простейшей поддержки типичных конструкций языков программирования — той самой индексации массивов с красивыми размерами элементов. Если мы в духе CISC добавим ещё возможностей, хотя бы до 16 бит, сделаем их и для первого операнда в духе https://en.wikipedia.org/wiki/Orthogonal_instruction_set, а особенно добавим поддержку в качестве A, B и/или C ссылок на память по адресу в регистре — наши команды будет гораздо сложнее исполнять, и они просто раздуются: сейчас вся команда ARM с условием, опкодом и тремя операндами, один из которых флексит, занимает 4 байта, а в CISC-варианте эти 4 байта уйдут только на описание двух операндов.
В этом плане возможность чтения невыровненных данных CISC-идеологична: память работает с гранулярностью ~слов~, ~кэш-линий~ или ~ширины шины памяти~, и если невыровненное значение пересекает границу двух таких, его придётся читать в два обращения. Выравнивание гарантирует, что этого не будет.
>Говно какое-то из плюсов
Чё охуел!1 Ну, это действительно термин из std, но я говорю, массив, у которого элементы сначала не удовлетворяют некоторому условию, а потом удовлетворяют, называется partitioned (в частности, подзадачу quicksort, которая приводит его в такой вид относительно пивота, часто называют partition), поэтому твою задачу можно по-умному назвать н а х о ж д е н и е м p a r t i t i o n p o i n t.
>Почему? То есть им лучше, чтобы входные данные были в формате [XYZ][XYZ][XYZ]...
Скорее будет [XYZхуйня1хуйня2хуйня3][XYZхуйня1хуйня2хуйня3][XYZхуйня1хуйня2хуйня3], а SoA этого даже не заметит.
С SoA мы можем работать так. Пусть SIMD-регистр вмещает 4 числа.
>пока осталось больше 4 элементов, работать пачками по 4:
>r0 = [XXXX]
>r1 = [YYYY]
>r2 = [ZZZZ]
>r3 = {r0[0], r1[0], r2[0], 0}
>r4 = {r0[1], r1[1], r2[1], 0}
>r5 = {r0[2], r1[2], r2[2], 0}
>r6 = {r0[3], r1[3], r2[3], 0}
>обработать собранные векторы r3–r6, упаковать назад в r0–r2 и сохранить
Наконец:
>дообработать хвост из 0–3 элементов по одному
Этот {ш,а,ф,фл} элементов, несмотря на внешнюю громоздкость, выполняется чисто между регистрами и должен быть супер-быстрым — во всяком случае, на GPU он вообще бесплатен. Загрузка из AoS с мешающимися хуйня1хуйня2хуйня3 будет сама по себе печальнее, будет делать обращения по числу структур, а не по количеству компонентов в векторе, и, что самое главное, не будет масштабироваться шириной регистра: представь регистр на 8 или 16 чисел, AoS вообще не сможет этим воспользоваться (нам изначально повезло, что размер вектора близок к ширине регистра), а SoA будет ПРОСТО работать пачками по 8 или 16.
>Я только слышал, что RISC - это когда мало машинных инструкций, а CISC - много и они вроде частично интерпретируются где-то на низком уровне
Не совсем, у RISC могут быть сотни инструкций, а у CISC — немного. Особенность CISC — комплексность действий, выполняемых отдельными инструкциями: они могут поддерживать сложные режимы адресации, требовать нескольких обращений к памяти и т. д. Это было удобно, когда программы писали вручную, но с развитием языков высокого уровня оказалось, что важнее простота операций (ведь их можно раскидывать разным, специализированным модулям процессора!) и количество регистров (ведь туда можно ложить локальные переменные!), чем возможность выполнять сложные операции 1 командой. А чем больше регистров и вариантов их использования, тем банально нужно больше бит в машинной команде, чтобы всё это описывать.
Например, в ARMv7 (16 32-битных регистров) трёхоперандные операции вида C←A+B часто в качестве A (и, естественно, C) поддерживают только регистр, а в качестве B — «flexible second operand», являющийся
— либо константой вида ABCDEFGH₂<<2N, N∈[0; 15],
— либо регистром со сдвигом влево/вправо/знаковым вправо/циклическим вправо. Величина сдвига либо является константой из [0; 31], либо берётся из другого регистра.
Посчитаем, сколько этот операнд займёт (вот здесь https://alisdair.mcdiarmid.org/arm-immediate-value-encoding/ или здесь http://users.ece.utexas.edu/~valvano/EE345M/Arm_EE382N_4.pdf на слайде 17 он указан как Operand2, а вот здесь расписаны бинарные представления каждого варианта: https://heyrick.eu/armwiki/Shifts):
1 бит — различие между константой и регистром,
для константы: 8 бит — ABCDEFGH₂, 4 бита — N,
для регистра:
4 бита — номер регистра,
2 бита — вариант сдвига,
1 бит — различие между сдвигом на константу и регистр,
для сдвига на константу [0; 31]: 5 бит — константа,
для сдвига на регистр: 4 бита — номер регистра.
То есть 13 бит — больше 1,5 байт. Причём это всё ещё RISC в плане работы только с регистрами и простейшей поддержки типичных конструкций языков программирования — той самой индексации массивов с красивыми размерами элементов. Если мы в духе CISC добавим ещё возможностей, хотя бы до 16 бит, сделаем их и для первого операнда в духе https://en.wikipedia.org/wiki/Orthogonal_instruction_set, а особенно добавим поддержку в качестве A, B и/или C ссылок на память по адресу в регистре — наши команды будет гораздо сложнее исполнять, и они просто раздуются: сейчас вся команда ARM с условием, опкодом и тремя операндами, один из которых флексит, занимает 4 байта, а в CISC-варианте эти 4 байта уйдут только на описание двух операндов.
В этом плане возможность чтения невыровненных данных CISC-идеологична: память работает с гранулярностью ~слов~, ~кэш-линий~ или ~ширины шины памяти~, и если невыровненное значение пересекает границу двух таких, его придётся читать в два обращения. Выравнивание гарантирует, что этого не будет.
1,2 Мб, 1600x2400>>14190
Чё охуел!1 Ну, это действительно термин из std, но я говорю, массив, у которого элементы сначала не удовлетворяют некоторому условию, а потом удовлетворяют, называется partitioned (в частности, подзадачу quicksort, которая приводит его в такой вид относительно пивота, часто называют partition), поэтому твою задачу можно по-умному назвать н а х о ж д е н и е м p a r t i t i o n p o i n t.
Скорее будет [XYZхуйня1хуйня2хуйня3][XYZхуйня1хуйня2хуйня3][XYZхуйня1хуйня2хуйня3], а SoA этого даже не заметит.
С SoA мы можем работать так. Пусть SIMD-регистр вмещает 4 числа.
Наконец:
Этот {ш,а,ф,фл} элементов, несмотря на внешнюю громоздкость, выполняется чисто между регистрами и должен быть супер-быстрым — во всяком случае, на GPU он вообще бесплатен. Загрузка из AoS с мешающимися хуйня1хуйня2хуйня3 будет сама по себе печальнее, будет делать обращения по числу структур, а не по количеству компонентов в векторе, и, что самое главное, не будет масштабироваться шириной регистра: представь регистр на 8 или 16 чисел, AoS вообще не сможет этим воспользоваться (нам изначально повезло, что размер вектора близок к ширине регистра), а SoA будет ПРОСТО работать пачками по 8 или 16.
Не совсем, у RISC могут быть сотни инструкций, а у CISC — немного. Особенность CISC — комплексность действий, выполняемых отдельными инструкциями: они могут поддерживать сложные режимы адресации, требовать нескольких обращений к памяти и т. д. Это было удобно, когда программы писали вручную, но с развитием языков высокого уровня оказалось, что важнее простота операций (ведь их можно раскидывать разным, специализированным модулям процессора!) и количество регистров (ведь туда можно ложить локальные переменные!), чем возможность выполнять сложные операции 1 командой. А чем больше регистров и вариантов их использования, тем банально нужно больше бит в машинной команде, чтобы всё это описывать.
Например, в ARMv7 (16 32-битных регистров) трёхоперандные операции вида C←A+B часто в качестве A (и, естественно, C) поддерживают только регистр, а в качестве B — «flexible second operand», являющийся
— либо константой вида ABCDEFGH₂<<2N, N∈[0; 15],
— либо регистром со сдвигом влево/вправо/знаковым вправо/циклическим вправо. Величина сдвига либо является константой из [0; 31], либо берётся из другого регистра.
Посчитаем, сколько этот операнд займёт (вот здесь https://alisdair.mcdiarmid.org/arm-immediate-value-encoding/ или здесь http://users.ece.utexas.edu/~valvano/EE345M/Arm_EE382N_4.pdf на слайде 17 он указан как Operand2, а вот здесь расписаны бинарные представления каждого варианта: https://heyrick.eu/armwiki/Shifts):
1 бит — различие между константой и регистром,
для константы: 8 бит — ABCDEFGH₂, 4 бита — N,
для регистра:
4 бита — номер регистра,
2 бита — вариант сдвига,
1 бит — различие между сдвигом на константу и регистр,
для сдвига на константу [0; 31]: 5 бит — константа,
для сдвига на регистр: 4 бита — номер регистра.
То есть 13 бит — больше 1,5 байт. Причём это всё ещё RISC в плане работы только с регистрами и простейшей поддержки типичных конструкций языков программирования — той самой индексации массивов с красивыми размерами элементов. Если мы в духе CISC добавим ещё возможностей, хотя бы до 16 бит, сделаем их и для первого операнда в духе https://en.wikipedia.org/wiki/Orthogonal_instruction_set, а особенно добавим поддержку в качестве A, B и/или C ссылок на память по адресу в регистре — наши команды будет гораздо сложнее исполнять, и они просто раздуются: сейчас вся команда ARM с условием, опкодом и тремя операндами, один из которых флексит, занимает 4 байта, а в CISC-варианте эти 4 байта уйдут только на описание двух операндов.
В этом плане возможность чтения невыровненных данных CISC-идеологична: память работает с гранулярностью ~слов~, ~кэш-линий~ или ~ширины шины памяти~, и если невыровненное значение пересекает границу двух таких, его придётся читать в два обращения. Выравнивание гарантирует, что этого не будет.
>Говно какое-то из плюсов
Чё охуел!1 Ну, это действительно термин из std, но я говорю, массив, у которого элементы сначала не удовлетворяют некоторому условию, а потом удовлетворяют, называется partitioned (в частности, подзадачу quicksort, которая приводит его в такой вид относительно пивота, часто называют partition), поэтому твою задачу можно по-умному назвать н а х о ж д е н и е м p a r t i t i o n p o i n t.
>Почему? То есть им лучше, чтобы входные данные были в формате [XYZ][XYZ][XYZ]...
Скорее будет [XYZхуйня1хуйня2хуйня3][XYZхуйня1хуйня2хуйня3][XYZхуйня1хуйня2хуйня3], а SoA этого даже не заметит.
С SoA мы можем работать так. Пусть SIMD-регистр вмещает 4 числа.
>пока осталось больше 4 элементов, работать пачками по 4:
>r0 = [XXXX]
>r1 = [YYYY]
>r2 = [ZZZZ]
>r3 = {r0[0], r1[0], r2[0], 0}
>r4 = {r0[1], r1[1], r2[1], 0}
>r5 = {r0[2], r1[2], r2[2], 0}
>r6 = {r0[3], r1[3], r2[3], 0}
>обработать собранные векторы r3–r6, упаковать назад в r0–r2 и сохранить
Наконец:
>дообработать хвост из 0–3 элементов по одному
Этот {ш,а,ф,фл} элементов, несмотря на внешнюю громоздкость, выполняется чисто между регистрами и должен быть супер-быстрым — во всяком случае, на GPU он вообще бесплатен. Загрузка из AoS с мешающимися хуйня1хуйня2хуйня3 будет сама по себе печальнее, будет делать обращения по числу структур, а не по количеству компонентов в векторе, и, что самое главное, не будет масштабироваться шириной регистра: представь регистр на 8 или 16 чисел, AoS вообще не сможет этим воспользоваться (нам изначально повезло, что размер вектора близок к ширине регистра), а SoA будет ПРОСТО работать пачками по 8 или 16.
>Я только слышал, что RISC - это когда мало машинных инструкций, а CISC - много и они вроде частично интерпретируются где-то на низком уровне
Не совсем, у RISC могут быть сотни инструкций, а у CISC — немного. Особенность CISC — комплексность действий, выполняемых отдельными инструкциями: они могут поддерживать сложные режимы адресации, требовать нескольких обращений к памяти и т. д. Это было удобно, когда программы писали вручную, но с развитием языков высокого уровня оказалось, что важнее простота операций (ведь их можно раскидывать разным, специализированным модулям процессора!) и количество регистров (ведь туда можно ложить локальные переменные!), чем возможность выполнять сложные операции 1 командой. А чем больше регистров и вариантов их использования, тем банально нужно больше бит в машинной команде, чтобы всё это описывать.
Например, в ARMv7 (16 32-битных регистров) трёхоперандные операции вида C←A+B часто в качестве A (и, естественно, C) поддерживают только регистр, а в качестве B — «flexible second operand», являющийся
— либо константой вида ABCDEFGH₂<<2N, N∈[0; 15],
— либо регистром со сдвигом влево/вправо/знаковым вправо/циклическим вправо. Величина сдвига либо является константой из [0; 31], либо берётся из другого регистра.
Посчитаем, сколько этот операнд займёт (вот здесь https://alisdair.mcdiarmid.org/arm-immediate-value-encoding/ или здесь http://users.ece.utexas.edu/~valvano/EE345M/Arm_EE382N_4.pdf на слайде 17 он указан как Operand2, а вот здесь расписаны бинарные представления каждого варианта: https://heyrick.eu/armwiki/Shifts):
1 бит — различие между константой и регистром,
для константы: 8 бит — ABCDEFGH₂, 4 бита — N,
для регистра:
4 бита — номер регистра,
2 бита — вариант сдвига,
1 бит — различие между сдвигом на константу и регистр,
для сдвига на константу [0; 31]: 5 бит — константа,
для сдвига на регистр: 4 бита — номер регистра.
То есть 13 бит — больше 1,5 байт. Причём это всё ещё RISC в плане работы только с регистрами и простейшей поддержки типичных конструкций языков программирования — той самой индексации массивов с красивыми размерами элементов. Если мы в духе CISC добавим ещё возможностей, хотя бы до 16 бит, сделаем их и для первого операнда в духе https://en.wikipedia.org/wiki/Orthogonal_instruction_set, а особенно добавим поддержку в качестве A, B и/или C ссылок на память по адресу в регистре — наши команды будет гораздо сложнее исполнять, и они просто раздуются: сейчас вся команда ARM с условием, опкодом и тремя операндами, один из которых флексит, занимает 4 байта, а в CISC-варианте эти 4 байта уйдут только на описание двух операндов.
В этом плане возможность чтения невыровненных данных CISC-идеологична: память работает с гранулярностью ~слов~, ~кэш-линий~ или ~ширины шины памяти~, и если невыровненное значение пересекает границу двух таких, его придётся читать в два обращения. Выравнивание гарантирует, что этого не будет.
202 Кб, 719x1080>>14287
Блять, я чёто немного неправильно думал про simd
Непонятные слова. Типа в твоём примере для загрузки [XXXX] из SoA понадобится одно чтение, в то время как при загрузке из AoS понадобится 4 чтения, потому что там эти иксы раскиданы в разных местах по структурам
Нихуя не понимаю. Ширина регистра - это размер обычных регистров? Которые r0-r2? При чём тут она вообще?
Если SIMD инструкция будет обрабатывать одновременно 4 вектора, каждый по 8 или 16 чисел, то куда будет сохраняться результат? Понадобится тогда дохуя обычных регистров, чтобы в них упаковать результат? Или SIMD инструкция может записать результат в память? Но на RISC вроде для доступа к памяти ровно две инструкции load/store, там тогда всё же в регистры пишется и это норм, потому что на RISC регистров есть дохуя?
А, condition - это условие, при котором инструкция будет выполняться или нет, получается в каждой инструкции хранится даже, если условия нет и она всегда выполняется
Окей
Потому что надо писать меньше кода чтобы это сделать
Блять, я чёто немного неправильно думал про simd
>Загрузка из AoS с мешающимися хуйня1хуйня2хуйня3 будет сама по себе печальнее, будет делать обращения по числу структур, а не по количеству компонентов в векторе
Непонятные слова. Типа в твоём примере для загрузки [XXXX] из SoA понадобится одно чтение, в то время как при загрузке из AoS понадобится 4 чтения, потому что там эти иксы раскиданы в разных местах по структурам
>представь регистр на 8 или 16 чисел, AoS вообще не сможет этим воспользоваться (нам изначально повезло, что размер вектора близок к ширине регистра)
Нихуя не понимаю. Ширина регистра - это размер обычных регистров? Которые r0-r2? При чём тут она вообще?
Если SIMD инструкция будет обрабатывать одновременно 4 вектора, каждый по 8 или 16 чисел, то куда будет сохраняться результат? Понадобится тогда дохуя обычных регистров, чтобы в них упаковать результат? Или SIMD инструкция может записать результат в память? Но на RISC вроде для доступа к памяти ровно две инструкции load/store, там тогда всё же в регистры пишется и это норм, потому что на RISC регистров есть дохуя?
>http://users.ece.utexas.edu/~valvano/EE345M/Arm_EE382N_4.pdf
А, condition - это условие, при котором инструкция будет выполняться или нет, получается в каждой инструкции хранится даже, если условия нет и она всегда выполняется
>Это было удобно, когда программы писали вручную
Окей
>В этом плане возможность чтения невыровненных данных CISC-идеологична
Потому что надо писать меньше кода чтобы это сделать
934 Кб, 1280x720>>14369
Неважно, сколько чисел помещается в SIMD-регистр (пусть 8), если мы работаем с массивом трёхмерных векторов как с SoA, мы прочитаем 8 векторов в 3 захода: 8 иксов, 8 игреков и 8 зетов. С XYZ-хуйня-XYZ-хуйня придётся читать по одному XYZ-вектору.
Да. SIMD и RISC — несвязанные вещи, просто обе приплелись в контексте того, где может пригодиться SoA.
Под «r» я имел в виду SIMD-регистры (простите меня). В случае x86 они называются xmm, ymm, zmm.
xmm (SSE) имеют размер 128 бит и могут интерпретироваться как пачки из 4 флоатов (float32) или 2 даблов. (Также можно работать с единственным, младшим, флоатом/даблом; собственно, на x86-64 они используются для всех флоатовых расчётов вместо устаревшего FPU. Можно интерпретировать и как пачки целых чисел.)
ymm (AVX) — 256 бит, 8 флоатов/4 дабла.
zmm (AVX-512) — 512 бит, 16 флоатов/8 даблов.
Операции могут работать над регистрами как над пачками чисел (в этом вся фишка): покомпонентно сложить один регистр с другим, извлечь корни сразу из всех компонентов и т. д.
Под шириной я имел в виду число флоатов, которые умещаются в регистр. Т. к. xmm-регистр умещает 4 флоата, мы можем интерпретировать его как трёх- (четвёртый компонент просто не используется) или четырёхмерный вектор и загружать/сохранять его в AoS. Но нам просто повезло, это не масштабируется на более широкие регистры.
А вот SoA элементарно масштабируется. Пример.
Представь, что мы сгенерировали трёхмерную процедурную девочку как набор треугольников и нам нужно посчитать их нормали.
Нормаль к треугольнику можно получить нормализацией векторного произведения двух его сторон.
Рассмотрим, как мы будем искать нормаль N треугольника ABC.
Векторы 2 сторон: V1 = B − A, V2 = C − A.
Векторное произведение: P = V1 × V2 = { x = V1.y × V2.z − V1.z × V2.y, y = ..., z = ... }
Нормаль: N = P / |P| = P / √(P.x² + P.y² + P.z²)
А теперь возьмём SoA-список в условную тысячу таких треугольников — 9 массивов, по 3 компонента 3 вершин:
Ax[] = [Ax Ax Ax Ax Ax ...×1000...]
Ay[] = [Ay Ay Ay Ay Ay ...]
Az[] = [Az Az Az Az Az ...]
Bx[], By[], ..., Cz[]
Мы можем считать всё пачками произвольного размера по тем же формулам!
Векторы 2 сторон — V1x[] = Bx[] − Ax[], ..., V2z = Cz[] − Az[].
...вычисляем пачку векторных произведений Px[], Py[], Pz[]...
len[] = √(Px[]² + Py[]² + Pz[]²)
Nx[] = Px[] / len[]
Ny[] = Py[] / len[]
Nz[] = Pz[] / len[]
Получаем Nx[], Ny[], Nz[] — SoA-же список нормалей к исходным треугольникам.
С AoS так не получится.
Нет, потому что инструкция может развернуться в 2 обращения к памяти.
>обращения по числу структур, а не по количеству компонентов в векторе
Неважно, сколько чисел помещается в SIMD-регистр (пусть 8), если мы работаем с массивом трёхмерных векторов как с SoA, мы прочитаем 8 векторов в 3 захода: 8 иксов, 8 игреков и 8 зетов. С XYZ-хуйня-XYZ-хуйня придётся читать по одному XYZ-вектору.
>Или SIMD инструкция может записать результат в память?
Да. SIMD и RISC — несвязанные вещи, просто обе приплелись в контексте того, где может пригодиться SoA.
>Ширина регистра - это размер обычных регистров? Которые r0-r2? При чём тут она вообще?
Под «r» я имел в виду SIMD-регистры (простите меня). В случае x86 они называются xmm, ymm, zmm.
xmm (SSE) имеют размер 128 бит и могут интерпретироваться как пачки из 4 флоатов (float32) или 2 даблов. (Также можно работать с единственным, младшим, флоатом/даблом; собственно, на x86-64 они используются для всех флоатовых расчётов вместо устаревшего FPU. Можно интерпретировать и как пачки целых чисел.)
ymm (AVX) — 256 бит, 8 флоатов/4 дабла.
zmm (AVX-512) — 512 бит, 16 флоатов/8 даблов.
Операции могут работать над регистрами как над пачками чисел (в этом вся фишка): покомпонентно сложить один регистр с другим, извлечь корни сразу из всех компонентов и т. д.
Под шириной я имел в виду число флоатов, которые умещаются в регистр. Т. к. xmm-регистр умещает 4 флоата, мы можем интерпретировать его как трёх- (четвёртый компонент просто не используется) или четырёхмерный вектор и загружать/сохранять его в AoS. Но нам просто повезло, это не масштабируется на более широкие регистры.
А вот SoA элементарно масштабируется. Пример.
Представь, что мы сгенерировали трёхмерную процедурную девочку как набор треугольников и нам нужно посчитать их нормали.
Нормаль к треугольнику можно получить нормализацией векторного произведения двух его сторон.
Рассмотрим, как мы будем искать нормаль N треугольника ABC.
Векторы 2 сторон: V1 = B − A, V2 = C − A.
Векторное произведение: P = V1 × V2 = { x = V1.y × V2.z − V1.z × V2.y, y = ..., z = ... }
Нормаль: N = P / |P| = P / √(P.x² + P.y² + P.z²)
А теперь возьмём SoA-список в условную тысячу таких треугольников — 9 массивов, по 3 компонента 3 вершин:
Ax[] = [Ax Ax Ax Ax Ax ...×1000...]
Ay[] = [Ay Ay Ay Ay Ay ...]
Az[] = [Az Az Az Az Az ...]
Bx[], By[], ..., Cz[]
Мы можем считать всё пачками произвольного размера по тем же формулам!
Векторы 2 сторон — V1x[] = Bx[] − Ax[], ..., V2z = Cz[] − Az[].
...вычисляем пачку векторных произведений Px[], Py[], Pz[]...
len[] = √(Px[]² + Py[]² + Pz[]²)
Nx[] = Px[] / len[]
Ny[] = Py[] / len[]
Nz[] = Pz[] / len[]
Получаем Nx[], Ny[], Nz[] — SoA-же список нормалей к исходным треугольникам.
С AoS так не получится.
>Потому что надо писать меньше кода чтобы это сделать
Нет, потому что инструкция может развернуться в 2 обращения к памяти.
934 Кб, 1280x720>>14369
Неважно, сколько чисел помещается в SIMD-регистр (пусть 8), если мы работаем с массивом трёхмерных векторов как с SoA, мы прочитаем 8 векторов в 3 захода: 8 иксов, 8 игреков и 8 зетов. С XYZ-хуйня-XYZ-хуйня придётся читать по одному XYZ-вектору.
Да. SIMD и RISC — несвязанные вещи, просто обе приплелись в контексте того, где может пригодиться SoA.
Под «r» я имел в виду SIMD-регистры (простите меня). В случае x86 они называются xmm, ymm, zmm.
xmm (SSE) имеют размер 128 бит и могут интерпретироваться как пачки из 4 флоатов (float32) или 2 даблов. (Также можно работать с единственным, младшим, флоатом/даблом; собственно, на x86-64 они используются для всех флоатовых расчётов вместо устаревшего FPU. Можно интерпретировать и как пачки целых чисел.)
ymm (AVX) — 256 бит, 8 флоатов/4 дабла.
zmm (AVX-512) — 512 бит, 16 флоатов/8 даблов.
Операции могут работать над регистрами как над пачками чисел (в этом вся фишка): покомпонентно сложить один регистр с другим, извлечь корни сразу из всех компонентов и т. д.
Под шириной я имел в виду число флоатов, которые умещаются в регистр. Т. к. xmm-регистр умещает 4 флоата, мы можем интерпретировать его как трёх- (четвёртый компонент просто не используется) или четырёхмерный вектор и загружать/сохранять его в AoS. Но нам просто повезло, это не масштабируется на более широкие регистры.
А вот SoA элементарно масштабируется. Пример.
Представь, что мы сгенерировали трёхмерную процедурную девочку как набор треугольников и нам нужно посчитать их нормали.
Нормаль к треугольнику можно получить нормализацией векторного произведения двух его сторон.
Рассмотрим, как мы будем искать нормаль N треугольника ABC.
Векторы 2 сторон: V1 = B − A, V2 = C − A.
Векторное произведение: P = V1 × V2 = { x = V1.y × V2.z − V1.z × V2.y, y = ..., z = ... }
Нормаль: N = P / |P| = P / √(P.x² + P.y² + P.z²)
А теперь возьмём SoA-список в условную тысячу таких треугольников — 9 массивов, по 3 компонента 3 вершин:
Ax[] = [Ax Ax Ax Ax Ax ...×1000...]
Ay[] = [Ay Ay Ay Ay Ay ...]
Az[] = [Az Az Az Az Az ...]
Bx[], By[], ..., Cz[]
Мы можем считать всё пачками произвольного размера по тем же формулам!
Векторы 2 сторон — V1x[] = Bx[] − Ax[], ..., V2z = Cz[] − Az[].
...вычисляем пачку векторных произведений Px[], Py[], Pz[]...
len[] = √(Px[]² + Py[]² + Pz[]²)
Nx[] = Px[] / len[]
Ny[] = Py[] / len[]
Nz[] = Pz[] / len[]
Получаем Nx[], Ny[], Nz[] — SoA-же список нормалей к исходным треугольникам.
С AoS так не получится.
Нет, потому что инструкция может развернуться в 2 обращения к памяти.
>обращения по числу структур, а не по количеству компонентов в векторе
Неважно, сколько чисел помещается в SIMD-регистр (пусть 8), если мы работаем с массивом трёхмерных векторов как с SoA, мы прочитаем 8 векторов в 3 захода: 8 иксов, 8 игреков и 8 зетов. С XYZ-хуйня-XYZ-хуйня придётся читать по одному XYZ-вектору.
>Или SIMD инструкция может записать результат в память?
Да. SIMD и RISC — несвязанные вещи, просто обе приплелись в контексте того, где может пригодиться SoA.
>Ширина регистра - это размер обычных регистров? Которые r0-r2? При чём тут она вообще?
Под «r» я имел в виду SIMD-регистры (простите меня). В случае x86 они называются xmm, ymm, zmm.
xmm (SSE) имеют размер 128 бит и могут интерпретироваться как пачки из 4 флоатов (float32) или 2 даблов. (Также можно работать с единственным, младшим, флоатом/даблом; собственно, на x86-64 они используются для всех флоатовых расчётов вместо устаревшего FPU. Можно интерпретировать и как пачки целых чисел.)
ymm (AVX) — 256 бит, 8 флоатов/4 дабла.
zmm (AVX-512) — 512 бит, 16 флоатов/8 даблов.
Операции могут работать над регистрами как над пачками чисел (в этом вся фишка): покомпонентно сложить один регистр с другим, извлечь корни сразу из всех компонентов и т. д.
Под шириной я имел в виду число флоатов, которые умещаются в регистр. Т. к. xmm-регистр умещает 4 флоата, мы можем интерпретировать его как трёх- (четвёртый компонент просто не используется) или четырёхмерный вектор и загружать/сохранять его в AoS. Но нам просто повезло, это не масштабируется на более широкие регистры.
А вот SoA элементарно масштабируется. Пример.
Представь, что мы сгенерировали трёхмерную процедурную девочку как набор треугольников и нам нужно посчитать их нормали.
Нормаль к треугольнику можно получить нормализацией векторного произведения двух его сторон.
Рассмотрим, как мы будем искать нормаль N треугольника ABC.
Векторы 2 сторон: V1 = B − A, V2 = C − A.
Векторное произведение: P = V1 × V2 = { x = V1.y × V2.z − V1.z × V2.y, y = ..., z = ... }
Нормаль: N = P / |P| = P / √(P.x² + P.y² + P.z²)
А теперь возьмём SoA-список в условную тысячу таких треугольников — 9 массивов, по 3 компонента 3 вершин:
Ax[] = [Ax Ax Ax Ax Ax ...×1000...]
Ay[] = [Ay Ay Ay Ay Ay ...]
Az[] = [Az Az Az Az Az ...]
Bx[], By[], ..., Cz[]
Мы можем считать всё пачками произвольного размера по тем же формулам!
Векторы 2 сторон — V1x[] = Bx[] − Ax[], ..., V2z = Cz[] − Az[].
...вычисляем пачку векторных произведений Px[], Py[], Pz[]...
len[] = √(Px[]² + Py[]² + Pz[]²)
Nx[] = Px[] / len[]
Ny[] = Py[] / len[]
Nz[] = Pz[] / len[]
Получаем Nx[], Ny[], Nz[] — SoA-же список нормалей к исходным треугольникам.
С AoS так не получится.
>Потому что надо писать меньше кода чтобы это сделать
Нет, потому что инструкция может развернуться в 2 обращения к памяти.
17,1 Мб, webm,1920x1080, 1:45
Окей, с конкретными примерами понятнее, спасибо
271 Кб, 1300x1948так всё и все достали, я хочу спать только, больше нихуя не хочу и чтобы все нахуй пошли блять и отъебались от меня. Вчера у препода всё же было время вечером посмотреть мою домашку, поэтому её зачли. И на тот момент я чёто сильно хотел спать уже поэтому забил на всё и уснул. Ещё сильно устал из-за того, что два раза ездил в вуз из за дебильного расписания: сначала очная пара (математика), потом дистанционная (вот как раз сдача домашки) а потом снова очная (бля тут мега палево и диванон, не буду говорить что это).
По математике было чёто про порядки малости функций, короче всё ещё задачи на посчитать пределы. На мега палевной паре я так и не понял, как нужно отмечать свою посещаемость, не увидел никого из своей группы (потому что пара на много людей сразу). Вроде видел место, где после окончания все толпой скучковались, но зассал подходить туда чёто, в следующий раз надо будет подождать, пока все уйдут и посмотреть что там. Наверное там листочек со списками групп, где галочки надо ставить
Проспал дохуя теперь болит голова, снова математика была, на этот раз дистанционная и вообще весь день дистанционным сделали. В полуха слушал, вроде про точки разрыва было. Большой минус пар по ебучему майкрософт тимсу, что мне на них становится абсолютно похуй. Потом лекция по программированию была, её я слушал в четверть уха, но там нихуя не рассказали толком, показали, слайды с какой-то программой разобранной что мол вот структурная парадигма, дейкстра, сверху вниз, заглушки вместо реализаций.
Единственное, что я усвоил из этого, что я нихуя так и не понял указатели, когда увидел объевление функции test(int ∗const ∗arg). Короче, оказалось, надо читать это справа налево и я для себя решил "∗const" воспринимать как одну штуку, которая ознает константный указатель. То есть вот так типа постфиксная запись: ((int)∗const)∗ - указатель на константный указатель, который указывает на int. То есть из этого можно менять значение самого arg и arg[j], но нельзя менять arg. А если так: test(int ∗const ∗const arg), то нельзя будет менять arg, только arg[j].
ПОтом по алгоритмам была лекция, на которой тупа задачки разбирали и от нас предполагалось что мы будем сразу их решать, но я затупил на первой же, сдался, остальные просто слушал разборы.
Там блин ещё такое было что надо посчитать (составить соотношение рекурентное) сколько существует последовательностей из 0 и 1 таких, чтобы не было трёх подряд идущих нулей. И ответ - это T(n) = T(n-1)+T(n-2)+T(n-3), это называется последовательностью трибоначи. И решение нихуя не очевидное, короче, все последовательности можно разбить на те, которые заканчиваются на 1, 10 и 100 и эти разбиения не пересекаются. И в сумме они дадут ВСЕ корректные последовательности, потому что дальше те, которые оканчиваются на 1000, 10000 и так далее не удовлетворяют условию
Ну и дальше если есть корректная (без трёх нулей подряд нигде) последовательность длины n-1, то можно дописать 1 и получить корректную последоватлеьность длины n, если есть длины n-2, то можно безболезненно дописать 10, если n-3, то 100.
И это будет исчерпывающе, потому что ну скажем если бы хотели дописать 101, то нет, мы уже рассмотрели этот вариант, потому что на 1 заканчивается. 110 - тоже. И именно до n-3 надо идти, потому что если меньше, например, до n-2, то хуй: если n-2-ое число - это 1, то можно было бы дописать и 00. И мы этот случай как раз рассматриваем, когда добавляем 100. А дальше n-4 уже не нужно, потому что 1000 надо будет дописывать, а это некорректная последовательноть по условию
Ещё была задача на лексикографический перебор перестановок я её нихуя не понял там алгоритм такой:
1. Находим ХВОСТ. ХВОСТ - эта наибольшая возрастающая последовательность, если считать с конца.
2. Берём элемент, который идёт слева от хвоста, и меняем его с наименьшим из ХВОСТА, который был бы больше него.
3. Переворачиваем ХВОСТ задом наперед
Я хуй знает как это понимать но наверно это в духе того, что случается при переполнении разряда (999 -> 1000) только у нас ограниченное число цифр и использовать их все можно только единожды. В 1432, например, "432" - это максимальная перестановка, которую можно сложить из этих цифр, поэтому нам надо апдейтнуть верхний разряд "1" следующим значением. Так как мы перебираем лексикографически, то гарантированно в ХВОСТЕ будет следующее значение для верхнего разряда, ну мы и достаём его оттуда. При этом после свопа отсортированность сохранится и переворачивая ХВОСТ задом наперёд мы делаем его отсортированным по возрастанию.
Другая задача - про нахождение максимальной подпоследовательности чисел, чтобы первое делило второе, второе - третье и так далее, но это хуета простая. Ещё задача про то, что есть набор прямоугольников размерами (w, h) и надо подобрать размеры минимального квадрата, куда их надо уместить, поворачивать прямоугольники нельзя. Нам сказали, что тут надо бинарным поиском по размерам квадрата, проверяя, влезают ли все прямоугольники в квадрат данного размера. Проверка на влезание делается сравнением числа прямоугольников из входных данных c (x/w ∗ x/h), где x - догадка о размерах квадрата в бинарном поиске. Немного неочевидно откуда эта формула с подсчётом количества влезающих прямоугольников, наверное из-за того, что как ни крути (блять, нет, КРУТИТЬ НЕЛЬЗЯ СУКА НЕЛЬЗЯ по условию), оптимальнее, чем тупо располагая по строкам до упора, в квадрат заданного размера ты их не уместишь.
Последняя задача - на проверку того, соответствует ли строка паттерну со звёдочкой и вопросиком. Тут динамика: если сделать таблицу, где строки - это символы из паттерна, столбцы - символы из строки, ячейка (i, j) - соответствует ли подстрока stroka[1, j] паттерну pattern[1, i]. И заполнять таблицу понемногу. Если попадаются две равные буквы или вопросик, то приравниваем к ячейке слева сверху (то есть отъедаем и от строки, и от паттерна). Если попадается звёздочка, то берём максимум из того, что слева (звёздочка съедает букву) и что сверху (игнорируем звёздочку). Иначе ставим 0. Ну там наверняка всё сложно из-за краевых случаев на границе таблицы можно наверно сделать дополнительно слева столбец и сверху строку из нулей и в (-1, -1) ячейке поставить единицу, чтобы сматчился базовый случай с одной буквой в строке и одним вопросиком в паттерне (или той же буквой).
Бля пиздос я думал с токой стипендеей в 5.5к древянных я буду нихуёво богатой сучкой, но я забыл абсолютно про ПОБОРЫ НА ДНИ РОЖДЕНИЯ ОДНОГРУПНИКОВ какого вообще хуя. Я ОТДАЛ СОТКУ на двоих одногрупников. Я хуй знает, что у нас там дарят, бля полторы тыщи на подарок примерно это же нихуйственные деньги. Надеюсь, мне потом это сконвертируется в резиновый хуй и килограмм смазки, и всё равно сука жалко отдавать..
По математике было чёто про порядки малости функций, короче всё ещё задачи на посчитать пределы. На мега палевной паре я так и не понял, как нужно отмечать свою посещаемость, не увидел никого из своей группы (потому что пара на много людей сразу). Вроде видел место, где после окончания все толпой скучковались, но зассал подходить туда чёто, в следующий раз надо будет подождать, пока все уйдут и посмотреть что там. Наверное там листочек со списками групп, где галочки надо ставить
Проспал дохуя теперь болит голова, снова математика была, на этот раз дистанционная и вообще весь день дистанционным сделали. В полуха слушал, вроде про точки разрыва было. Большой минус пар по ебучему майкрософт тимсу, что мне на них становится абсолютно похуй. Потом лекция по программированию была, её я слушал в четверть уха, но там нихуя не рассказали толком, показали, слайды с какой-то программой разобранной что мол вот структурная парадигма, дейкстра, сверху вниз, заглушки вместо реализаций.
Единственное, что я усвоил из этого, что я нихуя так и не понял указатели, когда увидел объевление функции test(int ∗const ∗arg). Короче, оказалось, надо читать это справа налево и я для себя решил "∗const" воспринимать как одну штуку, которая ознает константный указатель. То есть вот так типа постфиксная запись: ((int)∗const)∗ - указатель на константный указатель, который указывает на int. То есть из этого можно менять значение самого arg и arg[j], но нельзя менять arg. А если так: test(int ∗const ∗const arg), то нельзя будет менять arg, только arg[j].
ПОтом по алгоритмам была лекция, на которой тупа задачки разбирали и от нас предполагалось что мы будем сразу их решать, но я затупил на первой же, сдался, остальные просто слушал разборы.
Там блин ещё такое было что надо посчитать (составить соотношение рекурентное) сколько существует последовательностей из 0 и 1 таких, чтобы не было трёх подряд идущих нулей. И ответ - это T(n) = T(n-1)+T(n-2)+T(n-3), это называется последовательностью трибоначи. И решение нихуя не очевидное, короче, все последовательности можно разбить на те, которые заканчиваются на 1, 10 и 100 и эти разбиения не пересекаются. И в сумме они дадут ВСЕ корректные последовательности, потому что дальше те, которые оканчиваются на 1000, 10000 и так далее не удовлетворяют условию
Ну и дальше если есть корректная (без трёх нулей подряд нигде) последовательность длины n-1, то можно дописать 1 и получить корректную последоватлеьность длины n, если есть длины n-2, то можно безболезненно дописать 10, если n-3, то 100.
И это будет исчерпывающе, потому что ну скажем если бы хотели дописать 101, то нет, мы уже рассмотрели этот вариант, потому что на 1 заканчивается. 110 - тоже. И именно до n-3 надо идти, потому что если меньше, например, до n-2, то хуй: если n-2-ое число - это 1, то можно было бы дописать и 00. И мы этот случай как раз рассматриваем, когда добавляем 100. А дальше n-4 уже не нужно, потому что 1000 надо будет дописывать, а это некорректная последовательноть по условию
Ещё была задача на лексикографический перебор перестановок я её нихуя не понял там алгоритм такой:
1. Находим ХВОСТ. ХВОСТ - эта наибольшая возрастающая последовательность, если считать с конца.
2. Берём элемент, который идёт слева от хвоста, и меняем его с наименьшим из ХВОСТА, который был бы больше него.
3. Переворачиваем ХВОСТ задом наперед
Я хуй знает как это понимать но наверно это в духе того, что случается при переполнении разряда (999 -> 1000) только у нас ограниченное число цифр и использовать их все можно только единожды. В 1432, например, "432" - это максимальная перестановка, которую можно сложить из этих цифр, поэтому нам надо апдейтнуть верхний разряд "1" следующим значением. Так как мы перебираем лексикографически, то гарантированно в ХВОСТЕ будет следующее значение для верхнего разряда, ну мы и достаём его оттуда. При этом после свопа отсортированность сохранится и переворачивая ХВОСТ задом наперёд мы делаем его отсортированным по возрастанию.
Другая задача - про нахождение максимальной подпоследовательности чисел, чтобы первое делило второе, второе - третье и так далее, но это хуета простая. Ещё задача про то, что есть набор прямоугольников размерами (w, h) и надо подобрать размеры минимального квадрата, куда их надо уместить, поворачивать прямоугольники нельзя. Нам сказали, что тут надо бинарным поиском по размерам квадрата, проверяя, влезают ли все прямоугольники в квадрат данного размера. Проверка на влезание делается сравнением числа прямоугольников из входных данных c (x/w ∗ x/h), где x - догадка о размерах квадрата в бинарном поиске. Немного неочевидно откуда эта формула с подсчётом количества влезающих прямоугольников, наверное из-за того, что как ни крути (блять, нет, КРУТИТЬ НЕЛЬЗЯ СУКА НЕЛЬЗЯ по условию), оптимальнее, чем тупо располагая по строкам до упора, в квадрат заданного размера ты их не уместишь.
Последняя задача - на проверку того, соответствует ли строка паттерну со звёдочкой и вопросиком. Тут динамика: если сделать таблицу, где строки - это символы из паттерна, столбцы - символы из строки, ячейка (i, j) - соответствует ли подстрока stroka[1, j] паттерну pattern[1, i]. И заполнять таблицу понемногу. Если попадаются две равные буквы или вопросик, то приравниваем к ячейке слева сверху (то есть отъедаем и от строки, и от паттерна). Если попадается звёздочка, то берём максимум из того, что слева (звёздочка съедает букву) и что сверху (игнорируем звёздочку). Иначе ставим 0. Ну там наверняка всё сложно из-за краевых случаев на границе таблицы можно наверно сделать дополнительно слева столбец и сверху строку из нулей и в (-1, -1) ячейке поставить единицу, чтобы сматчился базовый случай с одной буквой в строке и одним вопросиком в паттерне (или той же буквой).
Бля пиздос я думал с токой стипендеей в 5.5к древянных я буду нихуёво богатой сучкой, но я забыл абсолютно про ПОБОРЫ НА ДНИ РОЖДЕНИЯ ОДНОГРУПНИКОВ какого вообще хуя. Я ОТДАЛ СОТКУ на двоих одногрупников. Я хуй знает, что у нас там дарят, бля полторы тыщи на подарок примерно это же нихуйственные деньги. Надеюсь, мне потом это сконвертируется в резиновый хуй и килограмм смазки, и всё равно сука жалко отдавать..
271 Кб, 1300x1948так всё и все достали, я хочу спать только, больше нихуя не хочу и чтобы все нахуй пошли блять и отъебались от меня. Вчера у препода всё же было время вечером посмотреть мою домашку, поэтому её зачли. И на тот момент я чёто сильно хотел спать уже поэтому забил на всё и уснул. Ещё сильно устал из-за того, что два раза ездил в вуз из за дебильного расписания: сначала очная пара (математика), потом дистанционная (вот как раз сдача домашки) а потом снова очная (бля тут мега палево и диванон, не буду говорить что это).
По математике было чёто про порядки малости функций, короче всё ещё задачи на посчитать пределы. На мега палевной паре я так и не понял, как нужно отмечать свою посещаемость, не увидел никого из своей группы (потому что пара на много людей сразу). Вроде видел место, где после окончания все толпой скучковались, но зассал подходить туда чёто, в следующий раз надо будет подождать, пока все уйдут и посмотреть что там. Наверное там листочек со списками групп, где галочки надо ставить
Проспал дохуя теперь болит голова, снова математика была, на этот раз дистанционная и вообще весь день дистанционным сделали. В полуха слушал, вроде про точки разрыва было. Большой минус пар по ебучему майкрософт тимсу, что мне на них становится абсолютно похуй. Потом лекция по программированию была, её я слушал в четверть уха, но там нихуя не рассказали толком, показали, слайды с какой-то программой разобранной что мол вот структурная парадигма, дейкстра, сверху вниз, заглушки вместо реализаций.
Единственное, что я усвоил из этого, что я нихуя так и не понял указатели, когда увидел объевление функции test(int ∗const ∗arg). Короче, оказалось, надо читать это справа налево и я для себя решил "∗const" воспринимать как одну штуку, которая ознает константный указатель. То есть вот так типа постфиксная запись: ((int)∗const)∗ - указатель на константный указатель, который указывает на int. То есть из этого можно менять значение самого arg и arg[j], но нельзя менять arg. А если так: test(int ∗const ∗const arg), то нельзя будет менять arg, только arg[j].
ПОтом по алгоритмам была лекция, на которой тупа задачки разбирали и от нас предполагалось что мы будем сразу их решать, но я затупил на первой же, сдался, остальные просто слушал разборы.
Там блин ещё такое было что надо посчитать (составить соотношение рекурентное) сколько существует последовательностей из 0 и 1 таких, чтобы не было трёх подряд идущих нулей. И ответ - это T(n) = T(n-1)+T(n-2)+T(n-3), это называется последовательностью трибоначи. И решение нихуя не очевидное, короче, все последовательности можно разбить на те, которые заканчиваются на 1, 10 и 100 и эти разбиения не пересекаются. И в сумме они дадут ВСЕ корректные последовательности, потому что дальше те, которые оканчиваются на 1000, 10000 и так далее не удовлетворяют условию
Ну и дальше если есть корректная (без трёх нулей подряд нигде) последовательность длины n-1, то можно дописать 1 и получить корректную последоватлеьность длины n, если есть длины n-2, то можно безболезненно дописать 10, если n-3, то 100.
И это будет исчерпывающе, потому что ну скажем если бы хотели дописать 101, то нет, мы уже рассмотрели этот вариант, потому что на 1 заканчивается. 110 - тоже. И именно до n-3 надо идти, потому что если меньше, например, до n-2, то хуй: если n-2-ое число - это 1, то можно было бы дописать и 00. И мы этот случай как раз рассматриваем, когда добавляем 100. А дальше n-4 уже не нужно, потому что 1000 надо будет дописывать, а это некорректная последовательноть по условию
Ещё была задача на лексикографический перебор перестановок я её нихуя не понял там алгоритм такой:
1. Находим ХВОСТ. ХВОСТ - эта наибольшая возрастающая последовательность, если считать с конца.
2. Берём элемент, который идёт слева от хвоста, и меняем его с наименьшим из ХВОСТА, который был бы больше него.
3. Переворачиваем ХВОСТ задом наперед
Я хуй знает как это понимать но наверно это в духе того, что случается при переполнении разряда (999 -> 1000) только у нас ограниченное число цифр и использовать их все можно только единожды. В 1432, например, "432" - это максимальная перестановка, которую можно сложить из этих цифр, поэтому нам надо апдейтнуть верхний разряд "1" следующим значением. Так как мы перебираем лексикографически, то гарантированно в ХВОСТЕ будет следующее значение для верхнего разряда, ну мы и достаём его оттуда. При этом после свопа отсортированность сохранится и переворачивая ХВОСТ задом наперёд мы делаем его отсортированным по возрастанию.
Другая задача - про нахождение максимальной подпоследовательности чисел, чтобы первое делило второе, второе - третье и так далее, но это хуета простая. Ещё задача про то, что есть набор прямоугольников размерами (w, h) и надо подобрать размеры минимального квадрата, куда их надо уместить, поворачивать прямоугольники нельзя. Нам сказали, что тут надо бинарным поиском по размерам квадрата, проверяя, влезают ли все прямоугольники в квадрат данного размера. Проверка на влезание делается сравнением числа прямоугольников из входных данных c (x/w ∗ x/h), где x - догадка о размерах квадрата в бинарном поиске. Немного неочевидно откуда эта формула с подсчётом количества влезающих прямоугольников, наверное из-за того, что как ни крути (блять, нет, КРУТИТЬ НЕЛЬЗЯ СУКА НЕЛЬЗЯ по условию), оптимальнее, чем тупо располагая по строкам до упора, в квадрат заданного размера ты их не уместишь.
Последняя задача - на проверку того, соответствует ли строка паттерну со звёдочкой и вопросиком. Тут динамика: если сделать таблицу, где строки - это символы из паттерна, столбцы - символы из строки, ячейка (i, j) - соответствует ли подстрока stroka[1, j] паттерну pattern[1, i]. И заполнять таблицу понемногу. Если попадаются две равные буквы или вопросик, то приравниваем к ячейке слева сверху (то есть отъедаем и от строки, и от паттерна). Если попадается звёздочка, то берём максимум из того, что слева (звёздочка съедает букву) и что сверху (игнорируем звёздочку). Иначе ставим 0. Ну там наверняка всё сложно из-за краевых случаев на границе таблицы можно наверно сделать дополнительно слева столбец и сверху строку из нулей и в (-1, -1) ячейке поставить единицу, чтобы сматчился базовый случай с одной буквой в строке и одним вопросиком в паттерне (или той же буквой).
Бля пиздос я думал с токой стипендеей в 5.5к древянных я буду нихуёво богатой сучкой, но я забыл абсолютно про ПОБОРЫ НА ДНИ РОЖДЕНИЯ ОДНОГРУПНИКОВ какого вообще хуя. Я ОТДАЛ СОТКУ на двоих одногрупников. Я хуй знает, что у нас там дарят, бля полторы тыщи на подарок примерно это же нихуйственные деньги. Надеюсь, мне потом это сконвертируется в резиновый хуй и килограмм смазки, и всё равно сука жалко отдавать..
По математике было чёто про порядки малости функций, короче всё ещё задачи на посчитать пределы. На мега палевной паре я так и не понял, как нужно отмечать свою посещаемость, не увидел никого из своей группы (потому что пара на много людей сразу). Вроде видел место, где после окончания все толпой скучковались, но зассал подходить туда чёто, в следующий раз надо будет подождать, пока все уйдут и посмотреть что там. Наверное там листочек со списками групп, где галочки надо ставить
Проспал дохуя теперь болит голова, снова математика была, на этот раз дистанционная и вообще весь день дистанционным сделали. В полуха слушал, вроде про точки разрыва было. Большой минус пар по ебучему майкрософт тимсу, что мне на них становится абсолютно похуй. Потом лекция по программированию была, её я слушал в четверть уха, но там нихуя не рассказали толком, показали, слайды с какой-то программой разобранной что мол вот структурная парадигма, дейкстра, сверху вниз, заглушки вместо реализаций.
Единственное, что я усвоил из этого, что я нихуя так и не понял указатели, когда увидел объевление функции test(int ∗const ∗arg). Короче, оказалось, надо читать это справа налево и я для себя решил "∗const" воспринимать как одну штуку, которая ознает константный указатель. То есть вот так типа постфиксная запись: ((int)∗const)∗ - указатель на константный указатель, который указывает на int. То есть из этого можно менять значение самого arg и arg[j], но нельзя менять arg. А если так: test(int ∗const ∗const arg), то нельзя будет менять arg, только arg[j].
ПОтом по алгоритмам была лекция, на которой тупа задачки разбирали и от нас предполагалось что мы будем сразу их решать, но я затупил на первой же, сдался, остальные просто слушал разборы.
Там блин ещё такое было что надо посчитать (составить соотношение рекурентное) сколько существует последовательностей из 0 и 1 таких, чтобы не было трёх подряд идущих нулей. И ответ - это T(n) = T(n-1)+T(n-2)+T(n-3), это называется последовательностью трибоначи. И решение нихуя не очевидное, короче, все последовательности можно разбить на те, которые заканчиваются на 1, 10 и 100 и эти разбиения не пересекаются. И в сумме они дадут ВСЕ корректные последовательности, потому что дальше те, которые оканчиваются на 1000, 10000 и так далее не удовлетворяют условию
Ну и дальше если есть корректная (без трёх нулей подряд нигде) последовательность длины n-1, то можно дописать 1 и получить корректную последоватлеьность длины n, если есть длины n-2, то можно безболезненно дописать 10, если n-3, то 100.
И это будет исчерпывающе, потому что ну скажем если бы хотели дописать 101, то нет, мы уже рассмотрели этот вариант, потому что на 1 заканчивается. 110 - тоже. И именно до n-3 надо идти, потому что если меньше, например, до n-2, то хуй: если n-2-ое число - это 1, то можно было бы дописать и 00. И мы этот случай как раз рассматриваем, когда добавляем 100. А дальше n-4 уже не нужно, потому что 1000 надо будет дописывать, а это некорректная последовательноть по условию
Ещё была задача на лексикографический перебор перестановок я её нихуя не понял там алгоритм такой:
1. Находим ХВОСТ. ХВОСТ - эта наибольшая возрастающая последовательность, если считать с конца.
2. Берём элемент, который идёт слева от хвоста, и меняем его с наименьшим из ХВОСТА, который был бы больше него.
3. Переворачиваем ХВОСТ задом наперед
Я хуй знает как это понимать но наверно это в духе того, что случается при переполнении разряда (999 -> 1000) только у нас ограниченное число цифр и использовать их все можно только единожды. В 1432, например, "432" - это максимальная перестановка, которую можно сложить из этих цифр, поэтому нам надо апдейтнуть верхний разряд "1" следующим значением. Так как мы перебираем лексикографически, то гарантированно в ХВОСТЕ будет следующее значение для верхнего разряда, ну мы и достаём его оттуда. При этом после свопа отсортированность сохранится и переворачивая ХВОСТ задом наперёд мы делаем его отсортированным по возрастанию.
Другая задача - про нахождение максимальной подпоследовательности чисел, чтобы первое делило второе, второе - третье и так далее, но это хуета простая. Ещё задача про то, что есть набор прямоугольников размерами (w, h) и надо подобрать размеры минимального квадрата, куда их надо уместить, поворачивать прямоугольники нельзя. Нам сказали, что тут надо бинарным поиском по размерам квадрата, проверяя, влезают ли все прямоугольники в квадрат данного размера. Проверка на влезание делается сравнением числа прямоугольников из входных данных c (x/w ∗ x/h), где x - догадка о размерах квадрата в бинарном поиске. Немного неочевидно откуда эта формула с подсчётом количества влезающих прямоугольников, наверное из-за того, что как ни крути (блять, нет, КРУТИТЬ НЕЛЬЗЯ СУКА НЕЛЬЗЯ по условию), оптимальнее, чем тупо располагая по строкам до упора, в квадрат заданного размера ты их не уместишь.
Последняя задача - на проверку того, соответствует ли строка паттерну со звёдочкой и вопросиком. Тут динамика: если сделать таблицу, где строки - это символы из паттерна, столбцы - символы из строки, ячейка (i, j) - соответствует ли подстрока stroka[1, j] паттерну pattern[1, i]. И заполнять таблицу понемногу. Если попадаются две равные буквы или вопросик, то приравниваем к ячейке слева сверху (то есть отъедаем и от строки, и от паттерна). Если попадается звёздочка, то берём максимум из того, что слева (звёздочка съедает букву) и что сверху (игнорируем звёздочку). Иначе ставим 0. Ну там наверняка всё сложно из-за краевых случаев на границе таблицы можно наверно сделать дополнительно слева столбец и сверху строку из нулей и в (-1, -1) ячейке поставить единицу, чтобы сматчился базовый случай с одной буквой в строке и одним вопросиком в паттерне (или той же буквой).
Бля пиздос я думал с токой стипендеей в 5.5к древянных я буду нихуёво богатой сучкой, но я забыл абсолютно про ПОБОРЫ НА ДНИ РОЖДЕНИЯ ОДНОГРУПНИКОВ какого вообще хуя. Я ОТДАЛ СОТКУ на двоих одногрупников. Я хуй знает, что у нас там дарят, бля полторы тыщи на подарок примерно это же нихуйственные деньги. Надеюсь, мне потом это сконвертируется в резиновый хуй и килограмм смазки, и всё равно сука жалко отдавать..
>>14496
Блять, ну конечно [i][/i] - это ёбаный курсив.
>((int)∗const)∗ - указатель на константный указатель, который указывает на int. То есть из этого можно менять значение самого arg и arg[j][i], но нельзя менять arg[i]. А если так: test(int ∗const ∗const arg), то нельзя будет менять arg[i], только arg[j][i].
Блять, ну конечно [i][/i] - это ёбаный курсив.
Охуенная конверсия, определённо стоило того, чтобы впихнуть свою обоссанную ватермарку
Интересно, можно ли только средствами ffmpeg всё пофиксить. Наверняка же да, тот, кто склепал это видео был достаточно тупым, чтобы наложить текст поверх статичного момента.
Сначала надо извлечь кадры, чтобы определить, какой из них последний без ватермарки:
ffmpeg -ss 00:00:08 -to 00:00:09 -i video.webm -r 30/1 %02d.bmp
Получаем, что 9 кадр в 8 секунде - последний без ватермарки, а сама ватермарка длится с 10 по 15 кадры включительно. То есть примерно с 8.2 секунды по 8.5 (я первый раз с ffmpeg ом что то делаю не понел, как кадры указывать, поэтому взял секунды тупо с небольшим запасом) Чистим ненужное:
find . -not -name '09.bmp' -and -name '*.bmp' -delete
И вот так не знаю сокпировал из интернета это
ffmpeg -i video.webm -i 09.bmp -filter_complex "[0:v][1:v] overlay=0:0:enable='between(t, 8.2, 8.5)'" -c:a copy output.webm
Всё, я победил.
>>14509
Если взять шире, то это будет неправдой же.
Сначала надо извлечь кадры, чтобы определить, какой из них последний без ватермарки:
ffmpeg -ss 00:00:08 -to 00:00:09 -i video.webm -r 30/1 %02d.bmp
Получаем, что 9 кадр в 8 секунде - последний без ватермарки, а сама ватермарка длится с 10 по 15 кадры включительно. То есть примерно с 8.2 секунды по 8.5 (я первый раз с ffmpeg ом что то делаю не понел, как кадры указывать, поэтому взял секунды тупо с небольшим запасом) Чистим ненужное:
find . -not -name '09.bmp' -and -name '*.bmp' -delete
И вот так не знаю сокпировал из интернета это
ffmpeg -i video.webm -i 09.bmp -filter_complex "[0:v][1:v] overlay=0:0:enable='between(t, 8.2, 8.5)'" -c:a copy output.webm
Всё, я победил.
>>14509
Если взять шире, то это будет неправдой же.
>>14519
Почему неправда? У быдла может родиться только быдло, а не девственники быдло, значит все быдло.
Почему неправда? У быдла может родиться только быдло, а не девственники быдло, значит все быдло.
>>14534
Да отъебись от меня уже со своими девственниками.
Пиздец, как же достало всё когда я уже сдохну нахуй. Очень хочется спать, нихуя не могу делать из-за этого. Наверное часа три уже так хуйнёй маюсь.
На физкультуре сегодня ничего не было особенного. Было очень холодно токо, руки сильно замёрзли. Я так не люблю носить перчатки, но видимо придётся на физкультуру откопать какие нибудь, потому что в карманы руки не спрячешь. В следующий раз вроде нормативы по прыжкам с места будем сдавать, но это всё так, даже, если не сдаёшь, тебе всё равно начисляют половину баллов.
На физике какие то задачи решали на момент силы вроде. Я мало что понял, потому что теорию ещё не прошёл по этой теме. А через неделю будет уже контрольная с задачками по темам, которые решали. В перерыве смотрел немного физику, про момент импульса, момент инерции и момент импульса. По сути вроде как момент импульса - это аналог обычного импульса, только для вращательного движения, момент инерции - аналог массы, а момент силы - аналог силы. И там тоже есть закон сохранения момента импульса для замкнутых систем.
Но я всё равно слабо понимаю, что этот момент импульса означает на практике. Если обычный импульс - это количество поступательного движения, то момент импульса - это количество вращательного, при этом оно зависит от радиуса вращения и уголовой скорости.
Сдал ещё одну лабу по микроэлектронике, всё ещё ничего особенного и вроде всё понятно. Но была одна филлерная лекция, которую я так и не посмотрел, там про МОП транзисторы чёто было. Я даже не знаю чё такое электрический ток очень сложно пытаться понимать из-за этого, как работают эти транзисторы. Чисто интуитивно на чёрную штуку сверху подаётся заряд, который либо наводит, либо разрывает ток между стоком и истоком, то есть типа как механическое реле работает, только без подвижных частей. Электронику на транзисторах поэтому ещё давно начали называть solid-state именно потому, тчо ничего не двигается.
Чёт я ещё читал про коды хэмминга, что они используются в оперативной памяти для каждого слова. Для того, чтобы можно было задетектить k ошибок, нужно, чтобы между корректными кодовыми словами было расстояние хэмминга (сколько раз минимум поменять биты, чтобы получить из одного слова другое) было k+1, то есть чтобы за k ошибок нельзя было перейти от одного корректного кодового слова к другому. А для коррекции k ошибок понадобится 2k+1, чтобы после k ошибок ты всё ещё был ближе к кодовому слову, в котором ошибался. Блин, я этот момент не понимал, думал, что коды эти - это магия какая та, а конкретно тут это всё не так слонжо.
А ещё есть какие та коды рида соломона, которые уже хуй объяснишь так просто и они вроде умеют исправлять много ошибок, очень оптимально используя избыточность. Они вроде используются там, где избыточность разумна, потому что невозможно (данные на компакт диске) или очень дорого (очень маленькая и/или сильно подверженная помехами скорость передачи данных) восстановить данные иначе.
а в хеминге Если хотим уметь исправлять ровно одну ошибку, то если взять слово из n = m + r битов, где m - данные, r - проверочные биты, то на каждый набор данных должно прийтись n+1 кодовых слов: n с ошибками и одно корректное. ПОэтому можно составить неравенство (n+1)2^m <= 2^n или (m+r+1)<=2^r. То есть при заданном m можно найти минимальное количество проверочных битов r.
При этом проверочные биты это тупо биты чётности по определённым позициям. Для m = 2^b понадобится b+1 проверочных битов. То есть каждый проверочный бит можно сопоставить разряду в двоичном представлении индекса бита данных. Хуй знает почему это работает на самам деле. Наверно тупо из-за того, что биты слова (данные) разбиваются на пересекающиеся группы по двоичным представлениям своих индексов. И, если фейлятся какие-то биты чётности, то можно через пересечение этих групп найти ровно один ошибочный бит. Именно поэтому там в алгоритме нахождения ошибки суммируются индексы ошибочных битов чётности: это и есть по сути пересечение групп.
Зачем-то ещё биты чётности в кодовом слове ставят на позиции степени двойки. Я слышал, что что-то похожее называется interleaving и оно делается потому, что часто ошибки кучкуются, а все ECC (error correction code) заточены под равномерное распредение ошибок. Но тут-то в любом случае только одну ошибку сможем исправить, так что не всё ли равно. Хотя может это обусловлено удобством проверки корректности кодового слова, не знаю.
Да отъебись от меня уже со своими девственниками.
Пиздец, как же достало всё когда я уже сдохну нахуй. Очень хочется спать, нихуя не могу делать из-за этого. Наверное часа три уже так хуйнёй маюсь.
На физкультуре сегодня ничего не было особенного. Было очень холодно токо, руки сильно замёрзли. Я так не люблю носить перчатки, но видимо придётся на физкультуру откопать какие нибудь, потому что в карманы руки не спрячешь. В следующий раз вроде нормативы по прыжкам с места будем сдавать, но это всё так, даже, если не сдаёшь, тебе всё равно начисляют половину баллов.
На физике какие то задачи решали на момент силы вроде. Я мало что понял, потому что теорию ещё не прошёл по этой теме. А через неделю будет уже контрольная с задачками по темам, которые решали. В перерыве смотрел немного физику, про момент импульса, момент инерции и момент импульса. По сути вроде как момент импульса - это аналог обычного импульса, только для вращательного движения, момент инерции - аналог массы, а момент силы - аналог силы. И там тоже есть закон сохранения момента импульса для замкнутых систем.
Но я всё равно слабо понимаю, что этот момент импульса означает на практике. Если обычный импульс - это количество поступательного движения, то момент импульса - это количество вращательного, при этом оно зависит от радиуса вращения и уголовой скорости.
Сдал ещё одну лабу по микроэлектронике, всё ещё ничего особенного и вроде всё понятно. Но была одна филлерная лекция, которую я так и не посмотрел, там про МОП транзисторы чёто было. Я даже не знаю чё такое электрический ток очень сложно пытаться понимать из-за этого, как работают эти транзисторы. Чисто интуитивно на чёрную штуку сверху подаётся заряд, который либо наводит, либо разрывает ток между стоком и истоком, то есть типа как механическое реле работает, только без подвижных частей. Электронику на транзисторах поэтому ещё давно начали называть solid-state именно потому, тчо ничего не двигается.
Чёт я ещё читал про коды хэмминга, что они используются в оперативной памяти для каждого слова. Для того, чтобы можно было задетектить k ошибок, нужно, чтобы между корректными кодовыми словами было расстояние хэмминга (сколько раз минимум поменять биты, чтобы получить из одного слова другое) было k+1, то есть чтобы за k ошибок нельзя было перейти от одного корректного кодового слова к другому. А для коррекции k ошибок понадобится 2k+1, чтобы после k ошибок ты всё ещё был ближе к кодовому слову, в котором ошибался. Блин, я этот момент не понимал, думал, что коды эти - это магия какая та, а конкретно тут это всё не так слонжо.
А ещё есть какие та коды рида соломона, которые уже хуй объяснишь так просто и они вроде умеют исправлять много ошибок, очень оптимально используя избыточность. Они вроде используются там, где избыточность разумна, потому что невозможно (данные на компакт диске) или очень дорого (очень маленькая и/или сильно подверженная помехами скорость передачи данных) восстановить данные иначе.
а в хеминге Если хотим уметь исправлять ровно одну ошибку, то если взять слово из n = m + r битов, где m - данные, r - проверочные биты, то на каждый набор данных должно прийтись n+1 кодовых слов: n с ошибками и одно корректное. ПОэтому можно составить неравенство (n+1)2^m <= 2^n или (m+r+1)<=2^r. То есть при заданном m можно найти минимальное количество проверочных битов r.
При этом проверочные биты это тупо биты чётности по определённым позициям. Для m = 2^b понадобится b+1 проверочных битов. То есть каждый проверочный бит можно сопоставить разряду в двоичном представлении индекса бита данных. Хуй знает почему это работает на самам деле. Наверно тупо из-за того, что биты слова (данные) разбиваются на пересекающиеся группы по двоичным представлениям своих индексов. И, если фейлятся какие-то биты чётности, то можно через пересечение этих групп найти ровно один ошибочный бит. Именно поэтому там в алгоритме нахождения ошибки суммируются индексы ошибочных битов чётности: это и есть по сути пересечение групп.
Зачем-то ещё биты чётности в кодовом слове ставят на позиции степени двойки. Я слышал, что что-то похожее называется interleaving и оно делается потому, что часто ошибки кучкуются, а все ECC (error correction code) заточены под равномерное распредение ошибок. Но тут-то в любом случае только одну ошибку сможем исправить, так что не всё ли равно. Хотя может это обусловлено удобством проверки корректности кодового слова, не знаю.
>>14534
Да отъебись от меня уже со своими девственниками.
Пиздец, как же достало всё когда я уже сдохну нахуй. Очень хочется спать, нихуя не могу делать из-за этого. Наверное часа три уже так хуйнёй маюсь.
На физкультуре сегодня ничего не было особенного. Было очень холодно токо, руки сильно замёрзли. Я так не люблю носить перчатки, но видимо придётся на физкультуру откопать какие нибудь, потому что в карманы руки не спрячешь. В следующий раз вроде нормативы по прыжкам с места будем сдавать, но это всё так, даже, если не сдаёшь, тебе всё равно начисляют половину баллов.
На физике какие то задачи решали на момент силы вроде. Я мало что понял, потому что теорию ещё не прошёл по этой теме. А через неделю будет уже контрольная с задачками по темам, которые решали. В перерыве смотрел немного физику, про момент импульса, момент инерции и момент импульса. По сути вроде как момент импульса - это аналог обычного импульса, только для вращательного движения, момент инерции - аналог массы, а момент силы - аналог силы. И там тоже есть закон сохранения момента импульса для замкнутых систем.
Но я всё равно слабо понимаю, что этот момент импульса означает на практике. Если обычный импульс - это количество поступательного движения, то момент импульса - это количество вращательного, при этом оно зависит от радиуса вращения и уголовой скорости.
Сдал ещё одну лабу по микроэлектронике, всё ещё ничего особенного и вроде всё понятно. Но была одна филлерная лекция, которую я так и не посмотрел, там про МОП транзисторы чёто было. Я даже не знаю чё такое электрический ток очень сложно пытаться понимать из-за этого, как работают эти транзисторы. Чисто интуитивно на чёрную штуку сверху подаётся заряд, который либо наводит, либо разрывает ток между стоком и истоком, то есть типа как механическое реле работает, только без подвижных частей. Электронику на транзисторах поэтому ещё давно начали называть solid-state именно потому, тчо ничего не двигается.
Чёт я ещё читал про коды хэмминга, что они используются в оперативной памяти для каждого слова. Для того, чтобы можно было задетектить k ошибок, нужно, чтобы между корректными кодовыми словами было расстояние хэмминга (сколько раз минимум поменять биты, чтобы получить из одного слова другое) было k+1, то есть чтобы за k ошибок нельзя было перейти от одного корректного кодового слова к другому. А для коррекции k ошибок понадобится 2k+1, чтобы после k ошибок ты всё ещё был ближе к кодовому слову, в котором ошибался. Блин, я этот момент не понимал, думал, что коды эти - это магия какая та, а конкретно тут это всё не так слонжо.
А ещё есть какие та коды рида соломона, которые уже хуй объяснишь так просто и они вроде умеют исправлять много ошибок, очень оптимально используя избыточность. Они вроде используются там, где избыточность разумна, потому что невозможно (данные на компакт диске) или очень дорого (очень маленькая и/или сильно подверженная помехами скорость передачи данных) восстановить данные иначе.
а в хеминге Если хотим уметь исправлять ровно одну ошибку, то если взять слово из n = m + r битов, где m - данные, r - проверочные биты, то на каждый набор данных должно прийтись n+1 кодовых слов: n с ошибками и одно корректное. ПОэтому можно составить неравенство (n+1)2^m <= 2^n или (m+r+1)<=2^r. То есть при заданном m можно найти минимальное количество проверочных битов r.
При этом проверочные биты это тупо биты чётности по определённым позициям. Для m = 2^b понадобится b+1 проверочных битов. То есть каждый проверочный бит можно сопоставить разряду в двоичном представлении индекса бита данных. Хуй знает почему это работает на самам деле. Наверно тупо из-за того, что биты слова (данные) разбиваются на пересекающиеся группы по двоичным представлениям своих индексов. И, если фейлятся какие-то биты чётности, то можно через пересечение этих групп найти ровно один ошибочный бит. Именно поэтому там в алгоритме нахождения ошибки суммируются индексы ошибочных битов чётности: это и есть по сути пересечение групп.
Зачем-то ещё биты чётности в кодовом слове ставят на позиции степени двойки. Я слышал, что что-то похожее называется interleaving и оно делается потому, что часто ошибки кучкуются, а все ECC (error correction code) заточены под равномерное распредение ошибок. Но тут-то в любом случае только одну ошибку сможем исправить, так что не всё ли равно. Хотя может это обусловлено удобством проверки корректности кодового слова, не знаю.
Да отъебись от меня уже со своими девственниками.
Пиздец, как же достало всё когда я уже сдохну нахуй. Очень хочется спать, нихуя не могу делать из-за этого. Наверное часа три уже так хуйнёй маюсь.
На физкультуре сегодня ничего не было особенного. Было очень холодно токо, руки сильно замёрзли. Я так не люблю носить перчатки, но видимо придётся на физкультуру откопать какие нибудь, потому что в карманы руки не спрячешь. В следующий раз вроде нормативы по прыжкам с места будем сдавать, но это всё так, даже, если не сдаёшь, тебе всё равно начисляют половину баллов.
На физике какие то задачи решали на момент силы вроде. Я мало что понял, потому что теорию ещё не прошёл по этой теме. А через неделю будет уже контрольная с задачками по темам, которые решали. В перерыве смотрел немного физику, про момент импульса, момент инерции и момент импульса. По сути вроде как момент импульса - это аналог обычного импульса, только для вращательного движения, момент инерции - аналог массы, а момент силы - аналог силы. И там тоже есть закон сохранения момента импульса для замкнутых систем.
Но я всё равно слабо понимаю, что этот момент импульса означает на практике. Если обычный импульс - это количество поступательного движения, то момент импульса - это количество вращательного, при этом оно зависит от радиуса вращения и уголовой скорости.
Сдал ещё одну лабу по микроэлектронике, всё ещё ничего особенного и вроде всё понятно. Но была одна филлерная лекция, которую я так и не посмотрел, там про МОП транзисторы чёто было. Я даже не знаю чё такое электрический ток очень сложно пытаться понимать из-за этого, как работают эти транзисторы. Чисто интуитивно на чёрную штуку сверху подаётся заряд, который либо наводит, либо разрывает ток между стоком и истоком, то есть типа как механическое реле работает, только без подвижных частей. Электронику на транзисторах поэтому ещё давно начали называть solid-state именно потому, тчо ничего не двигается.
Чёт я ещё читал про коды хэмминга, что они используются в оперативной памяти для каждого слова. Для того, чтобы можно было задетектить k ошибок, нужно, чтобы между корректными кодовыми словами было расстояние хэмминга (сколько раз минимум поменять биты, чтобы получить из одного слова другое) было k+1, то есть чтобы за k ошибок нельзя было перейти от одного корректного кодового слова к другому. А для коррекции k ошибок понадобится 2k+1, чтобы после k ошибок ты всё ещё был ближе к кодовому слову, в котором ошибался. Блин, я этот момент не понимал, думал, что коды эти - это магия какая та, а конкретно тут это всё не так слонжо.
А ещё есть какие та коды рида соломона, которые уже хуй объяснишь так просто и они вроде умеют исправлять много ошибок, очень оптимально используя избыточность. Они вроде используются там, где избыточность разумна, потому что невозможно (данные на компакт диске) или очень дорого (очень маленькая и/или сильно подверженная помехами скорость передачи данных) восстановить данные иначе.
а в хеминге Если хотим уметь исправлять ровно одну ошибку, то если взять слово из n = m + r битов, где m - данные, r - проверочные биты, то на каждый набор данных должно прийтись n+1 кодовых слов: n с ошибками и одно корректное. ПОэтому можно составить неравенство (n+1)2^m <= 2^n или (m+r+1)<=2^r. То есть при заданном m можно найти минимальное количество проверочных битов r.
При этом проверочные биты это тупо биты чётности по определённым позициям. Для m = 2^b понадобится b+1 проверочных битов. То есть каждый проверочный бит можно сопоставить разряду в двоичном представлении индекса бита данных. Хуй знает почему это работает на самам деле. Наверно тупо из-за того, что биты слова (данные) разбиваются на пересекающиеся группы по двоичным представлениям своих индексов. И, если фейлятся какие-то биты чётности, то можно через пересечение этих групп найти ровно один ошибочный бит. Именно поэтому там в алгоритме нахождения ошибки суммируются индексы ошибочных битов чётности: это и есть по сути пересечение групп.
Зачем-то ещё биты чётности в кодовом слове ставят на позиции степени двойки. Я слышал, что что-то похожее называется interleaving и оно делается потому, что часто ошибки кучкуются, а все ECC (error correction code) заточены под равномерное распредение ошибок. Но тут-то в любом случае только одну ошибку сможем исправить, так что не всё ли равно. Хотя может это обусловлено удобством проверки корректности кодового слова, не знаю.
Немного совсем про secondary память читал ещё. Что в магнитных дисках используется не тупо один диск, а сразу много и сразу много считывающих головок соответственно и по каждой стороне диска, которые синхронизированы по расстоянию от центра диска. (Но так и не понял, синхронно ли вращаются диски) То есть данные образуют такие цилиндры. Я видел какой-то раздолбанный винчестер один раз, там внутри диск токо один был, наверное это был старый винчестер, раз только один, а не много. Круг из данных на одном диске - это трек и он дополнительно делится ещё на секторы, каждый из которых помимо данных хранит ещё ECC в конце и преамбулу, видимо, чтобы считывающая головка могла понять, откуда надо читать и синхронизировалась.
Опять же понятия не имею, как это работает. ну раз диски магнитные то они наврено магнетизируются что бы это не знаачило. И можно это делать по разному, например, на картинке сравниваются два варианта, второй - более крутой, потому что он плотнее упаковывает данные на диске за счёт того, что магнетизирует. глубже?
Вроде Проблема с дисками в том, что у них длина трека увеличивается по удалению от центра диска. И раньше это решали ещё тем, что делали тупо меньшую плотность данных по краям, так что можно было выровнять секторы по всему диску. Но потом стали использовать более умное решение с разделенеием диска на зоны, в которых на треках одинаковое количество секторов. Наверное так всё равно будет теряться некоторое количество полезного пространства, но там ещё говорилось про то, что "плохие" секторы (в которых чёто магнетизировалось навсегда) автоматически маппятся контроллером диска на здоровые секторы, может, как раз используются неиспользованые куски в зонах.
Из того, что было про стандраты передачи данных между компом и дисками я только понел то, что их было очень много и они все отпадали из-за того, что слишком мало бит выделялось на адресацию секторов. И сейчас два использующихся - это SATA (вроде во всех обычных компах такой, накопители подключаются по одному) и SCSI (произносится как "скази", используются в серверах, можно сразу много по шине подключать, и вроде там они подключаются последовательно типа как тут https://youtu.be/rJ5bao4o3pk?t=95 )
А вот про RAID ещё узнал но я так и не понял, пользуются ли им кто-то сейчас. Я до этого о нём слышал, но там было хуёвое объяснение, ещё и думал, что нумерация вариантов RAID массивов означает, что кто-то является предшественником кого то, А оказалось, что это нихуя не значит, просто номера
И RAID - это не только про увеличение надёжности (redundant), но и про увеличение скорости за счёт распараллеливания чтенния. Например RAID 0 - это когда данные делятся на стрипы, в каждом из которых по k секторов. И если пишется достаточно много данных, то они распределяются равномерно между четырьмя дисками по стрипам. Потом при чтении можно сразу с нескольких дисков читать в параллели.
Там упоминалось про то, что если скажем срок жизни диска скажем 20,000 часов, то если есть 4 таких диска, то они будут ломаться в среднем каждые 5,000 часов. Это немного ломает мозг, я не понимаю. Типа мало вероятно, что все 4 дослужат до 20к, скорее всего, кто-то сломается по пути и наибольшая вероятность, если они будут ломаться каждые 5к часов. Странна. RAID 1 - то же самое, но с избыточностью.
RAID 2 - это какая та убийственная вещь, которая каждое кодовое слово (с битами чётности) длины N размазывает по N дискам побитово. Плюс в том, что если какой-то диск выходит из строя, то теряется один бит из каждого слова, то есть можно восстановить все данные. Но минус вроде в том, что сложно синхронизировать считывающие головки дисков. Не понял про это.
RAID 3 - упрощённый вариант RAID 2, тут биты чётности хранятся для каждого слова на отдельном диске, по одному биту чётности на каждое слово, потому что если какой-то диск с данными выходит из строя, то можно восстановить выпавшие биты, потому что в отличие от общего случая применения, мы тут ЗНАЕМ, КАКОЙ КОНКРЕТНО БИТ ВЫПАЛ. Не знаю, нафига в RAID 2 хранить тогда было всё в кодах хемминга, а нет ну по той же причине, по какой мы бы на обычном диске хранили данные с ECC.
RAID 4 и 5 хранят последовательные цельные стрипы, а не отдельные биты, и ещё XOR'ят все стрипы в одном ряду (как на картинке от Strip 0 до Strip 3, например). То есть тоже, если один из дисков выходит из строя, можно всё восстановить. RAID 5 решает проблему RAID 4 с тем, что диск с битами чётности может быть боттлнеком, потому что нам в него надо писать / из него читать при доступе к любым другим дискам. RAID 5 распределяет равномерно стрипы с битами чётности по всем дискам. И вроде общая проблема RAID 4, RAID 5, что при изменении только одного сектора в стрипе придётся в лучшем случае прочесть старые данные в секторе, прочесть биты чётности, чтобы записать потом новые биты чётности. То есть одно обращение для записи превращается в две записи и два чтения.
Вообще они все выглядят проблемными и странными. В википедии на эту тему в достоинствах и недостатках слишком непонятно расписано, хуй знает что в итоге в чём лучше чего работает
Ещё про SSD (solid state drives) совсем немного было, что они быстрые, но дорогие относительно магнитных дисков, и в них транзисторы изнашиваются. Потому что там при записи используется являение, которое называется hot-carrier injection: в транзисторах мы там в диэлектрик запихиваем небольшой проводник, как я понимаю https://en.wikipedia.org/wiki/Floating-gate_MOSFET и если подать достаточно большое напряжение на затвор, то электроны, путешествующие между истоком и стоком будут набирать достаточную кинетическую энергию, чтобы они попадали в этот проводник между слоями диэлектрика. И когда их там набирается достаточно, они разрывают ток между истоком и стоком. То есть так можно хранить данные и это будет non-volatile хранение. Проблема в том, что из-за hot-carrier injection будут рушиться структуры диэлектрика и проводника внутри него, поэтому на каждый транзистор приходится ограниченное число записей. НО вроде как неограниченное число чтений, потому что читать можно безопасно. Не очень понял только, как вытащить электтроны оттуда, но ладно. Какой та Fowler–Nordheim tunneling сложные слова я ничего не понимаю
Опять же понятия не имею, как это работает. ну раз диски магнитные то они наврено магнетизируются что бы это не знаачило. И можно это делать по разному, например, на картинке сравниваются два варианта, второй - более крутой, потому что он плотнее упаковывает данные на диске за счёт того, что магнетизирует. глубже?
Вроде Проблема с дисками в том, что у них длина трека увеличивается по удалению от центра диска. И раньше это решали ещё тем, что делали тупо меньшую плотность данных по краям, так что можно было выровнять секторы по всему диску. Но потом стали использовать более умное решение с разделенеием диска на зоны, в которых на треках одинаковое количество секторов. Наверное так всё равно будет теряться некоторое количество полезного пространства, но там ещё говорилось про то, что "плохие" секторы (в которых чёто магнетизировалось навсегда) автоматически маппятся контроллером диска на здоровые секторы, может, как раз используются неиспользованые куски в зонах.
Из того, что было про стандраты передачи данных между компом и дисками я только понел то, что их было очень много и они все отпадали из-за того, что слишком мало бит выделялось на адресацию секторов. И сейчас два использующихся - это SATA (вроде во всех обычных компах такой, накопители подключаются по одному) и SCSI (произносится как "скази", используются в серверах, можно сразу много по шине подключать, и вроде там они подключаются последовательно типа как тут https://youtu.be/rJ5bao4o3pk?t=95 )
А вот про RAID ещё узнал но я так и не понял, пользуются ли им кто-то сейчас. Я до этого о нём слышал, но там было хуёвое объяснение, ещё и думал, что нумерация вариантов RAID массивов означает, что кто-то является предшественником кого то, А оказалось, что это нихуя не значит, просто номера
И RAID - это не только про увеличение надёжности (redundant), но и про увеличение скорости за счёт распараллеливания чтенния. Например RAID 0 - это когда данные делятся на стрипы, в каждом из которых по k секторов. И если пишется достаточно много данных, то они распределяются равномерно между четырьмя дисками по стрипам. Потом при чтении можно сразу с нескольких дисков читать в параллели.
Там упоминалось про то, что если скажем срок жизни диска скажем 20,000 часов, то если есть 4 таких диска, то они будут ломаться в среднем каждые 5,000 часов. Это немного ломает мозг, я не понимаю. Типа мало вероятно, что все 4 дослужат до 20к, скорее всего, кто-то сломается по пути и наибольшая вероятность, если они будут ломаться каждые 5к часов. Странна. RAID 1 - то же самое, но с избыточностью.
RAID 2 - это какая та убийственная вещь, которая каждое кодовое слово (с битами чётности) длины N размазывает по N дискам побитово. Плюс в том, что если какой-то диск выходит из строя, то теряется один бит из каждого слова, то есть можно восстановить все данные. Но минус вроде в том, что сложно синхронизировать считывающие головки дисков. Не понял про это.
RAID 3 - упрощённый вариант RAID 2, тут биты чётности хранятся для каждого слова на отдельном диске, по одному биту чётности на каждое слово, потому что если какой-то диск с данными выходит из строя, то можно восстановить выпавшие биты, потому что в отличие от общего случая применения, мы тут ЗНАЕМ, КАКОЙ КОНКРЕТНО БИТ ВЫПАЛ. Не знаю, нафига в RAID 2 хранить тогда было всё в кодах хемминга, а нет ну по той же причине, по какой мы бы на обычном диске хранили данные с ECC.
RAID 4 и 5 хранят последовательные цельные стрипы, а не отдельные биты, и ещё XOR'ят все стрипы в одном ряду (как на картинке от Strip 0 до Strip 3, например). То есть тоже, если один из дисков выходит из строя, можно всё восстановить. RAID 5 решает проблему RAID 4 с тем, что диск с битами чётности может быть боттлнеком, потому что нам в него надо писать / из него читать при доступе к любым другим дискам. RAID 5 распределяет равномерно стрипы с битами чётности по всем дискам. И вроде общая проблема RAID 4, RAID 5, что при изменении только одного сектора в стрипе придётся в лучшем случае прочесть старые данные в секторе, прочесть биты чётности, чтобы записать потом новые биты чётности. То есть одно обращение для записи превращается в две записи и два чтения.
Вообще они все выглядят проблемными и странными. В википедии на эту тему в достоинствах и недостатках слишком непонятно расписано, хуй знает что в итоге в чём лучше чего работает
Ещё про SSD (solid state drives) совсем немного было, что они быстрые, но дорогие относительно магнитных дисков, и в них транзисторы изнашиваются. Потому что там при записи используется являение, которое называется hot-carrier injection: в транзисторах мы там в диэлектрик запихиваем небольшой проводник, как я понимаю https://en.wikipedia.org/wiki/Floating-gate_MOSFET и если подать достаточно большое напряжение на затвор, то электроны, путешествующие между истоком и стоком будут набирать достаточную кинетическую энергию, чтобы они попадали в этот проводник между слоями диэлектрика. И когда их там набирается достаточно, они разрывают ток между истоком и стоком. То есть так можно хранить данные и это будет non-volatile хранение. Проблема в том, что из-за hot-carrier injection будут рушиться структуры диэлектрика и проводника внутри него, поэтому на каждый транзистор приходится ограниченное число записей. НО вроде как неограниченное число чтений, потому что читать можно безопасно. Не очень понял только, как вытащить электтроны оттуда, но ладно. Какой та Fowler–Nordheim tunneling сложные слова я ничего не понимаю
Немного совсем про secondary память читал ещё. Что в магнитных дисках используется не тупо один диск, а сразу много и сразу много считывающих головок соответственно и по каждой стороне диска, которые синхронизированы по расстоянию от центра диска. (Но так и не понял, синхронно ли вращаются диски) То есть данные образуют такие цилиндры. Я видел какой-то раздолбанный винчестер один раз, там внутри диск токо один был, наверное это был старый винчестер, раз только один, а не много. Круг из данных на одном диске - это трек и он дополнительно делится ещё на секторы, каждый из которых помимо данных хранит ещё ECC в конце и преамбулу, видимо, чтобы считывающая головка могла понять, откуда надо читать и синхронизировалась.
Опять же понятия не имею, как это работает. ну раз диски магнитные то они наврено магнетизируются что бы это не знаачило. И можно это делать по разному, например, на картинке сравниваются два варианта, второй - более крутой, потому что он плотнее упаковывает данные на диске за счёт того, что магнетизирует. глубже?
Вроде Проблема с дисками в том, что у них длина трека увеличивается по удалению от центра диска. И раньше это решали ещё тем, что делали тупо меньшую плотность данных по краям, так что можно было выровнять секторы по всему диску. Но потом стали использовать более умное решение с разделенеием диска на зоны, в которых на треках одинаковое количество секторов. Наверное так всё равно будет теряться некоторое количество полезного пространства, но там ещё говорилось про то, что "плохие" секторы (в которых чёто магнетизировалось навсегда) автоматически маппятся контроллером диска на здоровые секторы, может, как раз используются неиспользованые куски в зонах.
Из того, что было про стандраты передачи данных между компом и дисками я только понел то, что их было очень много и они все отпадали из-за того, что слишком мало бит выделялось на адресацию секторов. И сейчас два использующихся - это SATA (вроде во всех обычных компах такой, накопители подключаются по одному) и SCSI (произносится как "скази", используются в серверах, можно сразу много по шине подключать, и вроде там они подключаются последовательно типа как тут https://youtu.be/rJ5bao4o3pk?t=95 )
А вот про RAID ещё узнал но я так и не понял, пользуются ли им кто-то сейчас. Я до этого о нём слышал, но там было хуёвое объяснение, ещё и думал, что нумерация вариантов RAID массивов означает, что кто-то является предшественником кого то, А оказалось, что это нихуя не значит, просто номера
И RAID - это не только про увеличение надёжности (redundant), но и про увеличение скорости за счёт распараллеливания чтенния. Например RAID 0 - это когда данные делятся на стрипы, в каждом из которых по k секторов. И если пишется достаточно много данных, то они распределяются равномерно между четырьмя дисками по стрипам. Потом при чтении можно сразу с нескольких дисков читать в параллели.
Там упоминалось про то, что если скажем срок жизни диска скажем 20,000 часов, то если есть 4 таких диска, то они будут ломаться в среднем каждые 5,000 часов. Это немного ломает мозг, я не понимаю. Типа мало вероятно, что все 4 дослужат до 20к, скорее всего, кто-то сломается по пути и наибольшая вероятность, если они будут ломаться каждые 5к часов. Странна. RAID 1 - то же самое, но с избыточностью.
RAID 2 - это какая та убийственная вещь, которая каждое кодовое слово (с битами чётности) длины N размазывает по N дискам побитово. Плюс в том, что если какой-то диск выходит из строя, то теряется один бит из каждого слова, то есть можно восстановить все данные. Но минус вроде в том, что сложно синхронизировать считывающие головки дисков. Не понял про это.
RAID 3 - упрощённый вариант RAID 2, тут биты чётности хранятся для каждого слова на отдельном диске, по одному биту чётности на каждое слово, потому что если какой-то диск с данными выходит из строя, то можно восстановить выпавшие биты, потому что в отличие от общего случая применения, мы тут ЗНАЕМ, КАКОЙ КОНКРЕТНО БИТ ВЫПАЛ. Не знаю, нафига в RAID 2 хранить тогда было всё в кодах хемминга, а нет ну по той же причине, по какой мы бы на обычном диске хранили данные с ECC.
RAID 4 и 5 хранят последовательные цельные стрипы, а не отдельные биты, и ещё XOR'ят все стрипы в одном ряду (как на картинке от Strip 0 до Strip 3, например). То есть тоже, если один из дисков выходит из строя, можно всё восстановить. RAID 5 решает проблему RAID 4 с тем, что диск с битами чётности может быть боттлнеком, потому что нам в него надо писать / из него читать при доступе к любым другим дискам. RAID 5 распределяет равномерно стрипы с битами чётности по всем дискам. И вроде общая проблема RAID 4, RAID 5, что при изменении только одного сектора в стрипе придётся в лучшем случае прочесть старые данные в секторе, прочесть биты чётности, чтобы записать потом новые биты чётности. То есть одно обращение для записи превращается в две записи и два чтения.
Вообще они все выглядят проблемными и странными. В википедии на эту тему в достоинствах и недостатках слишком непонятно расписано, хуй знает что в итоге в чём лучше чего работает
Ещё про SSD (solid state drives) совсем немного было, что они быстрые, но дорогие относительно магнитных дисков, и в них транзисторы изнашиваются. Потому что там при записи используется являение, которое называется hot-carrier injection: в транзисторах мы там в диэлектрик запихиваем небольшой проводник, как я понимаю https://en.wikipedia.org/wiki/Floating-gate_MOSFET и если подать достаточно большое напряжение на затвор, то электроны, путешествующие между истоком и стоком будут набирать достаточную кинетическую энергию, чтобы они попадали в этот проводник между слоями диэлектрика. И когда их там набирается достаточно, они разрывают ток между истоком и стоком. То есть так можно хранить данные и это будет non-volatile хранение. Проблема в том, что из-за hot-carrier injection будут рушиться структуры диэлектрика и проводника внутри него, поэтому на каждый транзистор приходится ограниченное число записей. НО вроде как неограниченное число чтений, потому что читать можно безопасно. Не очень понял только, как вытащить электтроны оттуда, но ладно. Какой та Fowler–Nordheim tunneling сложные слова я ничего не понимаю
Опять же понятия не имею, как это работает. ну раз диски магнитные то они наврено магнетизируются что бы это не знаачило. И можно это делать по разному, например, на картинке сравниваются два варианта, второй - более крутой, потому что он плотнее упаковывает данные на диске за счёт того, что магнетизирует. глубже?
Вроде Проблема с дисками в том, что у них длина трека увеличивается по удалению от центра диска. И раньше это решали ещё тем, что делали тупо меньшую плотность данных по краям, так что можно было выровнять секторы по всему диску. Но потом стали использовать более умное решение с разделенеием диска на зоны, в которых на треках одинаковое количество секторов. Наверное так всё равно будет теряться некоторое количество полезного пространства, но там ещё говорилось про то, что "плохие" секторы (в которых чёто магнетизировалось навсегда) автоматически маппятся контроллером диска на здоровые секторы, может, как раз используются неиспользованые куски в зонах.
Из того, что было про стандраты передачи данных между компом и дисками я только понел то, что их было очень много и они все отпадали из-за того, что слишком мало бит выделялось на адресацию секторов. И сейчас два использующихся - это SATA (вроде во всех обычных компах такой, накопители подключаются по одному) и SCSI (произносится как "скази", используются в серверах, можно сразу много по шине подключать, и вроде там они подключаются последовательно типа как тут https://youtu.be/rJ5bao4o3pk?t=95 )
А вот про RAID ещё узнал но я так и не понял, пользуются ли им кто-то сейчас. Я до этого о нём слышал, но там было хуёвое объяснение, ещё и думал, что нумерация вариантов RAID массивов означает, что кто-то является предшественником кого то, А оказалось, что это нихуя не значит, просто номера
И RAID - это не только про увеличение надёжности (redundant), но и про увеличение скорости за счёт распараллеливания чтенния. Например RAID 0 - это когда данные делятся на стрипы, в каждом из которых по k секторов. И если пишется достаточно много данных, то они распределяются равномерно между четырьмя дисками по стрипам. Потом при чтении можно сразу с нескольких дисков читать в параллели.
Там упоминалось про то, что если скажем срок жизни диска скажем 20,000 часов, то если есть 4 таких диска, то они будут ломаться в среднем каждые 5,000 часов. Это немного ломает мозг, я не понимаю. Типа мало вероятно, что все 4 дослужат до 20к, скорее всего, кто-то сломается по пути и наибольшая вероятность, если они будут ломаться каждые 5к часов. Странна. RAID 1 - то же самое, но с избыточностью.
RAID 2 - это какая та убийственная вещь, которая каждое кодовое слово (с битами чётности) длины N размазывает по N дискам побитово. Плюс в том, что если какой-то диск выходит из строя, то теряется один бит из каждого слова, то есть можно восстановить все данные. Но минус вроде в том, что сложно синхронизировать считывающие головки дисков. Не понял про это.
RAID 3 - упрощённый вариант RAID 2, тут биты чётности хранятся для каждого слова на отдельном диске, по одному биту чётности на каждое слово, потому что если какой-то диск с данными выходит из строя, то можно восстановить выпавшие биты, потому что в отличие от общего случая применения, мы тут ЗНАЕМ, КАКОЙ КОНКРЕТНО БИТ ВЫПАЛ. Не знаю, нафига в RAID 2 хранить тогда было всё в кодах хемминга, а нет ну по той же причине, по какой мы бы на обычном диске хранили данные с ECC.
RAID 4 и 5 хранят последовательные цельные стрипы, а не отдельные биты, и ещё XOR'ят все стрипы в одном ряду (как на картинке от Strip 0 до Strip 3, например). То есть тоже, если один из дисков выходит из строя, можно всё восстановить. RAID 5 решает проблему RAID 4 с тем, что диск с битами чётности может быть боттлнеком, потому что нам в него надо писать / из него читать при доступе к любым другим дискам. RAID 5 распределяет равномерно стрипы с битами чётности по всем дискам. И вроде общая проблема RAID 4, RAID 5, что при изменении только одного сектора в стрипе придётся в лучшем случае прочесть старые данные в секторе, прочесть биты чётности, чтобы записать потом новые биты чётности. То есть одно обращение для записи превращается в две записи и два чтения.
Вообще они все выглядят проблемными и странными. В википедии на эту тему в достоинствах и недостатках слишком непонятно расписано, хуй знает что в итоге в чём лучше чего работает
Ещё про SSD (solid state drives) совсем немного было, что они быстрые, но дорогие относительно магнитных дисков, и в них транзисторы изнашиваются. Потому что там при записи используется являение, которое называется hot-carrier injection: в транзисторах мы там в диэлектрик запихиваем небольшой проводник, как я понимаю https://en.wikipedia.org/wiki/Floating-gate_MOSFET и если подать достаточно большое напряжение на затвор, то электроны, путешествующие между истоком и стоком будут набирать достаточную кинетическую энергию, чтобы они попадали в этот проводник между слоями диэлектрика. И когда их там набирается достаточно, они разрывают ток между истоком и стоком. То есть так можно хранить данные и это будет non-volatile хранение. Проблема в том, что из-за hot-carrier injection будут рушиться структуры диэлектрика и проводника внутри него, поэтому на каждый транзистор приходится ограниченное число записей. НО вроде как неограниченное число чтений, потому что читать можно безопасно. Не очень понял только, как вытащить электтроны оттуда, но ладно. Какой та Fowler–Nordheim tunneling сложные слова я ничего не понимаю
154 Кб, 1536x1024>>13143
Я думал, что сейчас быстро решу домашку по стрим апи, но нихуя, блять, я не могу первое задание даже решить, я так хочу уже умереть. Там надо написать функцию, которая принимает на вход список из унарных фукнций, действующих на интах, и возвращает фукнцию, которая принимает на вход список аргументов и к каждому из них последовательно применяет все функции.
То есть из списка [x -> x, x -> x + 1, x -> x^2] она должна сделать функцию такую, чтобы на список аргументов [1, 2] она вернула [1, 1 + 1, (1 + 1)^2, 2, (2 + 1), (2 + 1)^3] = [1, 2, 4, 2, 3, 9].
У меня только так получилось https://ideone.com/61jv8L Я не знаю как список фукнций [f1(x), f2(x), f3(x)] преобразовать в список [f1(x), f2(f1(x)), f3(f2(f1(x)))]. reduce возвращает функцию f3(f2(f1(x))), а мне нужен список из всех промежуточных. Можно было бы попробовать сделать так, чтобы на каждый вызов аккумулятора в reduce результат добавлялся в список, но говно получится же.
Я думал, что сейчас быстро решу домашку по стрим апи, но нихуя, блять, я не могу первое задание даже решить, я так хочу уже умереть. Там надо написать функцию, которая принимает на вход список из унарных фукнций, действующих на интах, и возвращает фукнцию, которая принимает на вход список аргументов и к каждому из них последовательно применяет все функции.
То есть из списка [x -> x, x -> x + 1, x -> x^2] она должна сделать функцию такую, чтобы на список аргументов [1, 2] она вернула [1, 1 + 1, (1 + 1)^2, 2, (2 + 1), (2 + 1)^3] = [1, 2, 4, 2, 3, 9].
У меня только так получилось https://ideone.com/61jv8L Я не знаю как список фукнций [f1(x), f2(x), f3(x)] преобразовать в список [f1(x), f2(f1(x)), f3(f2(f1(x)))]. reduce возвращает функцию f3(f2(f1(x))), а мне нужен список из всех промежуточных. Можно было бы попробовать сделать так, чтобы на каждый вызов аккумулятора в reduce результат добавлялся в список, но говно получится же.
415 Кб, 1920x1279>>14787
Хотя нет всё же стрим апи плохо подходит под такие задачи видимо вроде вычисления running sum или нарастающей композиции функции
https://stackoverflow.com/a/55266102
Есть какой то Arrays.parallelPrefix, но он не возвращает массива, поэтому его сложно будет впихнуть в выражение в стиле стрим апи. Можно было бы вообще написать ещё свой коллектор, чтобы написать такое https://ideone.com/fPa2yl только это уже шиза.
Хотя нет всё же стрим апи плохо подходит под такие задачи видимо вроде вычисления running sum или нарастающей композиции функции
https://stackoverflow.com/a/55266102
Есть какой то Arrays.parallelPrefix, но он не возвращает массива, поэтому его сложно будет впихнуть в выражение в стиле стрим апи. Можно было бы вообще написать ещё свой коллектор, чтобы написать такое https://ideone.com/fPa2yl только это уже шиза.
667 Кб, 724x1024>>14789
https://ideone.com/WlgwvR
Ладно там шиза, так она ж ещё и квадратная.
У меня первый вариант (Mappers.reduce) внешне похож на твой первый, но работает как твой второй, т. е. нанизывает функции, а второй (Mappers.collect) — внешне похож на твой второй, но работает как твой первый, т. е. нанизывает результаты в один проход. Ещё я добавил третий вариант Mappers.sane, просто для смеха.
https://ideone.com/WlgwvR
Ладно там шиза, так она ж ещё и квадратная.
У меня первый вариант (Mappers.reduce) внешне похож на твой первый, но работает как твой второй, т. е. нанизывает функции, а второй (Mappers.collect) — внешне похож на твой второй, но работает как твой первый, т. е. нанизывает результаты в один проход. Ещё я добавил третий вариант Mappers.sane, просто для смеха.
>>14800
Рирурушечка, а общаешься ли ты сейчас с вылезатором, который писал под ником Riku?
Я недавно перечитал его тред, и стало интересно, как он сейчас? Он ведь был весьма упорным вылезатором, а потом вдруг забил. Вроде вы общались за пределами дневникача?
Рирурушечка, а общаешься ли ты сейчас с вылезатором, который писал под ником Riku?
Я недавно перечитал его тред, и стало интересно, как он сейчас? Он ведь был весьма упорным вылезатором, а потом вдруг забил. Вроде вы общались за пределами дневникача?
2,7 Мб, 1500x2275>>14811
Я ебучая Куроки Томоко, у меня Н Е Т, блять, друзей, со мной никогда никто не ходит на свидания и просто не рассказывает, >как он сейчас. Видишь, вот я даже ОПу предложил дружить и он меня просто проигнорировал. Зачем ты опять меня в это тыкаешь? Думаешь, изящно подъебал? Нихуя, изящество слона в посудной лавке.
Я ебучая Куроки Томоко, у меня Н Е Т, блять, друзей, со мной никогда никто не ходит на свидания и просто не рассказывает, >как он сейчас. Видишь, вот я даже ОПу предложил дружить и он меня просто проигнорировал. Зачем ты опять меня в это тыкаешь? Думаешь, изящно подъебал? Нихуя, изящество слона в посудной лавке.
>>14840
Да-да, куча тяночек и кунчиков в друзьях, не говоря уже о тех, с кем ты общался ирл...
Да-да, куча тяночек и кунчиков в друзьях, не говоря уже о тех, с кем ты общался ирл...
>>14811
Я здесь.
Не очень.
Еще нет ;). Просто проблемы со здоровьем.
Я здесь.
> Как он сейчас?
Не очень.
> Он ведь был весьма упорным вылезатором, а потом вдруг забил.
Еще нет ;). Просто проблемы со здоровьем.
>>14840
Ну не злись, Рирурушечка.
У меня вовсе не было желания тебя подъебать.
Прости мне это наступание на мозоль, это со мной бывает, просто по неуклюжести. Я не очень хорошо могу в тонкости общения.
Давай, если хочешь, посидим рядом. Смотри, тут есть укромная скамеечка за этой акацией. Нас никто не увидит. Можно, я поглажу тебя по спине, между лопаток? Можно? Вот так...
Ну не злись, Рирурушечка.
У меня вовсе не было желания тебя подъебать.
Прости мне это наступание на мозоль, это со мной бывает, просто по неуклюжести. Я не очень хорошо могу в тонкости общения.
Давай, если хочешь, посидим рядом. Смотри, тут есть укромная скамеечка за этой акацией. Нас никто не увидит. Можно, я поглажу тебя по спине, между лопаток? Можно? Вот так...
>>14800
Не догадался до sublist. Охуенно изящно
Нихуя я сегодня не делал блять, лекцию по математике снова проебал сука, я так хочу умереть уже пожалуйста. Послушал микроэлектронику там ничего содержательного не было, чёто про декодеры, но мы же на уровне вентильной логики это всё рассматриваем, тут не про что говорить особо. Сделал домашку по html на завтра, тупо срисовал флексбоксами по макету с фигмы, не пиксель пёрфект, на глаз, чтобы хотя бы похоже было. Было вроде не очень сложна, но некоторые моменты гуглить пришлось и использовать какие та цсс хаки хуяки, чтобы центрировать текст внутри <label>. На скриншоте только css и html, то есть там "3 items left" - это захардкоженный текст тупа пока что.
Послушал лекцию по джаве, чёто про работу с файлами и блокирующий ввод вывод. Миллиард ебучих классов для стримов и ещё столько же для ридеров и райтеров, сучий паттерн хуятерн декоратор. Я токо сейчас понел, что ридеры и райтеры для символов, а инпут и атупут стримы для байтов. И Input/OutputStreamReader - это как раз ридер, который читает байты из стрима и интерпретирует их как символы. И PrintStream (java 1.0) и PrintWriter (java 1.1) - это функционально одно и то же, но первый сам разбирается с тем, чё ему делать с символами (потому что не подумоли что это может быть неудобно, в следующей же версии добавили райтеры), тогда как PrintWriter использует райтер как абстракцию всего этого и работает только с символами.
Ещё про сериализацию немного было: в том числе про сериализацию вручную через Externalizable, первый раз про это услышал. ВОобще логично, что все хотят писать свою сериализацию, чтобы сделать её оптимальнее под какую-та конкретную задачу, например, если надо сериализовать много объектов одного типа, то стандартная сериализация плохо подойдёт, потому что вроде на каждый объект будет оверхед из-за сохранения всех метаданных, когда можно было бы сохранить мету один раз только на все объекты. И ещё стандартная сериализация может быть офигенно небезопасной из-за того, что есть вероятность прочитать неправильные данные и нет никаких проверок на это, к тому же там, если поменять внутреннюю структуру класса, то нельзя будет (вроде можно, но там чёто надо сделать дополнительно, вроде как написать в поле класса SerialVersionUID, чтобы он соответствовал тому, который у сериализованного класса) прочитать старые версии сериализованных.
Про логирование было совсем чуть-чуть, только про то, что стандартный логгер говно и лучше использовать slf4j, который предоставляет единый интерфейс для разных реализаций логгеров.
Не догадался до sublist. Охуенно изящно
Нихуя я сегодня не делал блять, лекцию по математике снова проебал сука, я так хочу умереть уже пожалуйста. Послушал микроэлектронику там ничего содержательного не было, чёто про декодеры, но мы же на уровне вентильной логики это всё рассматриваем, тут не про что говорить особо. Сделал домашку по html на завтра, тупо срисовал флексбоксами по макету с фигмы, не пиксель пёрфект, на глаз, чтобы хотя бы похоже было. Было вроде не очень сложна, но некоторые моменты гуглить пришлось и использовать какие та цсс хаки хуяки, чтобы центрировать текст внутри <label>. На скриншоте только css и html, то есть там "3 items left" - это захардкоженный текст тупа пока что.
Послушал лекцию по джаве, чёто про работу с файлами и блокирующий ввод вывод. Миллиард ебучих классов для стримов и ещё столько же для ридеров и райтеров, сучий паттерн хуятерн декоратор. Я токо сейчас понел, что ридеры и райтеры для символов, а инпут и атупут стримы для байтов. И Input/OutputStreamReader - это как раз ридер, который читает байты из стрима и интерпретирует их как символы. И PrintStream (java 1.0) и PrintWriter (java 1.1) - это функционально одно и то же, но первый сам разбирается с тем, чё ему делать с символами (потому что не подумоли что это может быть неудобно, в следующей же версии добавили райтеры), тогда как PrintWriter использует райтер как абстракцию всего этого и работает только с символами.
Ещё про сериализацию немного было: в том числе про сериализацию вручную через Externalizable, первый раз про это услышал. ВОобще логично, что все хотят писать свою сериализацию, чтобы сделать её оптимальнее под какую-та конкретную задачу, например, если надо сериализовать много объектов одного типа, то стандартная сериализация плохо подойдёт, потому что вроде на каждый объект будет оверхед из-за сохранения всех метаданных, когда можно было бы сохранить мету один раз только на все объекты. И ещё стандартная сериализация может быть офигенно небезопасной из-за того, что есть вероятность прочитать неправильные данные и нет никаких проверок на это, к тому же там, если поменять внутреннюю структуру класса, то нельзя будет (вроде можно, но там чёто надо сделать дополнительно, вроде как написать в поле класса SerialVersionUID, чтобы он соответствовал тому, который у сериализованного класса) прочитать старые версии сериализованных.
Про логирование было совсем чуть-чуть, только про то, что стандартный логгер говно и лучше использовать slf4j, который предоставляет единый интерфейс для разных реализаций логгеров.
>>14800
Не догадался до sublist. Охуенно изящно
Нихуя я сегодня не делал блять, лекцию по математике снова проебал сука, я так хочу умереть уже пожалуйста. Послушал микроэлектронику там ничего содержательного не было, чёто про декодеры, но мы же на уровне вентильной логики это всё рассматриваем, тут не про что говорить особо. Сделал домашку по html на завтра, тупо срисовал флексбоксами по макету с фигмы, не пиксель пёрфект, на глаз, чтобы хотя бы похоже было. Было вроде не очень сложна, но некоторые моменты гуглить пришлось и использовать какие та цсс хаки хуяки, чтобы центрировать текст внутри <label>. На скриншоте только css и html, то есть там "3 items left" - это захардкоженный текст тупа пока что.
Послушал лекцию по джаве, чёто про работу с файлами и блокирующий ввод вывод. Миллиард ебучих классов для стримов и ещё столько же для ридеров и райтеров, сучий паттерн хуятерн декоратор. Я токо сейчас понел, что ридеры и райтеры для символов, а инпут и атупут стримы для байтов. И Input/OutputStreamReader - это как раз ридер, который читает байты из стрима и интерпретирует их как символы. И PrintStream (java 1.0) и PrintWriter (java 1.1) - это функционально одно и то же, но первый сам разбирается с тем, чё ему делать с символами (потому что не подумоли что это может быть неудобно, в следующей же версии добавили райтеры), тогда как PrintWriter использует райтер как абстракцию всего этого и работает только с символами.
Ещё про сериализацию немного было: в том числе про сериализацию вручную через Externalizable, первый раз про это услышал. ВОобще логично, что все хотят писать свою сериализацию, чтобы сделать её оптимальнее под какую-та конкретную задачу, например, если надо сериализовать много объектов одного типа, то стандартная сериализация плохо подойдёт, потому что вроде на каждый объект будет оверхед из-за сохранения всех метаданных, когда можно было бы сохранить мету один раз только на все объекты. И ещё стандартная сериализация может быть офигенно небезопасной из-за того, что есть вероятность прочитать неправильные данные и нет никаких проверок на это, к тому же там, если поменять внутреннюю структуру класса, то нельзя будет (вроде можно, но там чёто надо сделать дополнительно, вроде как написать в поле класса SerialVersionUID, чтобы он соответствовал тому, который у сериализованного класса) прочитать старые версии сериализованных.
Про логирование было совсем чуть-чуть, только про то, что стандартный логгер говно и лучше использовать slf4j, который предоставляет единый интерфейс для разных реализаций логгеров.
Не догадался до sublist. Охуенно изящно
Нихуя я сегодня не делал блять, лекцию по математике снова проебал сука, я так хочу умереть уже пожалуйста. Послушал микроэлектронику там ничего содержательного не было, чёто про декодеры, но мы же на уровне вентильной логики это всё рассматриваем, тут не про что говорить особо. Сделал домашку по html на завтра, тупо срисовал флексбоксами по макету с фигмы, не пиксель пёрфект, на глаз, чтобы хотя бы похоже было. Было вроде не очень сложна, но некоторые моменты гуглить пришлось и использовать какие та цсс хаки хуяки, чтобы центрировать текст внутри <label>. На скриншоте только css и html, то есть там "3 items left" - это захардкоженный текст тупа пока что.
Послушал лекцию по джаве, чёто про работу с файлами и блокирующий ввод вывод. Миллиард ебучих классов для стримов и ещё столько же для ридеров и райтеров, сучий паттерн хуятерн декоратор. Я токо сейчас понел, что ридеры и райтеры для символов, а инпут и атупут стримы для байтов. И Input/OutputStreamReader - это как раз ридер, который читает байты из стрима и интерпретирует их как символы. И PrintStream (java 1.0) и PrintWriter (java 1.1) - это функционально одно и то же, но первый сам разбирается с тем, чё ему делать с символами (потому что не подумоли что это может быть неудобно, в следующей же версии добавили райтеры), тогда как PrintWriter использует райтер как абстракцию всего этого и работает только с символами.
Ещё про сериализацию немного было: в том числе про сериализацию вручную через Externalizable, первый раз про это услышал. ВОобще логично, что все хотят писать свою сериализацию, чтобы сделать её оптимальнее под какую-та конкретную задачу, например, если надо сериализовать много объектов одного типа, то стандартная сериализация плохо подойдёт, потому что вроде на каждый объект будет оверхед из-за сохранения всех метаданных, когда можно было бы сохранить мету один раз только на все объекты. И ещё стандартная сериализация может быть офигенно небезопасной из-за того, что есть вероятность прочитать неправильные данные и нет никаких проверок на это, к тому же там, если поменять внутреннюю структуру класса, то нельзя будет (вроде можно, но там чёто надо сделать дополнительно, вроде как написать в поле класса SerialVersionUID, чтобы он соответствовал тому, который у сериализованного класса) прочитать старые версии сериализованных.
Про логирование было совсем чуть-чуть, только про то, что стандартный логгер говно и лучше использовать slf4j, который предоставляет единый интерфейс для разных реализаций логгеров.
>>14840
Опять обосрался, сука
Опять обосрался, сука
Какого хуя нахуя я блять проснулся сука. Сейчас надо умыться и почистить зубы, потом я не знаю, я ничего не знаю я ничего не хочу я хочу заснуть обратно. Потом будут практики семенары по программированию и информатике и ещё лекция по html вечером будет. Надо сделать хотя бы английский за сегодня, потому что там задали написать текст большой. Ещё неплохо было бы посмотреть ещё физику, чтобы я знал достаточно теории, чтобы решать задачи, которые были на практиках и начать решать задачи с домашних заданий, чтобы подготовиться к контрольной.
А ещё же надо тот ебучий >>12087 мнолог по русскому написать, хотя бы тему нормальную придумать типа почему полезно есть земленику. И по физике лабораторную сделать. Я нихуя не успею это всё в срок до делдайнов наверняка но блять я незнаю внезапно оказалось, что мне надо дохуя всего сделать.
Сука, ебучее автозаполнение полей при постинге в любой тред, спасибо блять, очень удобно, вот теперь серьёзно хочется вскрыться. С трипкодами приходит большая ответственность, пиздец. нет, блть, всё мне похуй мне на всё похуя суканет как удалить
А ещё же надо тот ебучий >>12087 мнолог по русскому написать, хотя бы тему нормальную придумать типа почему полезно есть земленику. И по физике лабораторную сделать. Я нихуя не успею это всё в срок до делдайнов наверняка но блять я незнаю внезапно оказалось, что мне надо дохуя всего сделать.
Сука, ебучее автозаполнение полей при постинге в любой тред, спасибо блять, очень удобно, вот теперь серьёзно хочется вскрыться. С трипкодами приходит большая ответственность, пиздец. нет, блть, всё мне похуй мне на всё похуя суканет как удалить
НЕ могу я ничего не хочу, нихуя не делал блять печенье кликал. Посидел на программировании и информатике, но там вообще ничего не было мне нечего даже тут написать. На информатике опять электронные таблицы, чёто про фильтры. Самое главное - что есть фукнция subtotal, которая работает с отфильтрованными таблицами. Посидел на html там про картинки (img и background-image) и совсем немного про анимацию (через keyframe и через transition) было, просто что существует. И ещё про бэм, acss и mcss, про последнее слабо понял. Прилетел ревью моего говна, которое я вчера склепал, надо будет потом поправить. Самое главное, что исправить там - сделать, чтобы при навигации через таб отображалось, где ты сейчас находишься. И заодно сделать по бэм наименования классов и разбить один большой css йфал на несколько поменьше наверное
Я не хочу делать ебучий английский я не понимаю как писать ебучий монолог сука. Я нихуя не хочу я хочу сдохнуть уже пожалуйста когда это уже закончится блять я бесполезен я плох во всём я должен уже умереть.
Я не хочу делать ебучий английский я не понимаю как писать ебучий монолог сука. Я нихуя не хочу я хочу сдохнуть уже пожалуйста когда это уже закончится блять я бесполезен я плох во всём я должен уже умереть.
170 Кб, 852x1280>>15417
Нет, нихуя. То тогда не погромисты в моём понимании. И ты неправильно понял, я реально конченый дегенерат. Отсталая хуета без половины мозга. Я не могу ни на чём больше 15 минут концентрироваться даже. Я едва ли за человека могу считаться.
Нет, нихуя. То тогда не погромисты в моём понимании. И ты неправильно понял, я реально конченый дегенерат. Отсталая хуета без половины мозга. Я не могу ни на чём больше 15 минут концентрироваться даже. Я едва ли за человека могу считаться.
293 Кб, 1367x2048Ничего не делал, я ничего не хочу, я хочу лежать и ничего не делать. Очень хочется навсегда заснуть, было бы круто, да, я всё равно ничего не делаю, было бы оптимальнее, если бы я просто спал. Сейчас надо сделать домашние задания по плюсам и математике. Почему-то колено очень сильно болит, когда разгибаю и сгибаю ногу, хотя я вроде ничего такого с ним не делал, надеюсь, эта нога нахуй отвалится.
>>15407
Я не знаю, возможно, это моя ретиношиза прогрессирует, но несколько раз было такое, что я кастовал заклинанием золотое печенье, появлялось сообщение о том, что оно успешно скастовалось, и ничего. Я нигде не мог увидеть печенинку. Конечно, у меня есть проблемы с нахождением каких-то конкретных кусков визуальной информации на полотне. (Не могу вспомнить конкретных примеров, но, скажем, если мне понадобится найти какое-то слово в списке слов, даже упорядоченном по алфавиту, с алфавитом тоже проблемы мне понадобится довольно много времени, чтобы отыскать его.)
Поэтому мог тупо не заметить её, но в один из таких моментов я случайно увидел очень маленькую золотую печенинку, только из-за того, что она была рядом с кнопкой, на которую я собирался нажать, и, когда кликнул на неё, она дала тупо печенье, но явно больше 15% от текущего количества, так что это вряд ли просто визуальный баг обычной золотой печенинки, которая "Lucky!" Нашёл по этой теме только такое https://www.reddit.com/r/CookieClicker/comments/gtpfuz/force_the_hand_of_fate_is_spawning_these_really/ но это нифига не объясняет, куки шторм вообще же другой и он не спавнит такие маленькие печенья, да и они не дают много обычных печенек.
Я не знаю, возможно, это моя ретиношиза прогрессирует, но несколько раз было такое, что я кастовал заклинанием золотое печенье, появлялось сообщение о том, что оно успешно скастовалось, и ничего. Я нигде не мог увидеть печенинку. Конечно, у меня есть проблемы с нахождением каких-то конкретных кусков визуальной информации на полотне. (Не могу вспомнить конкретных примеров, но, скажем, если мне понадобится найти какое-то слово в списке слов, даже упорядоченном по алфавиту, с алфавитом тоже проблемы мне понадобится довольно много времени, чтобы отыскать его.)
Поэтому мог тупо не заметить её, но в один из таких моментов я случайно увидел очень маленькую золотую печенинку, только из-за того, что она была рядом с кнопкой, на которую я собирался нажать, и, когда кликнул на неё, она дала тупо печенье, но явно больше 15% от текущего количества, так что это вряд ли просто визуальный баг обычной золотой печенинки, которая "Lucky!" Нашёл по этой теме только такое https://www.reddit.com/r/CookieClicker/comments/gtpfuz/force_the_hand_of_fate_is_spawning_these_really/ но это нифига не объясняет, куки шторм вообще же другой и он не спавнит такие маленькие печенья, да и они не дают много обычных печенек.
70 Кб, 682x1024Я не могу, я ничего не хочу. Еле как заставил себя написать маленькую программку на плюсах для домашнего задания, но больше ничего, и потом не мог ночью не мог заснуть из-за того, что плакал. И сегодня никуда не пошёл. Я не понимаю, зачем я вообще пошёл учиться опять, я это просто так ляпнул родителям, чтобы они меня не трогали некоторое время, потому что думал, что что-нибудь изменится или я просто успею и правда умереть за это время и тогда мне не надо будет больше ни о чём беспокоиться, но ни того и ни другого не произошло в итоге, а время пролетело очень быстро. Я не понимаю, зачем я существую, я не понимаю, почему меня всё ещё не послали на хуй те два человека, с которыми я общаюсь в интернете. Всё, чего я вообще когда-либо хотел - это, чтобы меня ничего не беспокоило, потому что я постоянно чувствую, что что-то кому-то должен, меня вообще больше ничего не интересует, я не знаю, что мне делать.
76 Кб, 768x1024Я не понимаю, как мне заставлять себя делать то, что я не хочу. И как мне делать вообще что-либо, если мне ничего не нравится, потому что всё слишком сложно и для всего надо прикладывать минимальные усилия для достижения результата. А я не могу, я и в игры новые особо не играю и мультики новые тяжело смотреть, потому что там тоже нужно прикладывать усилия, чтобы разобраться в новых механиках или хотя бы запоминать имена персонажей. Иногда тупо захожу в TBoI или EtG и то, я даже TBoI ни разу до конца на все ачивки не прошёл, несмотря на то, что играю в неё с даты релиза и до этого в оригинальную игру ещё относительно долго играл. EtG вообще только один раз до последнего босса дошёл и не знаю, что вообще надо делать там, потому что я привык к TBoI и не могу переучиться под новую игру, потому что нужно прилагать какие-то усилия к этому, запоминать, что делают предметы. По той же причине часто не могу пройти до конца игру, а начинаю заново с нового сейва, потому что я уже знаю, что делать в начале игры и прогресс даётся легче, чем в первый раз, появляется ощущение прогресса, а потом снова забиваю. А в дебильной учёбе в дебильном бестолковом вузе даже результата нет никакого, ради которого хотелось бы стараться.
528 Кб, 1536x2048Я не знаю, с одной стороны. проблемы надо решать поступательно, то есть забить на всё кроме того, что надо сделать из ближайшего по дедлайнам, но вот мне в теории надо сделать на завтра лабораторную по физике, домашку по алгоритмам и написать текст для монолога по русскому. И через час где-то мне надо будет сдать домашку по плюсам. И потом после этого надо будет сделать лабораторную по микроэлектронике. Но я ничего из этого не хочу делать, я хочу лежать на кровати и смотреть видео на ютубе, больше ничего. Постоянно такое ощущение, что голова в тумане и время течёт для меня ускоренно.
Мне чего-то надоело постить тридешных женщин. Твиттер чего-то стал выдавать в фиде только порнушку с двадешными женщинами. Нужна штука, которая бы выдавала ленту картинок из твоих подписок, а то сам твиттер как-то рандомно выбирает, чьи посты тебе показывать.
Я не знаю, короче, неважно, я вроде там что-то сдал, но это не так важно уже. Мне как-то сейчас внезапно стало как-то мега-уныло из-за того, что мне захотелось обновить свой тупой сает на гитхаб pages. Мне почему-то давно независимо запомнилась эта >>274664 → идея, и я к тому же увидел, что там Лелуш >>413104 → вроде сверстал копию постов как тут (или это он скрапит посты отсюда, не знаю, не имеет значения), и мне тоже захотелось что-то такое.
Чтобы на каждую категорию постов была своя страница, где бы все посты в категории отображались в контейнерах с ограниченной высотой (со скроллом тупо, ну как тут посты). И чтобы был список всех категорий, отсортированных по дате последнего добавленного поста. Но чего-то такой мусор получился, это просто ужас, ещё и яп этот дурацкий https://shopify.github.io/liquid/ в джекилле используется, на котором ничего нормально не сделаешь но всё равно кто-то запилил довольно юзабельный генератор оглавлений https://github.com/allejo/jekyll-toc на нём, который я запихнул себе.
Там главная проблема в том, что можно использовать только перечисленные тут https://pages.github.com/versions/ джекилл плагины (я не очень смотрел, что там, возможно, можно было не придумывать велосипеды, но уже всё равно), поэтому, если хочешь, чтобы гитхаб сам собирал тебе сает, то придётся мириться с этими ограничениями. И в этом нет особой проблемы, на самом деле, но я принципиально не хочу пушить собранный сайт руками, потому что нафиг надо тогда это всё, можно было бы тогда и самому каждую хтмльку верстать, ну уж нет.
Поэтому в частности приходится генерировать страницы для категорий через джекилловские коллекции https://jekyllrb.com/docs/collections/ то есть надо поддерживать кучу фаелов с одинаковым содержанием, отличающихся только названиями категорий, которые они представляют. Потому что нельзя заюзать какой-нибудь готовый плагин, который генерирует страницы из одного YAML файла. И ещё нельзя сделать кликабельные картинки, встроенные внутри постов, потому что вроде тупо нет возможности обернуть каждый <img> в <a>. На js, наверное, можно было бы написать скрипт, который на клиенте парсит html и изменяет его, но я уже не хочу ничего делать, пофигг. Да и опять же, это уже какая-то мега-тупость выходит, хотя вот mathjax, кажется, по сути это и делает: парсит содержимое страницы, находит математику на латехе и встраивает туда свой код, чтобы оно всё красиво отображалась.
Потратил на это довольно много времени для подобного, дня два-три суммарно, мне кажется, причём в воскресенье, которое недавно было, просидел с этим буквально целый день, сегодня ещё немного доделывал, вот сортировку категорий в частности. А там такой говнокод на этом liquid, что просто жесть, и непонятно, как нормально написать, так тошно стало от себя и от саета этого дебильного. И теперь ничего не хочется совсем. Я драматизирую, конечно, но правда, блин, ужасно, мне убило мозг.
Я не знаю, короче, неважно, я вроде там что-то сдал, но это не так важно уже. Мне как-то сейчас внезапно стало как-то мега-уныло из-за того, что мне захотелось обновить свой тупой сает на гитхаб pages. Мне почему-то давно независимо запомнилась эта >>274664 → идея, и я к тому же увидел, что там Лелуш >>413104 → вроде сверстал копию постов как тут (или это он скрапит посты отсюда, не знаю, не имеет значения), и мне тоже захотелось что-то такое.
Чтобы на каждую категорию постов была своя страница, где бы все посты в категории отображались в контейнерах с ограниченной высотой (со скроллом тупо, ну как тут посты). И чтобы был список всех категорий, отсортированных по дате последнего добавленного поста. Но чего-то такой мусор получился, это просто ужас, ещё и яп этот дурацкий https://shopify.github.io/liquid/ в джекилле используется, на котором ничего нормально не сделаешь но всё равно кто-то запилил довольно юзабельный генератор оглавлений https://github.com/allejo/jekyll-toc на нём, который я запихнул себе.
Там главная проблема в том, что можно использовать только перечисленные тут https://pages.github.com/versions/ джекилл плагины (я не очень смотрел, что там, возможно, можно было не придумывать велосипеды, но уже всё равно), поэтому, если хочешь, чтобы гитхаб сам собирал тебе сает, то придётся мириться с этими ограничениями. И в этом нет особой проблемы, на самом деле, но я принципиально не хочу пушить собранный сайт руками, потому что нафиг надо тогда это всё, можно было бы тогда и самому каждую хтмльку верстать, ну уж нет.
Поэтому в частности приходится генерировать страницы для категорий через джекилловские коллекции https://jekyllrb.com/docs/collections/ то есть надо поддерживать кучу фаелов с одинаковым содержанием, отличающихся только названиями категорий, которые они представляют. Потому что нельзя заюзать какой-нибудь готовый плагин, который генерирует страницы из одного YAML файла. И ещё нельзя сделать кликабельные картинки, встроенные внутри постов, потому что вроде тупо нет возможности обернуть каждый <img> в <a>. На js, наверное, можно было бы написать скрипт, который на клиенте парсит html и изменяет его, но я уже не хочу ничего делать, пофигг. Да и опять же, это уже какая-то мега-тупость выходит, хотя вот mathjax, кажется, по сути это и делает: парсит содержимое страницы, находит математику на латехе и встраивает туда свой код, чтобы оно всё красиво отображалась.
Потратил на это довольно много времени для подобного, дня два-три суммарно, мне кажется, причём в воскресенье, которое недавно было, просидел с этим буквально целый день, сегодня ещё немного доделывал, вот сортировку категорий в частности. А там такой говнокод на этом liquid, что просто жесть, и непонятно, как нормально написать, так тошно стало от себя и от саета этого дебильного. И теперь ничего не хочется совсем. Я драматизирую, конечно, но правда, блин, ужасно, мне убило мозг.
Мне чего-то надоело постить тридешных женщин. Твиттер чего-то стал выдавать в фиде только порнушку с двадешными женщинами. Нужна штука, которая бы выдавала ленту картинок из твоих подписок, а то сам твиттер как-то рандомно выбирает, чьи посты тебе показывать.
Я не знаю, короче, неважно, я вроде там что-то сдал, но это не так важно уже. Мне как-то сейчас внезапно стало как-то мега-уныло из-за того, что мне захотелось обновить свой тупой сает на гитхаб pages. Мне почему-то давно независимо запомнилась эта >>274664 → идея, и я к тому же увидел, что там Лелуш >>413104 → вроде сверстал копию постов как тут (или это он скрапит посты отсюда, не знаю, не имеет значения), и мне тоже захотелось что-то такое.
Чтобы на каждую категорию постов была своя страница, где бы все посты в категории отображались в контейнерах с ограниченной высотой (со скроллом тупо, ну как тут посты). И чтобы был список всех категорий, отсортированных по дате последнего добавленного поста. Но чего-то такой мусор получился, это просто ужас, ещё и яп этот дурацкий https://shopify.github.io/liquid/ в джекилле используется, на котором ничего нормально не сделаешь но всё равно кто-то запилил довольно юзабельный генератор оглавлений https://github.com/allejo/jekyll-toc на нём, который я запихнул себе.
Там главная проблема в том, что можно использовать только перечисленные тут https://pages.github.com/versions/ джекилл плагины (я не очень смотрел, что там, возможно, можно было не придумывать велосипеды, но уже всё равно), поэтому, если хочешь, чтобы гитхаб сам собирал тебе сает, то придётся мириться с этими ограничениями. И в этом нет особой проблемы, на самом деле, но я принципиально не хочу пушить собранный сайт руками, потому что нафиг надо тогда это всё, можно было бы тогда и самому каждую хтмльку верстать, ну уж нет.
Поэтому в частности приходится генерировать страницы для категорий через джекилловские коллекции https://jekyllrb.com/docs/collections/ то есть надо поддерживать кучу фаелов с одинаковым содержанием, отличающихся только названиями категорий, которые они представляют. Потому что нельзя заюзать какой-нибудь готовый плагин, который генерирует страницы из одного YAML файла. И ещё нельзя сделать кликабельные картинки, встроенные внутри постов, потому что вроде тупо нет возможности обернуть каждый <img> в <a>. На js, наверное, можно было бы написать скрипт, который на клиенте парсит html и изменяет его, но я уже не хочу ничего делать, пофигг. Да и опять же, это уже какая-то мега-тупость выходит, хотя вот mathjax, кажется, по сути это и делает: парсит содержимое страницы, находит математику на латехе и встраивает туда свой код, чтобы оно всё красиво отображалась.
Потратил на это довольно много времени для подобного, дня два-три суммарно, мне кажется, причём в воскресенье, которое недавно было, просидел с этим буквально целый день, сегодня ещё немного доделывал, вот сортировку категорий в частности. А там такой говнокод на этом liquid, что просто жесть, и непонятно, как нормально написать, так тошно стало от себя и от саета этого дебильного. И теперь ничего не хочется совсем. Я драматизирую, конечно, но правда, блин, ужасно, мне убило мозг.
Я не знаю, короче, неважно, я вроде там что-то сдал, но это не так важно уже. Мне как-то сейчас внезапно стало как-то мега-уныло из-за того, что мне захотелось обновить свой тупой сает на гитхаб pages. Мне почему-то давно независимо запомнилась эта >>274664 → идея, и я к тому же увидел, что там Лелуш >>413104 → вроде сверстал копию постов как тут (или это он скрапит посты отсюда, не знаю, не имеет значения), и мне тоже захотелось что-то такое.
Чтобы на каждую категорию постов была своя страница, где бы все посты в категории отображались в контейнерах с ограниченной высотой (со скроллом тупо, ну как тут посты). И чтобы был список всех категорий, отсортированных по дате последнего добавленного поста. Но чего-то такой мусор получился, это просто ужас, ещё и яп этот дурацкий https://shopify.github.io/liquid/ в джекилле используется, на котором ничего нормально не сделаешь но всё равно кто-то запилил довольно юзабельный генератор оглавлений https://github.com/allejo/jekyll-toc на нём, который я запихнул себе.
Там главная проблема в том, что можно использовать только перечисленные тут https://pages.github.com/versions/ джекилл плагины (я не очень смотрел, что там, возможно, можно было не придумывать велосипеды, но уже всё равно), поэтому, если хочешь, чтобы гитхаб сам собирал тебе сает, то придётся мириться с этими ограничениями. И в этом нет особой проблемы, на самом деле, но я принципиально не хочу пушить собранный сайт руками, потому что нафиг надо тогда это всё, можно было бы тогда и самому каждую хтмльку верстать, ну уж нет.
Поэтому в частности приходится генерировать страницы для категорий через джекилловские коллекции https://jekyllrb.com/docs/collections/ то есть надо поддерживать кучу фаелов с одинаковым содержанием, отличающихся только названиями категорий, которые они представляют. Потому что нельзя заюзать какой-нибудь готовый плагин, который генерирует страницы из одного YAML файла. И ещё нельзя сделать кликабельные картинки, встроенные внутри постов, потому что вроде тупо нет возможности обернуть каждый <img> в <a>. На js, наверное, можно было бы написать скрипт, который на клиенте парсит html и изменяет его, но я уже не хочу ничего делать, пофигг. Да и опять же, это уже какая-то мега-тупость выходит, хотя вот mathjax, кажется, по сути это и делает: парсит содержимое страницы, находит математику на латехе и встраивает туда свой код, чтобы оно всё красиво отображалась.
Потратил на это довольно много времени для подобного, дня два-три суммарно, мне кажется, причём в воскресенье, которое недавно было, просидел с этим буквально целый день, сегодня ещё немного доделывал, вот сортировку категорий в частности. А там такой говнокод на этом liquid, что просто жесть, и непонятно, как нормально написать, так тошно стало от себя и от саета этого дебильного. И теперь ничего не хочется совсем. Я драматизирую, конечно, но правда, блин, ужасно, мне убило мозг.
Хотел забить на всё и пойти спать, но всё же сделал домашку по алгоритмам. Там были просто задачки на динамику, о которых я писал где-то выше, нового ничего за столько времени не было, потому что одно занятие было потрачено на типа контрольную, где опять же ничего интересного не было, просто задачки по разным пройденным темам. И сейчас тоже ничего такого, все сложности связаны разве что с какой-нибудь ерундой вроде переполнения интов или деления на ноль, из-за того, что я невнимательно читаю, какие входные данные подаются. На лекции сегодня было про несбалансированные бинарные деревья и про АВЛ-деревья. Про первые я знаю, про вторые до этого только слышал или забыл, но там вроде смысл в том, что в них поддерживается инвариант того, что для каждой вершины высоты поддеревьев отличаются не более, чем на 1.
И вроде можно доказать, что из этого следует, что высота всего дерева - это O(lgN). Я немного не в состоянии был слушать и плохо понял, но вроде там смысл в том, что можно составить рекуррентное соотношение для минимального количества вершин в АВЛ-дереве в зависимости от его высоты. T(1) = 1, T(2) = 2 - база, T(h) = T(h - 1) + T(h - 2) + 1, потому что там получается что та по типу пикрила (если что-то уберём, то нарушается АВЛьность). А это что-то, что больше N-ного числа фибоначчи, то есть T(h) > F(h) > там какие-то степени и в показателе степени находится h, в основании степени - золотое сечение, короче, выйдет в итоге, что h меньше логарифма.
И было про то, как сохранять это свойство АВЛ-дерева, там два типа базовых вращений и два сложных, каждое из которых состоит из двух базовых. И для удобства в каждой вершине храним разность высот поддеревьев. И, чтобы пофиксить дерево после добавления, надо пройтись от места вставки вверх до корня, выполняя вращения и исправляя высоты. И вроде вот, если как-то прикольно рекурсивно реализовать метод добавления, чтобы ты ему давал вставляемый элемент и дерево, куда вставлять, а он бы возвращал (возможно) новый корень, то там мега-простой на вид и компактный код, я уже видел такой подход.
А с этими вращениями, короче, нашёл картинку неплохую. Главное там отмечено Root - это то, к чему применяется вращение, я вот этого не понимал немного. Если применить тупо простое правое вращение к left-right случаю или тупо левое к right-left кейсу, то ты нифига не исправишь несбалансированность, нужно сначала свести к left-left или right-right случаям. Я не особо уверен и без картинки этой вряд ли напишу код, когда сам сделаю потом, может, лучше в голове уляжется.
И вроде можно доказать, что из этого следует, что высота всего дерева - это O(lgN). Я немного не в состоянии был слушать и плохо понял, но вроде там смысл в том, что можно составить рекуррентное соотношение для минимального количества вершин в АВЛ-дереве в зависимости от его высоты. T(1) = 1, T(2) = 2 - база, T(h) = T(h - 1) + T(h - 2) + 1, потому что там получается что та по типу пикрила (если что-то уберём, то нарушается АВЛьность). А это что-то, что больше N-ного числа фибоначчи, то есть T(h) > F(h) > там какие-то степени и в показателе степени находится h, в основании степени - золотое сечение, короче, выйдет в итоге, что h меньше логарифма.
И было про то, как сохранять это свойство АВЛ-дерева, там два типа базовых вращений и два сложных, каждое из которых состоит из двух базовых. И для удобства в каждой вершине храним разность высот поддеревьев. И, чтобы пофиксить дерево после добавления, надо пройтись от места вставки вверх до корня, выполняя вращения и исправляя высоты. И вроде вот, если как-то прикольно рекурсивно реализовать метод добавления, чтобы ты ему давал вставляемый элемент и дерево, куда вставлять, а он бы возвращал (возможно) новый корень, то там мега-простой на вид и компактный код, я уже видел такой подход.
А с этими вращениями, короче, нашёл картинку неплохую. Главное там отмечено Root - это то, к чему применяется вращение, я вот этого не понимал немного. Если применить тупо простое правое вращение к left-right случаю или тупо левое к right-left кейсу, то ты нифига не исправишь несбалансированность, нужно сначала свести к left-left или right-right случаям. Я не особо уверен и без картинки этой вряд ли напишу код, когда сам сделаю потом, может, лучше в голове уляжется.
Хотел забить на всё и пойти спать, но всё же сделал домашку по алгоритмам. Там были просто задачки на динамику, о которых я писал где-то выше, нового ничего за столько времени не было, потому что одно занятие было потрачено на типа контрольную, где опять же ничего интересного не было, просто задачки по разным пройденным темам. И сейчас тоже ничего такого, все сложности связаны разве что с какой-нибудь ерундой вроде переполнения интов или деления на ноль, из-за того, что я невнимательно читаю, какие входные данные подаются. На лекции сегодня было про несбалансированные бинарные деревья и про АВЛ-деревья. Про первые я знаю, про вторые до этого только слышал или забыл, но там вроде смысл в том, что в них поддерживается инвариант того, что для каждой вершины высоты поддеревьев отличаются не более, чем на 1.
И вроде можно доказать, что из этого следует, что высота всего дерева - это O(lgN). Я немного не в состоянии был слушать и плохо понял, но вроде там смысл в том, что можно составить рекуррентное соотношение для минимального количества вершин в АВЛ-дереве в зависимости от его высоты. T(1) = 1, T(2) = 2 - база, T(h) = T(h - 1) + T(h - 2) + 1, потому что там получается что та по типу пикрила (если что-то уберём, то нарушается АВЛьность). А это что-то, что больше N-ного числа фибоначчи, то есть T(h) > F(h) > там какие-то степени и в показателе степени находится h, в основании степени - золотое сечение, короче, выйдет в итоге, что h меньше логарифма.
И было про то, как сохранять это свойство АВЛ-дерева, там два типа базовых вращений и два сложных, каждое из которых состоит из двух базовых. И для удобства в каждой вершине храним разность высот поддеревьев. И, чтобы пофиксить дерево после добавления, надо пройтись от места вставки вверх до корня, выполняя вращения и исправляя высоты. И вроде вот, если как-то прикольно рекурсивно реализовать метод добавления, чтобы ты ему давал вставляемый элемент и дерево, куда вставлять, а он бы возвращал (возможно) новый корень, то там мега-простой на вид и компактный код, я уже видел такой подход.
А с этими вращениями, короче, нашёл картинку неплохую. Главное там отмечено Root - это то, к чему применяется вращение, я вот этого не понимал немного. Если применить тупо простое правое вращение к left-right случаю или тупо левое к right-left кейсу, то ты нифига не исправишь несбалансированность, нужно сначала свести к left-left или right-right случаям. Я не особо уверен и без картинки этой вряд ли напишу код, когда сам сделаю потом, может, лучше в голове уляжется.
И вроде можно доказать, что из этого следует, что высота всего дерева - это O(lgN). Я немного не в состоянии был слушать и плохо понял, но вроде там смысл в том, что можно составить рекуррентное соотношение для минимального количества вершин в АВЛ-дереве в зависимости от его высоты. T(1) = 1, T(2) = 2 - база, T(h) = T(h - 1) + T(h - 2) + 1, потому что там получается что та по типу пикрила (если что-то уберём, то нарушается АВЛьность). А это что-то, что больше N-ного числа фибоначчи, то есть T(h) > F(h) > там какие-то степени и в показателе степени находится h, в основании степени - золотое сечение, короче, выйдет в итоге, что h меньше логарифма.
И было про то, как сохранять это свойство АВЛ-дерева, там два типа базовых вращений и два сложных, каждое из которых состоит из двух базовых. И для удобства в каждой вершине храним разность высот поддеревьев. И, чтобы пофиксить дерево после добавления, надо пройтись от места вставки вверх до корня, выполняя вращения и исправляя высоты. И вроде вот, если как-то прикольно рекурсивно реализовать метод добавления, чтобы ты ему давал вставляемый элемент и дерево, куда вставлять, а он бы возвращал (возможно) новый корень, то там мега-простой на вид и компактный код, я уже видел такой подход.
А с этими вращениями, короче, нашёл картинку неплохую. Главное там отмечено Root - это то, к чему применяется вращение, я вот этого не понимал немного. Если применить тупо простое правое вращение к left-right случаю или тупо левое к right-left кейсу, то ты нифига не исправишь несбалансированность, нужно сначала свести к left-left или right-right случаям. Я не особо уверен и без картинки этой вряд ли напишу код, когда сам сделаю потом, может, лучше в голове уляжется.
538 Кб, 2307x3414Весь вчерашний день на какую-то фиггню потратил в виде домашнего задания по джамбе. Там надо было сделать какой-нибудь объект и протестить разные способы сериализации списка из этих объектов. И я очень долго сначала писал этот объект, потому что не знаю почему, а потом ещё с сериализацией долго тупил.
Единственное, что я понял - это, что в тупом джамба io api DataIOStream (записывает в поток, который он оборачивает, примитивные типы и строки в UTF) - это ровно то же самое, что и ObjectIOStream, но без методов для сериализации объектов. И ещё одно различие в том, что ObjectIOStream делает буферизацию для последовательно записываемых примитивных типов, а DataIOStream - нет, поэтому при создании DataStream в файл, например, ему прямо обязательно надо передавать поток с буферизацией, иначе он тормозит просто жесть. И я из-за этого долго не понимал, почему один работает быстрее другого при вызове идентичных методов.
Непонятно, зачем нужно два способа сериализации: через Externalizable и через объявление приватных методов read/writeObject. Через Externalizable обычно лучше работает и по памяти почему-то он выигрывает часто, хотя там код вообще идентичный и вообще оба способа похожи. И Externalizable немного быстрее обычно, может быть, из-за того, что там от класса требуется публичный конструктор без аргументов и имплементирующиеся методы read/write, то есть делаются только прямые вызовы функций. А в read/writeObject методы все приватные.
Единственное ещё - если через read/writeObject, то вроде можно вызвать дефолтную сериализацию на объекте, а потом дописать/дочитать какие-то данные, например, что-то, что нельзя сериализовать из полей внутри. А в Externalizable ты сам каждое поле объекта вручную записываешь в поток по-любому.
А дефолтная сериализация совсем отстой какой-то по всем пунктам: и работает значительно медленнее, чем любой из способов выше, и размеры файлов получаются большими. Но идеально вообще самому писать то, что надо в файл и читать, руководствуясь своим представлением, чтобы оптимизировать и по памяти, и по времени.
Я про такое узнал
https://refactoring.guru/design-patterns/builder
паттерны не нужны ооп не нужно да да мне всё равно
и я у себя в том сериализуемом объекте тупом его использовал, потому что там по условию надо было, чтобы внутри объекта был список, а у меня там много списков, которые все надо инициализировать. И у меня довольно тупо объект Animal и внутри типа объект-поведение, в котором прописано, с кем животное дружит и какую еду любит, не знаю, имеет ли это смысл в теории практический. Хотя, может быть, и не очень тупо, потому что в теории можно было бы задать любое поведение для конкретного экземпляра животного, чтобы, например, кошка вела себя как со бака.
А билдер я там использовал, потому что в объекте-поведении несколько списков (друзья, враги, среды обитания там) и неудобно их все в конструкторе животного инициализировать. Возможно, это /mɪsˈjuːz/ этого паттерна, я не знаю, но это точно более-менее способ, чтобы упростить код, если есть куча параметров по умолчанию, отсюда куча конструкторов (в ссылке выше это называется "telescoping constructor"), по крайней мере в джамбе точно лучше выглядит, потому что в частности тут у методов и конструкторов вообще нельзя никак добавить значения аргументов по умолчанию. Такой /ˈwəːkəraʊnd/ по крайней мере этого ограничения. И ещё там такие применения упоминаются:
Там на эту тему был интересный пример с тем, что там два билдера, один делает машину, а второй - мануал по её эксплуатации и там шаги одни и те же, потому что мануал должен полностью описывать машину, но билдеры создают разные объекты.
Это тоже, если объект внутри себя содержит несколько других объектов. Но это нормально, наверное, только, если внутренние объекты сильно связаны с внешним, потому что иначе проще было бы снаружи создать эти внутренние объекты. То есть, например, у меня животное /diːˈkʌpəld/ от своего поведения, поэтому мне не имело бы смысла делать билдер животного, который в том числе занимается созданием его поведения.
Единственное, что я понял - это, что в тупом джамба io api DataIOStream (записывает в поток, который он оборачивает, примитивные типы и строки в UTF) - это ровно то же самое, что и ObjectIOStream, но без методов для сериализации объектов. И ещё одно различие в том, что ObjectIOStream делает буферизацию для последовательно записываемых примитивных типов, а DataIOStream - нет, поэтому при создании DataStream в файл, например, ему прямо обязательно надо передавать поток с буферизацией, иначе он тормозит просто жесть. И я из-за этого долго не понимал, почему один работает быстрее другого при вызове идентичных методов.
Непонятно, зачем нужно два способа сериализации: через Externalizable и через объявление приватных методов read/writeObject. Через Externalizable обычно лучше работает и по памяти почему-то он выигрывает часто, хотя там код вообще идентичный и вообще оба способа похожи. И Externalizable немного быстрее обычно, может быть, из-за того, что там от класса требуется публичный конструктор без аргументов и имплементирующиеся методы read/write, то есть делаются только прямые вызовы функций. А в read/writeObject методы все приватные.
Единственное ещё - если через read/writeObject, то вроде можно вызвать дефолтную сериализацию на объекте, а потом дописать/дочитать какие-то данные, например, что-то, что нельзя сериализовать из полей внутри. А в Externalizable ты сам каждое поле объекта вручную записываешь в поток по-любому.
А дефолтная сериализация совсем отстой какой-то по всем пунктам: и работает значительно медленнее, чем любой из способов выше, и размеры файлов получаются большими. Но идеально вообще самому писать то, что надо в файл и читать, руководствуясь своим представлением, чтобы оптимизировать и по памяти, и по времени.
Я про такое узнал
https://refactoring.guru/design-patterns/builder
паттерны не нужны ооп не нужно да да мне всё равно
и я у себя в том сериализуемом объекте тупом его использовал, потому что там по условию надо было, чтобы внутри объекта был список, а у меня там много списков, которые все надо инициализировать. И у меня довольно тупо объект Animal и внутри типа объект-поведение, в котором прописано, с кем животное дружит и какую еду любит, не знаю, имеет ли это смысл в теории практический. Хотя, может быть, и не очень тупо, потому что в теории можно было бы задать любое поведение для конкретного экземпляра животного, чтобы, например, кошка вела себя как со бака.
А билдер я там использовал, потому что в объекте-поведении несколько списков (друзья, враги, среды обитания там) и неудобно их все в конструкторе животного инициализировать. Возможно, это /mɪsˈjuːz/ этого паттерна, я не знаю, но это точно более-менее способ, чтобы упростить код, если есть куча параметров по умолчанию, отсюда куча конструкторов (в ссылке выше это называется "telescoping constructor"), по крайней мере в джамбе точно лучше выглядит, потому что в частности тут у методов и конструкторов вообще нельзя никак добавить значения аргументов по умолчанию. Такой /ˈwəːkəraʊnd/ по крайней мере этого ограничения. И ещё там такие применения упоминаются:
>Use the Builder pattern when you want your code to be able to create different representations of some product
Там на эту тему был интересный пример с тем, что там два билдера, один делает машину, а второй - мануал по её эксплуатации и там шаги одни и те же, потому что мануал должен полностью описывать машину, но билдеры создают разные объекты.
>Use the Builder to construct Composite trees or other complex objects.
Это тоже, если объект внутри себя содержит несколько других объектов. Но это нормально, наверное, только, если внутренние объекты сильно связаны с внешним, потому что иначе проще было бы снаружи создать эти внутренние объекты. То есть, например, у меня животное /diːˈkʌpəld/ от своего поведения, поэтому мне не имело бы смысла делать билдер животного, который в том числе занимается созданием его поведения.
538 Кб, 2307x3414Весь вчерашний день на какую-то фиггню потратил в виде домашнего задания по джамбе. Там надо было сделать какой-нибудь объект и протестить разные способы сериализации списка из этих объектов. И я очень долго сначала писал этот объект, потому что не знаю почему, а потом ещё с сериализацией долго тупил.
Единственное, что я понял - это, что в тупом джамба io api DataIOStream (записывает в поток, который он оборачивает, примитивные типы и строки в UTF) - это ровно то же самое, что и ObjectIOStream, но без методов для сериализации объектов. И ещё одно различие в том, что ObjectIOStream делает буферизацию для последовательно записываемых примитивных типов, а DataIOStream - нет, поэтому при создании DataStream в файл, например, ему прямо обязательно надо передавать поток с буферизацией, иначе он тормозит просто жесть. И я из-за этого долго не понимал, почему один работает быстрее другого при вызове идентичных методов.
Непонятно, зачем нужно два способа сериализации: через Externalizable и через объявление приватных методов read/writeObject. Через Externalizable обычно лучше работает и по памяти почему-то он выигрывает часто, хотя там код вообще идентичный и вообще оба способа похожи. И Externalizable немного быстрее обычно, может быть, из-за того, что там от класса требуется публичный конструктор без аргументов и имплементирующиеся методы read/write, то есть делаются только прямые вызовы функций. А в read/writeObject методы все приватные.
Единственное ещё - если через read/writeObject, то вроде можно вызвать дефолтную сериализацию на объекте, а потом дописать/дочитать какие-то данные, например, что-то, что нельзя сериализовать из полей внутри. А в Externalizable ты сам каждое поле объекта вручную записываешь в поток по-любому.
А дефолтная сериализация совсем отстой какой-то по всем пунктам: и работает значительно медленнее, чем любой из способов выше, и размеры файлов получаются большими. Но идеально вообще самому писать то, что надо в файл и читать, руководствуясь своим представлением, чтобы оптимизировать и по памяти, и по времени.
Я про такое узнал
https://refactoring.guru/design-patterns/builder
паттерны не нужны ооп не нужно да да мне всё равно
и я у себя в том сериализуемом объекте тупом его использовал, потому что там по условию надо было, чтобы внутри объекта был список, а у меня там много списков, которые все надо инициализировать. И у меня довольно тупо объект Animal и внутри типа объект-поведение, в котором прописано, с кем животное дружит и какую еду любит, не знаю, имеет ли это смысл в теории практический. Хотя, может быть, и не очень тупо, потому что в теории можно было бы задать любое поведение для конкретного экземпляра животного, чтобы, например, кошка вела себя как со бака.
А билдер я там использовал, потому что в объекте-поведении несколько списков (друзья, враги, среды обитания там) и неудобно их все в конструкторе животного инициализировать. Возможно, это /mɪsˈjuːz/ этого паттерна, я не знаю, но это точно более-менее способ, чтобы упростить код, если есть куча параметров по умолчанию, отсюда куча конструкторов (в ссылке выше это называется "telescoping constructor"), по крайней мере в джамбе точно лучше выглядит, потому что в частности тут у методов и конструкторов вообще нельзя никак добавить значения аргументов по умолчанию. Такой /ˈwəːkəraʊnd/ по крайней мере этого ограничения. И ещё там такие применения упоминаются:
Там на эту тему был интересный пример с тем, что там два билдера, один делает машину, а второй - мануал по её эксплуатации и там шаги одни и те же, потому что мануал должен полностью описывать машину, но билдеры создают разные объекты.
Это тоже, если объект внутри себя содержит несколько других объектов. Но это нормально, наверное, только, если внутренние объекты сильно связаны с внешним, потому что иначе проще было бы снаружи создать эти внутренние объекты. То есть, например, у меня животное /diːˈkʌpəld/ от своего поведения, поэтому мне не имело бы смысла делать билдер животного, который в том числе занимается созданием его поведения.
Единственное, что я понял - это, что в тупом джамба io api DataIOStream (записывает в поток, который он оборачивает, примитивные типы и строки в UTF) - это ровно то же самое, что и ObjectIOStream, но без методов для сериализации объектов. И ещё одно различие в том, что ObjectIOStream делает буферизацию для последовательно записываемых примитивных типов, а DataIOStream - нет, поэтому при создании DataStream в файл, например, ему прямо обязательно надо передавать поток с буферизацией, иначе он тормозит просто жесть. И я из-за этого долго не понимал, почему один работает быстрее другого при вызове идентичных методов.
Непонятно, зачем нужно два способа сериализации: через Externalizable и через объявление приватных методов read/writeObject. Через Externalizable обычно лучше работает и по памяти почему-то он выигрывает часто, хотя там код вообще идентичный и вообще оба способа похожи. И Externalizable немного быстрее обычно, может быть, из-за того, что там от класса требуется публичный конструктор без аргументов и имплементирующиеся методы read/write, то есть делаются только прямые вызовы функций. А в read/writeObject методы все приватные.
Единственное ещё - если через read/writeObject, то вроде можно вызвать дефолтную сериализацию на объекте, а потом дописать/дочитать какие-то данные, например, что-то, что нельзя сериализовать из полей внутри. А в Externalizable ты сам каждое поле объекта вручную записываешь в поток по-любому.
А дефолтная сериализация совсем отстой какой-то по всем пунктам: и работает значительно медленнее, чем любой из способов выше, и размеры файлов получаются большими. Но идеально вообще самому писать то, что надо в файл и читать, руководствуясь своим представлением, чтобы оптимизировать и по памяти, и по времени.
Я про такое узнал
https://refactoring.guru/design-patterns/builder
паттерны не нужны ооп не нужно да да мне всё равно
и я у себя в том сериализуемом объекте тупом его использовал, потому что там по условию надо было, чтобы внутри объекта был список, а у меня там много списков, которые все надо инициализировать. И у меня довольно тупо объект Animal и внутри типа объект-поведение, в котором прописано, с кем животное дружит и какую еду любит, не знаю, имеет ли это смысл в теории практический. Хотя, может быть, и не очень тупо, потому что в теории можно было бы задать любое поведение для конкретного экземпляра животного, чтобы, например, кошка вела себя как со бака.
А билдер я там использовал, потому что в объекте-поведении несколько списков (друзья, враги, среды обитания там) и неудобно их все в конструкторе животного инициализировать. Возможно, это /mɪsˈjuːz/ этого паттерна, я не знаю, но это точно более-менее способ, чтобы упростить код, если есть куча параметров по умолчанию, отсюда куча конструкторов (в ссылке выше это называется "telescoping constructor"), по крайней мере в джамбе точно лучше выглядит, потому что в частности тут у методов и конструкторов вообще нельзя никак добавить значения аргументов по умолчанию. Такой /ˈwəːkəraʊnd/ по крайней мере этого ограничения. И ещё там такие применения упоминаются:
>Use the Builder pattern when you want your code to be able to create different representations of some product
Там на эту тему был интересный пример с тем, что там два билдера, один делает машину, а второй - мануал по её эксплуатации и там шаги одни и те же, потому что мануал должен полностью описывать машину, но билдеры создают разные объекты.
>Use the Builder to construct Composite trees or other complex objects.
Это тоже, если объект внутри себя содержит несколько других объектов. Но это нормально, наверное, только, если внутренние объекты сильно связаны с внешним, потому что иначе проще было бы снаружи создать эти внутренние объекты. То есть, например, у меня животное /diːˈkʌpəld/ от своего поведения, поэтому мне не имело бы смысла делать билдер животного, который в том числе занимается созданием его поведения.
>>18772
Ээ, liquid не трогай это же не яп, а шаблонизатор.
Попробуй это:
[](https://google.com)
Не, велосипед получится, тормознутый.
Согласен.
> яп этот дурацкий
Ээ, liquid не трогай это же не яп, а шаблонизатор.
> нельзя сделать кликабельные картинки, встроенные внутри постов, потому что вроде тупо нет возможности обернуть каждый <img> в <a>.
Попробуй это:
[](https://google.com)
> На js, наверное, можно было бы написать скрипт
Не, велосипед получится, тормознутый.
> мега-тупость выходит
Согласен.
717 Кб, 1684x2048>>19524
Не знаю, шаблонизатор - это вроде всё же программа, которая процессит шаблоны и данные https://en.wikipedia.org/wiki/Template_processor а liquid - это шаблонный язык.
Я не разбираюсь, но вроде он (liquid) по крайней мере тьюринг-полный, есть же циклы, ветвление, переменные, вот это всё. К тому же наверняка можно легко написать интерпретатор какого-нибудь брейнфака, а брейнфак тьюринг-полный. Так что почему бы и не яп.
Хотя я не знаю, что нужно, чтобы какая-то штука могла называться яп. Может, зависит от применения. Но вот генератор оглавлений можно написать на нём, и в этом случае liquid выполняет роль не шаблонного языка, а просто языка программирования, который описывает >a set of instructions that produce various kinds of output (определение яп из вики).
Для сравнения регексы вроде не тьюринг-полные. А регексы с возможностью последовательно много раз применять (find and replace) их к данным https://github.com/Tegmen/RegEx-Brainfuck-Interpreter уже тьюринг-полные. Это по сути что-то вроде алгоритмов маркова вроде получается https://en.wikipedia.org/wiki/Markov_algorithm
Извини, что пристал с этим.
Бтв под кликабельными картинками я имел в виду скорее [](/images/котэ.jpg). Но в любом случае я уже видел такое решение в интернете, так неинтересно и мне слишком лень прописывать такую штуку каждый раз, когда я хочу всатвить картинку, вместо того, чтобы тупо вставить её через Ctrl+V в маркдаун редакторе, которым я пользуюсь (typora). Может, можно попробовать научиться в макросы в емаксе или виме, но мне нравится тайпора.
короче слишком сложно это всё
>это же не яп, а шаблонизатор
Не знаю, шаблонизатор - это вроде всё же программа, которая процессит шаблоны и данные https://en.wikipedia.org/wiki/Template_processor а liquid - это шаблонный язык.
Я не разбираюсь, но вроде он (liquid) по крайней мере тьюринг-полный, есть же циклы, ветвление, переменные, вот это всё. К тому же наверняка можно легко написать интерпретатор какого-нибудь брейнфака, а брейнфак тьюринг-полный. Так что почему бы и не яп.
Хотя я не знаю, что нужно, чтобы какая-то штука могла называться яп. Может, зависит от применения. Но вот генератор оглавлений можно написать на нём, и в этом случае liquid выполняет роль не шаблонного языка, а просто языка программирования, который описывает >a set of instructions that produce various kinds of output (определение яп из вики).
Для сравнения регексы вроде не тьюринг-полные. А регексы с возможностью последовательно много раз применять (find and replace) их к данным https://github.com/Tegmen/RegEx-Brainfuck-Interpreter уже тьюринг-полные. Это по сути что-то вроде алгоритмов маркова вроде получается https://en.wikipedia.org/wiki/Markov_algorithm
Извини, что пристал с этим.
>[](https://google.com)
Бтв под кликабельными картинками я имел в виду скорее [](/images/котэ.jpg). Но в любом случае я уже видел такое решение в интернете, так неинтересно и мне слишком лень прописывать такую штуку каждый раз, когда я хочу всатвить картинку, вместо того, чтобы тупо вставить её через Ctrl+V в маркдаун редакторе, которым я пользуюсь (typora). Может, можно попробовать научиться в макросы в емаксе или виме, но мне нравится тайпора.
короче слишком сложно это всё
338 Кб, 1451x2048Снапшот 1.17 манкрафта вышел, кстати. Неплохое видео илманго про изменения
https://youtu.be/6-81_JCArlw
и они там уже успели сделать ферму шалкербоксов
https://youtu.be/8RqWiEJuauQ
которая эксплойтит новую фишку с тем, что снаряд, попадающий в открытого шалкера может заспавнить нового на его месте, а старый телепортируется с этого блока. То есть можно даже не париться по поводу того, что шалкеры дамажатся, потому что задамаженные телепортируются и ты их где-нибудь убиваешь. У них сделано так, что они в ад телепортируются и там их убивают визер розами.
Я не очень следил, но вроде слышал, что медь можно будет получить только ручным майнингом, и кристаллы эти - вырастить только на специальных блоках, положение которых фиксировано в мире: никак нельзя ни поршнем сдвинуть, ни силк тачем собрать. Это довольно странно с учётом того, что изменение с шалкерами однозначно сделано, чтобы была возможность фармить шалкербоксы, а тут специально делают так, чтобы фармить медь и кристаллы было максимально сложно. При этом все остальные руды/ископаемые в манкрафте на данный момент возобновляемы.
Вроде как с громоотводом станет проще фармить заряженных криперов, может, можно будет автоматизировать это. До этого можно было вручную их делать с помощью трезубца во время грозы. Насчёт лошадей-скелетов - не очень понятно, могут ли они спавниться, если молния притягивается громоотводом, не знаю, поможет ли это как-то их фармить. Вообще я долго не знал, откуда эти лошади берутся и встречал их только один раз, когда играл.
Интересно, что добавили уникальное применение для кроличьих шкурок (бандлы) и больше применений для пчелиных сот (свечи и обмазывание медных блоков). Медные блоки, кстати, как-то мега-медленно покрываются ржавчиной:
То есть от 16,66 до 27,33 часов реального времени + чтобы чанки с блоками были всегда прогружены, то есть их нужно будет хранить в спавн чанках, видимо https://minecraft.gamepedia.com/Spawn_chunk Кстати, очень классно, что можно зажигать свечи диспенсером, вообще любой новый предмет, который излучает свет - круто, потому что факелы слишком уродливые.
Это https://youtu.be/6-81_JCArlw?t=890 действительно забавно и похоже на то, что за этим стоит какой-нибудь мусорный код по типу if (ПКМ на торте && на торте есть свеча) { дропнуть свечу }.
Waterlogged рельсы - круто, котёл с лавой - нет, потому что можно было бы сделать, чтобы он взаимодействовал с водой (cobblestone generator), чтобы можно было делать штуки, которые строят мосты, но это добавлено тупо потому, что в бедроке котёл с лавой уже есть. Странно тогда почему не добавили уже и котлы с покрашенной водой.
Было бы круто, если бы уже наконец добавили MBE (movable block entities), непонятно, почему их нет в игре. Есть мод, который их добавляет и илманго делал видео про то, как можно было бы использовать эту возможность. Но, кстати, это бы, наверное, сломало много редстоун механизмов, потому что многие используют, например, печки как non-movable блоки. Ну, это не особо проблема, просто наблюдение. Эм, я не знаю, почему и зачем я вообще не разбираюсь в таком. Но вроде слаймблоки не прилипают к MBE и печку довольно дёшево скрафтить/получить по сравнению с, скажем, сундуками, обсидианом и другими блоками, которые не двигаются и не прилипают. И в летающих штуках на слаймблоках это используется как штука, чтобы её остановить.
Ещё непонятно, почему в манкрафте нет динамического освещения. Я постоянно слышу про это, что мол в том числе, ха, вы все голосовали за glowing сквидов, а они даже светиться не смогут. Не понимаю, почему нельзя реализовать. Почему в оптифайне динамическое освещение есть, а в ваниллу типа нельзя добавить.
Кстати, раз уж манкрафт, то я про такое ещё узнал https://youtu.be/SkTU_LgviRY?t=392 можно на любую высоту по сути отправлять редстоун сигнал снизу вверх, при этом на всех высотах он детектится одновременно. А сверху вниз можно через датчики дневного света (если прямо над ними на любой высоте есть блок, то они детектят это, так что можно его просто поршнем убирать и возвращать).
https://youtu.be/6-81_JCArlw
и они там уже успели сделать ферму шалкербоксов
https://youtu.be/8RqWiEJuauQ
которая эксплойтит новую фишку с тем, что снаряд, попадающий в открытого шалкера может заспавнить нового на его месте, а старый телепортируется с этого блока. То есть можно даже не париться по поводу того, что шалкеры дамажатся, потому что задамаженные телепортируются и ты их где-нибудь убиваешь. У них сделано так, что они в ад телепортируются и там их убивают визер розами.
Я не очень следил, но вроде слышал, что медь можно будет получить только ручным майнингом, и кристаллы эти - вырастить только на специальных блоках, положение которых фиксировано в мире: никак нельзя ни поршнем сдвинуть, ни силк тачем собрать. Это довольно странно с учётом того, что изменение с шалкерами однозначно сделано, чтобы была возможность фармить шалкербоксы, а тут специально делают так, чтобы фармить медь и кристаллы было максимально сложно. При этом все остальные руды/ископаемые в манкрафте на данный момент возобновляемы.
Вроде как с громоотводом станет проще фармить заряженных криперов, может, можно будет автоматизировать это. До этого можно было вручную их делать с помощью трезубца во время грозы. Насчёт лошадей-скелетов - не очень понятно, могут ли они спавниться, если молния притягивается громоотводом, не знаю, поможет ли это как-то их фармить. Вообще я долго не знал, откуда эти лошади берутся и встречал их только один раз, когда играл.
Интересно, что добавили уникальное применение для кроличьих шкурок (бандлы) и больше применений для пчелиных сот (свечи и обмазывание медных блоков). Медные блоки, кстати, как-то мега-медленно покрываются ржавчиной:
>It takes 50-82 Minecraft days (in loaded chunks) for a copper block to oxidize one stage.
То есть от 16,66 до 27,33 часов реального времени + чтобы чанки с блоками были всегда прогружены, то есть их нужно будет хранить в спавн чанках, видимо https://minecraft.gamepedia.com/Spawn_chunk Кстати, очень классно, что можно зажигать свечи диспенсером, вообще любой новый предмет, который излучает свет - круто, потому что факелы слишком уродливые.
Это https://youtu.be/6-81_JCArlw?t=890 действительно забавно и похоже на то, что за этим стоит какой-нибудь мусорный код по типу if (ПКМ на торте && на торте есть свеча) { дропнуть свечу }.
Waterlogged рельсы - круто, котёл с лавой - нет, потому что можно было бы сделать, чтобы он взаимодействовал с водой (cobblestone generator), чтобы можно было делать штуки, которые строят мосты, но это добавлено тупо потому, что в бедроке котёл с лавой уже есть. Странно тогда почему не добавили уже и котлы с покрашенной водой.
Было бы круто, если бы уже наконец добавили MBE (movable block entities), непонятно, почему их нет в игре. Есть мод, который их добавляет и илманго делал видео про то, как можно было бы использовать эту возможность. Но, кстати, это бы, наверное, сломало много редстоун механизмов, потому что многие используют, например, печки как non-movable блоки. Ну, это не особо проблема, просто наблюдение. Эм, я не знаю, почему и зачем я вообще не разбираюсь в таком. Но вроде слаймблоки не прилипают к MBE и печку довольно дёшево скрафтить/получить по сравнению с, скажем, сундуками, обсидианом и другими блоками, которые не двигаются и не прилипают. И в летающих штуках на слаймблоках это используется как штука, чтобы её остановить.
Ещё непонятно, почему в манкрафте нет динамического освещения. Я постоянно слышу про это, что мол в том числе, ха, вы все голосовали за glowing сквидов, а они даже светиться не смогут. Не понимаю, почему нельзя реализовать. Почему в оптифайне динамическое освещение есть, а в ваниллу типа нельзя добавить.
Кстати, раз уж манкрафт, то я про такое ещё узнал https://youtu.be/SkTU_LgviRY?t=392 можно на любую высоту по сути отправлять редстоун сигнал снизу вверх, при этом на всех высотах он детектится одновременно. А сверху вниз можно через датчики дневного света (если прямо над ними на любой высоте есть блок, то они детектят это, так что можно его просто поршнем убирать и возвращать).
338 Кб, 1451x2048Снапшот 1.17 манкрафта вышел, кстати. Неплохое видео илманго про изменения
https://youtu.be/6-81_JCArlw
и они там уже успели сделать ферму шалкербоксов
https://youtu.be/8RqWiEJuauQ
которая эксплойтит новую фишку с тем, что снаряд, попадающий в открытого шалкера может заспавнить нового на его месте, а старый телепортируется с этого блока. То есть можно даже не париться по поводу того, что шалкеры дамажатся, потому что задамаженные телепортируются и ты их где-нибудь убиваешь. У них сделано так, что они в ад телепортируются и там их убивают визер розами.
Я не очень следил, но вроде слышал, что медь можно будет получить только ручным майнингом, и кристаллы эти - вырастить только на специальных блоках, положение которых фиксировано в мире: никак нельзя ни поршнем сдвинуть, ни силк тачем собрать. Это довольно странно с учётом того, что изменение с шалкерами однозначно сделано, чтобы была возможность фармить шалкербоксы, а тут специально делают так, чтобы фармить медь и кристаллы было максимально сложно. При этом все остальные руды/ископаемые в манкрафте на данный момент возобновляемы.
Вроде как с громоотводом станет проще фармить заряженных криперов, может, можно будет автоматизировать это. До этого можно было вручную их делать с помощью трезубца во время грозы. Насчёт лошадей-скелетов - не очень понятно, могут ли они спавниться, если молния притягивается громоотводом, не знаю, поможет ли это как-то их фармить. Вообще я долго не знал, откуда эти лошади берутся и встречал их только один раз, когда играл.
Интересно, что добавили уникальное применение для кроличьих шкурок (бандлы) и больше применений для пчелиных сот (свечи и обмазывание медных блоков). Медные блоки, кстати, как-то мега-медленно покрываются ржавчиной:
То есть от 16,66 до 27,33 часов реального времени + чтобы чанки с блоками были всегда прогружены, то есть их нужно будет хранить в спавн чанках, видимо https://minecraft.gamepedia.com/Spawn_chunk Кстати, очень классно, что можно зажигать свечи диспенсером, вообще любой новый предмет, который излучает свет - круто, потому что факелы слишком уродливые.
Это https://youtu.be/6-81_JCArlw?t=890 действительно забавно и похоже на то, что за этим стоит какой-нибудь мусорный код по типу if (ПКМ на торте && на торте есть свеча) { дропнуть свечу }.
Waterlogged рельсы - круто, котёл с лавой - нет, потому что можно было бы сделать, чтобы он взаимодействовал с водой (cobblestone generator), чтобы можно было делать штуки, которые строят мосты, но это добавлено тупо потому, что в бедроке котёл с лавой уже есть. Странно тогда почему не добавили уже и котлы с покрашенной водой.
Было бы круто, если бы уже наконец добавили MBE (movable block entities), непонятно, почему их нет в игре. Есть мод, который их добавляет и илманго делал видео про то, как можно было бы использовать эту возможность. Но, кстати, это бы, наверное, сломало много редстоун механизмов, потому что многие используют, например, печки как non-movable блоки. Ну, это не особо проблема, просто наблюдение. Эм, я не знаю, почему и зачем я вообще не разбираюсь в таком. Но вроде слаймблоки не прилипают к MBE и печку довольно дёшево скрафтить/получить по сравнению с, скажем, сундуками, обсидианом и другими блоками, которые не двигаются и не прилипают. И в летающих штуках на слаймблоках это используется как штука, чтобы её остановить.
Ещё непонятно, почему в манкрафте нет динамического освещения. Я постоянно слышу про это, что мол в том числе, ха, вы все голосовали за glowing сквидов, а они даже светиться не смогут. Не понимаю, почему нельзя реализовать. Почему в оптифайне динамическое освещение есть, а в ваниллу типа нельзя добавить.
Кстати, раз уж манкрафт, то я про такое ещё узнал https://youtu.be/SkTU_LgviRY?t=392 можно на любую высоту по сути отправлять редстоун сигнал снизу вверх, при этом на всех высотах он детектится одновременно. А сверху вниз можно через датчики дневного света (если прямо над ними на любой высоте есть блок, то они детектят это, так что можно его просто поршнем убирать и возвращать).
https://youtu.be/6-81_JCArlw
и они там уже успели сделать ферму шалкербоксов
https://youtu.be/8RqWiEJuauQ
которая эксплойтит новую фишку с тем, что снаряд, попадающий в открытого шалкера может заспавнить нового на его месте, а старый телепортируется с этого блока. То есть можно даже не париться по поводу того, что шалкеры дамажатся, потому что задамаженные телепортируются и ты их где-нибудь убиваешь. У них сделано так, что они в ад телепортируются и там их убивают визер розами.
Я не очень следил, но вроде слышал, что медь можно будет получить только ручным майнингом, и кристаллы эти - вырастить только на специальных блоках, положение которых фиксировано в мире: никак нельзя ни поршнем сдвинуть, ни силк тачем собрать. Это довольно странно с учётом того, что изменение с шалкерами однозначно сделано, чтобы была возможность фармить шалкербоксы, а тут специально делают так, чтобы фармить медь и кристаллы было максимально сложно. При этом все остальные руды/ископаемые в манкрафте на данный момент возобновляемы.
Вроде как с громоотводом станет проще фармить заряженных криперов, может, можно будет автоматизировать это. До этого можно было вручную их делать с помощью трезубца во время грозы. Насчёт лошадей-скелетов - не очень понятно, могут ли они спавниться, если молния притягивается громоотводом, не знаю, поможет ли это как-то их фармить. Вообще я долго не знал, откуда эти лошади берутся и встречал их только один раз, когда играл.
Интересно, что добавили уникальное применение для кроличьих шкурок (бандлы) и больше применений для пчелиных сот (свечи и обмазывание медных блоков). Медные блоки, кстати, как-то мега-медленно покрываются ржавчиной:
>It takes 50-82 Minecraft days (in loaded chunks) for a copper block to oxidize one stage.
То есть от 16,66 до 27,33 часов реального времени + чтобы чанки с блоками были всегда прогружены, то есть их нужно будет хранить в спавн чанках, видимо https://minecraft.gamepedia.com/Spawn_chunk Кстати, очень классно, что можно зажигать свечи диспенсером, вообще любой новый предмет, который излучает свет - круто, потому что факелы слишком уродливые.
Это https://youtu.be/6-81_JCArlw?t=890 действительно забавно и похоже на то, что за этим стоит какой-нибудь мусорный код по типу if (ПКМ на торте && на торте есть свеча) { дропнуть свечу }.
Waterlogged рельсы - круто, котёл с лавой - нет, потому что можно было бы сделать, чтобы он взаимодействовал с водой (cobblestone generator), чтобы можно было делать штуки, которые строят мосты, но это добавлено тупо потому, что в бедроке котёл с лавой уже есть. Странно тогда почему не добавили уже и котлы с покрашенной водой.
Было бы круто, если бы уже наконец добавили MBE (movable block entities), непонятно, почему их нет в игре. Есть мод, который их добавляет и илманго делал видео про то, как можно было бы использовать эту возможность. Но, кстати, это бы, наверное, сломало много редстоун механизмов, потому что многие используют, например, печки как non-movable блоки. Ну, это не особо проблема, просто наблюдение. Эм, я не знаю, почему и зачем я вообще не разбираюсь в таком. Но вроде слаймблоки не прилипают к MBE и печку довольно дёшево скрафтить/получить по сравнению с, скажем, сундуками, обсидианом и другими блоками, которые не двигаются и не прилипают. И в летающих штуках на слаймблоках это используется как штука, чтобы её остановить.
Ещё непонятно, почему в манкрафте нет динамического освещения. Я постоянно слышу про это, что мол в том числе, ха, вы все голосовали за glowing сквидов, а они даже светиться не смогут. Не понимаю, почему нельзя реализовать. Почему в оптифайне динамическое освещение есть, а в ваниллу типа нельзя добавить.
Кстати, раз уж манкрафт, то я про такое ещё узнал https://youtu.be/SkTU_LgviRY?t=392 можно на любую высоту по сути отправлять редстоун сигнал снизу вверх, при этом на всех высотах он детектится одновременно. А сверху вниз можно через датчики дневного света (если прямо над ними на любой высоте есть блок, то они детектят это, так что можно его просто поршнем убирать и возвращать).
>>19471
Быдлер — крутая штука, ещё можно сочетать их с fluent interface. Недавно, обчитавшись этого соевого куколда: https://medium.com/@ricomariani/size-matters-it-may-be-the-only-thing-that-matters-64b473900873, я придумал один интересный юзкейс.
Представь, что нам нужно описать СТРУКТУРУ ВЕРШИНЫ типа этой: >>411411 →. Не данные конкретной модели, а метаинформацию о них.
СТРУКТУРА ВЕРШИНЫ содержит:
— список атрибутов;
— список групп. Разбиение на группы удобно для динамических моделей, где атрибуты из одной группы хранятся вперемешку (как AoS :), обновляются одновременно и независимо от других. Ужасный, но пример: поверхность воды может анимироваться программно, а в отдельной группе иметь неанимируемые атрибуты posXZ (X и Z-компонент позиции) и depth (глубина воды под этой точкой).
Атрибут хранит информацию о себе: имя, тип и проч. На картинках всё, кроме имён, скрыто за «...».
Группа тоже хранит кое-какую информацию («...»), а также список атрибутов (индексов в общем списке атрибутов, или сразу указателей на его элементы), которые ей принадлежат, чтобы можно было перебрать атрибуты определённой группы сразу.
Пусть наша структура содержит следующие атрибуты:
группа 0 — позиция (pos), нормаль (normal), касательная (tangent);
группа 1 — координаты текстуры 0 (tex0), координаты текстуры 1 (tex1).
Как это будет лежать в памяти в наивном варианте: 1-я картинка.
Как это можно сделать круче, в предположении, что СТРУКТУРА ВЕРШИНЫ после создания иммутабельна (а это так, т. к. предполагается её переиспользование неопределённым кругом моделей): 2-я картинка. Все данные СТРУКТУРЫ ВЕРШИНЫ лежат в 1 аллокации, соевичок был бы доволен.
В первом варианте не иметь строителя, а доверить пользователю руками создать объект СТРУКТУРЫ ВЕРШИНЫ и заполнять его по 1 элементу, ещё более-менее приемлемо (но со строителем всё равно лучше). А вот обустройство второго — вычисление размера выделяемого блока, смещений внутри него и вот это всё, вплоть до собственно заполнения данными и, возможно, пулинга — кроме строителя не доверить никому. Ещё второй вариант невозможен в Java, но это уже мелочь :^).
Быдлер — крутая штука, ещё можно сочетать их с fluent interface. Недавно, обчитавшись этого соевого куколда: https://medium.com/@ricomariani/size-matters-it-may-be-the-only-thing-that-matters-64b473900873, я придумал один интересный юзкейс.
Представь, что нам нужно описать СТРУКТУРУ ВЕРШИНЫ типа этой: >>411411 →. Не данные конкретной модели, а метаинформацию о них.
СТРУКТУРА ВЕРШИНЫ содержит:
— список атрибутов;
— список групп. Разбиение на группы удобно для динамических моделей, где атрибуты из одной группы хранятся вперемешку (как AoS :), обновляются одновременно и независимо от других. Ужасный, но пример: поверхность воды может анимироваться программно, а в отдельной группе иметь неанимируемые атрибуты posXZ (X и Z-компонент позиции) и depth (глубина воды под этой точкой).
Атрибут хранит информацию о себе: имя, тип и проч. На картинках всё, кроме имён, скрыто за «...».
Группа тоже хранит кое-какую информацию («...»), а также список атрибутов (индексов в общем списке атрибутов, или сразу указателей на его элементы), которые ей принадлежат, чтобы можно было перебрать атрибуты определённой группы сразу.
Пусть наша структура содержит следующие атрибуты:
группа 0 — позиция (pos), нормаль (normal), касательная (tangent);
группа 1 — координаты текстуры 0 (tex0), координаты текстуры 1 (tex1).
Как это будет лежать в памяти в наивном варианте: 1-я картинка.
Как это можно сделать круче, в предположении, что СТРУКТУРА ВЕРШИНЫ после создания иммутабельна (а это так, т. к. предполагается её переиспользование неопределённым кругом моделей): 2-я картинка. Все данные СТРУКТУРЫ ВЕРШИНЫ лежат в 1 аллокации, соевичок был бы доволен.
В первом варианте не иметь строителя, а доверить пользователю руками создать объект СТРУКТУРЫ ВЕРШИНЫ и заполнять его по 1 элементу, ещё более-менее приемлемо (но со строителем всё равно лучше). А вот обустройство второго — вычисление размера выделяемого блока, смещений внутри него и вот это всё, вплоть до собственно заполнения данными и, возможно, пулинга — кроме строителя не доверить никому. Ещё второй вариант невозможен в Java, но это уже мелочь :^).
>>19471
Быдлер — крутая штука, ещё можно сочетать их с fluent interface. Недавно, обчитавшись этого соевого куколда: https://medium.com/@ricomariani/size-matters-it-may-be-the-only-thing-that-matters-64b473900873, я придумал один интересный юзкейс.
Представь, что нам нужно описать СТРУКТУРУ ВЕРШИНЫ типа этой: >>411411 →. Не данные конкретной модели, а метаинформацию о них.
СТРУКТУРА ВЕРШИНЫ содержит:
— список атрибутов;
— список групп. Разбиение на группы удобно для динамических моделей, где атрибуты из одной группы хранятся вперемешку (как AoS :), обновляются одновременно и независимо от других. Ужасный, но пример: поверхность воды может анимироваться программно, а в отдельной группе иметь неанимируемые атрибуты posXZ (X и Z-компонент позиции) и depth (глубина воды под этой точкой).
Атрибут хранит информацию о себе: имя, тип и проч. На картинках всё, кроме имён, скрыто за «...».
Группа тоже хранит кое-какую информацию («...»), а также список атрибутов (индексов в общем списке атрибутов, или сразу указателей на его элементы), которые ей принадлежат, чтобы можно было перебрать атрибуты определённой группы сразу.
Пусть наша структура содержит следующие атрибуты:
группа 0 — позиция (pos), нормаль (normal), касательная (tangent);
группа 1 — координаты текстуры 0 (tex0), координаты текстуры 1 (tex1).
Как это будет лежать в памяти в наивном варианте: 1-я картинка.
Как это можно сделать круче, в предположении, что СТРУКТУРА ВЕРШИНЫ после создания иммутабельна (а это так, т. к. предполагается её переиспользование неопределённым кругом моделей): 2-я картинка. Все данные СТРУКТУРЫ ВЕРШИНЫ лежат в 1 аллокации, соевичок был бы доволен.
В первом варианте не иметь строителя, а доверить пользователю руками создать объект СТРУКТУРЫ ВЕРШИНЫ и заполнять его по 1 элементу, ещё более-менее приемлемо (но со строителем всё равно лучше). А вот обустройство второго — вычисление размера выделяемого блока, смещений внутри него и вот это всё, вплоть до собственно заполнения данными и, возможно, пулинга — кроме строителя не доверить никому. Ещё второй вариант невозможен в Java, но это уже мелочь :^).
Быдлер — крутая штука, ещё можно сочетать их с fluent interface. Недавно, обчитавшись этого соевого куколда: https://medium.com/@ricomariani/size-matters-it-may-be-the-only-thing-that-matters-64b473900873, я придумал один интересный юзкейс.
Представь, что нам нужно описать СТРУКТУРУ ВЕРШИНЫ типа этой: >>411411 →. Не данные конкретной модели, а метаинформацию о них.
СТРУКТУРА ВЕРШИНЫ содержит:
— список атрибутов;
— список групп. Разбиение на группы удобно для динамических моделей, где атрибуты из одной группы хранятся вперемешку (как AoS :), обновляются одновременно и независимо от других. Ужасный, но пример: поверхность воды может анимироваться программно, а в отдельной группе иметь неанимируемые атрибуты posXZ (X и Z-компонент позиции) и depth (глубина воды под этой точкой).
Атрибут хранит информацию о себе: имя, тип и проч. На картинках всё, кроме имён, скрыто за «...».
Группа тоже хранит кое-какую информацию («...»), а также список атрибутов (индексов в общем списке атрибутов, или сразу указателей на его элементы), которые ей принадлежат, чтобы можно было перебрать атрибуты определённой группы сразу.
Пусть наша структура содержит следующие атрибуты:
группа 0 — позиция (pos), нормаль (normal), касательная (tangent);
группа 1 — координаты текстуры 0 (tex0), координаты текстуры 1 (tex1).
Как это будет лежать в памяти в наивном варианте: 1-я картинка.
Как это можно сделать круче, в предположении, что СТРУКТУРА ВЕРШИНЫ после создания иммутабельна (а это так, т. к. предполагается её переиспользование неопределённым кругом моделей): 2-я картинка. Все данные СТРУКТУРЫ ВЕРШИНЫ лежат в 1 аллокации, соевичок был бы доволен.
В первом варианте не иметь строителя, а доверить пользователю руками создать объект СТРУКТУРЫ ВЕРШИНЫ и заполнять его по 1 элементу, ещё более-менее приемлемо (но со строителем всё равно лучше). А вот обустройство второго — вычисление размера выделяемого блока, смещений внутри него и вот это всё, вплоть до собственно заполнения данными и, возможно, пулинга — кроме строителя не доверить никому. Ещё второй вариант невозможен в Java, но это уже мелочь :^).
201 Кб, 2048x2048>>19698
Ну да, такие низкоуровневые приколы нужно как-то инкапуслировать.
А что за пулинг?
Ну да, такие низкоуровневые приколы нужно как-то инкапуслировать.
>вот это всё, вплоть до собственно заполнения данными и, возможно, пулинга — кроме строителя не доверить никому
А что за пулинг?
376 Кб, 1417x846Не смог сегодня заставить себя сделать, просто залипал в монитор. Поправил уже офигенно старую >>15104 домашку по хтмл, я уже должен был к завтрашнему дню вообще другую сделать, но я не знаю. Там ничего по сути и не надо было делать, но я просто не хочу ничего делать, было бы неплохо, если бы кто-нибудь меня уже прикончил. Надо было сделать домашку по плюсам на завтра, уже сегодня, получается, я нифига да не сделал, потому что я не могу просто ничего заставить. Я просто хочу пойти спать, просплю будильник и ничего не сдам. Колено >>15848 вроде прошло, а вроде и если долго держать согнутым, то разгибать больно. Когда я уже сдохну нахуй
60 Кб, 1200x675>>19791
Пул (зд.) — это когда мы храним одинаковые иммутабельные объекты только в одном экземпляре. Если такая же СТРУКТУРА уже существует в программе, вместо создания новой мы возвращаем существующую. Отслеживание существования, смерти и поиск существующего экземпляра можно обеспечить хранением всех экземпляров в глобальной слабой хэш-таблице. Два ключевых профита — экономия памяти и мгновенные сравнения на равенство. Представь себе роль пула строк при работе с большими текстами, включая естественные.
В терминах твоих любимых шаблонов это flyweight.
Пул (зд.) — это когда мы храним одинаковые иммутабельные объекты только в одном экземпляре. Если такая же СТРУКТУРА уже существует в программе, вместо создания новой мы возвращаем существующую. Отслеживание существования, смерти и поиск существующего экземпляра можно обеспечить хранением всех экземпляров в глобальной слабой хэш-таблице. Два ключевых профита — экономия памяти и мгновенные сравнения на равенство. Представь себе роль пула строк при работе с большими текстами, включая естественные.
В терминах твоих любимых шаблонов это flyweight.
494 Кб, 1007x1500>когда мы храним одинаковые иммутабельные объекты только в одном экземпляре
Понятно. Мне почему-то вчера показалось, что это что-то другое.
>твоих любимых шаблонов
Если бы я ещё знал их хотя бы столько штук, соклько пальцев на руке. И если бы у меня был опыт применения на практике хотя бы одного.
1,2 Мб, 2048x2048>>19471
Я короче неважно я отсталый. Externalizable и read/writeObject абсолютно идентичны по скорости. И дефолтная сериализация по памяти не особо прогриывает. Но по скорости она точно мусор, 100%.
Я ничего не сделал и я не умер домашку по плюсам я типа сделал, но её не сегодня надо было сдавать блин там даже, там, короче, неважно даже. Я вообще не понимаю синтаксиса по типу int (array[])[N]. Типа это должен быть массив из указателей на int[N]. Но почему он так странно выглядит. И я не понимал, что нельзя кастить поинтер в поинтер на константу, потому что можно было бы сделать так https://stackoverflow.com/a/16390371 Синтаксис указателей на функции и лямбд какой-то жуткий. И шаблонов. И я так и не посмотрел про них пока что ничего
Там что-то по хтмл было про жс, но ничего пока что особо такого. Я только понял, что this там какой то странный и может принимать непонятные значения из-за bind(), и вообще по-разному ведёт себя в разных ситуациях.
Я как-то не понимаю. Препроцессоры делают css из не-css, добавляя всякие новые возможности в css. Постпроцессоры берут валидный css и улучшают его, но тут единственный полезный пример, который я видел, - это штука, которая добавляет вендорные префиксы. Но при этом постпроцессор может парсить не по скобкам, а по отступам, что позволяет добавить, например, вложенность селекторов. То есть он тогда функционально как препроцессор что ли. зачем тогда препроцессоры существуют
я не знаю
просто неважно
>Через Externalizable обычно лучше работает и по памяти почему-то он выигрывает часто
>А дефолтная сериализация совсем отстой <...> размеры файлов получаются большими.
Я короче неважно я отсталый. Externalizable и read/writeObject абсолютно идентичны по скорости. И дефолтная сериализация по памяти не особо прогриывает. Но по скорости она точно мусор, 100%.
Я ничего не сделал и я не умер домашку по плюсам я типа сделал, но её не сегодня надо было сдавать блин там даже, там, короче, неважно даже. Я вообще не понимаю синтаксиса по типу int (array[])[N]. Типа это должен быть массив из указателей на int[N]. Но почему он так странно выглядит. И я не понимал, что нельзя кастить поинтер в поинтер на константу, потому что можно было бы сделать так https://stackoverflow.com/a/16390371 Синтаксис указателей на функции и лямбд какой-то жуткий. И шаблонов. И я так и не посмотрел про них пока что ничего
Там что-то по хтмл было про жс, но ничего пока что особо такого. Я только понял, что this там какой то странный и может принимать непонятные значения из-за bind(), и вообще по-разному ведёт себя в разных ситуациях.
Я как-то не понимаю. Препроцессоры делают css из не-css, добавляя всякие новые возможности в css. Постпроцессоры берут валидный css и улучшают его, но тут единственный полезный пример, который я видел, - это штука, которая добавляет вендорные префиксы. Но при этом постпроцессор может парсить не по скобкам, а по отступам, что позволяет добавить, например, вложенность селекторов. То есть он тогда функционально как препроцессор что ли. зачем тогда препроцессоры существуют
я не знаю
просто неважно
727 Кб, webm,240x240, 0:40
Я не знаю, мне всё так же плохо от всего завтра куда-то идти надо будет кстати. И сделать лабораторную по микроэлектронике. И по физике ещё, следующую. Там ничего такого вроде не должно быть. Я не могу, мне так не хочется ничего делать и ещё хуже, когда я понимаю, что мне именно надо что то делать, я не понимаю как жить. не хочу ничего
257 Кб, 1191x1684Не могу, не хочется ничего делать. Вчера на физкультуре сдавали потягивания. Я затупил и, оказывается, можно было на выбор, либо потягивания, либо отжимания сдать, вторые вроде попроще, хотя не уверен, там надо было 28 раз сделать, а потягивания 10, но я только 8 смог. Хотя думал, что и четырёх раз не смогу, потому что ничего руками не делаю же кроме фапа плюс по причине жирный. После этого очень сильно хотелось спать, потом перестало хотеться, но всё равно сидел и куда-то тупил в интернете. Сегодня тоже ничего не делал и долго спал. Когда уже всё закончится, я устал.
187 Кб, 1105x1450Сейчас надо умыться и почистить зубы, а потом попытаться разобраться с лабораторной по физике и желательно потратить на это как можно меньше времени. Где-то в процессе нужно будет ещё сдать домашку по плюсам.
678 Кб, 4096x2666>>20915
Сдал ту домашку и плюс-минус сделал что-то похожее на лабораторную по физике, но ничего не понял, потому что там тупо какие-то странные вычисления с измеренными данными и непонятно, что должно получиться в результате. И частично сделал лабораторную по микроэлектронике там что-то про шифраторы и мультиплексоры, мда, надо будет завтра доделать.
И на это ушёл целый день, потому что я не делал что-то, а пытался себя заставить сделать это что-то, постоянно отвлекаясь, потому что мне ничего не хочется и ничего не интересно, я не понимаю, зачем я живу. Я занимаюсь какой-то откровенной хуйнёй, я хочу лежать в кровати и ничего не делать, а потом сидеть за компом и ничего не делать и чтобы меня никто не трогал и не отвлекал. Но так не бывает, по крайней мере у меня не фига не вышло с этим. Не понимаю я ничего.
Сейчас надо почистить зубы и лечь спать. Я не могу собраться с тем, чтобы лечь спать уже пару часов точно, потому что сейчас лучшее время для того, чтобы не спать. Но из-за конфликта между не хочу спать и нужно пойти спать я попадаю в ступор и просто сижу, хотя мог бы что-нибудь сделать. Когда это всё закончится.
Завтра надо куда-то идти. Завтра надо доделать микроэлектронику и сделать домашку по алгоритмам. Завтра надо будет ещё что-нибудь сделать.
Мне так надоело, что болит колено, это сильно мешает, хотя вроде уже лучше, потому что сколько-то дней назад был момент, когда надо было опуститься на корточки, и это было внезапно очень больно и я чуть не упал на колени, а сейчас почти спокойно могу это сделать. Но всё ещё больно разгибать, если нога долго была согнута.
За что мне конкретно вот это, я же с этой ногой ничего не делал, она просто внезапно начала болеть.
Сдал ту домашку и плюс-минус сделал что-то похожее на лабораторную по физике, но ничего не понял, потому что там тупо какие-то странные вычисления с измеренными данными и непонятно, что должно получиться в результате. И частично сделал лабораторную по микроэлектронике там что-то про шифраторы и мультиплексоры, мда, надо будет завтра доделать.
И на это ушёл целый день, потому что я не делал что-то, а пытался себя заставить сделать это что-то, постоянно отвлекаясь, потому что мне ничего не хочется и ничего не интересно, я не понимаю, зачем я живу. Я занимаюсь какой-то откровенной хуйнёй, я хочу лежать в кровати и ничего не делать, а потом сидеть за компом и ничего не делать и чтобы меня никто не трогал и не отвлекал. Но так не бывает, по крайней мере у меня не фига не вышло с этим. Не понимаю я ничего.
Сейчас надо почистить зубы и лечь спать. Я не могу собраться с тем, чтобы лечь спать уже пару часов точно, потому что сейчас лучшее время для того, чтобы не спать. Но из-за конфликта между не хочу спать и нужно пойти спать я попадаю в ступор и просто сижу, хотя мог бы что-нибудь сделать. Когда это всё закончится.
Завтра надо куда-то идти. Завтра надо доделать микроэлектронику и сделать домашку по алгоритмам. Завтра надо будет ещё что-нибудь сделать.
Мне так надоело, что болит колено, это сильно мешает, хотя вроде уже лучше, потому что сколько-то дней назад был момент, когда надо было опуститься на корточки, и это было внезапно очень больно и я чуть не упал на колени, а сейчас почти спокойно могу это сделать. Но всё ещё больно разгибать, если нога долго была согнута.
За что мне конкретно вот это, я же с этой ногой ничего не делал, она просто внезапно начала болеть.
977 Кб, 1414x2000Я снова ничего почти не сделал, одну лабу мою по физике не фига не приняли, а вторую не смотрели, опять мерили какую-то странную штуку.
По алгоритмам сегодня было много про 2-3 деревья и про красно чёрмные, но я, если честно, не слушал почти, потому что надо было доделать микроэлектронику на завтра и у меня не вышло сделать это быстро. Поэтому очень мало, что понял. Вроде там было конкретно про left-leaning RB деревья. В любом случае потом разбираться ещё придётся и тут не так просто как с авл получится.
Сегодня я куда-то ходил. Сегодня я доделал микроэлектронику, там ничего особенного не было, я выше говорил, сделал домашку по алгоритмам, там было авл дерево. Сегодня я что-нибудь ещё (не путать с ничего больше) не сделал.
Я больше ничего не могу вспомнить, как будто ничего не было, просто, вот, прошло же двадцать четыре часа, а ничего. А, вот я понял, что хоть выше и писал, что круто, что в манкрафте можно свечи диспенсером зажигать, а без MBE непонятно, как это реализовать так, чтобы механизм зажигания прятался, скажем, в стене. Хотя, может, можно выстрелом фаер чарджа сделать это, не уверен, что так сработает и мне лень пробовать самому, мне нравится смотреть как подобные вещи делают другие люди https://youtu.be/PDSPwoZXOko
Заставил стиральную машину постирать мои вещи.
Почистил зубы и сейчас надо лечь спать.
Завтра надо куда-то идти. Завтра надо посмотреть физику. Завтра надо что-нибудь ещё сделать. Возможно, надо сделать домашку по английскому на субботу.
Я ничего не хочу, я хочу лежать и ничего не делать. На улице холодно, не хочу ходить на улицу, потому что надо надевать неудобную одежду, чтобы не заболеть слеш не умереть от холода слеш от последствий хождения на морозе без специальной одежды.
По алгоритмам сегодня было много про 2-3 деревья и про красно чёрмные, но я, если честно, не слушал почти, потому что надо было доделать микроэлектронику на завтра и у меня не вышло сделать это быстро. Поэтому очень мало, что понял. Вроде там было конкретно про left-leaning RB деревья. В любом случае потом разбираться ещё придётся и тут не так просто как с авл получится.
Сегодня я куда-то ходил. Сегодня я доделал микроэлектронику, там ничего особенного не было, я выше говорил, сделал домашку по алгоритмам, там было авл дерево. Сегодня я что-нибудь ещё (не путать с ничего больше) не сделал.
Я больше ничего не могу вспомнить, как будто ничего не было, просто, вот, прошло же двадцать четыре часа, а ничего. А, вот я понял, что хоть выше и писал, что круто, что в манкрафте можно свечи диспенсером зажигать, а без MBE непонятно, как это реализовать так, чтобы механизм зажигания прятался, скажем, в стене. Хотя, может, можно выстрелом фаер чарджа сделать это, не уверен, что так сработает и мне лень пробовать самому, мне нравится смотреть как подобные вещи делают другие люди https://youtu.be/PDSPwoZXOko
Заставил стиральную машину постирать мои вещи.
Почистил зубы и сейчас надо лечь спать.
Завтра надо куда-то идти. Завтра надо посмотреть физику. Завтра надо что-нибудь ещё сделать. Возможно, надо сделать домашку по английскому на субботу.
Я ничего не хочу, я хочу лежать и ничего не делать. На улице холодно, не хочу ходить на улицу, потому что надо надевать неудобную одежду, чтобы не заболеть слеш не умереть от холода слеш от последствий хождения на морозе без специальной одежды.
Не могу опять ничего не хочется , пусть уже всё закончится, я устал. Pixi.JS выглядит интересно, но чёто лагает (мику, конечно, не лагает, а всякие более-менее тяжёлые демки уже да) в фаерфоксе по крайней мере на линупсе, на винде не пробовал. И вообще он пишет, что WebGL context was lost, непонятно, что это конкретно означает. А в хроме нормально.
Было бы прикольно сделать это
https://youtu.be/mhjuuHl6qHM
https://en.wikipedia.org/wiki/Boids
но в 3д. Там особой нет разницы нет в плане реализации логики: основная суть в том, что ты вычисляешь три вектора силы (separation - чтобы они держали дистанцию между друг другом и не сливались в одну точку, alignment - чтобы летели в одном направлении, cohesion - чтобы держались вместе) на основе локальных данных для каждой птички и применяешь их к ним. Так что без разницы вроде же, какой размерности будут там векторы. И можно ещё добавить приколов вроде препятствий и хищников, которых они будут избегать. И ещё надо будет впихнуть туда разделение пространства, чтобы не перебирать всех со всеми и можно было хоть тысчу птичек запустить. И, возможно, можно ещё какие-то правила добавлять, например, вот в видео он предлагает, чтобы прямо перед тобой не было никого, тогда они будут не роиться (ну, неправильно, наверное, это роением называть, но неважно), а выстраиваться в что-то вроде клина с вожаком.
А я чего-то подумал, ну, я же вроде хотел в опенгл, но попробовал и быстро забил и вообще должен был бы наверное хотеть в вулкан. Но, короче, подумал, почему бы не попробовать вспомнить хотя бы как делать кубик в вебгл, чтобы прямо в браузере. И не фига не вышло из этого хорошего, я текстурированный треугольник нарисовал только, мда, и про такое узнал https://en.wikipedia.org/wiki/Kernel_(image_processing). А я думал вообще webgpu попробовать посмотреть, но он вроде ещё только в firefox nightly / chrome canary есть, а смысл тогда вообще это делать, если придётся скачивать особый браузер, чтобы посмотреть. Да и мне бы просто сейчас хотя бы с каким-то рендеринг апи разо браться.
В js промисы интересно, можно собирать последовательность коллбеков. В джамбе чёто похожее тоже есть, но в js уместнее, там же постоянно какая то асинхронная ерунда: запрос туда сделать, файл отсюда загрузить и так далее, так что даже обсыпали это сахаром (async/await). Неудобно, что в vscode (и скорее всего в любой другой иде) не работают подсказки, но можно писать такое для аргументов функций /＊＊ @param {type} argName ＊/ и тогда они будут. Или писать на тайпскрипте, но я не хочу, это вроде какая-то унылая надстройка с более строгой типизацией.
И я так подумал, что, наверное, толку от того, что я буду сначала с рендеринг апи разбираться и только потом птичек этих делать, что, короче, проще будет сейчас прямо тупо взять какой-нибудь даже не pixi.js, в котором пришлось бы работать с VBO и прочим таким, скорее всего, а three.js, чтобы сразу всё готовое, и конкретно уже с птичками разбираться.
С моим хотением что-либо делать рабочий вариант можно ожидать примерно через три месяца.
https://youtu.be/mhjuuHl6qHM
https://en.wikipedia.org/wiki/Boids
но в 3д. Там особой нет разницы нет в плане реализации логики: основная суть в том, что ты вычисляешь три вектора силы (separation - чтобы они держали дистанцию между друг другом и не сливались в одну точку, alignment - чтобы летели в одном направлении, cohesion - чтобы держались вместе) на основе локальных данных для каждой птички и применяешь их к ним. Так что без разницы вроде же, какой размерности будут там векторы. И можно ещё добавить приколов вроде препятствий и хищников, которых они будут избегать. И ещё надо будет впихнуть туда разделение пространства, чтобы не перебирать всех со всеми и можно было хоть тысчу птичек запустить. И, возможно, можно ещё какие-то правила добавлять, например, вот в видео он предлагает, чтобы прямо перед тобой не было никого, тогда они будут не роиться (ну, неправильно, наверное, это роением называть, но неважно), а выстраиваться в что-то вроде клина с вожаком.
А я чего-то подумал, ну, я же вроде хотел в опенгл, но попробовал и быстро забил и вообще должен был бы наверное хотеть в вулкан. Но, короче, подумал, почему бы не попробовать вспомнить хотя бы как делать кубик в вебгл, чтобы прямо в браузере. И не фига не вышло из этого хорошего, я текстурированный треугольник нарисовал только, мда, и про такое узнал https://en.wikipedia.org/wiki/Kernel_(image_processing). А я думал вообще webgpu попробовать посмотреть, но он вроде ещё только в firefox nightly / chrome canary есть, а смысл тогда вообще это делать, если придётся скачивать особый браузер, чтобы посмотреть. Да и мне бы просто сейчас хотя бы с каким-то рендеринг апи разо браться.
В js промисы интересно, можно собирать последовательность коллбеков. В джамбе чёто похожее тоже есть, но в js уместнее, там же постоянно какая то асинхронная ерунда: запрос туда сделать, файл отсюда загрузить и так далее, так что даже обсыпали это сахаром (async/await). Неудобно, что в vscode (и скорее всего в любой другой иде) не работают подсказки, но можно писать такое для аргументов функций /＊＊ @param {type} argName ＊/ и тогда они будут. Или писать на тайпскрипте, но я не хочу, это вроде какая-то унылая надстройка с более строгой типизацией.
И я так подумал, что, наверное, толку от того, что я буду сначала с рендеринг апи разбираться и только потом птичек этих делать, что, короче, проще будет сейчас прямо тупо взять какой-нибудь даже не pixi.js, в котором пришлось бы работать с VBO и прочим таким, скорее всего, а three.js, чтобы сразу всё готовое, и конкретно уже с птичками разбираться.
С моим хотением что-либо делать рабочий вариант можно ожидать примерно через три месяца.
Было бы прикольно сделать это
https://youtu.be/mhjuuHl6qHM
https://en.wikipedia.org/wiki/Boids
но в 3д. Там особой нет разницы нет в плане реализации логики: основная суть в том, что ты вычисляешь три вектора силы (separation - чтобы они держали дистанцию между друг другом и не сливались в одну точку, alignment - чтобы летели в одном направлении, cohesion - чтобы держались вместе) на основе локальных данных для каждой птички и применяешь их к ним. Так что без разницы вроде же, какой размерности будут там векторы. И можно ещё добавить приколов вроде препятствий и хищников, которых они будут избегать. И ещё надо будет впихнуть туда разделение пространства, чтобы не перебирать всех со всеми и можно было хоть тысчу птичек запустить. И, возможно, можно ещё какие-то правила добавлять, например, вот в видео он предлагает, чтобы прямо перед тобой не было никого, тогда они будут не роиться (ну, неправильно, наверное, это роением называть, но неважно), а выстраиваться в что-то вроде клина с вожаком.
А я чего-то подумал, ну, я же вроде хотел в опенгл, но попробовал и быстро забил и вообще должен был бы наверное хотеть в вулкан. Но, короче, подумал, почему бы не попробовать вспомнить хотя бы как делать кубик в вебгл, чтобы прямо в браузере. И не фига не вышло из этого хорошего, я текстурированный треугольник нарисовал только, мда, и про такое узнал https://en.wikipedia.org/wiki/Kernel_(image_processing). А я думал вообще webgpu попробовать посмотреть, но он вроде ещё только в firefox nightly / chrome canary есть, а смысл тогда вообще это делать, если придётся скачивать особый браузер, чтобы посмотреть. Да и мне бы просто сейчас хотя бы с каким-то рендеринг апи разо браться.
В js промисы интересно, можно собирать последовательность коллбеков. В джамбе чёто похожее тоже есть, но в js уместнее, там же постоянно какая то асинхронная ерунда: запрос туда сделать, файл отсюда загрузить и так далее, так что даже обсыпали это сахаром (async/await). Неудобно, что в vscode (и скорее всего в любой другой иде) не работают подсказки, но можно писать такое для аргументов функций /＊＊ @param {type} argName ＊/ и тогда они будут. Или писать на тайпскрипте, но я не хочу, это вроде какая-то унылая надстройка с более строгой типизацией.
И я так подумал, что, наверное, толку от того, что я буду сначала с рендеринг апи разбираться и только потом птичек этих делать, что, короче, проще будет сейчас прямо тупо взять какой-нибудь даже не pixi.js, в котором пришлось бы работать с VBO и прочим таким, скорее всего, а three.js, чтобы сразу всё готовое, и конкретно уже с птичками разбираться.
С моим хотением что-либо делать рабочий вариант можно ожидать примерно через три месяца.
https://youtu.be/mhjuuHl6qHM
https://en.wikipedia.org/wiki/Boids
но в 3д. Там особой нет разницы нет в плане реализации логики: основная суть в том, что ты вычисляешь три вектора силы (separation - чтобы они держали дистанцию между друг другом и не сливались в одну точку, alignment - чтобы летели в одном направлении, cohesion - чтобы держались вместе) на основе локальных данных для каждой птички и применяешь их к ним. Так что без разницы вроде же, какой размерности будут там векторы. И можно ещё добавить приколов вроде препятствий и хищников, которых они будут избегать. И ещё надо будет впихнуть туда разделение пространства, чтобы не перебирать всех со всеми и можно было хоть тысчу птичек запустить. И, возможно, можно ещё какие-то правила добавлять, например, вот в видео он предлагает, чтобы прямо перед тобой не было никого, тогда они будут не роиться (ну, неправильно, наверное, это роением называть, но неважно), а выстраиваться в что-то вроде клина с вожаком.
А я чего-то подумал, ну, я же вроде хотел в опенгл, но попробовал и быстро забил и вообще должен был бы наверное хотеть в вулкан. Но, короче, подумал, почему бы не попробовать вспомнить хотя бы как делать кубик в вебгл, чтобы прямо в браузере. И не фига не вышло из этого хорошего, я текстурированный треугольник нарисовал только, мда, и про такое узнал https://en.wikipedia.org/wiki/Kernel_(image_processing). А я думал вообще webgpu попробовать посмотреть, но он вроде ещё только в firefox nightly / chrome canary есть, а смысл тогда вообще это делать, если придётся скачивать особый браузер, чтобы посмотреть. Да и мне бы просто сейчас хотя бы с каким-то рендеринг апи разо браться.
В js промисы интересно, можно собирать последовательность коллбеков. В джамбе чёто похожее тоже есть, но в js уместнее, там же постоянно какая то асинхронная ерунда: запрос туда сделать, файл отсюда загрузить и так далее, так что даже обсыпали это сахаром (async/await). Неудобно, что в vscode (и скорее всего в любой другой иде) не работают подсказки, но можно писать такое для аргументов функций /＊＊ @param {type} argName ＊/ и тогда они будут. Или писать на тайпскрипте, но я не хочу, это вроде какая-то унылая надстройка с более строгой типизацией.
И я так подумал, что, наверное, толку от того, что я буду сначала с рендеринг апи разбираться и только потом птичек этих делать, что, короче, проще будет сейчас прямо тупо взять какой-нибудь даже не pixi.js, в котором пришлось бы работать с VBO и прочим таким, скорее всего, а three.js, чтобы сразу всё готовое, и конкретно уже с птичками разбираться.
С моим хотением что-либо делать рабочий вариант можно ожидать примерно через три месяца.
388 Кб, 1240x1242>>22989
!!! ОХУЕННАЯ ЕБАТЬ В РОТ ИДЕЯ, ТОЛЬКО ЧТО ПРИДУМАЛ !!!
(UPD: А, чёрт, посмотрел-таки видео, там это в конце первым пунктом доделок и упоминается, ну да ладно.)
Положим, у тебя есть массив БОЙДОВ и их нужно всех апдейтнуть. Положим состоянием БОЙДА позицию. При апдейте БОЙД смотрит на позиции других БОЙДОВ.
Проблема в том, что при апдейте мы меняем позицию БОЙДА, и апдейтящиеся после этого будут видеть сдвинутую, а апдейтившиеся до этого видели исходную. Так что порядок апдейтов будет слегка менять поведение. Кроме того, это препятствует распараллеливанию.
Что же делать?
Всё просто. Нам нужны ДВА массива бойдов: ТЕКУЩИЙ и НОВЫЙ. Все смотрят на ТЕКУЩИЙ, а пишут в НОВЫЙ. В конце кадра НОВЫЙ заменяет ТЕКУЩИЙ.
Если апдейтятся все элементы, то можно не руками переписывать НОВЫЙ в ТЕКУЩИЙ, а просто поменять ссылки местами.
Ну, либо, наверное, лучше не делать 2 копии сцены, а просто все значения, на которые могут СМОТРЕТЬ другие, хранить в 2 экземплярах — «текущие» и «новые», и после всех апдейтов переносить «новые» в «текущие».
Ещё такой интересный вариант. Всеми подобными значениями-в-двух-версиях заведует специальный менеджер: https://ideone.com/5p1fGk. Это мудрёное, зато, типа, ПРОМЫШЛЕННОЕ решение. Чтобы избежать синхронизации и не превращать менеджер в высококонкурентно синхронизируемый объект, предполагается, что ты не будешь смешивать добавление/удаление и Get/Set — иными словами, если апдейт хочет создать новый объект или удалить существующий, то создание и удаление не исполняются немедленно, а откладываются до CommitFrame. Ты в любом случае захочешь это делать, т. к. добавленные и удалённые объекты — это, как и обновлённые позиции существующих, «new»-информация.
Алсо, я так примерно почувствовал, что у мужичка в конце ошибка: он не должен был делать setMag(maxSpeed) для разделения, и сама проблема с дёргаными бойдами вылезла исключительно из-за этого (или 50:50 с ошибкой из закреплённого комментария), а не из-за 1 массива.
Шесть лет, шесть долгих лет я пытался вспомнить этот термин...
!!! ОХУЕННАЯ ЕБАТЬ В РОТ ИДЕЯ, ТОЛЬКО ЧТО ПРИДУМАЛ !!!
(UPD: А, чёрт, посмотрел-таки видео, там это в конце первым пунктом доделок и упоминается, ну да ладно.)
Положим, у тебя есть массив БОЙДОВ и их нужно всех апдейтнуть. Положим состоянием БОЙДА позицию. При апдейте БОЙД смотрит на позиции других БОЙДОВ.
Проблема в том, что при апдейте мы меняем позицию БОЙДА, и апдейтящиеся после этого будут видеть сдвинутую, а апдейтившиеся до этого видели исходную. Так что порядок апдейтов будет слегка менять поведение. Кроме того, это препятствует распараллеливанию.
Что же делать?
Всё просто. Нам нужны ДВА массива бойдов: ТЕКУЩИЙ и НОВЫЙ. Все смотрят на ТЕКУЩИЙ, а пишут в НОВЫЙ. В конце кадра НОВЫЙ заменяет ТЕКУЩИЙ.
Если апдейтятся все элементы, то можно не руками переписывать НОВЫЙ в ТЕКУЩИЙ, а просто поменять ссылки местами.
Ну, либо, наверное, лучше не делать 2 копии сцены, а просто все значения, на которые могут СМОТРЕТЬ другие, хранить в 2 экземплярах — «текущие» и «новые», и после всех апдейтов переносить «новые» в «текущие».
Ещё такой интересный вариант. Всеми подобными значениями-в-двух-версиях заведует специальный менеджер: https://ideone.com/5p1fGk. Это мудрёное, зато, типа, ПРОМЫШЛЕННОЕ решение. Чтобы избежать синхронизации и не превращать менеджер в высококонкурентно синхронизируемый объект, предполагается, что ты не будешь смешивать добавление/удаление и Get/Set — иными словами, если апдейт хочет создать новый объект или удалить существующий, то создание и удаление не исполняются немедленно, а откладываются до CommitFrame. Ты в любом случае захочешь это делать, т. к. добавленные и удалённые объекты — это, как и обновлённые позиции существующих, «new»-информация.
Алсо, я так примерно почувствовал, что у мужичка в конце ошибка: он не должен был делать setMag(maxSpeed) для разделения, и сама проблема с дёргаными бойдами вылезла исключительно из-за этого (или 50:50 с ошибкой из закреплённого комментария), а не из-за 1 массива.
>эмерджентность
Шесть лет, шесть долгих лет я пытался вспомнить этот термин...
388 Кб, 1240x1242>>22989
!!! ОХУЕННАЯ ЕБАТЬ В РОТ ИДЕЯ, ТОЛЬКО ЧТО ПРИДУМАЛ !!!
(UPD: А, чёрт, посмотрел-таки видео, там это в конце первым пунктом доделок и упоминается, ну да ладно.)
Положим, у тебя есть массив БОЙДОВ и их нужно всех апдейтнуть. Положим состоянием БОЙДА позицию. При апдейте БОЙД смотрит на позиции других БОЙДОВ.
Проблема в том, что при апдейте мы меняем позицию БОЙДА, и апдейтящиеся после этого будут видеть сдвинутую, а апдейтившиеся до этого видели исходную. Так что порядок апдейтов будет слегка менять поведение. Кроме того, это препятствует распараллеливанию.
Что же делать?
Всё просто. Нам нужны ДВА массива бойдов: ТЕКУЩИЙ и НОВЫЙ. Все смотрят на ТЕКУЩИЙ, а пишут в НОВЫЙ. В конце кадра НОВЫЙ заменяет ТЕКУЩИЙ.
Если апдейтятся все элементы, то можно не руками переписывать НОВЫЙ в ТЕКУЩИЙ, а просто поменять ссылки местами.
Ну, либо, наверное, лучше не делать 2 копии сцены, а просто все значения, на которые могут СМОТРЕТЬ другие, хранить в 2 экземплярах — «текущие» и «новые», и после всех апдейтов переносить «новые» в «текущие».
Ещё такой интересный вариант. Всеми подобными значениями-в-двух-версиях заведует специальный менеджер: https://ideone.com/5p1fGk. Это мудрёное, зато, типа, ПРОМЫШЛЕННОЕ решение. Чтобы избежать синхронизации и не превращать менеджер в высококонкурентно синхронизируемый объект, предполагается, что ты не будешь смешивать добавление/удаление и Get/Set — иными словами, если апдейт хочет создать новый объект или удалить существующий, то создание и удаление не исполняются немедленно, а откладываются до CommitFrame. Ты в любом случае захочешь это делать, т. к. добавленные и удалённые объекты — это, как и обновлённые позиции существующих, «new»-информация.
Алсо, я так примерно почувствовал, что у мужичка в конце ошибка: он не должен был делать setMag(maxSpeed) для разделения, и сама проблема с дёргаными бойдами вылезла исключительно из-за этого (или 50:50 с ошибкой из закреплённого комментария), а не из-за 1 массива.
Шесть лет, шесть долгих лет я пытался вспомнить этот термин...
!!! ОХУЕННАЯ ЕБАТЬ В РОТ ИДЕЯ, ТОЛЬКО ЧТО ПРИДУМАЛ !!!
(UPD: А, чёрт, посмотрел-таки видео, там это в конце первым пунктом доделок и упоминается, ну да ладно.)
Положим, у тебя есть массив БОЙДОВ и их нужно всех апдейтнуть. Положим состоянием БОЙДА позицию. При апдейте БОЙД смотрит на позиции других БОЙДОВ.
Проблема в том, что при апдейте мы меняем позицию БОЙДА, и апдейтящиеся после этого будут видеть сдвинутую, а апдейтившиеся до этого видели исходную. Так что порядок апдейтов будет слегка менять поведение. Кроме того, это препятствует распараллеливанию.
Что же делать?
Всё просто. Нам нужны ДВА массива бойдов: ТЕКУЩИЙ и НОВЫЙ. Все смотрят на ТЕКУЩИЙ, а пишут в НОВЫЙ. В конце кадра НОВЫЙ заменяет ТЕКУЩИЙ.
Если апдейтятся все элементы, то можно не руками переписывать НОВЫЙ в ТЕКУЩИЙ, а просто поменять ссылки местами.
Ну, либо, наверное, лучше не делать 2 копии сцены, а просто все значения, на которые могут СМОТРЕТЬ другие, хранить в 2 экземплярах — «текущие» и «новые», и после всех апдейтов переносить «новые» в «текущие».
Ещё такой интересный вариант. Всеми подобными значениями-в-двух-версиях заведует специальный менеджер: https://ideone.com/5p1fGk. Это мудрёное, зато, типа, ПРОМЫШЛЕННОЕ решение. Чтобы избежать синхронизации и не превращать менеджер в высококонкурентно синхронизируемый объект, предполагается, что ты не будешь смешивать добавление/удаление и Get/Set — иными словами, если апдейт хочет создать новый объект или удалить существующий, то создание и удаление не исполняются немедленно, а откладываются до CommitFrame. Ты в любом случае захочешь это делать, т. к. добавленные и удалённые объекты — это, как и обновлённые позиции существующих, «new»-информация.
Алсо, я так примерно почувствовал, что у мужичка в конце ошибка: он не должен был делать setMag(maxSpeed) для разделения, и сама проблема с дёргаными бойдами вылезла исключительно из-за этого (или 50:50 с ошибкой из закреплённого комментария), а не из-за 1 массива.
>эмерджентность
Шесть лет, шесть долгих лет я пытался вспомнить этот термин...
381 Кб, 1630x2047>>23002
Хм, да.
Почему этот твой паскаль такой непонятный: какие-то Reference, IInterface, TInterfacedObject и что это означает - непонятно. Вообще непонятно, что за >подсчёт ссылок, зачем он нужен, и зачем эти штуки с суффиксами -life. Но сама идея сделать штуку, которая будет менеджить старые и новые значения, примерно по нятна, да.
Мудро.
Возможно. Ну и плюс да, то, что все окружающие птички в радиусе восприятия действуют на тебя одинаково из-за того, про то что в закреплённом комментарии. Хотя всё равно не очень понимаю: типа дёргаются из-за того, что слишком мощная сила разделения? И малейшие изменения в окружении заставляют птичку резко подстраиваться под них.
Кстати, на видео плохо видно, но у меня такое ощущение, что колбасятся в том числе отдельно летящие птички, которые в теории должны были бы просто по прямой лететь, потому что у них нет никого рядом в радиусе восприятия. Так что, может, проблема вообще в чём-то другом.
>Если апдейтятся все элементы, то можно не руками переписывать НОВЫЙ в ТЕКУЩИЙ, а просто поменять ссылки местами.
Хм, да.
Почему этот твой паскаль такой непонятный: какие-то Reference, IInterface, TInterfacedObject и что это означает - непонятно. Вообще непонятно, что за >подсчёт ссылок, зачем он нужен, и зачем эти штуки с суффиксами -life. Но сама идея сделать штуку, которая будет менеджить старые и новые значения, примерно по нятна, да.
>добавленные и удалённые объекты — это, как и обновлённые позиции существующих, «new»-информация
Мудро.
>он не должен был делать setMag(maxSpeed) для разделения
Возможно. Ну и плюс да, то, что все окружающие птички в радиусе восприятия действуют на тебя одинаково из-за того, про то что в закреплённом комментарии. Хотя всё равно не очень понимаю: типа дёргаются из-за того, что слишком мощная сила разделения? И малейшие изменения в окружении заставляют птичку резко подстраиваться под них.
Кстати, на видео плохо видно, но у меня такое ощущение, что колбасятся в том числе отдельно летящие птички, которые в теории должны были бы просто по прямой лететь, потому что у них нет никого рядом в радиусе восприятия. Так что, может, проблема вообще в чём-то другом.
1,6 Мб, 1345x1690>>23036
Пушо долбоёбы.
В паскале есть НЕУПРАВЛЯЕМЫЕ и УПРАВЛЯЕМЫЕ типы, по сути эквивалент POD / не-POD в C++. НЕУПРАВЛЯЕМЫЕ типы — это сырые блоки памяти, которые можно копировать через Move(), а у УПРАВЛЯЕМЫХ есть логика инициализации, финализации и копирования: например, переменная типа string является динамически выделенной CoW-строкой, и код вида
var a, b: string;
begin
...
a := b;
...
end;
развернётся в
var a, b: string;
begin
pointer(a) := nil; pointer(b) := nil;
try
...
_string_release(a); _string_addref(b); pointer(a) := pointer(b);
...
finally
_string_release(a); _string_release(b);
end;
end;
Тогда как НЕУПРАВЛЯЕМАЯ локальная переменная, пока ей ничего не присваивалось, содержит мусор.
Аналогично строки-поля класса инициализируются в ходе создания объекта и финализируются в ходе уничтожения.
Переменные классовых типов (var x: TMyObject, где type TMyObject = class ... end) являются НЕУПРАВЛЯЕМЫМИ — простыми указателями. Их нужно уничтожать и, если нужно, занулять вручную:
var
x, y: TMyObject;
begin
x := TMyObject.Create;
try
...
y := x;
...
finally
x.Free; // теперь x и y — висячие указатели
end;
end;
А вот к управляемым типам относятся также ИНТЕРФЕЙСНЫЕ ССЫЛКИ (переменные типа ISomeInterface = interface ... end), почему — см. первое предложение (объединены два несвязанных механизма, интерфейсы и подсчёт ссылок). Интерфейсы подразумевают подсчёт ссылок: IInterface — неявный общий предок всех интерфейсов, ИНТЕРФЕЙСНЫЕ ССЫЛКИ при присваивании им интерфейса дёргают IInterface.AddRef, при расприсваивании (присваивании другого или финализации) — IInterface.Release.
TInterfacedObject реализует IInterface, хранит внутри себя счётчик ссылок, реализует AddRef как atomic_inc(refcount), а Release — как if atomic_dec(refcount) = 0 then Destroy, так что удобен как базовый тип для объектов с подсчётом ссылок.
Поэтому если мы используем фишку с life, мы избавляемся от ручного уничтожения объектов и при этом, храня и нормальную ссылку на объект, можем по-прежнему работать с ней по-человечески, не переходя на чистые интерфейсы:
var
x: TMyObject;
xLife: IInterface;
begin
x := TMyObject.Create; xLife := x;
...
end;
распишется в
var
x: TMyObject;
xLife: IInterface;
begin
x := TMyObject.Create; x.AddRef; // refcount = 1
try
...
finally
x.Release; // refcount = 0, x.Destroy
end;
end;
Так никто не делает, я это сам придумал. Все либо работают с классовой переменной и ебутся с ручным уничтожением (нетривиальным при передаче владения и тем более расшаривании), либо работают с интерфейсной переменной и получают необходимость вводить для каждого класса бойлерплейтный зеркальный интерфейс (IMyObject), а также оверхед на косвенный вызов на каждый чих.
Почему этот твой паскаль... ой, ща, подожди, мусор соберётся... такой непонятный.
Потому что для птички странно разлетаться всегда с максимальным усердием, что её заставляет делать setMag, мне кажется.
Пушо долбоёбы.
В паскале есть НЕУПРАВЛЯЕМЫЕ и УПРАВЛЯЕМЫЕ типы, по сути эквивалент POD / не-POD в C++. НЕУПРАВЛЯЕМЫЕ типы — это сырые блоки памяти, которые можно копировать через Move(), а у УПРАВЛЯЕМЫХ есть логика инициализации, финализации и копирования: например, переменная типа string является динамически выделенной CoW-строкой, и код вида
var a, b: string;
begin
...
a := b;
...
end;
развернётся в
var a, b: string;
begin
pointer(a) := nil; pointer(b) := nil;
try
...
_string_release(a); _string_addref(b); pointer(a) := pointer(b);
...
finally
_string_release(a); _string_release(b);
end;
end;
Тогда как НЕУПРАВЛЯЕМАЯ локальная переменная, пока ей ничего не присваивалось, содержит мусор.
Аналогично строки-поля класса инициализируются в ходе создания объекта и финализируются в ходе уничтожения.
Переменные классовых типов (var x: TMyObject, где type TMyObject = class ... end) являются НЕУПРАВЛЯЕМЫМИ — простыми указателями. Их нужно уничтожать и, если нужно, занулять вручную:
var
x, y: TMyObject;
begin
x := TMyObject.Create;
try
...
y := x;
...
finally
x.Free; // теперь x и y — висячие указатели
end;
end;
А вот к управляемым типам относятся также ИНТЕРФЕЙСНЫЕ ССЫЛКИ (переменные типа ISomeInterface = interface ... end), почему — см. первое предложение (объединены два несвязанных механизма, интерфейсы и подсчёт ссылок). Интерфейсы подразумевают подсчёт ссылок: IInterface — неявный общий предок всех интерфейсов, ИНТЕРФЕЙСНЫЕ ССЫЛКИ при присваивании им интерфейса дёргают IInterface.AddRef, при расприсваивании (присваивании другого или финализации) — IInterface.Release.
TInterfacedObject реализует IInterface, хранит внутри себя счётчик ссылок, реализует AddRef как atomic_inc(refcount), а Release — как if atomic_dec(refcount) = 0 then Destroy, так что удобен как базовый тип для объектов с подсчётом ссылок.
Поэтому если мы используем фишку с life, мы избавляемся от ручного уничтожения объектов и при этом, храня и нормальную ссылку на объект, можем по-прежнему работать с ней по-человечески, не переходя на чистые интерфейсы:
var
x: TMyObject;
xLife: IInterface;
begin
x := TMyObject.Create; xLife := x;
...
end;
распишется в
var
x: TMyObject;
xLife: IInterface;
begin
x := TMyObject.Create; x.AddRef; // refcount = 1
try
...
finally
x.Release; // refcount = 0, x.Destroy
end;
end;
Так никто не делает, я это сам придумал. Все либо работают с классовой переменной и ебутся с ручным уничтожением (нетривиальным при передаче владения и тем более расшаривании), либо работают с интерфейсной переменной и получают необходимость вводить для каждого класса бойлерплейтный зеркальный интерфейс (IMyObject), а также оверхед на косвенный вызов на каждый чих.
>Почему этот твой паскаль такой непонятный.
Почему этот твой паскаль... ой, ща, подожди, мусор соберётся... такой непонятный.
>типа дёргаются из-за того, что слишком мощная сила разделения
Потому что для птички странно разлетаться всегда с максимальным усердием, что её заставляет делать setMag, мне кажется.
1,6 Мб, 1345x1690>>23036
Пушо долбоёбы.
В паскале есть НЕУПРАВЛЯЕМЫЕ и УПРАВЛЯЕМЫЕ типы, по сути эквивалент POD / не-POD в C++. НЕУПРАВЛЯЕМЫЕ типы — это сырые блоки памяти, которые можно копировать через Move(), а у УПРАВЛЯЕМЫХ есть логика инициализации, финализации и копирования: например, переменная типа string является динамически выделенной CoW-строкой, и код вида
var a, b: string;
begin
...
a := b;
...
end;
развернётся в
var a, b: string;
begin
pointer(a) := nil; pointer(b) := nil;
try
...
_string_release(a); _string_addref(b); pointer(a) := pointer(b);
...
finally
_string_release(a); _string_release(b);
end;
end;
Тогда как НЕУПРАВЛЯЕМАЯ локальная переменная, пока ей ничего не присваивалось, содержит мусор.
Аналогично строки-поля класса инициализируются в ходе создания объекта и финализируются в ходе уничтожения.
Переменные классовых типов (var x: TMyObject, где type TMyObject = class ... end) являются НЕУПРАВЛЯЕМЫМИ — простыми указателями. Их нужно уничтожать и, если нужно, занулять вручную:
var
x, y: TMyObject;
begin
x := TMyObject.Create;
try
...
y := x;
...
finally
x.Free; // теперь x и y — висячие указатели
end;
end;
А вот к управляемым типам относятся также ИНТЕРФЕЙСНЫЕ ССЫЛКИ (переменные типа ISomeInterface = interface ... end), почему — см. первое предложение (объединены два несвязанных механизма, интерфейсы и подсчёт ссылок). Интерфейсы подразумевают подсчёт ссылок: IInterface — неявный общий предок всех интерфейсов, ИНТЕРФЕЙСНЫЕ ССЫЛКИ при присваивании им интерфейса дёргают IInterface.AddRef, при расприсваивании (присваивании другого или финализации) — IInterface.Release.
TInterfacedObject реализует IInterface, хранит внутри себя счётчик ссылок, реализует AddRef как atomic_inc(refcount), а Release — как if atomic_dec(refcount) = 0 then Destroy, так что удобен как базовый тип для объектов с подсчётом ссылок.
Поэтому если мы используем фишку с life, мы избавляемся от ручного уничтожения объектов и при этом, храня и нормальную ссылку на объект, можем по-прежнему работать с ней по-человечески, не переходя на чистые интерфейсы:
var
x: TMyObject;
xLife: IInterface;
begin
x := TMyObject.Create; xLife := x;
...
end;
распишется в
var
x: TMyObject;
xLife: IInterface;
begin
x := TMyObject.Create; x.AddRef; // refcount = 1
try
...
finally
x.Release; // refcount = 0, x.Destroy
end;
end;
Так никто не делает, я это сам придумал. Все либо работают с классовой переменной и ебутся с ручным уничтожением (нетривиальным при передаче владения и тем более расшаривании), либо работают с интерфейсной переменной и получают необходимость вводить для каждого класса бойлерплейтный зеркальный интерфейс (IMyObject), а также оверхед на косвенный вызов на каждый чих.
Почему этот твой паскаль... ой, ща, подожди, мусор соберётся... такой непонятный.
Потому что для птички странно разлетаться всегда с максимальным усердием, что её заставляет делать setMag, мне кажется.
Пушо долбоёбы.
В паскале есть НЕУПРАВЛЯЕМЫЕ и УПРАВЛЯЕМЫЕ типы, по сути эквивалент POD / не-POD в C++. НЕУПРАВЛЯЕМЫЕ типы — это сырые блоки памяти, которые можно копировать через Move(), а у УПРАВЛЯЕМЫХ есть логика инициализации, финализации и копирования: например, переменная типа string является динамически выделенной CoW-строкой, и код вида
var a, b: string;
begin
...
a := b;
...
end;
развернётся в
var a, b: string;
begin
pointer(a) := nil; pointer(b) := nil;
try
...
_string_release(a); _string_addref(b); pointer(a) := pointer(b);
...
finally
_string_release(a); _string_release(b);
end;
end;
Тогда как НЕУПРАВЛЯЕМАЯ локальная переменная, пока ей ничего не присваивалось, содержит мусор.
Аналогично строки-поля класса инициализируются в ходе создания объекта и финализируются в ходе уничтожения.
Переменные классовых типов (var x: TMyObject, где type TMyObject = class ... end) являются НЕУПРАВЛЯЕМЫМИ — простыми указателями. Их нужно уничтожать и, если нужно, занулять вручную:
var
x, y: TMyObject;
begin
x := TMyObject.Create;
try
...
y := x;
...
finally
x.Free; // теперь x и y — висячие указатели
end;
end;
А вот к управляемым типам относятся также ИНТЕРФЕЙСНЫЕ ССЫЛКИ (переменные типа ISomeInterface = interface ... end), почему — см. первое предложение (объединены два несвязанных механизма, интерфейсы и подсчёт ссылок). Интерфейсы подразумевают подсчёт ссылок: IInterface — неявный общий предок всех интерфейсов, ИНТЕРФЕЙСНЫЕ ССЫЛКИ при присваивании им интерфейса дёргают IInterface.AddRef, при расприсваивании (присваивании другого или финализации) — IInterface.Release.
TInterfacedObject реализует IInterface, хранит внутри себя счётчик ссылок, реализует AddRef как atomic_inc(refcount), а Release — как if atomic_dec(refcount) = 0 then Destroy, так что удобен как базовый тип для объектов с подсчётом ссылок.
Поэтому если мы используем фишку с life, мы избавляемся от ручного уничтожения объектов и при этом, храня и нормальную ссылку на объект, можем по-прежнему работать с ней по-человечески, не переходя на чистые интерфейсы:
var
x: TMyObject;
xLife: IInterface;
begin
x := TMyObject.Create; xLife := x;
...
end;
распишется в
var
x: TMyObject;
xLife: IInterface;
begin
x := TMyObject.Create; x.AddRef; // refcount = 1
try
...
finally
x.Release; // refcount = 0, x.Destroy
end;
end;
Так никто не делает, я это сам придумал. Все либо работают с классовой переменной и ебутся с ручным уничтожением (нетривиальным при передаче владения и тем более расшаривании), либо работают с интерфейсной переменной и получают необходимость вводить для каждого класса бойлерплейтный зеркальный интерфейс (IMyObject), а также оверхед на косвенный вызов на каждый чих.
>Почему этот твой паскаль такой непонятный.
Почему этот твой паскаль... ой, ща, подожди, мусор соберётся... такой непонятный.
>типа дёргаются из-за того, что слишком мощная сила разделения
Потому что для птички странно разлетаться всегда с максимальным усердием, что её заставляет делать setMag, мне кажется.
385 Кб, 1605x2048>>23094
Понятно, спасибо, что объяснил.
Понятно, спасибо, что объяснил.
152 Кб, 1900x1300Очередной плохой унылый день. Почему-то очень грустно, вернее не почему-то, но какая разница, я не знаю. Ничего не делал, в этот раз только мне даже сказать нечего, прямо совсем. Обычно можно хотя бы что-то, а сегодня нельзя. Завтра никуда не надо. Завтра будет такой же мусорный день. Какая же тупость, к чему это вообще.
Чёто кажется, что я on my way to become a second-time uni dropout. Вчера сдал какие-то лабораторные по микроэлектронике, там было про компараторы, ничего особенного, как и во всех последних лабах.
Вроде более-менее разобрался с 2-3 деревьями и left-leaning RB-деревьями. Услышал хорошее объяснение того, как удалять из 2-3 дерева. Тут, как и в обычном бинарном дереве, удаление произвольного ключа сводится к удалению минимума из правого поддерева / максимума из левого. И вот, когда идёшь влево до упора, ты перед переходом в следующую вершину (или находясь в корне) делаешь такие преобразования, чтобы каждый раз попадать не в 2-вершину. Так что благодаря этому инварианту, когда ты дойдёшь до дна, ты окажешься не в 2-вершине с минимальным элементом и спокойно его удалишь.
Преобразования для поддержания того инварианта интуитивно понятные: если у брат вершины, куда хочешь прийти, - это 3-вершина, то заимствуешь из неё ключ и там его перекидываешь, нефига непонятно без картинки, ну и ладно. Если брат - это 2-вершина, то там объедияешь всё в 4-вершину.
Да, и после того, как удалил, надо пройтись наверх и пофиксить все 4-вершины, ну, так же, как после добавления.
Я видел мега-сложное какое-то другое объяснение https://www.cs.princeton.edu/~dpw/courses/cos326-12/ass/2-3-trees.pdf с рассмотрением кучи разных вариантов преобразований и введением 1-вершины, но его невозможно понять. Это гораздо проще и оно ложится на удаление из LLRB.
Добавлять в LLRB - легко, тупо добавляешь красную ссылку на дно и потом проходишься вверх и фиксишь штуки, нарушающие определение LLRB: две красных линки подряд, правая красная линка, узел, из которого выходят две красные линки. Это всё делается тупо тремя преобразованиями два поворота как в AVL дереве и флип цветов, который меняет цвета входящей и двух исходящих линков на противоположные. Последняя операция соответствует разбиению временного 4-узла из 2-3 дерева и выталкиванию ключа наверх.
С удалением немного сложнее, короче, посмотрим сначала на удаление минимума. Ну, да, я уже сказал, оно тут соответствует удалению из 2-3, поэтому при переходе налево надо поддерживать инвариант того, что мы приходим либо в красную вершину, либо в вершину, у которой левый ребёнок - красный. (Красная вершина означает, что в неё втыкается красная линка.) Если это не фига не так, то мы делаем флип цветов текущей вершины X (которая, кстати, в таком случае гарантированно красная) - это то же самое, что и создание временной 4-вершины. И теперь смотрим, не создали ли мы сучьего монстра 5-вершину, потому что X.right.left может быть красной. Если да, то дополнительно делаем rotateRight(x.right.left), rotateLeft(x), и потом флип цветов ещё раз. Короче, блин, ладно, вот на пике видно, мне было лень скриншотить, но реально не фига не понятно.
И так приходим в самую левую вершину, которая оказывается красной, поэтому тупо её отбрасываем. И потом, наверное, имеет смысл пройтись наверх и всё (4-вершины) поправить.
С удалением максимума почти то же самое, но перед каждым шагом направо, если у нас есть красная исходящая левая линка, то мы делаем rotateRight, чтобы повернуть её направо. Я не очень понимаю, зачем это. Интуитивно: если бы не делали этого, то могли бы попасть в такую ситуацию, что надо сделать флип цветов, а и текущая, и дочерние вершины - все чёрные. В случае с удалением минимума мы в такую ситуацию не могли попасть: по инварианту либо приходим в красную, либо у вершины, куда хотим перейти, левый ребёнок красный, тогда мы ничего не делаем и просто переходим дальше. А здесь мы-то направо переходим, а красным может быть разве что левый ребёнок вершины, в которую переходим.
Так что воот. Тут, выходит инвариант такой: нужно приходить либо в вершину с левой красной линкой, либо в красную (вот после поворота, о котором выше говорил).
И ещё одно различие: в удалении минимума, когда доходили до конца, мы оказывались в левой красной линке, а тут, когда доходим до упора направо, окажется, что мы в чёрной вершине, если у нас есть левая красная линка (если нету, то мы сами красная вершина, видимо). И нам вот надо снова тот поворот направо сделать, чтобы стать красным (на пике при удалении 175). То есть, короче, надо тот поворот направо обязательно сделать приоритетнее, чем пацаны, валим его и сваливаем наверх.
Теперь произвольное удаление: оно тут тоже не фига не простое: хотя казалось бы, найди нужную вершину и сделай удаление предшественника слеш преды э-э дущника. Но проблема в том, что в рассмотренных выше удалениях минимума/максимума мы шли от корня, а на корень нам вообще наплевать, какого он там цвета и могли его флипать как хотели, всё равно потом принудительно устанавливаем в чёрный цвет. Здесь же мы вызываем deleteMin/Max от промежуточной вершины, поэтому нам надо убедиться в том, что она красная, чтобы спокойно делать флип цветов. Поэтому, когда ищем вершину для удаления при переходе налево надо сохранять инвариант из deleteMin, при переходе направо - инвариант из deleteMax.
При этом, блин, я сейчас понял, что нужно же не только в итоге, чтобы не сам искомый ключ находился в красной вершине, а чтобы его правый потомок состоял в не-2-вершине, потому что мы же вызываем deleteMin от правого потомка. То есть по-любому перед тем, как нашли вершину с искомым ключом, надо поддержать инвариант для deleteMax: чтобы либо правый потомок был красным, либо, чтобы из него исходила правая красная линка. И это вот делается как раз так же, как в deleteMax.
Короче, получается такая приоритетность при удалении:
- если идём налево, то поддерживаем инвариант и идём налево
- иначе, если не идём налево то делаем тот поворот из deleteMax, который делает из левой красной линки правую
- иначе, если нашли что надо и нет правого потомка, то тупо удаляем
- теперь последний вариант: мы либо нашли и надо пойти направо (deleteMin(x.right)) либо не нашли, и тогда тем более придётся пойти направо, поэтому сразу поддерживаем инвариант, после чего либо идём направо, либо deleteMin все дела
На последнем пике moveRedLeft - операция как на втором пикриле, moveRedRight - аналогичная для перехода направо.
В конце после удаления проходимся вверх и фиксим правые красные линки и 4-вершины.
Короче, вот так примерно. Вроде как это один из довольно простых способов сделать RB дерево, потому что ограничение на ориентацию красных линков позволяет рассматривать меньше различных случаев. Но вроде как её критиковали за то, что она делает больше каких-то операций (сравнений и присваиваний? потому что приходится восстанавливать левую ориентированность красных ссылок? это мои необоснованные домыслы, я не смотрел по этому поводу пока что ничего). В теории лучше, чем АВЛ, по крайней мере тем, что не надо хранить высоты. Тут это обычное BST с дополнительным битом на каждую вершину, который в мега-оптимизированной реализации наверное? можно куда-нибудь запихнуть? Я вот на словах это слышал, но на деле не знаю. Вроде есть варианты как-то засунуть в поинтер, либо красные вершины обозначить так, что у них потомки в неправильном порядке.
Сделал какое-то количество отжиманий и приседаний и ещё чего-то. Потыкал в three js, но блин я ничего толкового там не сделал пока что, хотя это же и проще гораздо, чем самому всё писать. Но сам всё написать я потом как-нибудь, а этто всё просто грустно.
Вроде более-менее разобрался с 2-3 деревьями и left-leaning RB-деревьями. Услышал хорошее объяснение того, как удалять из 2-3 дерева. Тут, как и в обычном бинарном дереве, удаление произвольного ключа сводится к удалению минимума из правого поддерева / максимума из левого. И вот, когда идёшь влево до упора, ты перед переходом в следующую вершину (или находясь в корне) делаешь такие преобразования, чтобы каждый раз попадать не в 2-вершину. Так что благодаря этому инварианту, когда ты дойдёшь до дна, ты окажешься не в 2-вершине с минимальным элементом и спокойно его удалишь.
Преобразования для поддержания того инварианта интуитивно понятные: если у брат вершины, куда хочешь прийти, - это 3-вершина, то заимствуешь из неё ключ и там его перекидываешь, нефига непонятно без картинки, ну и ладно. Если брат - это 2-вершина, то там объедияешь всё в 4-вершину.
Да, и после того, как удалил, надо пройтись наверх и пофиксить все 4-вершины, ну, так же, как после добавления.
Я видел мега-сложное какое-то другое объяснение https://www.cs.princeton.edu/~dpw/courses/cos326-12/ass/2-3-trees.pdf с рассмотрением кучи разных вариантов преобразований и введением 1-вершины, но его невозможно понять. Это гораздо проще и оно ложится на удаление из LLRB.
Добавлять в LLRB - легко, тупо добавляешь красную ссылку на дно и потом проходишься вверх и фиксишь штуки, нарушающие определение LLRB: две красных линки подряд, правая красная линка, узел, из которого выходят две красные линки. Это всё делается тупо тремя преобразованиями два поворота как в AVL дереве и флип цветов, который меняет цвета входящей и двух исходящих линков на противоположные. Последняя операция соответствует разбиению временного 4-узла из 2-3 дерева и выталкиванию ключа наверх.
С удалением немного сложнее, короче, посмотрим сначала на удаление минимума. Ну, да, я уже сказал, оно тут соответствует удалению из 2-3, поэтому при переходе налево надо поддерживать инвариант того, что мы приходим либо в красную вершину, либо в вершину, у которой левый ребёнок - красный. (Красная вершина означает, что в неё втыкается красная линка.) Если это не фига не так, то мы делаем флип цветов текущей вершины X (которая, кстати, в таком случае гарантированно красная) - это то же самое, что и создание временной 4-вершины. И теперь смотрим, не создали ли мы сучьего монстра 5-вершину, потому что X.right.left может быть красной. Если да, то дополнительно делаем rotateRight(x.right.left), rotateLeft(x), и потом флип цветов ещё раз. Короче, блин, ладно, вот на пике видно, мне было лень скриншотить, но реально не фига не понятно.
И так приходим в самую левую вершину, которая оказывается красной, поэтому тупо её отбрасываем. И потом, наверное, имеет смысл пройтись наверх и всё (4-вершины) поправить.
С удалением максимума почти то же самое, но перед каждым шагом направо, если у нас есть красная исходящая левая линка, то мы делаем rotateRight, чтобы повернуть её направо. Я не очень понимаю, зачем это. Интуитивно: если бы не делали этого, то могли бы попасть в такую ситуацию, что надо сделать флип цветов, а и текущая, и дочерние вершины - все чёрные. В случае с удалением минимума мы в такую ситуацию не могли попасть: по инварианту либо приходим в красную, либо у вершины, куда хотим перейти, левый ребёнок красный, тогда мы ничего не делаем и просто переходим дальше. А здесь мы-то направо переходим, а красным может быть разве что левый ребёнок вершины, в которую переходим.
Так что воот. Тут, выходит инвариант такой: нужно приходить либо в вершину с левой красной линкой, либо в красную (вот после поворота, о котором выше говорил).
И ещё одно различие: в удалении минимума, когда доходили до конца, мы оказывались в левой красной линке, а тут, когда доходим до упора направо, окажется, что мы в чёрной вершине, если у нас есть левая красная линка (если нету, то мы сами красная вершина, видимо). И нам вот надо снова тот поворот направо сделать, чтобы стать красным (на пике при удалении 175). То есть, короче, надо тот поворот направо обязательно сделать приоритетнее, чем пацаны, валим его и сваливаем наверх.
Теперь произвольное удаление: оно тут тоже не фига не простое: хотя казалось бы, найди нужную вершину и сделай удаление предшественника слеш преды э-э дущника. Но проблема в том, что в рассмотренных выше удалениях минимума/максимума мы шли от корня, а на корень нам вообще наплевать, какого он там цвета и могли его флипать как хотели, всё равно потом принудительно устанавливаем в чёрный цвет. Здесь же мы вызываем deleteMin/Max от промежуточной вершины, поэтому нам надо убедиться в том, что она красная, чтобы спокойно делать флип цветов. Поэтому, когда ищем вершину для удаления при переходе налево надо сохранять инвариант из deleteMin, при переходе направо - инвариант из deleteMax.
При этом, блин, я сейчас понял, что нужно же не только в итоге, чтобы не сам искомый ключ находился в красной вершине, а чтобы его правый потомок состоял в не-2-вершине, потому что мы же вызываем deleteMin от правого потомка. То есть по-любому перед тем, как нашли вершину с искомым ключом, надо поддержать инвариант для deleteMax: чтобы либо правый потомок был красным, либо, чтобы из него исходила правая красная линка. И это вот делается как раз так же, как в deleteMax.
Короче, получается такая приоритетность при удалении:
- если идём налево, то поддерживаем инвариант и идём налево
- иначе, если не идём налево то делаем тот поворот из deleteMax, который делает из левой красной линки правую
- иначе, если нашли что надо и нет правого потомка, то тупо удаляем
- теперь последний вариант: мы либо нашли и надо пойти направо (deleteMin(x.right)) либо не нашли, и тогда тем более придётся пойти направо, поэтому сразу поддерживаем инвариант, после чего либо идём направо, либо deleteMin все дела
На последнем пике moveRedLeft - операция как на втором пикриле, moveRedRight - аналогичная для перехода направо.
В конце после удаления проходимся вверх и фиксим правые красные линки и 4-вершины.
Короче, вот так примерно. Вроде как это один из довольно простых способов сделать RB дерево, потому что ограничение на ориентацию красных линков позволяет рассматривать меньше различных случаев. Но вроде как её критиковали за то, что она делает больше каких-то операций (сравнений и присваиваний? потому что приходится восстанавливать левую ориентированность красных ссылок? это мои необоснованные домыслы, я не смотрел по этому поводу пока что ничего). В теории лучше, чем АВЛ, по крайней мере тем, что не надо хранить высоты. Тут это обычное BST с дополнительным битом на каждую вершину, который в мега-оптимизированной реализации наверное? можно куда-нибудь запихнуть? Я вот на словах это слышал, но на деле не знаю. Вроде есть варианты как-то засунуть в поинтер, либо красные вершины обозначить так, что у них потомки в неправильном порядке.
Сделал какое-то количество отжиманий и приседаний и ещё чего-то. Потыкал в three js, но блин я ничего толкового там не сделал пока что, хотя это же и проще гораздо, чем самому всё писать. Но сам всё написать я потом как-нибудь, а этто всё просто грустно.
Чёто кажется, что я on my way to become a second-time uni dropout. Вчера сдал какие-то лабораторные по микроэлектронике, там было про компараторы, ничего особенного, как и во всех последних лабах.
Вроде более-менее разобрался с 2-3 деревьями и left-leaning RB-деревьями. Услышал хорошее объяснение того, как удалять из 2-3 дерева. Тут, как и в обычном бинарном дереве, удаление произвольного ключа сводится к удалению минимума из правого поддерева / максимума из левого. И вот, когда идёшь влево до упора, ты перед переходом в следующую вершину (или находясь в корне) делаешь такие преобразования, чтобы каждый раз попадать не в 2-вершину. Так что благодаря этому инварианту, когда ты дойдёшь до дна, ты окажешься не в 2-вершине с минимальным элементом и спокойно его удалишь.
Преобразования для поддержания того инварианта интуитивно понятные: если у брат вершины, куда хочешь прийти, - это 3-вершина, то заимствуешь из неё ключ и там его перекидываешь, нефига непонятно без картинки, ну и ладно. Если брат - это 2-вершина, то там объедияешь всё в 4-вершину.
Да, и после того, как удалил, надо пройтись наверх и пофиксить все 4-вершины, ну, так же, как после добавления.
Я видел мега-сложное какое-то другое объяснение https://www.cs.princeton.edu/~dpw/courses/cos326-12/ass/2-3-trees.pdf с рассмотрением кучи разных вариантов преобразований и введением 1-вершины, но его невозможно понять. Это гораздо проще и оно ложится на удаление из LLRB.
Добавлять в LLRB - легко, тупо добавляешь красную ссылку на дно и потом проходишься вверх и фиксишь штуки, нарушающие определение LLRB: две красных линки подряд, правая красная линка, узел, из которого выходят две красные линки. Это всё делается тупо тремя преобразованиями два поворота как в AVL дереве и флип цветов, который меняет цвета входящей и двух исходящих линков на противоположные. Последняя операция соответствует разбиению временного 4-узла из 2-3 дерева и выталкиванию ключа наверх.
С удалением немного сложнее, короче, посмотрим сначала на удаление минимума. Ну, да, я уже сказал, оно тут соответствует удалению из 2-3, поэтому при переходе налево надо поддерживать инвариант того, что мы приходим либо в красную вершину, либо в вершину, у которой левый ребёнок - красный. (Красная вершина означает, что в неё втыкается красная линка.) Если это не фига не так, то мы делаем флип цветов текущей вершины X (которая, кстати, в таком случае гарантированно красная) - это то же самое, что и создание временной 4-вершины. И теперь смотрим, не создали ли мы сучьего монстра 5-вершину, потому что X.right.left может быть красной. Если да, то дополнительно делаем rotateRight(x.right.left), rotateLeft(x), и потом флип цветов ещё раз. Короче, блин, ладно, вот на пике видно, мне было лень скриншотить, но реально не фига не понятно.
И так приходим в самую левую вершину, которая оказывается красной, поэтому тупо её отбрасываем. И потом, наверное, имеет смысл пройтись наверх и всё (4-вершины) поправить.
С удалением максимума почти то же самое, но перед каждым шагом направо, если у нас есть красная исходящая левая линка, то мы делаем rotateRight, чтобы повернуть её направо. Я не очень понимаю, зачем это. Интуитивно: если бы не делали этого, то могли бы попасть в такую ситуацию, что надо сделать флип цветов, а и текущая, и дочерние вершины - все чёрные. В случае с удалением минимума мы в такую ситуацию не могли попасть: по инварианту либо приходим в красную, либо у вершины, куда хотим перейти, левый ребёнок красный, тогда мы ничего не делаем и просто переходим дальше. А здесь мы-то направо переходим, а красным может быть разве что левый ребёнок вершины, в которую переходим.
Так что воот. Тут, выходит инвариант такой: нужно приходить либо в вершину с левой красной линкой, либо в красную (вот после поворота, о котором выше говорил).
И ещё одно различие: в удалении минимума, когда доходили до конца, мы оказывались в левой красной линке, а тут, когда доходим до упора направо, окажется, что мы в чёрной вершине, если у нас есть левая красная линка (если нету, то мы сами красная вершина, видимо). И нам вот надо снова тот поворот направо сделать, чтобы стать красным (на пике при удалении 175). То есть, короче, надо тот поворот направо обязательно сделать приоритетнее, чем пацаны, валим его и сваливаем наверх.
Теперь произвольное удаление: оно тут тоже не фига не простое: хотя казалось бы, найди нужную вершину и сделай удаление предшественника слеш преды э-э дущника. Но проблема в том, что в рассмотренных выше удалениях минимума/максимума мы шли от корня, а на корень нам вообще наплевать, какого он там цвета и могли его флипать как хотели, всё равно потом принудительно устанавливаем в чёрный цвет. Здесь же мы вызываем deleteMin/Max от промежуточной вершины, поэтому нам надо убедиться в том, что она красная, чтобы спокойно делать флип цветов. Поэтому, когда ищем вершину для удаления при переходе налево надо сохранять инвариант из deleteMin, при переходе направо - инвариант из deleteMax.
При этом, блин, я сейчас понял, что нужно же не только в итоге, чтобы не сам искомый ключ находился в красной вершине, а чтобы его правый потомок состоял в не-2-вершине, потому что мы же вызываем deleteMin от правого потомка. То есть по-любому перед тем, как нашли вершину с искомым ключом, надо поддержать инвариант для deleteMax: чтобы либо правый потомок был красным, либо, чтобы из него исходила правая красная линка. И это вот делается как раз так же, как в deleteMax.
Короче, получается такая приоритетность при удалении:
- если идём налево, то поддерживаем инвариант и идём налево
- иначе, если не идём налево то делаем тот поворот из deleteMax, который делает из левой красной линки правую
- иначе, если нашли что надо и нет правого потомка, то тупо удаляем
- теперь последний вариант: мы либо нашли и надо пойти направо (deleteMin(x.right)) либо не нашли, и тогда тем более придётся пойти направо, поэтому сразу поддерживаем инвариант, после чего либо идём направо, либо deleteMin все дела
На последнем пике moveRedLeft - операция как на втором пикриле, moveRedRight - аналогичная для перехода направо.
В конце после удаления проходимся вверх и фиксим правые красные линки и 4-вершины.
Короче, вот так примерно. Вроде как это один из довольно простых способов сделать RB дерево, потому что ограничение на ориентацию красных линков позволяет рассматривать меньше различных случаев. Но вроде как её критиковали за то, что она делает больше каких-то операций (сравнений и присваиваний? потому что приходится восстанавливать левую ориентированность красных ссылок? это мои необоснованные домыслы, я не смотрел по этому поводу пока что ничего). В теории лучше, чем АВЛ, по крайней мере тем, что не надо хранить высоты. Тут это обычное BST с дополнительным битом на каждую вершину, который в мега-оптимизированной реализации наверное? можно куда-нибудь запихнуть? Я вот на словах это слышал, но на деле не знаю. Вроде есть варианты как-то засунуть в поинтер, либо красные вершины обозначить так, что у них потомки в неправильном порядке.
Сделал какое-то количество отжиманий и приседаний и ещё чего-то. Потыкал в three js, но блин я ничего толкового там не сделал пока что, хотя это же и проще гораздо, чем самому всё писать. Но сам всё написать я потом как-нибудь, а этто всё просто грустно.
Вроде более-менее разобрался с 2-3 деревьями и left-leaning RB-деревьями. Услышал хорошее объяснение того, как удалять из 2-3 дерева. Тут, как и в обычном бинарном дереве, удаление произвольного ключа сводится к удалению минимума из правого поддерева / максимума из левого. И вот, когда идёшь влево до упора, ты перед переходом в следующую вершину (или находясь в корне) делаешь такие преобразования, чтобы каждый раз попадать не в 2-вершину. Так что благодаря этому инварианту, когда ты дойдёшь до дна, ты окажешься не в 2-вершине с минимальным элементом и спокойно его удалишь.
Преобразования для поддержания того инварианта интуитивно понятные: если у брат вершины, куда хочешь прийти, - это 3-вершина, то заимствуешь из неё ключ и там его перекидываешь, нефига непонятно без картинки, ну и ладно. Если брат - это 2-вершина, то там объедияешь всё в 4-вершину.
Да, и после того, как удалил, надо пройтись наверх и пофиксить все 4-вершины, ну, так же, как после добавления.
Я видел мега-сложное какое-то другое объяснение https://www.cs.princeton.edu/~dpw/courses/cos326-12/ass/2-3-trees.pdf с рассмотрением кучи разных вариантов преобразований и введением 1-вершины, но его невозможно понять. Это гораздо проще и оно ложится на удаление из LLRB.
Добавлять в LLRB - легко, тупо добавляешь красную ссылку на дно и потом проходишься вверх и фиксишь штуки, нарушающие определение LLRB: две красных линки подряд, правая красная линка, узел, из которого выходят две красные линки. Это всё делается тупо тремя преобразованиями два поворота как в AVL дереве и флип цветов, который меняет цвета входящей и двух исходящих линков на противоположные. Последняя операция соответствует разбиению временного 4-узла из 2-3 дерева и выталкиванию ключа наверх.
С удалением немного сложнее, короче, посмотрим сначала на удаление минимума. Ну, да, я уже сказал, оно тут соответствует удалению из 2-3, поэтому при переходе налево надо поддерживать инвариант того, что мы приходим либо в красную вершину, либо в вершину, у которой левый ребёнок - красный. (Красная вершина означает, что в неё втыкается красная линка.) Если это не фига не так, то мы делаем флип цветов текущей вершины X (которая, кстати, в таком случае гарантированно красная) - это то же самое, что и создание временной 4-вершины. И теперь смотрим, не создали ли мы сучьего монстра 5-вершину, потому что X.right.left может быть красной. Если да, то дополнительно делаем rotateRight(x.right.left), rotateLeft(x), и потом флип цветов ещё раз. Короче, блин, ладно, вот на пике видно, мне было лень скриншотить, но реально не фига не понятно.
И так приходим в самую левую вершину, которая оказывается красной, поэтому тупо её отбрасываем. И потом, наверное, имеет смысл пройтись наверх и всё (4-вершины) поправить.
С удалением максимума почти то же самое, но перед каждым шагом направо, если у нас есть красная исходящая левая линка, то мы делаем rotateRight, чтобы повернуть её направо. Я не очень понимаю, зачем это. Интуитивно: если бы не делали этого, то могли бы попасть в такую ситуацию, что надо сделать флип цветов, а и текущая, и дочерние вершины - все чёрные. В случае с удалением минимума мы в такую ситуацию не могли попасть: по инварианту либо приходим в красную, либо у вершины, куда хотим перейти, левый ребёнок красный, тогда мы ничего не делаем и просто переходим дальше. А здесь мы-то направо переходим, а красным может быть разве что левый ребёнок вершины, в которую переходим.
Так что воот. Тут, выходит инвариант такой: нужно приходить либо в вершину с левой красной линкой, либо в красную (вот после поворота, о котором выше говорил).
И ещё одно различие: в удалении минимума, когда доходили до конца, мы оказывались в левой красной линке, а тут, когда доходим до упора направо, окажется, что мы в чёрной вершине, если у нас есть левая красная линка (если нету, то мы сами красная вершина, видимо). И нам вот надо снова тот поворот направо сделать, чтобы стать красным (на пике при удалении 175). То есть, короче, надо тот поворот направо обязательно сделать приоритетнее, чем пацаны, валим его и сваливаем наверх.
Теперь произвольное удаление: оно тут тоже не фига не простое: хотя казалось бы, найди нужную вершину и сделай удаление предшественника слеш преды э-э дущника. Но проблема в том, что в рассмотренных выше удалениях минимума/максимума мы шли от корня, а на корень нам вообще наплевать, какого он там цвета и могли его флипать как хотели, всё равно потом принудительно устанавливаем в чёрный цвет. Здесь же мы вызываем deleteMin/Max от промежуточной вершины, поэтому нам надо убедиться в том, что она красная, чтобы спокойно делать флип цветов. Поэтому, когда ищем вершину для удаления при переходе налево надо сохранять инвариант из deleteMin, при переходе направо - инвариант из deleteMax.
При этом, блин, я сейчас понял, что нужно же не только в итоге, чтобы не сам искомый ключ находился в красной вершине, а чтобы его правый потомок состоял в не-2-вершине, потому что мы же вызываем deleteMin от правого потомка. То есть по-любому перед тем, как нашли вершину с искомым ключом, надо поддержать инвариант для deleteMax: чтобы либо правый потомок был красным, либо, чтобы из него исходила правая красная линка. И это вот делается как раз так же, как в deleteMax.
Короче, получается такая приоритетность при удалении:
- если идём налево, то поддерживаем инвариант и идём налево
- иначе, если не идём налево то делаем тот поворот из deleteMax, который делает из левой красной линки правую
- иначе, если нашли что надо и нет правого потомка, то тупо удаляем
- теперь последний вариант: мы либо нашли и надо пойти направо (deleteMin(x.right)) либо не нашли, и тогда тем более придётся пойти направо, поэтому сразу поддерживаем инвариант, после чего либо идём направо, либо deleteMin все дела
На последнем пике moveRedLeft - операция как на втором пикриле, moveRedRight - аналогичная для перехода направо.
В конце после удаления проходимся вверх и фиксим правые красные линки и 4-вершины.
Короче, вот так примерно. Вроде как это один из довольно простых способов сделать RB дерево, потому что ограничение на ориентацию красных линков позволяет рассматривать меньше различных случаев. Но вроде как её критиковали за то, что она делает больше каких-то операций (сравнений и присваиваний? потому что приходится восстанавливать левую ориентированность красных ссылок? это мои необоснованные домыслы, я не смотрел по этому поводу пока что ничего). В теории лучше, чем АВЛ, по крайней мере тем, что не надо хранить высоты. Тут это обычное BST с дополнительным битом на каждую вершину, который в мега-оптимизированной реализации наверное? можно куда-нибудь запихнуть? Я вот на словах это слышал, но на деле не знаю. Вроде есть варианты как-то засунуть в поинтер, либо красные вершины обозначить так, что у них потомки в неправильном порядке.
Сделал какое-то количество отжиманий и приседаний и ещё чего-то. Потыкал в three js, но блин я ничего толкового там не сделал пока что, хотя это же и проще гораздо, чем самому всё писать. Но сам всё написать я потом как-нибудь, а этто всё просто грустно.
>>23779
микрофикс
На самом деле, можно второй пик из поста перерисовать как 2-3 дерево и тогда вот будет то, о чём я говорю в этом моменте. Ну ладно, вот ещё скриншоты про это. Если верхняя вершина - это 2-вершина, то есть, если мы в корне (в самом начале), то в первом случае примерно то же самое, а во втором тупо всё объединяется в 4-вершину.
ещё микрофикс
Я не уверен, что я это всё вообще правильно понимаю и что то, что я написал, вообще правильно работает и нормально самобалансируется, но оно по крайней мере good enough, чтобы проходить простые тесты.
Завтра надо сделать английский лол и русский лол обязательно, потому что там почти дэдлайны, какой бред, чем я занимаюсь.
>если брат вершины, куда хочешь прийти, - это 3-вершина, то заимствуешь из неё ключ и там его перекидываешь
микрофикс
На самом деле, можно второй пик из поста перерисовать как 2-3 дерево и тогда вот будет то, о чём я говорю в этом моменте. Ну ладно, вот ещё скриншоты про это. Если верхняя вершина - это 2-вершина, то есть, если мы в корне (в самом начале), то в первом случае примерно то же самое, а во втором тупо всё объединяется в 4-вершину.
>При этом, блин, я сейчас понял, что нужно же в итоге, чтобы не сам искомый ключ находился в красной вершине, а чтобы его правый потомок состоял в не-2-вершине, потому что мы же вызываем deleteMin от правого потомка.
ещё микрофикс
Я не уверен, что я это всё вообще правильно понимаю и что то, что я написал, вообще правильно работает и нормально самобалансируется, но оно по крайней мере good enough, чтобы проходить простые тесты.
Завтра надо сделать английский лол и русский лол обязательно, потому что там почти дэдлайны, какой бред, чем я занимаюсь.
26,2 Мб, webm,1920x1080, 1:31
>>23779
Мне казалось, я когда-то давно рассказывал про tagged pointers, но, по-видимому, я, как обычно, записал это в текстовый файлик и передумал/забыл запостить.
https://habr.com/ru/post/149012/
Исходим из 2 предположений:
— Поскольку узел дерева содержит указатели на другие узлы (а даже если бы не содержал), и указатель является примитивным типом с выравниванием, равным собственному размеру, узлы дерева выровнены минимум на sizeof(pointer).
— sizeof(pointer) = 2ᵏ ≥ 4.
Это означает, что два младших бита указателя Node＊ — гарантированно Gundam 00, и в них поместится и цвет узла красно-чёрного дерева (1 бит), и даже баланс узла АВЛ-дерева (2 бита). Тогда мы храним в узле не
а
получаем parent как
цвет как
записываем цвет как
(Или скорее будет запись сразу цвета и parent одним махом.)
Как правило, менеджер памяти, чтобы не озадачиваться тем, что ты будешь с ней делать, выделяет блоки с универсальным выравниванием а-ля 16 байт (см. статью). Либо мы можем не new'ать каждый узел как чмо, а делать по заветам соевичка — хранить узлы дерева в массиве и ссылать один на другой индексами, тогда можно либо отдать под цвет 1 бит одного из индексов, пожертвовав половиной пространства, либо отдельно вести битовое поле по размеру массива, либо, если полезная нагрузка узла сама представляет собой указатель, пытать его вместо своих.
>который в мега-оптимизированной реализации наверное? можно куда-нибудь запихнуть?
Мне казалось, я когда-то давно рассказывал про tagged pointers, но, по-видимому, я, как обычно, записал это в текстовый файлик и передумал/забыл запостить.
https://habr.com/ru/post/149012/
Исходим из 2 предположений:
— Поскольку узел дерева содержит указатели на другие узлы (а даже если бы не содержал), и указатель является примитивным типом с выравниванием, равным собственному размеру, узлы дерева выровнены минимум на sizeof(pointer).
— sizeof(pointer) = 2ᵏ ≥ 4.
Это означает, что два младших бита указателя Node＊ — гарантированно Gundam 00, и в них поместится и цвет узла красно-чёрного дерева (1 бит), и даже баланс узла АВЛ-дерева (2 бита). Тогда мы храним в узле не
>Node＊ left, right, parent;
>bool red;
а
>Node＊ left, right;
>uintptr_t tagParent;
получаем parent как
>Node＊ parent() { return (Node＊)(tagParent & ~uintptr_t(0b1)); };
цвет как
>bool red() { return (bool)(tagParent & 0b1); }
записываем цвет как
>void set_red(bool red) { tagParent = tagParent & ~uintptr_t(0b1) | (uintptr_t)red; }
(Или скорее будет запись сразу цвета и parent одним махом.)
>а даже если бы не содержал
Как правило, менеджер памяти, чтобы не озадачиваться тем, что ты будешь с ней делать, выделяет блоки с универсальным выравниванием а-ля 16 байт (см. статью). Либо мы можем не new'ать каждый узел как чмо, а делать по заветам соевичка — хранить узлы дерева в массиве и ссылать один на другой индексами, тогда можно либо отдать под цвет 1 бит одного из индексов, пожертвовав половиной пространства, либо отдельно вести битовое поле по размеру массива, либо, если полезная нагрузка узла сама представляет собой указатель, пытать его вместо своих.
26,2 Мб, webm,1920x1080, 1:31
>>23779
Мне казалось, я когда-то давно рассказывал про tagged pointers, но, по-видимому, я, как обычно, записал это в текстовый файлик и передумал/забыл запостить.
https://habr.com/ru/post/149012/
Исходим из 2 предположений:
— Поскольку узел дерева содержит указатели на другие узлы (а даже если бы не содержал), и указатель является примитивным типом с выравниванием, равным собственному размеру, узлы дерева выровнены минимум на sizeof(pointer).
— sizeof(pointer) = 2ᵏ ≥ 4.
Это означает, что два младших бита указателя Node＊ — гарантированно Gundam 00, и в них поместится и цвет узла красно-чёрного дерева (1 бит), и даже баланс узла АВЛ-дерева (2 бита). Тогда мы храним в узле не
а
получаем parent как
цвет как
записываем цвет как
(Или скорее будет запись сразу цвета и parent одним махом.)
Как правило, менеджер памяти, чтобы не озадачиваться тем, что ты будешь с ней делать, выделяет блоки с универсальным выравниванием а-ля 16 байт (см. статью). Либо мы можем не new'ать каждый узел как чмо, а делать по заветам соевичка — хранить узлы дерева в массиве и ссылать один на другой индексами, тогда можно либо отдать под цвет 1 бит одного из индексов, пожертвовав половиной пространства, либо отдельно вести битовое поле по размеру массива, либо, если полезная нагрузка узла сама представляет собой указатель, пытать его вместо своих.
>который в мега-оптимизированной реализации наверное? можно куда-нибудь запихнуть?
Мне казалось, я когда-то давно рассказывал про tagged pointers, но, по-видимому, я, как обычно, записал это в текстовый файлик и передумал/забыл запостить.
https://habr.com/ru/post/149012/
Исходим из 2 предположений:
— Поскольку узел дерева содержит указатели на другие узлы (а даже если бы не содержал), и указатель является примитивным типом с выравниванием, равным собственному размеру, узлы дерева выровнены минимум на sizeof(pointer).
— sizeof(pointer) = 2ᵏ ≥ 4.
Это означает, что два младших бита указателя Node＊ — гарантированно Gundam 00, и в них поместится и цвет узла красно-чёрного дерева (1 бит), и даже баланс узла АВЛ-дерева (2 бита). Тогда мы храним в узле не
>Node＊ left, right, parent;
>bool red;
а
>Node＊ left, right;
>uintptr_t tagParent;
получаем parent как
>Node＊ parent() { return (Node＊)(tagParent & ~uintptr_t(0b1)); };
цвет как
>bool red() { return (bool)(tagParent & 0b1); }
записываем цвет как
>void set_red(bool red) { tagParent = tagParent & ~uintptr_t(0b1) | (uintptr_t)red; }
(Или скорее будет запись сразу цвета и parent одним махом.)
>а даже если бы не содержал
Как правило, менеджер памяти, чтобы не озадачиваться тем, что ты будешь с ней делать, выделяет блоки с универсальным выравниванием а-ля 16 байт (см. статью). Либо мы можем не new'ать каждый узел как чмо, а делать по заветам соевичка — хранить узлы дерева в массиве и ссылать один на другой индексами, тогда можно либо отдать под цвет 1 бит одного из индексов, пожертвовав половиной пространства, либо отдельно вести битовое поле по размеру массива, либо, если полезная нагрузка узла сама представляет собой указатель, пытать его вместо своих.
>>23796
А, теперь понятно, почему можно заиспользовать для хранения least significant биты у указателей. Ээ и да, я не подумал, что в АВЛ можно не хранить высоты как инты, а только то, в какую сторону перекошено дерево, и на это да, достаточно двух битов.
Хм, интересно, как это реализовать можно. Надо, наверное, чтобы то, на что ты ссылаешься, было достаточно близким к тебе, но вставлять же в середину массива нежелательно, потому что придётся апдейтить все индексы тогда после сдвига. Да и с удалением я как-то не знаю, что делать: тут же та же проблема. Слишком сложно, непонятно. Тупое решение с апдейтом индексов ещё и линейным по времени же получается, вообще никуда не годится, проще тогда держать отсортированный массив или линейный поиск делать.
Это звучит попроще.
Но тогда выходит, что надо будет нам самим вычислять высоты? Просто вот по алгоритму нам же надо различать больше случаев, чем три: дополнительно нужны сильная перекошенность влево и вправо, помимо одинаковости высот и двух лёгких перекошенностей. А только из этих двух бит этого вроде не понять.
А нет, короче, проблема была в том, что у меня в голове была очень тупая реализация, вот https://en.wikipedia.org/wiki/AVL_tree#Insert в википедии гораздо лучше. Там, короче, исправление факторов (разниц высот) делается до того момента, пока не попадём в вершину с фактором 0 по пути нааверх, потому что тогда выше ничего уже не надо фиксить. И это означает, что нам можно не выделять отдельно случаи, когда факторы равны плюс-минус 2.
Мы проходимся вверх по дереву, инвариант: Z - корень дерева высота которого увеличилась на 1, в нём есть АВЛьность и правильно расставлены факторы, X - его родитель, в котором хранится старый фактор. И тут, если родитель X изначально был перекошен влево, а Z - правый потомок, то увеличение высоты Z съедается этим изначальным перекосом налево, factor(X) становится равным нулю и мы останавливаемся. А если изначально перекоса не было, то он вот появился и придётся дальше идти наверх.
Это простые случаи, когда не надо ничего вертеть, а сложный появляется, когда у X уже был перекос до добавления и потомок Z делает его ещё более сильным. Тогда выходит, что |factor(X)| == 2 и надо уже повертеть дерево. И прямо в поворотах можно заапдейтить все факторы, вот как на пикриле для левого поворота в Right-Right случае. И я не уверен уже, что можно будет тогда, если мы апдейтим факторы прямо в поворотах, обойтись только двумя функциями для простых поворотов: возможно да, придётся как на вики, писать отдельно функции для right-left и left-right поворотов, потому что по ощущениям там после одного поворота из двух может получиться такое, что у кого-то фактор временно по модулю больше единицы, а это недопустимо, если у нас в распоряжении только 2 бита? Или можно как-нибудь это всё обмануть, у нас же есть ещё одно неиспользованное значение. Мне даже об этом вот, о чём я думаю, думать сейчас тяжело.
Например, в right-left повороте: если t2 короче, чем t3, то после правого поворота t2 временно поднимется ещё выше, из-за чего у Y будет фактор 2 (блин, тут в вики записывается походу правая высота минус левая, а у меня в голове наоборот, но не важно), который потом поправится поворотом X налево, потому что t2 снова опустится ниже.
А, теперь понятно, почему можно заиспользовать для хранения least significant биты у указателей. Ээ и да, я не подумал, что в АВЛ можно не хранить высоты как инты, а только то, в какую сторону перекошено дерево, и на это да, достаточно двух битов.
>можно либо отдать под цвет 1 бит одного из индексов, пожертвовав половиной пространства
Хм, интересно, как это реализовать можно. Надо, наверное, чтобы то, на что ты ссылаешься, было достаточно близким к тебе, но вставлять же в середину массива нежелательно, потому что придётся апдейтить все индексы тогда после сдвига. Да и с удалением я как-то не знаю, что делать: тут же та же проблема. Слишком сложно, непонятно. Тупое решение с апдейтом индексов ещё и линейным по времени же получается, вообще никуда не годится, проще тогда держать отсортированный массив или линейный поиск делать.
>отдельно вести битовое поле по размеру массива
Это звучит попроще.
>в АВЛ можно не хранить высоты как инты <...> достаточно двух битов
Но тогда выходит, что надо будет нам самим вычислять высоты? Просто вот по алгоритму нам же надо различать больше случаев, чем три: дополнительно нужны сильная перекошенность влево и вправо, помимо одинаковости высот и двух лёгких перекошенностей. А только из этих двух бит этого вроде не понять.
А нет, короче, проблема была в том, что у меня в голове была очень тупая реализация, вот https://en.wikipedia.org/wiki/AVL_tree#Insert в википедии гораздо лучше. Там, короче, исправление факторов (разниц высот) делается до того момента, пока не попадём в вершину с фактором 0 по пути нааверх, потому что тогда выше ничего уже не надо фиксить. И это означает, что нам можно не выделять отдельно случаи, когда факторы равны плюс-минус 2.
Мы проходимся вверх по дереву, инвариант: Z - корень дерева высота которого увеличилась на 1, в нём есть АВЛьность и правильно расставлены факторы, X - его родитель, в котором хранится старый фактор. И тут, если родитель X изначально был перекошен влево, а Z - правый потомок, то увеличение высоты Z съедается этим изначальным перекосом налево, factor(X) становится равным нулю и мы останавливаемся. А если изначально перекоса не было, то он вот появился и придётся дальше идти наверх.
Это простые случаи, когда не надо ничего вертеть, а сложный появляется, когда у X уже был перекос до добавления и потомок Z делает его ещё более сильным. Тогда выходит, что |factor(X)| == 2 и надо уже повертеть дерево. И прямо в поворотах можно заапдейтить все факторы, вот как на пикриле для левого поворота в Right-Right случае. И я не уверен уже, что можно будет тогда, если мы апдейтим факторы прямо в поворотах, обойтись только двумя функциями для простых поворотов: возможно да, придётся как на вики, писать отдельно функции для right-left и left-right поворотов, потому что по ощущениям там после одного поворота из двух может получиться такое, что у кого-то фактор временно по модулю больше единицы, а это недопустимо, если у нас в распоряжении только 2 бита? Или можно как-нибудь это всё обмануть, у нас же есть ещё одно неиспользованное значение. Мне даже об этом вот, о чём я думаю, думать сейчас тяжело.
Например, в right-left повороте: если t2 короче, чем t3, то после правого поворота t2 временно поднимется ещё выше, из-за чего у Y будет фактор 2 (блин, тут в вики записывается походу правая высота минус левая, а у меня в голове наоборот, но не важно), который потом поправится поворотом X налево, потому что t2 снова опустится ниже.
>>23796
А, теперь понятно, почему можно заиспользовать для хранения least significant биты у указателей. Ээ и да, я не подумал, что в АВЛ можно не хранить высоты как инты, а только то, в какую сторону перекошено дерево, и на это да, достаточно двух битов.
Хм, интересно, как это реализовать можно. Надо, наверное, чтобы то, на что ты ссылаешься, было достаточно близким к тебе, но вставлять же в середину массива нежелательно, потому что придётся апдейтить все индексы тогда после сдвига. Да и с удалением я как-то не знаю, что делать: тут же та же проблема. Слишком сложно, непонятно. Тупое решение с апдейтом индексов ещё и линейным по времени же получается, вообще никуда не годится, проще тогда держать отсортированный массив или линейный поиск делать.
Это звучит попроще.
Но тогда выходит, что надо будет нам самим вычислять высоты? Просто вот по алгоритму нам же надо различать больше случаев, чем три: дополнительно нужны сильная перекошенность влево и вправо, помимо одинаковости высот и двух лёгких перекошенностей. А только из этих двух бит этого вроде не понять.
А нет, короче, проблема была в том, что у меня в голове была очень тупая реализация, вот https://en.wikipedia.org/wiki/AVL_tree#Insert в википедии гораздо лучше. Там, короче, исправление факторов (разниц высот) делается до того момента, пока не попадём в вершину с фактором 0 по пути нааверх, потому что тогда выше ничего уже не надо фиксить. И это означает, что нам можно не выделять отдельно случаи, когда факторы равны плюс-минус 2.
Мы проходимся вверх по дереву, инвариант: Z - корень дерева высота которого увеличилась на 1, в нём есть АВЛьность и правильно расставлены факторы, X - его родитель, в котором хранится старый фактор. И тут, если родитель X изначально был перекошен влево, а Z - правый потомок, то увеличение высоты Z съедается этим изначальным перекосом налево, factor(X) становится равным нулю и мы останавливаемся. А если изначально перекоса не было, то он вот появился и придётся дальше идти наверх.
Это простые случаи, когда не надо ничего вертеть, а сложный появляется, когда у X уже был перекос до добавления и потомок Z делает его ещё более сильным. Тогда выходит, что |factor(X)| == 2 и надо уже повертеть дерево. И прямо в поворотах можно заапдейтить все факторы, вот как на пикриле для левого поворота в Right-Right случае. И я не уверен уже, что можно будет тогда, если мы апдейтим факторы прямо в поворотах, обойтись только двумя функциями для простых поворотов: возможно да, придётся как на вики, писать отдельно функции для right-left и left-right поворотов, потому что по ощущениям там после одного поворота из двух может получиться такое, что у кого-то фактор временно по модулю больше единицы, а это недопустимо, если у нас в распоряжении только 2 бита? Или можно как-нибудь это всё обмануть, у нас же есть ещё одно неиспользованное значение. Мне даже об этом вот, о чём я думаю, думать сейчас тяжело.
Например, в right-left повороте: если t2 короче, чем t3, то после правого поворота t2 временно поднимется ещё выше, из-за чего у Y будет фактор 2 (блин, тут в вики записывается походу правая высота минус левая, а у меня в голове наоборот, но не важно), который потом поправится поворотом X налево, потому что t2 снова опустится ниже.
А, теперь понятно, почему можно заиспользовать для хранения least significant биты у указателей. Ээ и да, я не подумал, что в АВЛ можно не хранить высоты как инты, а только то, в какую сторону перекошено дерево, и на это да, достаточно двух битов.
>можно либо отдать под цвет 1 бит одного из индексов, пожертвовав половиной пространства
Хм, интересно, как это реализовать можно. Надо, наверное, чтобы то, на что ты ссылаешься, было достаточно близким к тебе, но вставлять же в середину массива нежелательно, потому что придётся апдейтить все индексы тогда после сдвига. Да и с удалением я как-то не знаю, что делать: тут же та же проблема. Слишком сложно, непонятно. Тупое решение с апдейтом индексов ещё и линейным по времени же получается, вообще никуда не годится, проще тогда держать отсортированный массив или линейный поиск делать.
>отдельно вести битовое поле по размеру массива
Это звучит попроще.
>в АВЛ можно не хранить высоты как инты <...> достаточно двух битов
Но тогда выходит, что надо будет нам самим вычислять высоты? Просто вот по алгоритму нам же надо различать больше случаев, чем три: дополнительно нужны сильная перекошенность влево и вправо, помимо одинаковости высот и двух лёгких перекошенностей. А только из этих двух бит этого вроде не понять.
А нет, короче, проблема была в том, что у меня в голове была очень тупая реализация, вот https://en.wikipedia.org/wiki/AVL_tree#Insert в википедии гораздо лучше. Там, короче, исправление факторов (разниц высот) делается до того момента, пока не попадём в вершину с фактором 0 по пути нааверх, потому что тогда выше ничего уже не надо фиксить. И это означает, что нам можно не выделять отдельно случаи, когда факторы равны плюс-минус 2.
Мы проходимся вверх по дереву, инвариант: Z - корень дерева высота которого увеличилась на 1, в нём есть АВЛьность и правильно расставлены факторы, X - его родитель, в котором хранится старый фактор. И тут, если родитель X изначально был перекошен влево, а Z - правый потомок, то увеличение высоты Z съедается этим изначальным перекосом налево, factor(X) становится равным нулю и мы останавливаемся. А если изначально перекоса не было, то он вот появился и придётся дальше идти наверх.
Это простые случаи, когда не надо ничего вертеть, а сложный появляется, когда у X уже был перекос до добавления и потомок Z делает его ещё более сильным. Тогда выходит, что |factor(X)| == 2 и надо уже повертеть дерево. И прямо в поворотах можно заапдейтить все факторы, вот как на пикриле для левого поворота в Right-Right случае. И я не уверен уже, что можно будет тогда, если мы апдейтим факторы прямо в поворотах, обойтись только двумя функциями для простых поворотов: возможно да, придётся как на вики, писать отдельно функции для right-left и left-right поворотов, потому что по ощущениям там после одного поворота из двух может получиться такое, что у кого-то фактор временно по модулю больше единицы, а это недопустимо, если у нас в распоряжении только 2 бита? Или можно как-нибудь это всё обмануть, у нас же есть ещё одно неиспользованное значение. Мне даже об этом вот, о чём я думаю, думать сейчас тяжело.
Например, в right-left повороте: если t2 короче, чем t3, то после правого поворота t2 временно поднимется ещё выше, из-за чего у Y будет фактор 2 (блин, тут в вики записывается походу правая высота минус левая, а у меня в голове наоборот, но не важно), который потом поправится поворотом X налево, потому что t2 снова опустится ниже.
167 Кб, 1378x2039Я сегодня тупил на каких-то бесполезных парах и ничего не понимал вообще. Устал от криков, я просто не вывожу, когда кто-то ругается и мне плохо становится, когда кто-то разговаривает на повышенных тонах, хорошо, что хоть меня в последнее время никто не трогает. С утра болит голова и я почему-то не догадался выпить таблетку до сих пор. Я связываю это с тем, что непонятно как сплю и с тем, что стал кофейным наркоманом да, я считаю, что намеренно путать паронимы - это очень смешно потому что после кофе голова по крайней мере начинает болеть чуть меньше.
На хтмл было про кучу вещей в джамбаскрипте, я сначала ещё старался воспринимать, о чём идёт, но потом потерялся, слишком много всего и когда сам не пробуешь написать, то не воспринимается. В какой-то момент усышал про промисы и подумал про себя, о, это я знаю, а потом снова потерялся.
Надо бы сейчас выпить таблетку какую-нибудь, а потом всё же сесть и написать штуку по английскому лол и хотя бы начать делать русский лол. Это всё какое-то уныние. Ноги теперь болят в смысле ну, мышцы, после вчера, поэтому ничего не сделал.
Кстати, про манкрафт, я чего-то задумался, можно ли фармить песок в манкрафте, и я в комментариях на ютубах увидел такое на смежную тему:
Надо бы проверить самому, потому что как-то про это не очень много пишут, либо я не умею гуглить (на самом деле я даже не гуглил).
А песок, видимо, конечен: его можно либо выкопать, либо в сундуках в пустынном храме (возможно, ещё в каких-то treasure сундуках можно найти). Но вроде его можно дюпать, причём уже очень давно. Как раз илманго относительно недавно делал дюпер песка жесть они там ломают фрейм портала в энд грибами, не знал о таком https://youtu.be/qG9kDi5PeqA?t=457 и там вот такой дюпер https://youtu.be/qG9kDi5PeqA?t=535
Кстати, тнт дюперы хотят вроде выпилить (мне лень искать твиты какого-то разраба из моджанга, которые намекают на это), это интересно, потому что в таком случае непонятно, как делать дыры в земле в промышленных масштабах. Ну, даже, если накопаешь руками / надюпаешь много песка и сделаешь кучу тнт, то тебе же придётся вручную их закапывать в землю или сбрасывать сверху в одну точку, потом в другую, потому что без MBE нельзя сделать летающую штуку, которая будет бомбардировать землю https://youtu.be/PqEyv1sk_rY
Я не очень следил за новыми снапшотами 1.17, там ничего прямо нового просто не было пока что: только пушистый снег по сути. Кстати, пушистый снег можно ставить диспенсером, это интересно, потому что я не вижу больше ни одного блока, который можно было бы поставить https://minecraft.gamepedia.com/Dispenser Но опять же, без MBE не вижу особых применений этому. Не знаю, надо потом посмотреть, какие кто применения уже придумал. Единственное, что я понял - фармить этот новый снег очень долго: надо афкшить около котлов, на которые сыплет снег https://youtu.be/dmo0rT4r7Po
На хтмл было про кучу вещей в джамбаскрипте, я сначала ещё старался воспринимать, о чём идёт, но потом потерялся, слишком много всего и когда сам не пробуешь написать, то не воспринимается. В какой-то момент усышал про промисы и подумал про себя, о, это я знаю, а потом снова потерялся.
Надо бы сейчас выпить таблетку какую-нибудь, а потом всё же сесть и написать штуку по английскому лол и хотя бы начать делать русский лол. Это всё какое-то уныние. Ноги теперь болят в смысле ну, мышцы, после вчера, поэтому ничего не сделал.
Кстати, про манкрафт, я чего-то задумался, можно ли фармить песок в манкрафте, и я в комментариях на ютубах увидел такое на смежную тему:
>Do you know what I just found out while browsing through the Minecraft Subreddit? There is this thing with villagers that if you're holding an item that they want, they'll hold the item they're offering for it. So far so good.
>The post I just found claimed that if you kill the village while they do this, they'll have a chance to drop the item they're holding as an equipment drop. I was skeptical at first, so I tested in-game and it actually worked! You can effectively steal from villagers!
>And the best part of it: It also work with the one trade that's normally non-renewable... The Emerald + Gravel = Flint trade. So you can kill Fletchers for Flint, making it (and, by extension, the fletching table) renewable. Fortunately, Gravel itself will be renewable through bartering in 1.16, so you won't need to murder several Fletchers for Flint anymore.
Надо бы проверить самому, потому что как-то про это не очень много пишут, либо я не умею гуглить (на самом деле я даже не гуглил).
А песок, видимо, конечен: его можно либо выкопать, либо в сундуках в пустынном храме (возможно, ещё в каких-то treasure сундуках можно найти). Но вроде его можно дюпать, причём уже очень давно. Как раз илманго относительно недавно делал дюпер песка жесть они там ломают фрейм портала в энд грибами, не знал о таком https://youtu.be/qG9kDi5PeqA?t=457 и там вот такой дюпер https://youtu.be/qG9kDi5PeqA?t=535
Кстати, тнт дюперы хотят вроде выпилить (мне лень искать твиты какого-то разраба из моджанга, которые намекают на это), это интересно, потому что в таком случае непонятно, как делать дыры в земле в промышленных масштабах. Ну, даже, если накопаешь руками / надюпаешь много песка и сделаешь кучу тнт, то тебе же придётся вручную их закапывать в землю или сбрасывать сверху в одну точку, потом в другую, потому что без MBE нельзя сделать летающую штуку, которая будет бомбардировать землю https://youtu.be/PqEyv1sk_rY
Я не очень следил за новыми снапшотами 1.17, там ничего прямо нового просто не было пока что: только пушистый снег по сути. Кстати, пушистый снег можно ставить диспенсером, это интересно, потому что я не вижу больше ни одного блока, который можно было бы поставить https://minecraft.gamepedia.com/Dispenser Но опять же, без MBE не вижу особых применений этому. Не знаю, надо потом посмотреть, какие кто применения уже придумал. Единственное, что я понял - фармить этот новый снег очень долго: надо афкшить около котлов, на которые сыплет снег https://youtu.be/dmo0rT4r7Po
167 Кб, 1378x2039Я сегодня тупил на каких-то бесполезных парах и ничего не понимал вообще. Устал от криков, я просто не вывожу, когда кто-то ругается и мне плохо становится, когда кто-то разговаривает на повышенных тонах, хорошо, что хоть меня в последнее время никто не трогает. С утра болит голова и я почему-то не догадался выпить таблетку до сих пор. Я связываю это с тем, что непонятно как сплю и с тем, что стал кофейным наркоманом да, я считаю, что намеренно путать паронимы - это очень смешно потому что после кофе голова по крайней мере начинает болеть чуть меньше.
На хтмл было про кучу вещей в джамбаскрипте, я сначала ещё старался воспринимать, о чём идёт, но потом потерялся, слишком много всего и когда сам не пробуешь написать, то не воспринимается. В какой-то момент усышал про промисы и подумал про себя, о, это я знаю, а потом снова потерялся.
Надо бы сейчас выпить таблетку какую-нибудь, а потом всё же сесть и написать штуку по английскому лол и хотя бы начать делать русский лол. Это всё какое-то уныние. Ноги теперь болят в смысле ну, мышцы, после вчера, поэтому ничего не сделал.
Кстати, про манкрафт, я чего-то задумался, можно ли фармить песок в манкрафте, и я в комментариях на ютубах увидел такое на смежную тему:
Надо бы проверить самому, потому что как-то про это не очень много пишут, либо я не умею гуглить (на самом деле я даже не гуглил).
А песок, видимо, конечен: его можно либо выкопать, либо в сундуках в пустынном храме (возможно, ещё в каких-то treasure сундуках можно найти). Но вроде его можно дюпать, причём уже очень давно. Как раз илманго относительно недавно делал дюпер песка жесть они там ломают фрейм портала в энд грибами, не знал о таком https://youtu.be/qG9kDi5PeqA?t=457 и там вот такой дюпер https://youtu.be/qG9kDi5PeqA?t=535
Кстати, тнт дюперы хотят вроде выпилить (мне лень искать твиты какого-то разраба из моджанга, которые намекают на это), это интересно, потому что в таком случае непонятно, как делать дыры в земле в промышленных масштабах. Ну, даже, если накопаешь руками / надюпаешь много песка и сделаешь кучу тнт, то тебе же придётся вручную их закапывать в землю или сбрасывать сверху в одну точку, потом в другую, потому что без MBE нельзя сделать летающую штуку, которая будет бомбардировать землю https://youtu.be/PqEyv1sk_rY
Я не очень следил за новыми снапшотами 1.17, там ничего прямо нового просто не было пока что: только пушистый снег по сути. Кстати, пушистый снег можно ставить диспенсером, это интересно, потому что я не вижу больше ни одного блока, который можно было бы поставить https://minecraft.gamepedia.com/Dispenser Но опять же, без MBE не вижу особых применений этому. Не знаю, надо потом посмотреть, какие кто применения уже придумал. Единственное, что я понял - фармить этот новый снег очень долго: надо афкшить около котлов, на которые сыплет снег https://youtu.be/dmo0rT4r7Po
На хтмл было про кучу вещей в джамбаскрипте, я сначала ещё старался воспринимать, о чём идёт, но потом потерялся, слишком много всего и когда сам не пробуешь написать, то не воспринимается. В какой-то момент усышал про промисы и подумал про себя, о, это я знаю, а потом снова потерялся.
Надо бы сейчас выпить таблетку какую-нибудь, а потом всё же сесть и написать штуку по английскому лол и хотя бы начать делать русский лол. Это всё какое-то уныние. Ноги теперь болят в смысле ну, мышцы, после вчера, поэтому ничего не сделал.
Кстати, про манкрафт, я чего-то задумался, можно ли фармить песок в манкрафте, и я в комментариях на ютубах увидел такое на смежную тему:
>Do you know what I just found out while browsing through the Minecraft Subreddit? There is this thing with villagers that if you're holding an item that they want, they'll hold the item they're offering for it. So far so good.
>The post I just found claimed that if you kill the village while they do this, they'll have a chance to drop the item they're holding as an equipment drop. I was skeptical at first, so I tested in-game and it actually worked! You can effectively steal from villagers!
>And the best part of it: It also work with the one trade that's normally non-renewable... The Emerald + Gravel = Flint trade. So you can kill Fletchers for Flint, making it (and, by extension, the fletching table) renewable. Fortunately, Gravel itself will be renewable through bartering in 1.16, so you won't need to murder several Fletchers for Flint anymore.
Надо бы проверить самому, потому что как-то про это не очень много пишут, либо я не умею гуглить (на самом деле я даже не гуглил).
А песок, видимо, конечен: его можно либо выкопать, либо в сундуках в пустынном храме (возможно, ещё в каких-то treasure сундуках можно найти). Но вроде его можно дюпать, причём уже очень давно. Как раз илманго относительно недавно делал дюпер песка жесть они там ломают фрейм портала в энд грибами, не знал о таком https://youtu.be/qG9kDi5PeqA?t=457 и там вот такой дюпер https://youtu.be/qG9kDi5PeqA?t=535
Кстати, тнт дюперы хотят вроде выпилить (мне лень искать твиты какого-то разраба из моджанга, которые намекают на это), это интересно, потому что в таком случае непонятно, как делать дыры в земле в промышленных масштабах. Ну, даже, если накопаешь руками / надюпаешь много песка и сделаешь кучу тнт, то тебе же придётся вручную их закапывать в землю или сбрасывать сверху в одну точку, потом в другую, потому что без MBE нельзя сделать летающую штуку, которая будет бомбардировать землю https://youtu.be/PqEyv1sk_rY
Я не очень следил за новыми снапшотами 1.17, там ничего прямо нового просто не было пока что: только пушистый снег по сути. Кстати, пушистый снег можно ставить диспенсером, это интересно, потому что я не вижу больше ни одного блока, который можно было бы поставить https://minecraft.gamepedia.com/Dispenser Но опять же, без MBE не вижу особых применений этому. Не знаю, надо потом посмотреть, какие кто применения уже придумал. Единственное, что я понял - фармить этот новый снег очень долго: надо афкшить около котлов, на которые сыплет снег https://youtu.be/dmo0rT4r7Po
1,5 Мб, mp4,576x1024, 0:09
>>24029
Я не в плане «нужно будет придумать способ, как ссылаться не слишком далеко», я просто в плане «нужно будет переходить на 32-битные индексы по достижении 32767 узлов, а не 65535», или «32-битными индексами можно будет адресовать всего 2 миллиарда узлов, а не 4, какая жалость».
Ничего не нужно вставлять в середину массива, для удаления узла с индексом rem нужно поместить на его место последний — (n − 1)-й, и исправить ссылки с (n − 1) на rem, которые могут быть в 4 местах: nodes[n−1].parent.left/right (одно из двух), nodes[n−1].left/right.parent (оба), а также root. (https://ideone.com/9ZOgFD) Можно даже следить, чтобы root всегда был в ячейке 0, и если балансировка выбрала новый корень — обменивать его с 0 с аналогичным исправлением ссылок на оба.
Все временные разбалансировки отслеживаются в локальном контексте, будь то параметр, локальная переменная или точка исполнения, не нужно ничего писать в узлы, это нарушение принципа, который я не могу сформулировать.
>Хм, интересно, как это реализовать можно.
Я не в плане «нужно будет придумать способ, как ссылаться не слишком далеко», я просто в плане «нужно будет переходить на 32-битные индексы по достижении 32767 узлов, а не 65535», или «32-битными индексами можно будет адресовать всего 2 миллиарда узлов, а не 4, какая жалость».
Ничего не нужно вставлять в середину массива, для удаления узла с индексом rem нужно поместить на его место последний — (n − 1)-й, и исправить ссылки с (n − 1) на rem, которые могут быть в 4 местах: nodes[n−1].parent.left/right (одно из двух), nodes[n−1].left/right.parent (оба), а также root. (https://ideone.com/9ZOgFD) Можно даже следить, чтобы root всегда был в ячейке 0, и если балансировка выбрала новый корень — обменивать его с 0 с аналогичным исправлением ссылок на оба.
>у кого-то фактор временно по модулю больше единицы, а это недопустимо, если у нас в распоряжении только 2 бита
Все временные разбалансировки отслеживаются в локальном контексте, будь то параметр, локальная переменная или точка исполнения, не нужно ничего писать в узлы, это нарушение принципа, который я не могу сформулировать.
>>24062
А, да, ясно. Какой же я тупой.
Каждый раз забываю про этот способ в похожих ситуациях. Какой же я тупой x2.
Тернарный оператор как lvalue (я чего-то не уверен, что правильно использую это слово, там, оказывается, до фига этих что-то тамvalue короче, слева от знака равно, вот) смешной. Я про него знал, но всё равно забавный способ записать в одну строку присваивание трём возможным переменным.
Интересная идея с тем, чтобы возвращать из find то, каким потомком, левым или правым, является вершина с искомым ключом. Я бы тупо забил и проверял каждый раз через равенство как вот на 63 строке. Кстати, если бы я это делал, то тут обязательно бы ошибся, не подумав, что rlm может быть тупо правым потомком node.
rlm (и тем более порождённые им rlmp и rlmr) какие-то не очень удачные наименования, мне страшно стало, когда увидел. Мне больше нравится succ.
Прикольно, да, получилось, небольшая милая си плюс плюсовая штука. Ну и я хотя бы почи тал си плюс плюсовый код.
Ээ, да, ты прав third time's a charm я даже не знаю, к месту ли, наверное, нет, это же больше про то, что что-то получается на третий раз, а не случается три раза. Но мне так не нравится русскоязычный аналог с троицей или что там. эти повороты же все происходят behind the scenes, нет смысла делать так, чтобы они были как самодостаточные единицы интерфейса взаимодействия с деревом. По духу примерно то же самое, что и с тем, что для локально использующихся функций нет смысла выбрасывать исключения. По крайней мере в моей голове. Или нет. Больше же про то, чтобы не лезть руками внутрь дерева раньше времени.
>32-битными индексами можно будет адресовать всего 2 миллиарда узлов, а не 4
А, да, ясно. Какой же я тупой.
>для удаления узла с индексом rem нужно поместить на его место последний
Каждый раз забываю про этот способ в похожих ситуациях. Какой же я тупой x2.
Тернарный оператор как lvalue (я чего-то не уверен, что правильно использую это слово, там, оказывается, до фига этих что-то тамvalue короче, слева от знака равно, вот) смешной. Я про него знал, но всё равно забавный способ записать в одну строку присваивание трём возможным переменным.
Интересная идея с тем, чтобы возвращать из find то, каким потомком, левым или правым, является вершина с искомым ключом. Я бы тупо забил и проверял каждый раз через равенство как вот на 63 строке. Кстати, если бы я это делал, то тут обязательно бы ошибся, не подумав, что rlm может быть тупо правым потомком node.
rlm (и тем более порождённые им rlmp и rlmr) какие-то не очень удачные наименования, мне страшно стало, когда увидел. Мне больше нравится succ.
Прикольно, да, получилось, небольшая милая си плюс плюсовая штука. Ну и я хотя бы почи тал си плюс плюсовый код.
>Все временные разбалансировки отслеживаются в локальном контексте
>не нужно ничего писать в узлы
Ээ, да, ты прав third time's a charm я даже не знаю, к месту ли, наверное, нет, это же больше про то, что что-то получается на третий раз, а не случается три раза. Но мне так не нравится русскоязычный аналог с троицей или что там. эти повороты же все происходят behind the scenes, нет смысла делать так, чтобы они были как самодостаточные единицы интерфейса взаимодействия с деревом. По духу примерно то же самое, что и с тем, что для локально использующихся функций нет смысла выбрасывать исключения. По крайней мере в моей голове. Или нет. Больше же про то, чтобы не лезть руками внутрь дерева раньше времени.
1,1 Мб, 1800x1152А, я не смог себя заставить ничего делать. Только вот сейчас смог сделать английский только из-за того, что дедлайн. Мне очень тяжело выдавать из себя английские слова, очень мало опыта в этом, маленький словарный запас и плохие знания грамматики. Спасибо практике через видео пьюдипая и летсплеи по манкрафту, что ещё хотя бы как-то на слух воспринимаю его. И там обычно такие темы, что у меня нет идей, что писать. Да и в целом со своим личным мнением как правило туговато, из-за этого каждый раз какой-то стыдный мусор выплёвываю из себя.
Я, наверное, пойду спать, короче, я не могу не хочу ничего и вообще грустно.
Я, наверное, пойду спать, короче, я не могу не хочу ничего и вообще грустно.
413 Кб, 2048x1894Весь день ничего не делал. Сейчас всё же надо попытаться себя заставить себя сделать какие-то домашние задания.
![Screenshot2020-11-22 169 595 quattuordecillion cookies - Co[...].jpg](https://2ch.hk//dr/src/412083/16060747509631.jpg)
>>15919
Не могу ничего заставить себя делать, я хочу лежать и ничего не делать, я лежу и ничего не делаю, жду, когда растения мутируют. Мне тошно даже от мысли о том, что надо что-то делать, я просто не могу.
Не могу ничего заставить себя делать, я хочу лежать и ничего не делать, я лежу и ничего не делаю, жду, когда растения мутируют. Мне тошно даже от мысли о том, что надо что-то делать, я просто не могу.
265 Кб, 1744x2048Да, короче, всё, не хочу ничего, не могу заставить себя учиться, то же самое, что и в прошлом году, уже бесполезно противиться этому. Вообще не ощутил, как прошло время. Комбинация тупости и лени. Можно забить и не мучить себя. Просто, видимо, действительно бывает, что рождаются никчёмные дегенераты, и мне не повезло оказаться одним из них.
1 Мб, 1200x1600Я не помню, что было в последние несколько дней, просто белое пятно какое-то. Вроде с очень переменным успехом пытался заставлять себя делать что-то для тупой учёбы, с трудом получается, половину дня после пробуждения нахожусь в состоянии совсем овоща, в голове каша, ничего не могу делать: либо слоняюсь по комнатам, либо в интернет туплю. Только спустя несколько часов более-менее просыпаюсь. Ничего не успеваю. Это выглядит как какая-то тупая компьютерная игра с кучей неинтересных заданий, которые надо выполнить. Хорошо, что хоть выходить на улицу не надо, но даже несмотря на это, всё равно я уже почти жалею о том, что у нас всё удалённо, и однозначно жалею о том, что где-то числюсь студентом, потому что из-за этого приходится делать кучу какой-то стыдной хуйности по типу разговоров с преподами по ебучему микрофону, сука, записи на видео того, как ты делаешь упражнения по физкультуре, вебкамера, это пиздец с учётом того, что меня от вида моего ебла блевать тянет, вообще не вывожу. Не могу, мне тошно от всего, плохое настроение и всё раздражает, я хочу просто лежать и ничего не делать. Сейчас сижу и в голове тупо пусто, потому что я забыл выпить блядский кофе, и до сих пор не могу проснуться.
Понял, что лежать за компом - это полнейшая хуета, неудобно и потом болит спина.
Понял, что лежать за компом - это полнейшая хуета, неудобно и потом болит спина.
Тред утонул или удален.
Это копия, сохраненная 30 июля 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 30 июля 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.