Category: отзывы

Category was added automatically. Read all entries about "отзывы".

doomguy

Побочные эффекты "Спутника-V"

В четверг наконец-то получил первую дозу. Никаких проблем: колют совсем чуть-чуть, 0,5 мл, в плечо. У меня ничего не распухло, рука не отнималась, ну разве что под вечер "на всякий случай" померял температуру: 37,1. А на следующее утро уже 36,6.

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

На прошлой неделе я точно также ездил на работу на том же велосипеде, по тому же маршруту, в той же одежде, но такой фигни не было, определённо это вакцина :)

Ну зато через 3 недели смогу попасть на территорию РКК Энергия, совершенно бесплатно! Вот бы ещё макет к тому времени запустить.

PS. Бонусный огарь, ему чего-то тоже тяжело, клюв раскрыл.
QuatCore

Алг. ближней дистанции, поиск "центральных" точек

Если помните, мишень ближней дистанции у нас трёхмерная: 6 уголковых отражателей стоят в одной плоскости, а ещё два, что по центру - вынесены вперёд:
IMG20201021153945.jpg
(см. макет: да будет свет)

поэтому, в зависимости от того, с какой стороны на неё смотришь, центральные точки могут очень хорошо гулять во все стороны:


Основная логика пока такова: у нас ракурс согласно ТЗ не может составить более 30°, и центральная точка всё-таки ограничена в своём перемещении. По последним данным, она вынесена вперёд на 6 см (вообще данная мишень должна иметь глубину не более 9,5 см, но уголковые отражатели тоже некоторую глубину имеют, особенно в своих оправках), поэтому при повороте на 30° может сместиться на 3,5 см, тогда как 3 уголка, лежащие на плоскости, отстоят каждый на 5,5 см.

Поэтому просто ищем точку, расстояние которой до "центральной позиции" (где точка стоит при взгляде под прямым углом) минимально

"Центральные позиции" можно сколько-нибудь точно поместить на отрезок, соединяющий наиболее отдалённые точки, его мы уже находили. Если назвать эти точки P6 и P7, то координаты "центральных позиций" выйдут:

0,7914P6 + 0,2086P7 и
0,2086P6 + 0,7914P7.

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

Впрочем, компьютерное моделирование показало, что всё не так просто, и на углах вблизи 30° бывают сбои. Вот тут ещё всё правильно:


(с нумерацией просто беда. Здесь точкам даны те номера, что в техническом задании на мишень. Вот чья-то левая пятка решила дать такую нумерацию - теперь будь добр используй. Вынесенные вперёд точки имеют номера 1 и 2. Затем перечисляются точки слева, а затем точки справа)

А здесь, буквально кадром позже:


Чудеса, да и только! Поначалу я грешил на перспективу, из-за которой так легко делить отрезки на части не получается, поскольку масштаб плавно меняется.

Collapse )

на этот этап требуется аж 30 слов кода, или 60 байт. Всего "алгоритм ближней дистанции" пока что занимает 81 слово кода, или 162 байта. И кто-то после этого скажет, что ассемблер - не выразительный, очень громоздкий язык!?

Осталось это дело проверить, а потом ещё один кусочек - "случай Берегового".
QuatCore

Алг. ближней дистанции, сортировка "слева направо"

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



то есть, два самых крупных индекса, 6 и 7, стали принадлежать "крайним" точкам. Теперь всех оставшихся надо отсортировать вдоль отрезка, соединяющего точки 6 и 7. Попробуем написать процедуру на ассемблере, делающую именно это.

Collapse )

Вся программа "алгоритма захвата ближней дистанции" сейчас занимает 54 слова кода (108 байт), из которых 9 слов будут "общими" с алгоритмом дальней дистанции, 25 слов - "поиск двух наиболее отдалённыхточек" и 19 слов - наша "сегодняшняя" сортировка. Сейчас попробуем всё это запустить...
Doc

Более тяжёлые тела падают быстрее!

