Комментарии 227
паскалевские конструкции вида FOR N := 1 TO N DO излишне нагружают ALU либо превращаются в квест для компилятора.Не это ли, внезапно, является причиной тормознутости циклов в Matlab (который тоже 1-based)?
Это как раз заводы факторио напоминают микросхемы.
TL;DR: RTX — www.youtube.com/watch?v=7lVAFcDX4eM
FFF — www.factorio.com/blog/post/fff-176
Не так давно в статье про запуск Bad Apple в диспетчере задач была ссылка на запуск оного же в factorio, так что рендеринг чего бы то ни было уже не новость.
Вот та статья, если что. Я как-то мимо неё прошёл, хотя это забавно.
Этот FFF – кажется, именно тот самый, с которого я начал знакомство с Факторио и вообще осознал, что сырые алгоритмы очень даже имеют место в геймдеве, да и в разработке в целом. То есть это понимание было, но на уровне "%игра% работает тормозно, что-то они там недооптимизировали" – но было неясно, что и как можно оптимизировать, а тут как раз наглядный частный случай.
Если мне не изменяет память, тогда переход от "предмета как объекта, перемещаемого конвейером" к "конвейеру как контейнеру списка предметов" помог снизить нагрузку на процессор, но привнёс странное поведение предметов на поворотах. В любом случае, спасибо за хорошую игру. ^_^
А с нумерацией, начиная с 1, даже сами человеки путаются: с какого года начинается третье тысячелетие, с 2000 или 2001? И если правильный ответ — второй, то почему праздновать больше тянет наступление первого? А с естественной нумерацией все просто: 1967 — это год 19 века и 1-го тысячелетия и праздновать надо круглые числа.
Естественная нумерация — это с нуля?
почему праздновать больше тянет наступление первого?
Потому что можно раньше начать пить путают порядковые числительные (идёт 2000-й год) с собирательными (прошло 2000 лет, и начался 2001-й)
Косинус первичен, потому что исторически первичен секанс, который, кстати, направлен вдоль первичной оси.
https://lez.m.wikipedia.org/wiki/Файл:Circle-trig7.svg
Объявление переменной типа массив в Паскале:
var
v: array[idx1..idx2] of sometype;
idx1 и idx2 могут быть даже отрицательными, главное чтобы idx2 > idx1.
так что вариант
a: array[0..9] of integer;
вполне себе вариант.
Даже если говорить про динамические массивы вида
a: array of integer;
то и там первый элемент будет a[0].
Или я чего-то путаю из школьной программы?
Массив в паскале может быть объявлен по любому диапазону любого скалярного типа.
Это автор попутал со строками в Turbo Pascal/Delphi. Там действительно 1-based (в старых версиях, в новых версиях это можно переключать опциями, а для некоторых мобильных платформ вообще сделали 0-based по умолчанию, что IMHO породило лютый беспорядок и вроде бы потом всё вернули взад).
1. Shortstring в Delphi — массив самый что ни не есть статический, размер задается при объявлении (255 по умолчанию). Текущая длина строки — да, лежит в 0-м байте.
2. В стандарте паскаля конкретная реализация строк никак не прописана (по крайней мере ранее не была, сейчас уже не знаю). Просто Борланд сделали так, как сделали…
3. В динамических массивах Delphi длина действительно хранится перед началом, но это скорее "-1" элемент, т.к. динамические массивы (относительно недавнее изобретение) как раз-таки 0-based :) Ага, и так у них всё…
Обычно обе вонючих шизы — биг эндиан и 1-бейс идут рука об руку (ещё и десятичная пихается система там где не надо, да). Байт в дворде с весом 2560 имеет номер 4, 2561 — 3-й, 2562 — 2-й, 2563 — 1-й. Любая работа с вложенными диапазонами — постоянная необходимость добавлять-вычитать единичку чтобы перейти от «номера» к нормальному смещению. Плеваться хочется от кривости и бессмысленности! Но им так привычно видите ли… При этом даже сами не могут решить как надо — даты нумеруют с 1 числа, а время — с 0 часов. Сами постоянно наступают на свои грабли: 21-й век — это 2000-е, причём начинается он с 2001 — они сами в этом путаются, но всё равно рьяно защищают свой дебильный 1-бейс. И ни чуть не смущаются!
Два главнейших врага разума — это привычки и инстинкты…
Два главнейших врага разума — это привычки и инстинкты…У человека инстинктов не так уж и много, и наблюдать их можно в полном объёме уже у новорождённых.
Да их и у моей кошки не так уж и много. Я как-то считал, что она руководствуется от силы двумя дюжинами стимулов, притом отклик у неё — почти всегда на инстинктах.
То же и у человека: в зависимости от обстоятельств, есть «непреодолимые» желания, которые один из двух главнейших врагов разума не даёт называть инстинктами, несмотря на объективные данные. Только у человека пути воплощения этих желаний могут быть изощрённее. А если подумать, глобальные цели людей почти всегда можно свести к инстинктам. Лучше жить (в частности, иметь больше зарплату, изобретать новые полезные вещи или, наоборот, сжигать вышки 5G) → иметь больше шанс завести потомство, обеспечить его лучшей жизнью, дать ему больше шансов на выживание.
Такая же беда была у Texas Instruments в их старых разработках — например, в TMS9918, где мозг взрывается от нелогичности нумерации при чтении документации, пока не сообразишь, что биты адреса у них нумеруются в одну сторону, а биты данных — в другую. Что, впрочем, логичности не добавляет. :)
"Косяк" с заимствованием вместе с "арабскими цифрами" ещё и арабскую запись чисел справа-налево вроде понятен. И я даже могу представить себе как бы это могло выглядеть и использовалось бы при "правильной" записи слева-направо. Но не хватает фантазии представить как бы это звучало в устной речи (и записи чисел словами). По моему в этом контексте как раз более важным является порядок числа, который в текущем виде озвучивается первым (две тысячи четыреста одиннадцать). Точно так же как он и записывается цифрами (2411). Так что может всё дело не в арабском справа-налево, а в том как было удобнее числа озвучивать устно?
Время традиционно тоже (25 минут двенадцатого).
Запись времени, так или иначе, была и остаётся именно такой.
Где-то была, где-то не была.
Да, если вы когда-нибудь набирали на дисковом телефоне «08», то должны были бы вспомнить формат ответа. :)
Там это было вызвано техническими ограничениями, чтобы из пары десятков записанных слов собирать все возможные ответы.
ну логика тут двояковыпуклая — раньше то что чаще меняется, а так то вы конечно правы, год-месяц-число было бы как цифры
Да, нет ничего лучше ISO-8601!
Особые извращённые
Ага, и имя им «американцы» :)
И я даже могу представить себе как бы это могло выглядеть и использовалось бы при «правильной» записи слева-направо. Но не хватает фантазии представить как бы это звучало в устной речи (и записи чисел словами).
В немецком, например, 42 произносится «два и сорок», в чем проблема?
Как вообще произносить десятки сотни и другие разряды, если они идут после?
Это вам к лингвистам. Как правильно произносить они решают. Мы тут решаем как удобнее считать.
Чтобы два раза не вставать. Статья великолепна.
123 = раз два три
А цифры называются тоже логично:
2 to 3 te 4 fo 5 fe и т.п.
2 to 3 te 4 fo 5 fe и т.п.
Почему-то в голове сразу ассоциация с DTMF пошла :-)
А в японском (и, наверное, китайском тоже) есть отдельные группировки и для других порядков, например 1万 = 10000, в английском в обратку встречаются конструкции вида "$2500 = twenty-five hundred bucks". Думаю, нам про все эти форматы ещё многое предстоит узнать...
ЗЫ. В японском при этом слово, обозначающее "забитость, полную занятость" читается так же, как и "десять тысяч" — "ман", но имеет разное написание; напр. 満車 — парковка занята, 満席 — мест нет. Интересно, это тоже как-то связано? :-)
А ещё, по поводу степеней 10^3n, n>2, в нашем языке тоже есть странности, кмк. В английском всё вроде достаточно понятно: n=2 — million, 3 — bi-llion, 4 — tri-llion, 5 — quad(ri)-llion и т.д.
А у нас — 10^9 — миллиард, а потому многие говорят на 10^12 не триллион, а триллиард, а из тех кто так не делают, некоторые думают, что триллиард 10^21 идет за триллионом и т.п… Да, в англ. тоже есть milliard, но он по факту не используется.
Конечно, кто технарь, так не делают, но большинство людей — не технари.
а из тех кто так не делают, некоторые думают, что триллиард 10^21 идет за триллионом
Это называется "длинный счёт" и является стандартом во многих странах.
В английском всё вроде достаточно понятно: n=2 — million, 3 — bi-llion, 4 — tri-llion, 5 — quad(ri)-llion и т.д.
Там же — в Англии до сих пор есть следы длинного счёта. В США короткий счёт утвердился очень давно.
Конечно, кто технарь, так не делают, но большинство людей — не технари.
Многие технари знают про это различие.
Я лично за длинный счёт, он удобнее и логичнее. Но ломать местную легаси, скорее всего, не получится.
в английском в обратку встречаются конструкции вида
Английский бывает разный: в индийском официально используются числительные lakh (сто тысяч) и crore (десять миллионов), можете сами погуглить их c site:gov.in
Интересно, это тоже как-то связано? :-)
Нет: оба слова заимствованы из китайского, где было /muɑnX/ «занятость» и /mʉɐnH/ «десять тысяч». В нынешнем кантонском они тоже различаются гласной и тоном: mun5 против maan6. Японская фонетика не в состоянии передать такую разницу.
Но вообще в живых языках полной логичности обычно не наблюдается — начнут так, продолжат эдак. Видимо, счет до тысячи стал актуален на несколько веков позже, чем счет в пределах сотни, который стал актуален позже, чем счет до 20. (В русском языке такого тоже достаточно, родительный падеж при числительных до 4 — остаток двойственного числа. «Не штОрмы, а штормА»; «ветрА, не вЕтры».) В одном из европейских языков вообще круть: 98 = «трижды-шесть и четырежды-двадцать», для двадцати отдельное слово.
По-хорошему, надо посмотреть, как числа записывались буквами до появления цифр, в каком порядке. Это даст какую-то аргументацию в пользу того, какой порядок для какого языка считался более естественным. (У римлян IX — это «без одного десять», напоминает дедушкин счет времени, нам-то ближе 18:56.)
А еще есть гипотеза, что цифры — это первые буквы алфавита какого-то языка, от которого возможно больше ничего не осталось.
По-хорошему, надо посмотреть, как числа записывались буквами до появления цифр, в каком порядке.
Для моего нижеупомянутого примера (Быт 5:27) — и в Септуагинте (3в), и в Вульгате (4в) современный порядок числительных (big-endian). У вас есть примеры более старых текстов на европейских языках с трёхзначными (или более) числительными?
Но не хватает фантазии представить как бы это звучало в устной речи (и записи чисел словами).
Я уже приводил пример: biblehub.com/interlinear/genesis/5-27.htm
А сколько надо? 6+6? Тогда же ориентироваться в них сложно будет))
Куда более интересно, почему си-бекар стал белой клавишей в то время, когда им пользовались примерно с той же частотой, что сейчас буквой ё
Мне музыканты не могли объяснить, почему на 12 полутонов 7 белых и 5 чёрных клавиш.
Гамма Ля (первая в западной теории) белыми и полутона которые в нее не входят черными.
ru.wikipedia.org/wiki/Лад_(музыка)
Во многом это все привычка, конечно, да и «теория музыки» — это на самом деле «Теория европейской музыки 18го столетия».
guitarmagazine.ru/exotic-guitar-scales
Так что если судить по звучанию (на слух), а не по цветам клавиш, то 12 тонов вполне себе имеет смысл.
Но после баяна на фортепьяно перейти не смог — мозг категорически сопротивляется нелогичности расположению клавиш.
Видимо мы ещё долго будем «есть кактус» создавая проблемы сами себе, потому что «так исторически сложилось».
Кстати по работе при анализе процессов фраза «мы так всегда делали» основа 40% технологий.
Люди при всей глобализации до сих пор на метры и килограммы не перешли, и розетки до сих пор разные.
Не "людям нравятся сложности", а "рефакторинг такого масштаба слишком дорог" и "необходимо поддерживать совместимость с уже имеющимися на рынке решениями". Давайте хотя бы розетки: представим, что у нас страна, где в розетках привычные ~230 вольт, просто форма штекера своя. Давайте прикиним, сколько нужно времени и денег, чтобы заменить эти розетки во всех домах страны, потом на всех производствах техники, а потом — сколько ещё вбухать деньги в переходники для старой техники. В дальней перспективе наверное круто, но кто здесь и сейчас за это платить будет? ;-)
Некоторые страны в этом веке уже меняли стронность движения и ничего. Недавно в течении нескольких лет у нас в стране все приборы давления к системе СИ приводили.
что например РФ переходит на US/CH стандарт вилок (плоские прямоугольные)Дурацкие вилки, кстати. Маломощные и небезопасные. Да и в целом энергетика у буржуев так себе…
Уж нам переходить на американские стандарты так же полезно как переходить на дюймы…
Да и в целом энергетика у буржуев так себе…
США на 2 месте после Китая, например
Дурацкие вилки, кстати.
Legacy оно такое… В странах, которые электрифицировались позже, провели работу над ошибками.
НА самом деле круче было бы провести исследование какая вилка более оптимальна с учётом практики и т.д.
У плоской вилки есть свои плюсы, кстати на некоторых есть отверстия на конце и они зажимаются в розетке. Тут нужен мега- ТРИЗ исследование.
Вы просто на британскую ночью в темноте не наступали, после этого любая будет иметь преимущество :-)
А американские да, погоняешь фен паяльный полчасика, или вскипятишь три чайника подряд — уже и вилка с розеткой тёплые. 100 вольт, они-то тоже уменьшению тока при константной мощности не способствуют.
Недавно в течении нескольких лет у нас в стране все приборы давления к системе СИ приводили.
а еще более недавно — два раза в 1/5 части суши меняли TZ… Туда и назад.
Давайте прикиним, сколько нужно времени и денег, чтобы заменить эти розетки во всех домах страны, потом на всех производствах техники, а потом — сколько ещё вбухать деньги в переходники для старой техники.Так прямо сейчас это происходит(или произошло), когда одновременно сосуществуют вилки типа C и F, когда не каждую вилку не в каждую розетку вставишь. И если современные вилки от лампы или смартфона втыкаются и туда и туда, то советские приборы, как впрочем и современные с заземлением входят только в своё родное. В несколько меньшем масштабе это происходит с usb при переходе с b на c.
В дальней перспективе наверное круто, но кто здесь и сейчас за это платить будет? ;-)А кто простых людей спрашивает? Их просто перед фактом ставят. В том же Казахстане алфавит меняют(или не меняют, не слежу за новостями), уже третий раз за последние сто лет, с арабской вязи на кириллицу и теперь на латиницу. При чём, если с переходниками и удлинителями можно пользоваться ещё не одно десятилетие, то это будет полной потерей обратной совместимости.
При чём, если с переходниками и удлинителями можно пользоваться ещё не одно десятилетие, то это будет полной потерей обратной совместимости.
в РФ сделали реформу языка в 1917 вроде. И ничего. Все скушали это
я вам больше скажу. после арабской была латиница, и только потом кириллица.«Назад в будущее» там точно снимать нельзя.
И не исключаю, что З взяли как цифру три — т.е. как будто Кирилл с Мефодием намеренно сделали «рельсы другой ширины»
Нет, это было задолго до прихода индийских-арабских цифр. Хвостик у Z в скорописи загнулся вниз и удлинился.
Кирилл с Мефодием, сейчас считается, сделали глаголицу, а кириллицу в нынешнем смысле породили их ученики, заменив все символы, для звука которых были буквы в греческом, на греческие.
А что недолюбливают (кто? не думаю, что все чехи — большинству пофиг) — точно так же можно и латиницу недолюбливать. Зачем потребовалось западным грекам (и вслед латинянам) заворачивать хвостик у П так, что она превратилась в Р, отчего исходная Р потребовала нового элемента и превратилась в R? Зачем было устранять K и искусственно создавать новую букву G, хотя исторически именно C выполняла роль Г (и это она же по происхождению, только переведена в плавную форму)? Многие прочие замены понятны, но зачем было тут вводить несовместимость на пустом месте?
Да, кстати, еще забыл упомянуть, что Я — это развёрнутая R.
Изменение форм букв: H, N, Ѧ на И, Н, Я соответственно — реформа письменности 1708 года, закрепившая упрощённые формы из уже привычной скорописи. Дальше вслед за русской кириллицей это изменение постепенно было принято всеми прочими. Это общеизвестный факт, прослеженный многими исследователями по источникам.
Так что откуда вы взяли про "развёрнутую R" — непонятно, но давайте не делать поспешных упрощений. А то так можно придраться и к тому, что у немцев V значит [f], Z — [ts], а в английском и французском вообще фиг поймёшь, как читать какие-нибудь anxious/anxiety или eaux...
Для особо альтернативно одарённых в статье в Википедии про "Я" достаточно чётко всё объяснено, а откуда R взялось — даже гифчик нарисовали:
А в двухбуквенных/трехбуквынных сочетаниях ничего плохого нет, как мне кажется. Минусы бывают только если чтение будет неоднозначным, но это от языка зависит.
А в двухбуквенных/трехбуквынных сочетаниях ничего плохого нет, как мне кажется.
Проблемы с сортировкой: либо слова на «Х» идут посередине слов на «Ц», либо сочетания надо выделять и обрабатывать как отдельные буквы.
Ещё проблемы, когда сочетания идут подряд, как в фамилии Chruschtschow.
Я немецкий в школе учил, там S частенько читается как «ш» в сочетаниях с T и P (ну и в случае sch), и никаких проблем с сортировкой нет
Ну, я не знаю… В том же венгерском — сначала идет Z (и все слова с него), а потом ZS (потому что это диграф). Ну, не хватило в латинице знаков для обозначения всех звуков
Это не буква ( в смысле нет символа «dzs» — это «d» + «zs», в противовес к d + z
Позор мне
https://en.m.wikipedia.org/wiki/Hungarian_dzs
Спасибо, интересно
Операция целочисленного деления дорогая.
srsly? Я то думал, что остаток легко считается циклом ) Чай — не операции с плавающей точкой (там ад). И, да, будто паковка и распаковка из BCD не требует энергии (да, я помню, что есть аппаратные операции для этих операций)
srsly? Я то думал, что остаток легко считается циклом )
На очень мелких числах — да. Но уже на десятках тысяч это становится слишком дорого.
А целочисленное деление, да, самая дорогая операция в этой группе.
Чай — не операции с плавающей точкой (там ад).
Сейчас уже наоборот: Goldschmidt division — требует тщательной подгонки точности, но из-за характера чисел сейчас выполняется дешевле, чем целочисленное деление при тех же размерах значений.
Есть еще один момент, где 1..N индексация даёт себя знать по сравнению с [0;N) индексацией – это работа с float’ами.
Не понял, чем работа с массивами float принципиально отличается от массивов int.
А так да, legacy наше всё.
На 2 числа с плавающей точкой делить легко — просто -1 к показателю степени. И если 2 это константа, ничто не мешает так и скомпилировать.
А вот если бы был выбор между умножать на 3 и делить на 3, скажем — тут деление действительно намного хуже.
— кинетическая энергия m*v*v/2
— путь при равномерном ускорении a*t*t/2
— энергия конденсатора c*u*u/2
— энергия поля соленоида l*i*i*/ 2
В этом ряду площадь круга tau*r*r/2 была бы вполне логичной.
В манифесте Тау наглядно разъясняется, что использование 2π получается логичнее и последовательнее в большинстве формул, даже если изначально двойки там вроде и не было.
EDIT: ой, там ниже на него сослались уже, ну ладно %)
tauday.com/tau-manifesto
На практике намного чаще нужно отношение длины окружности к радиусуИ причём тут «чаще»? Как раз из-за того что казалось, что чаще нужен диаметр, «пи» и ввели. По факту же диаметр применяется в математике примерно никогда.
Окружность — это по сути множество точек на плоскости, на заданном радиусе от центра. Радиус — фундаментальный параметр, а диаметр — вторичный. Именно по этому справедливая константа окружности — тау, а не пи.
Часто в жизни возникают моменты, когда ты что-то придумываешь, а тебя осекают фразами вида «так неудобно». Ты начинаешь рефлексировать, включать режим отладки головного мозга, — только ради того, чтобы прийти к выводу, что «неудобно == непривычно».В некоторых случаях переходить на удобно будет достаточно дорого, чтобы отказываться от привычного, взять те же s-выражения, отталкивающие людей одним своим видом.
Потом в Египте придумали концепцию нуля/ноляВ Вавилоне придумали, в Египте нуля не знали. Но это так и осталось в Вавилоне, последующие цивилизации не были знакомы с этой концепцией, пока в V веке в Индии её не переизобрели. Далее она попала к арабам, а от них — к европейцам.
А ещё индейцы майя совершенно независимо придумали ноль ещё до начала нашей эры, но с их математикой европейцы познакомились много позже.
Про ширину зада лошади было?
По бокам космического корабля "Кеннеди" размещаются два двигателя по 5 футов шириной. Конструкторы корабля хотели бы сделать эти двигатели еще шире, но не смогли.
Почему?
Дело в том, что двигатели эти доставлялись по железной дороге, которая проходит по узкому туннелю. Расстояние между рельсами стандартное: 4 фута 8.5 дюйма, поэтому конструкторы могли сделать двигатели только шириной 5 футов.
Возникает вопрос: почему расстояние между рельсами 4 фута 8.5 дюйма?
Откуда взялась эта цифра?
Оказывается, что железную дорогу в Штатах делали такую же, как и в Англии, а в Англии делали железнодорожные вагоны по тому же принципу, что и трамвайные, а первые трамваи производились в Англии по образу и подобию конки. А длина оси конки составляла как раз 4 фута 8.5 дюйма!
Но почему?
Потому что конки делали с тем расчетом, чтобы их оси попадали в колеи на английских дорогах, чтобы колеса меньше изнашивались, а расстояние между колеями в Англии как раз 4 фута 8.5 дюйма!
Отчего так?
Да просто дороги в Великобритании стали делать римляне, подводя их под размер своих боевых колесниц, и длина оси стандартной римской колесницы равнялась… правильно, 4 футам 8.5 дюймам! Ну вот теперь мы докопались, откуда взялся этот размер, но все же почему римлянам вздумалось делать свои колесницы с осями именно такой длины? А вот почему: в такую колесницу запрягали обычно двух лошадей. А 4 фута 8.5 дюйма — это был как раз размер двух лошадиных задниц! Делать ось колесницы длиннее было неудобно, так как это нарушало бы равновесие колесницы.
Следовательно, вот и ответ на самый первый вопрос: даже теперь, когда человек вышел в космос, его наивысшие технические достижения напрямую зависят от РАЗМЕРА ЛОШАДИНОЙ ЗАДНИЦЫ ДВЕ ТЫСЯЧИ ЛЕТ НАЗАД.
10-тичная система счисления была выбрана из-за того, что человеку удобно опрерировать 10 пальцами, но кто сейчас пользуется пальцами при расчетах? Самая оптимальная система счисления — близкая к основанию натуральных логарифмов, т.е. к 2,718… Если округлить до целого — то троичная, ну либо двоичная. Если все же нужна краткость записываемых чисел, то можно использовать системы с кратными основаниями: 2, 3, 4, 8, 9, 16. В крайнейм случае можно было бы выбрать 12 как число с большим количеством делителей, что немаловажно при расчетах: 2, 3, 4, 6. Но 10-тичная, увы, стала мировым стандартом.
Ок, выбрали 10-тичную, но зачем количесто часов в сутках делать в 12-ричной системе? Если с количеством суток в месяце и дней в годе все еще более понятно — они привязаны к оборотам луны и солнца, то чем обоснован выбор системы счисления для часов в сутках, минутах в часе и секунд в минуте?
Человеку удобно и в 12-ричной работать. Сюрприз, сюрприз. Как так? А вот так — у Вас на 4-х пальцах 12 суставов (большой палец не в счет). Вероятно отсюда же — 12 месяцев, 60 секунд, 60 минут (ну, там шумеры еще вроде подгадили). Еще отсюда же вроде названия числительных во многих языках (не задумывались о французских названиях, или, например, английский — ten, eleven, twelve, а потом уже по шаблону 10+x)?
Не вижу особых причин, почему не могли прижиться еще 5-ричная система (5 пальцев на одной руке) или 20-ричная (руки + ноги).
то чем обоснован выбор системы счисления для часов в сутках, минутах в часе и секунд в минуте?
ну, как я выше сказал. Шумеры. 12 месяцев в году (или все-таки они руководствовались упихиванием лунных циклов в солнечный — хз), потом в ДНЕ (как световом дне) = 12 часов. И столько же ночью (ну, суммарно 24, ага). Потом минуты как производная единица (понятно, что минуты начали считать не сразу) — 5*12=60 (откуда коэффициент 5 — для меня = загадка, возможно, опять магия подсчета на руках)? Секунду — как secunda minuta, т.е. деление по той же схеме, что и часа на минуты.
Задумывался — есть же даже термин "дюжина". 12-ричная еще норм — как я писал, у нее много делителей. Если бы ее использовали для всего, мир был бы чуточку лучше. А пальцы не ноге неудобно использовать.
у Вас на 4-х пальцах 12 суставов
Да откуда вы такие (со скелетным строением, близким к приматам) берётесь? :)
Ну я бы не сказал, что у меня какие-то сверхгибкие руки (скорее, наоборот), но дотянуться большим пальцем до каждой фаланги мизинца — не вижу проблем. Но профессиональные музыканты могут сильно больше.
Хотя, да, согласен, что есть разные варианты. Я спокойно нажимаю на стандартной десктопной клавиатуре Ctrl+L одной рукой, но знаю таких, что не могут.
Увы, если у вас это не получается, то у вас хоть и штатный, но достаточно редкий вариант.
Где-то в параллельной вселенной, где у людей по шесть пальцев на руках, а не по пять, математика у них развивалась ударными темпами, и сейчас они уже достигли технологической сингулярности, и вот-вот построят портал в нашу вселенную — тогда заживем.
Самая оптимальная система счисления — близкая к основанию натуральных логарифмов, т.е. к 2,718…
А вы смотрели, в чём тут определяется "оптимальность"? Да, есть такая теорема. Но дьявол — в её условии: ставится высокая цена за введение множества разных символов. И вот это условие как раз малоприменимо к человеческому общению: до 10-20 различных знаков не стоит ничего; наоборот, цена за удлинение самого представления числа сильно выше.
Поэтому лучше её тут вообще не вспоминать.
то чем обоснован выбор системы счисления для часов в сутках, минутах в часе и секунд в минуте?
Легаси, сэр. FYI: при Французской революции были проекты и это переделать (на 405050 или 10100100).
И вот это условие как раз малоприменимо к человеческому общению: до 10-20 различных знаков не стоит ничего
Ну так выбрали бы 12 — было бы удобней из-за количества делителей или 8 или 16 — из-за лучшей совместимости с цифровыми форматами и тоже из-за количества делителей.
Это другой вопрос, но тут стоит подумать, откуда таки пришли к 10 — это интересный результат.
Есть сильные намёки, что индоевропейская система переходила от 4 к 8 и далее к 10 — это предполагается из-за этимологий древнего 8 как удвоенного 4, а 9 как "новое" (neu- в обоих случаях). Если бы не этот переход, мы могли бы остаться с восьмеричной системой… а вот почему таки состоялся переход — тут как раз корневой вопрос. Но почему-то практически у всех устный счёт идёт по 10 и 20, несмотря на то, что письменный ещё с Шумера и Египта — по 12 и 60. Тут победила устная традиция, и даже интересно, откуда древний счёт по 4, почему не считался большой палец, если он тому причиной ;)
Откуда пошло лево/право по первичной оси X – я думаю, что из письменности.
Если мне не изменяет память, то какая-то из первых вавилонских письменностей вообще была феерическая: они пераую строку писали слева направо, а вторую — справа налево, чтобы взгляд не бегал на начало строки, а плавно перемещался по буквам.
Для машины не удобно определять, да. Человеку проще — увидит "абырвалг", подсознательно распознает слово и чуть более сознательно перескочит на другой конец строки.
Ага, вот я сам в ловушку инерционности мышления и попался. :D
К слову, это был бы прекрасный жанр поэзии: делать стихотворения, которые можно было бы читать в обе стороны.
Для иероглифической придётся парсить минимум пару слов.
Только для симметричных кандзи, которых не так уж и много, плюс за раз человек читает гораздо больше чем один символ.
Алфавитная письменность, но всё равно в каждой строке знаки «смотрят» в направлении письма.
Индекс в массивах ведь задает не номер элемента а смещение от начала. Подумайте об этом.
Индекс в массивах ведь задает не номер элемента а смещение от начала. Подумайте об этом.
Ситуация как раз обратная: обычно индекс массива — это номер элемента, а не смещение. По крайней мере в прикладном программировании, за системное не скажу.
Под вычислениями с индексами вы имеете в виду что-то в духе перевода между одномерной и многомерной индексацией одного и того же массива и т.п.? Этого в коде лучше избегать в явном виде, независимо от старта с 0/1, и пользоваться соответствующими абстракциями написанными один раз (хорошо если они в стандартной библиотеке). И багов меньше будет, и код понятнее.
Сенсационное открытие, при эволюционном развитии новое базируется на уже существующем!
Из-за этого паскалевские конструкции вида FOR N := 1 TO N DO излишне нагружают ALU либо превращаются в квест для компилятора.Какая «нагрузка», какой «квест»?
Что при начале с 0, что с 1 всё сводится к inc/cmp/jXX. А если значение N явно не используется, то и вовсе до dec/test/jnz
Теги: #math #realworld
Здравствуй, твиттор!
и никаких SIB выкрутасов для этого не потребуется, чтобы вертеть каждые 4 байта на ALU. В случае big-endian – welcome to hell.
Видно, имеется в виду, что оптимизации уровня "тут проще работать с индексом, уменьшенным на 1" стали доступны в компиляторах только пост-TurboPascal волны.
Что при начале с 0, что с 1 всё сводится к inc/cmp/jXX.
Нет, современные компиляторы обычно сдвигают индексацию в таких случаях. Не уверен, что это всегда полезно, но, видимо, явно такое добавили в правила.
счетчик = N;
loop:
<тело цикла>;
-- счетчик;
если не ноль, то переход на loop;
exit:vs
счетчик = 1;
loop:
<тело цикла>;
регистр = N;
сравнить счетчик с регистром;
если равны, то переход на exit;
++ счетчик;
переход на loop;
exit:Но вот незадача — у них по каким-то причинам пишут справа налево (об этом ниже), а импортировали as is, и с тех пор пишем числа от старшего разряда к младшему, хоть глазами и бегаем слева направо.
Это неверно. Запись в современной десятичной системе разработана в Индии, где пишут точно так же, как у нас, слева направо, и числа пишутся начиная со старших разрядов. Но, да, оно прошло через арабов, поменяв порядок один раз при приходе к ним и второй — при приходе в Европу, восстановив тем самым исходный порядок.
Более того, переход к счёту начиная со старших зафиксирован как минимум в развитии большинства индоевропейских языков. Для общеиндоевропейского восстанавливается порядок типа "один десять сто...", но сейчас это осталось только в некоторых языках в раритетах типа "ein zwanzig".
Так что для апологетизма little endianness надо найти более серьёзные основания, чем неверные аналогии.
и никаких SIB выкрутасов для этого не потребуется, чтобы вертеть каждые 4 байта на ALU. В случае big-endian – welcome to hell.
Я работал с обоими… нет ада, просто надо другой комплект привычек.
Так что для апологетизма little endianness надо найти более серьёзные основания, чем неверные аналогии.Основной довод — работа с длинной арифметикой. Простые операции вроде сложения/вычитания можно провернуть как Base-2^32, не переполняясь. А умножение уже может потребоать Base-2^8 подхода по тому же самому массиву цифр. При little-endian эта работает as is с простыми i++ циклами. При big-endian приходится обрабатывать байты в порядке 3-2-1-0-7-6-5-4-…
А умножение уже может потребоать Base-2^8 подхода по тому же самому массиву цифр.
Практика библиотек вроде GMP показывает, что ничего такого не происходит. Умножение по 8 бит — не нужно, потому что все нормальные процессоры, если имеют сложение чисел по N бит, имеют и умножение N*N в 2N бит (а те, что не умели такое, закончились где-то с 8086 и 6800). И им не нужно разделять числа на части для умножения.
Сами же библиотеки длинной арифметики работают абсолютно независимо от этого: у них своя логика определяет, что лежит в одном элементе (лимбе, в терминах GMP), массив лимбов чаще little-endian (по смещению 0 минимальный), но иногда и big-endian (никакой проблемы в реализации нет, просто надо чуть внимательнее кодить), поэтому на SystemZ, SPARC и прочих получаются варианты типа "little-endian array of big-endian words (limbs)" и опять же никого это не смущает.
У big endian есть другая проблема — она выглядит так. Естественная нумерация "0 старший" приводит к проблемам понимания при расширении, цитирую, "В случае z/Architecture использование стиля 0=MSB приводит к необходимости внимательно учитывать контекст нумерации; одни и те же биты могут называться 0-31, если регистр рассматривается как 32-битный (только 32 младших бита полного 64-битного регистра), и 32-63, если он же рассматривается как 64-битный; и наоборот, имея номер бита менее 32, надо знать, о какой части регистра идёт речь. Иногда приходится вдумываться и гадать на контексте."
По моему мнению, это самая крупная проблема от BE, остальные банально решаются привыканием за несколько дней.
И, кстати, пример для LE "вот вы записали int32_t и прочитали как int16_t по тому же адресу" — плохой, негодный. Фактически тут требуется сжимающая конверсия, а её без проверки делать вредно: по современным меркам лучше прочитать int32_t и проконвертировать уже прочтённое (возможно, с проверкой на переполнение), а ещё есть проблемы алиасинга, которые вообще могут не допускать такое использование. Ну и экономия на нулевом смещении в x86 специфична для x86, а для большинства RISC, например, смещение в такой команде есть всегда (как в ARM, MIPS, 12 бит со знаком).
(int&)++floatVariablestd::nextafter
eressea.ru/ambar/humor/comp09.shtml
www.ietf.org/rfc/ien/ien137.txt
Да, у меня в детстве был микрокалькулятор с обратной польской записью, всех моих знакомых он вводит в ступор и непонимание, а мне было удобнее обычной записи.
До сих пор скучаю.
У других (OpenGL) в глаз
В OpenGL настраивается
А чем дальше, тем круче. Люди не смогли договориться о том, как писать вектора – в строку или в столбец.
Хм… есть вектор-строка, есть вектор-столбец, и если надо, то один в другой можно волшебным путем превратить с помощью транспонирования. Дело в том, что вектором-то является любой элемент линейного пространства и могут быть представлены как угодно: матрицами, столбцами, строками, отрезками и т.д. и т.п., в обще что угодно. На уровне программирования под вектором понимается вообще любая упорядоченная последовательность однородных объектов. Так что запись может быть любая, но обычно вектор записывают строкой, если это возможно (и не имеет глубинного смысла).
Например, если мы рассматриваем матрицы как линейные отображение (linear map), то в таком случае принято работать с представлением векторов к веткор-столбцами, тогда получается вот такое выражение как f(v) = Av, где v — это вектор-столбец с размерностью n × 1, над которой совершает операцию отображения матрица A размерности m × n которая по сути является линейным отображением (linear map) из пространства R^n в R^m. И кстати вектор-столбец v по отношению к скаляру x также является линейным отображением f(x) = vx из R^1 в R^n. Так что когда мы имеем дело с матричными преобразованиями, например, в вычислительной геометрии, то за вектора конечно же должны приниматься веткторы-столбцы, ну а операторами над этими векторами будут всякие матрицы перехода, например, матрицы поворота.
И в таком контексте вектор-строка, например, r, на самом деле рассматривается тоже как матричный оператор, только размерностью 1 x n, который осуществляет частный случай линейного отображения вектора[-столбца] из размерности R^n в R^1, т.е. переводит из векторного пространства над скалярным полем в это же самое поле — это называется линейная форма (linear form, linear functional), и примером такой линейной формы будет скалярное произведение r*v=x.
Так то ничего не мешает поменять местами матрицу с вектором, если вектор представлен как вектор-строка, только вот матрицу придется для этого транспонировать, а если работа идет в поле комплексных чисел, то придется её еще эрмитово сопрягать. Ну а самое главное пропадает математический формализм для функциональных записей. Поэтому вектор-строки принимаемые за векторы, это скорее частный случай, когда работают с линейными формами, полиномами и т.д. и т.п., и в общем-то матричные операции не особенно важны, ну или понимают, что и как делают и не забывает где надо транспонировать и эрмитово сопрягать.
Еще один немаловажный момент, это то что вектором на самом деле может быть в принципе что угодно, например, матрицы тоже могут образовывать векторные пространства.
преобразование вектора чередой матриц иметь последовательный вид VxM1xM2xM3 или
извращённый вывернутый вид M3xM2xM1xV
Это две разные операции.
В первом варианте Вы сначала получайте линейную карту (rM1), причем r здесь тоже матрица, которую затем применяйте к М2 и получайте еще одну линейную карту ((rM1)M2), которую уже применяйте как оператор к матрице М3.
Во-втором случае Вы применяйте какую-то линейную карту (отображение) М полученную из ((М3М2)М1) к вектору v, причем принцип тот тот же: применяя линейную карту М3 к М2, получайте линейную карту (M3M2), которую затем применяйте к М1 и так получайте оператор линейного отображения М = ((М3М2)М1) для вектора v.
Математическая сущность операций разная: в первом случае принимается операция линейного отображения к матрице M3, во втором случае к вектору v. Причем если операция ((М3М2)М1) над v действительно существует, то чтобы получить тот же самый результат в обратном порядке с учетом того, что r эмитрово-сопряженная с v, то придется крутить-вертеть все матрицы, причем не просто крутить вертеть а комплексно сопрягать, иначе просто ответ не сойдется.
Дело в том, что эти все операции не просто умножение, Вы применяйте оператор линейного отображения к элементу векторного пространства и применяется это всегда слева направо. Причем появилось это не просто так, дело в том, что такая запись как Ax = y, это матричная запись систем линейных уравнений, где матрица A содержит коэффициенты линейных уравнений, ну а вектор x содержит их аргументы, которые отображаются в y линейным отображением А записанном в матричном виде. При строчки уравнений, записанных одна за другой, совершенно однозначно переводятся в более компактную запись, где коэффициенты (a) = a[1,1],...,a[m,n] и значения функций (y) = y[1], y[2],..., y[m] при m>=n совершенно однозначно попадают на свои места в матрицу А и вектор у в соответствии со своей позицией (и пофиг в каком порядке они записаны), ну а неизвестные аргументы x = x[1], x[2],..., x[n] образуют вектор этих самых неизвестных аргументов x. Ну а дальше получаем линейное отображение B = inv(A), применяем его к y как By и получаем профит — вектор неизвестных аргументов x. Ну а если взять и определить операцию матричного умножения наоборот, то чуда уже не получится. Так-то можно по-разному крутить вертеть, переставлять термы как это удобнее, добавлять новые термы и хитрить с понижением ранга, но исходное линейное уравнение всегда будет Ax = y, ну а линейная функция всегда будет y = Ax. Все идет оттуда — из алгебры, потом уже удобный вычислительный инструментарий алгебры применяется к другим областям математики, например, к геометрии.
---> -> --->
В случае B(A(v1)) + D(C(v2)) порядок чтения формулы получается
< — -> <---
Это по идее восходит к тому, что сама запись применения функции/оператора взялась как sin(x), а не x->sin к примеру (и в каком-то языке программирования так и сделали).
Не только применение, но и композиция функций записывается всегда справа налево: g∘f(x) = g(f(x))
Тут больше разговор о том, что мозги приходится вертеть туда-сюда при восприятии формул.
Ну, иначе никак. Такова особенность алгебра-прона: ради оптимизации вычислительной сложности (да и просто для решения задач), приходится крутить-вертеть, да гонять по местам все эти матрички. И эта проблема еще и исторически осложняется еще несовершенством парсеров — это у Матлаба вменяемый синтаксис с точки зрения математики, а вот все эти ваши Си-плюс-плюс только скалярными величинами оперировать и могут, а массивы не более чем структура данных, полноценных матриц нет, память плоская и т.д. и т.п. Работа с графикой уже подразумевает наличие векторных операций, однако видеокарты предназначены в первую очередь для того чтобы быстро отрендерить сцену и когда появились первые шейдеры (а я даже немного застал эти времена) их функционал был мягко говоря ограниченным, и понятное дело, что весь синтаксис был заточен под то, чтобы все транслировалось в высокоэффективный код. Отсюда тот же, например, column-major order, ну просто потому что при порядке row-major будет O(N^3) кэш-промахов, а это нехорошо, ща правда появилась возможность настраивать порядок, но там есть ньюанс, связанный с тем, что просто компиляторы поумнели, но это случилось далеко не сразу. Отсюда же идет мода реверсить порядок матриц (которые уже заранее будут транспонированы), так как начиная каскад умножений с вектора 1x4, мы сократим число умножителей и сумматоров для этого вычислительного потока, на сумматоры, конечно пофиг, а вот умножалка — она дорогая.
Это по идее восходит к тому, что сама запись применения функции/оператора взялась как sin(x), а не x->sin к примеру (и в каком-то языке программирования так и сделали).
Весь секрет в типичном порядке слов в человеческий языках, и в 42% языков используется именно SVO (subject-ver-object) порядок, например, в таких языках как греческий, русский, английский, китайский и т.д. и т.п. для которых простые предложения будут иметь следующий вид:
Кошка пьёт молоко
Уильям любит водку
Васян играет на фортепьяно
В общем что-то совершает действие над чем-то — субъект => действие => объект
Такой порядок является единственно-верным базовым порядком для английского языка и основным порядком слов для романских языков. Не смотря на то, что в славянских языках, кроме болгарского, порядок слов вроде бы свободный свободный, но нейтральным и дефолтным вариантом является именно SVO порядок (что хорошо видно на примере болгарского языка, где порядок слов фиксированный), аналогичная ситуация и в венгерском. Германские языки, все кроме английского, не являются SVO языками в полном смысле этого слова — они относятся к так называемым V2 языкам, где именно позиция глагола всегда фиксирована, что часто приводит к SVO структуре для простых предложений. Английский, так же как и другие германские языки был изначально тоже V2 языком, однако в процессе своей эволюции выродился в кристально чистый SVO язык (я думаю что это произошло не без участия влияния французского языка).
Ну а теперь вспоминаем кто двигал науку в современном виде: в первую очередь это были англичане с французами, у которых языки с порядком SVO, также в этом празднике жизни участвовали немцы, русские, поляки и венгры для которых SVO порядок является привычным, простым и нейтральным.
При этом древние индоевропейские языки, например, латинский и древнегреческий, а также современные азиатские версии индоевропейских языков, например, хинди, являются SOV (subject-object-verb) где подлежащие и дополнение меняется местами, однако сказуемое все равно остается на первом месте. Когда Ньютон придумывал матанализ, для него естественным был именно порядок SVO, а языком международного общения вплоть для середины XX века был также язык с сильным SVO порядком — французский и такой порядок поддерживался всеми остальными европейскими языками. Отсюда и пошла операторная форма записи, где сначала идет оператор (допустим, набла какая-нибудь — векторный дифференциальный оператор), а затем собственно аргумент (допусти, фи там какая-нибудь), отсюда и именная форма записи функций y=f(x), где f совершает какое-то действие над аргументом x и так далее. Просто так удобнее и это полностью соответствует структуре речи языков, на которых говорит большая заметная часть мира: китайский, испанский, английский, русский, португальский — это уже получается около 1/3 земного шара :-) Единственный серьезный конкурент SVO — это языки типа SOV, но так уже получилось, что именно носители SVO-языков доминируют в науке: подавляющее большинство ученых говорят либо на каком-нибудь языке, где базовой или нейтральной формой является именно SVO, либо языке с высоким сродством к SVO (немцы и скандинавы), а язык определяет мышление.
Встречаются, конечно, и обратные порядки, например, языки OVS и OSV — это несколько изолированных языков в Южной Америке. Ацтеки как и магистр Йода предпочитает порядок — «объект-субъект-предикат», OSV :-) А к OVS по-моему относится вообще всего один единственный язык, какой-то малой народности из Венесуэлы. А тот же арабский поддерживает две формы: SVO и VSO в зависимости что говорящий считает важнее: subject или verb (это немного влияет на контекст), причем, в современном арабском доминирует все же SVO порядок, а VSO это уже больше к классическим арабским текстам. По какой-то причине, но SVO форма является более сильной.
А вот:
x->sin к примеру (и в каком-то языке программирования так и сделали)
Это просто пришли функциональщики и давай сувать во все ЯП лямбда-формализм. Не в какой-то ЯП, а сразу в целую кучу: C#, Java, Scala, Kotlin, JS, Common Lisp, Python, C++, Delphi и т.д. в которые введён синтаксис функционального программирования, который подразумевает анонимность функций. Это просто одна из формальных систем для анализа вычислимости, где все по существу сводится к аппликации (тоже самое что и f(x) только, записанный в виде f x) и абстракции.
И все равно, корректной записью будет, что-нибудь типа такого y = x => Math.Sin(x); т.е. примерно тоже самое, просто немного другой формализм :-)
Весь секрет в типичном порядке слов в человеческий языках, и в 42% языков используется именно SVO (subject-ver-object) порядок
Вики: «SVO is the second-most common order by number of known languages, after SOV.»
Английский, так же как и другие германские языки был изначально тоже V2 языком, однако в процессе своей эволюции выродился в кристально чистый SVO язык
AreV youS sureO?
(subject-object-verb) где подлежащие и дополнение меняется местами, однако сказуемое все равно остается на первом месте.
Вы подлежащее со сказуемым перепутали.
Когда Ньютон придумывал матанализ, для него естественным был именно порядок SVO, а языком международного общения вплоть для середины XX века был также язык с сильным SVO порядком — французский
До 19в. языком международного общения, и заодно языком науки, на котором писал свои труды Ньютон — была латынь с SOV.
Вики: «SVO is the second-most common order by number of known languages, after SOV.»
Это если считать по количеству языков. А если по количеству носителей, SVO побеждает с заметным отрывом.
AreV youS sureO?
Вопросительные предложения тут не рассматриваются (потому и речь про SVO+V2, если вместе с ними).
До 19в. языком международного общения, и заодно языком науки, на котором писал свои труды Ньютон — была латынь с SOV.
Ну вопрос тут скорее на чём они думали… явно не на латыни. И чтобы языком международного общения была латынь — это скорее неактуально уже где-то с 15-16 веков. Но тут, да, надо оценить вес аргумента.
PS: я не в защиту предыдущего постинга — он требует отдельного рассмотрения.
Вопросительные предложения тут не рассматриваются (потому и речь про SVO+V2, если вместе с ними).
Прикол в том, что в вопросительных предложениях в германских языках тоже не V2 — глагол выносится в самое начало. Это уже три разных типичных порядка в одном английском языке :)
И чтобы языком международного общения была латынь — это скорее неактуально уже где-то с 15-16 веков.
это не так. Как минимум документооборот и официоз на латыни местами дожил до 18-го века.
это не так. Как минимум документооборот и официоз на латыни местами дожил до 18-го века.
"Местами" он и сейчас есть. А вот чтобы латынь преобладала как "язык международного общения" — таки после классического средневековья уже не факт.
finalvertex.pos = AffineTransformMatrix * RotationMatrix * ScaleMatrix * vertex.pos
где vertex.pos — естественно это вектор-столбец, ну а все остальное — это матрицы перехода 4x4.
Но в силу вычислительной сложности, и учитывая, что GPU все равно не умеют в комплексные числа лучше всего делать:
finalvertex.pos = (vertex.pos.Tranpose() * ScaleMatrix.Tranpose() * RotationMatrix.Tranpose() * AffineTransformMatrix.Tranpose()).Tranpose()
Экономия хорошая получается, поэтому и используется такая странная нотация, причем она что в HLSL, что в OpenGL одинаковая на самом деле: VxM1xM2xM3 и M3(M2(M1(V))) — оба варианта являются обратными и работают с транспонированными матрицами и векторами. GPU использую старые трюки и способы для организации памяти и построения вычислительного конвейера, и все это тянется еще со времен Фортрана из 50-ых.
Поэтому работает такая штука, как «кармическое воздаяние» — моторолы, PowerPC и SPARC’и остались только в банковской сфере, с нормального рынка они повылетали даже после захода на XBOX/PS приставки.
Скорее удача Intel.
Автор х86 ISA жалеет, что использовал little-endian ради призрачной совместимости с 8080.
www.pcworld.com/article/146917/article.html?page=3
SM: I always regret that I didn’t fix up some idiosyncrasies of the 8080 when I had a chance. For example, the 8080 stores the low-order byte of a 16-bit value before the high-order byte. The reason for that goes back to the 8008, which did it that way to mimic the behavior of a bit-serial processor designed by Datapoint (a bit-serial processor needs to see the least significant bits first so that it can correctly handle carries when doing additions). Now there was no reason for me to continue this idiocy, except for some obsessive desire to maintain strict 8080 compatibility. But if I had made the break with the past and stored the bytes more logically, nobody would have objected. And today we wouldn’t be dealing with issues involving big-endian and little-endian—the concepts just wouldn’t exist.
Как человек, который смотрит в дампы памяти значительную часть дня, я с ним согласен.
Работа с битовыми полями и SIMD опять же удобнее на big endian.
У big-endian есть один тонкий момент — нумерация бит.
В SPARC и 68K нулевым битом был LSB, аналогично little-endian.
А вот в Power сделано тупо — нулевой бит в MSB, что ставит его в зависимость от размера данных.
a bit-serial processor needs to see the least significant bits first so that it can correctly handle carries when doing additionsТак это до сих пор актуально на длинной арифметике (всякие BigInt) — я про это писал в основном контенте.
And today we wouldn’t be dealing with issues involving big-endian and little-endian—the concepts just wouldn’t exist.Довод у него за то, что не было бы двух вариантов endianness. Но если рассмотреть альтернативную вселенную, где изначально всё делали на little-endian, включая сетевые протоколы, SPARC'и, POWER'ы и т.п. — big-endian в той вселенной выглядел бы полной дичью. Т.е. у little-endian есть редко играющие, но доводы в пользу, а у big-endian кроме привычности других доводов нет.
But if I had made the break with the past and stored the bytes more logicallyТак в том и дело, что оно ни фига не «logically», а «habitually» :) об этом и статья.
Довод у него за то, что не было бы двух вариантов endianness.
Нет, это лишь следствие.
Почему-то вы проигнорировали все места, которые я выделил :)
there was no reason for me to continue this idiocy, except for some obsessive desire to maintain strict 8080 compatibility
Тут речь шла не о поддержке двух вариантов в коде, а конкретно об «идиотизме» little-endian.
Т.е. у little-endian есть редко играющие, но доводы в пользу, а у big-endian кроме привычности других доводов нет.
Вкусовщина.
(не туда ответил)
Почему-то вы проигнорировали все места, которые я выделил :)Ну там выделены эмоциональные всплески, без конструктивизма :)
Честно говоря, не ожидал такого от «отца 8086».
Тут речь шла не о поддержке двух вариантов в кодеЯ не про код, а про мир — чтобы не было двух разных парадигм, что в сети одно, а в железе другое. «Идиотией» он видимо это посчитал из-за того, что на рынке тогда уже были big-endian процы и на них кто-то уже начал равняться.
Т.е. я согласен с тем, что «у little-endian есть редко играющие, но доводы в пользу, а у big-endian кроме привычности других доводов нет», но не согласен с оценкой этого: машины перепрограммировать на новый порядок гораздо проще, чем людей, так что привычность — решающий фактор.
developers.google.com/protocol-buffers/docs/encoding#varints
Я всё время к длинной арифметике отсылаю, когда вылазит нелогичность big-endian — более явный (хоть и надуманный) пример — это допустим у нас есть два потока с длинными числами, которые идут стримом по сети. В случае little-endian мы можем их складывать на лету по мере поступления новых данных (per-byte-level). В случае big-endian это сильно заморочит алгоритм на delayed carry propagation.
Народ просто привык думать о little/big-endian только аспекте свой клетки одного 32/64-битного значения/регистра. Когда же соседние адреса тесно связаны семантически как части одного большого числа и с ними приходится работать на per-byte level всё это очень некрасиво вылазит.
это допустим у нас есть два потока с длинными числами, которые идут стримом по сети. В случае little-endian мы можем их складывать на лету по мере поступления новых данных
А если нужно эти числа поделить? :)
На big-endian процессоре эти числа из того же самого потока будут складываться точно так же. Обычно есть инструкции bswap или что-то подобное.
Что-то более близкое к реальности есть?
Ну там выделены эмоциональные всплески, без конструктивизма :)
Как и у вас в статье :)
«недообдуманные человеческие привычки»
«кармическое воздаяние»
Отсылка к длинной арифметике тоже странная, т.к. код отличается только направлением чтения слов.
А если нужно эти числа поделить? :)Если поделить, их всё равно придётся целиком принять до первых телодвижений — хоть в little, хоть в big постановке, realtime стриминг там нереален.
На big-endian процессоре эти числа из того же самого потока будут складываться точно так же. Обычно есть инструкции bswap или что-то подобноеА если цифр на 137 байт? т.е. не кратно ни 4, ни 8.
Что-то более близкое к реальности есть?Собс-но в 8008 оно возникло из-за схожих причин. Из современного резко на ум не приходит — хотя заморочки с trailing non-4-byte уже могут доставить. Ну и всё равно «математичеки» коробит, когда макро-порядок в длинной арифметике всегда little-endian, а внутренний может быть big-endian. Макро-порядок на little-endian — чтобы можно было инкрементнуть ++ или добавить += что-нибудь в длинное число и потом realloc дёргать с того же базового адреса, а не memmove делать всему и вся.
Как и у вас в статье :)У меня хотя бы конструктивно :) А «эмоции» — это чтобы было интересно/весело читать. типа кдпв :)
В пещерах этого не было