Увидел не так давно видео от Flammable Maths с таким заголовком, и подумал поначалу - он опять нас троллит. Это немецкий препод математики (насколько я знаю), и чувство юмора у него очень специфическое, особенно любит над инженерами издеваться, дескать e=π=3, cos(x) = 1, sin(x) = x.

Но нет, всё корректно: в безвоздушном пространстве, согласно законам Ньютона, тяжёлые тела действительно будут падать быстрее!

Быстренько изложу своими словами. Есть объект массой m и Земля массой M. На объект со стороны Земли действует сила



И согласно 2-му закону Ньютона она придаёт ему ускорение:



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



Ускорение зависит лишь от массы Земли и расстояния до неё, и не зависит от массы самого объекта, что как бы говорит все тела падают одинаково.

Вот только мы кое-чего забыли!

Collapse )
QuatCore

Супрематический алгоритм обнаружения на ассемблере готов!

Ладно, прекратим рассматривать два обособленных варианта, обойдёмся без AUP (Acquire UPdate, команда для видеопроцессора, чтобы не добавлять новое задание на обработку, а откорректировать уже отправленное).

Ещё возникла идея, что отказавшись от сравнения яркостей точек (только сравнение с порогом), мы могли бы и не получать яркость как таковую, лишь индикацию, что она выше пороговой. И работай мы исключительно с командой ACQ, это действительно уменьшило бы размер выходного буфера (вместо 8..12 бит на каждую яркость хватило бы 1 бита - "выше или ниже порога") и на пару слов объём кода. Но для TRK (TRacKing) - нахождения яркостного центра с субпиксельной точностью - всё равно эти биты в выходном буфере нужны, поэтому заморачиваться не хочу! Пущай будет как есть, в конце концов нам удалось скрестить ежа с ужом, т.е сумматор яркостей с обнаружителем самого яркого пикселя! (и подправленный вариант)

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

Начнём с первой:

TaskPending proc
		ABS	C
		JNO	[SP]		;вот в чём прелесть стека без инкремента!
		;если дошли до сюда, заказываем отрезки на обработку
AckNoCheck:	Acc	[X+2j+k]
		DIV2S	[X+1]	;теперь в аккмуляторе у нас X - Ceil(D/2)
		ACQ	Acc		;первый отрезок
		ADD	[X+1]	;а вот теперь X + Floor(D/2)
		ACQ	Acc		;второй отрезок
		JMP	[SP]
TaskPending endp	


Collapse )

Попробуем хотя бы откомпилить всё это безобразие. Старая версия компилится в 206 слов кода (412 байт) и 329 слов данных (658 байт), это "весь проект": выставить тактовую частоту 25 МГц, инициализировать ЖК-экранчик и выдать на него "приветствие", обработать кадр и выдать в удобочитаемом виде результаты этой обработки, а затем передать дамп памяти, и его же передать в случае какого-то из прерываний или нехватки памяти.

Новый алгоритм больше не требует запоминать яркость обнаруженных точек (нам хватает, что она превышает порог), поэтому можно сократить каждый элемент списка с 5 до 4 слов.

Компилиться он сходу не захотел, возмутился на команду [Z+2j], которой у нас нет, есть взамен [Z+2j+k] (и мы решили, что k=0 на всём протяжении, также как и j=1). Да, ошибся малость.

Далее ему не понравилась строка
@@MidCycle:	%CheckHazards OFF


ну да, привередливый, поэтому сделал метку всё-таки по самой команде:
		%CheckHazards OFF
@@MidCycle:	X		[X+k]


Потом он не нашёл метку ActPointsStart, и правильно сделал: о собаках-то я и забыл, @@ActPointsStart. Затем не нашёл ProcessFrame::AckNoCheck, и снова был прав, эта метка называлась AcqNoCheck, и была без "собак" (а значит никаких ProcessFrame::). Та же фигня с TaskPending.

И, наконец, оно откомпилилось, выдав ещё 2 Hazard'a (и автоматически их исправив добавлением NOP). Как результат получается 248 слов кода (496 байт) и 297 слов данных (594 байта) Понятно, 64 байта сэкономили в оперативке (за счёт 32 элементов списка обнаруженных пятен, где по слову откусили), но вот код усложнился...

Но есть шанс, что он по крайней мере будет работать :)
QuatCore

Опять периодическая таблица АЛУ

Не даёт оно мне покоя, попробовал разобраться, что делают "недокументированные" команды АЛУ. Похоже, их вполне можно задокументировать - они выполняют осмысленные вещи, но пока они были не нужны. А вот нужные мне команды сюда не попали.



Рыжие ячейки - куда можно было бы впихнуть нужные мне CMP и UDIV2. Красная - где команда с "побочным эффектом", из-за чего хоть назвать её осмысленно сложно. Серые - все остальные "недокументированные".

Collapse )

Poll #2098362 QuatCoreALU

Стоит ли добавить команды CMP и UDIV2

Да!
1(25.0%)
Добавить CMP
0(0.0%)
Добавить UDIV2
0(0.0%)
Сначала программу дописать, если чуть-чуть не влезет - добавить
3(75.0%)
Нет.
0(0.0%)
QuatCore

Жуткая адресация QuatCore

У меня продолжаются "душевные терзания". Остался один модуль, QuatCoreMem, в котором содержится 4 регистра для работы с памятью: X, Y, Z, SP. Их ширина совпадает с шириной шины адреса ОЗУ, пока что вообще 8 бит, если совсем прижмёт - станет 9 бит.

По изначальной идее, каждый из них играл совершенно определённую роль: каждый раз, когда мы производим операцию над двумя объектами, будь то умножение кватернионов, поворот вектора с помощью кватерниона, умножение матриц и пр. - X должен указывать на первый (левый) операнд, Y - на второй (правый), а Z - на результат. SP - это Stack Pointer, как полагается, отвечает за стек.

И чтобы программа имела компактные размеры и не тратила больше половины времени на "перекладывание из порожнего в пустое" (cat /dev/zero > /dev/null), мне хотелось ввести все необходимые режимы адресации, чтобы адрес каждого операнда и результата вычислялся прямо "на ходу" как раз в модуле Mem.

Пока писал программу - ни в чём себе не отказывал - нужно обратиться как-то хитро - добавлял соответсвующий адрес - "потом реализую". Вот пришла пора реализовывать, я выписал все варианты - и схватился за голову. Их вроде бы не так много - 21 адрес для SRC и 20 адресов для DEST, при том, что и на то, и на другое доступно 64 адреса. Но сколько-нибудь логичная система тут отсутствует напрочь!!!

Collapse )

Фух, по-моему решение найдено...
64 адреса делится почти "ортогонально", 3 раза на 4 части:

старшие 2 бита указывают "базовый регистр": X, Y, Z, SP,
средние 2 бита указывают первый индексный регистр:
4i (рег. X, Z), либо Treug(j) (рег. Y), либо 2i, либо 2j, либо 0,
младшие 2 бита указывают второй индексный регистр:
k, либо i, либо 1, либо i^k (рег. X, Z), либо i^j (рег. Y).

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

UPD. Ах да, ещё забыл команды для инициализации этих регистров и PUSH/POP для стека. Вот думаю, может сами регистры тоже перетащить в QuatCorePC, там вроде были ещё свободные места...

Дождались!

Есть вещи, которые, кажется, никогда не будут выпущены:
- Half-life 3,
- новые тома "Искусства программирования" Дональда Кнута,
- окончание "Песни льда и пламени"
- моя книжка по кватернионам, а также окончание циклов про теоретический кпд солнечных батарей, про уравновешенное троичное быстрое преобразование Фурье, хотя бы альфа-версия ScanCombine

Но недавно товарищ Freeman-47 выпустил ещё один "долгострой", который вселяет огромную надежду!
Collapse )

Мышки плакали, кололись,

но продолжали смотреть Доктора Кто...

Что-то не то, всё-таки. Какая-то бессмыссленность происходящего, простые сюжеты. Расизм - это плохо, экология - это хорошо, оружие - это плохо, убивать пауков - плохо, согнать пауков в замкнутый объём и запереть их, чтобы пожрали друг друга - это хорошо. LOL WAT?

Collapse )