Pull to refresh

Comments 226

паскалевские конструкции вида FOR N := 1 TO N DO излишне нагружают ALU либо превращаются в квест для компилятора.
Не это ли, внезапно, является причиной тормознутости циклов в Matlab (который тоже 1-based)?

Изначально Matlab был написан на FORTRAN. Отсюда индексация массивов с 1 и хранение матрицы по столбцам.

Хочется так думать, но не думаю. ALU нынче дешёвое. RAM/CAS latency pays the price.
Младший бит находится слева, то есть с начала. Ну как не понятно? Ну, блин, сверху.
Теперь эти микросхемы напоминают заводы в факторио)

Это как раз заводы факторио напоминают микросхемы.

Не так давно в статье про запуск Bad Apple в диспетчере задач была ссылка на запуск оного же в factorio, так что рендеринг чего бы то ни было уже не новость.

Вот та статья, если что. Я как-то мимо неё прошёл, хотя это забавно.

Это новость, а была еще статья с деталями, правда чо-то она не гуглится. Ужель в черновики спрятали.

Этот FFF – кажется, именно тот самый, с которого я начал знакомство с Факторио и вообще осознал, что сырые алгоритмы очень даже имеют место в геймдеве, да и в разработке в целом. То есть это понимание было, но на уровне "%игра% работает тормозно, что-то они там недооптимизировали" – но было неясно, что и как можно оптимизировать, а тут как раз наглядный частный случай.


Если мне не изменяет память, тогда переход от "предмета как объекта, перемещаемого конвейером" к "конвейеру как контейнеру списка предметов" помог снизить нагрузку на процессор, но привнёс странное поведение предметов на поворотах. В любом случае, спасибо за хорошую игру. ^_^

Да, ещё. Кажется, это называется «спонтанное нарушение симметрии» и происходит много где (в физике).
Косинус первичен потому, что cos(φ) = Re exp{iφ} и действительная часть числа первичнее мнимой части sin(φ) = Im exp{iφ}. Ну или, например, если мы повернем простейший нетривиальный вектор {1, 0} на некоторый угол, то первой (нулевой :) компонентой опять получим косинус (причем это работает не только для двухмерных поворотов).

А с нумерацией, начиная с 1, даже сами человеки путаются: с какого года начинается третье тысячелетие, с 2000 или 2001? И если правильный ответ — второй, то почему праздновать больше тянет наступление первого? А с естественной нумерацией все просто: 1967 — это год 19 века и 1-го тысячелетия и праздновать надо круглые числа.

Естественная нумерация — это с нуля?

Тут можно поспекулировать, что первичней мнимая часть, потому что через степени мнимой i можно выйти на действительные +1 и -1, а через степени действительных в мнимую уже никак.
почему праздновать больше тянет наступление первого?

Потому что можно раньше начать пить путают порядковые числительные (идёт 2000-й год) с собирательными (прошло 2000 лет, и начался 2001-й)

В смысле — «Паскаль1-based»?
Объявление переменной типа массив в Паскале:
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 породило лютый беспорядок и вроде бы потом всё вернули взад).
Классические строки в Паскале, насколько я помню, это вообще частный случай динамических char-массивов, когда 0-ой элемент зарезервирован под длину.
Тут есть несколько моментов:
1. Shortstring в Delphi — массив самый что ни не есть статический, размер задается при объявлении (255 по умолчанию). Текущая длина строки — да, лежит в 0-м байте.
2. В стандарте паскаля конкретная реализация строк никак не прописана (по крайней мере ранее не была, сейчас уже не знаю). Просто Борланд сделали так, как сделали…
3. В динамических массивах Delphi длина действительно хранится перед началом, но это скорее "-1" элемент, т.к. динамические массивы (относительно недавнее изобретение) как раз-таки 0-based :) Ага, и так у них всё…
т.к. динамические массивы (относительно недавнее изобретение)

Года через три после появления Delphi на свет, и более двадцати лет назад, если позанудствовать :)
Так я же говорю — относительно :)
Смотря с чем сравнивать. Я вот Turbo Pascal помню с 80-х, еще до изобретения Turbo Vision, (т.е. до синих панелек :) ).
Моим первым Паскалём была адаптация Турбо-Паскаля 3.0 для «Поиска». Запускалась с кассеты, компилировала тоже на кассету :)
Мне с Turbo/Borland Pascal'я во времена 286/386 запомнилось, что там по-умолчанию 1-based. Ну и соответственно в мозги будущим программистам лили эту парадигму, что обычно циклы писались I:=1 to N, а не I:=0 to N-1. Да, сам язык, возможно этого не запрещал, но вот так сложилось.
И циклы обычно писались… to N а не… i < N
Котангенс вполне даже логичен и мнемонически: «косинус»/«синус» = «ко»
Очень удобно и правильно когда веса разрядов равны смещению. Очень уважаю разработчиков процессоров, которые нашли смелость наплевать на дебильные общепринятые стандарты и сделать правильно!
Обычно обе вонючих шизы — биг эндиан и 1-бейс идут рука об руку (ещё и десятичная пихается система там где не надо, да). Байт в дворде с весом 2560 имеет номер 4, 2561 — 3-й, 2562 — 2-й, 2563 — 1-й. Любая работа с вложенными диапазонами — постоянная необходимость добавлять-вычитать единичку чтобы перейти от «номера» к нормальному смещению. Плеваться хочется от кривости и бессмысленности! Но им так привычно видите ли… При этом даже сами не могут решить как надо — даты нумеруют с 1 числа, а время — с 0 часов. Сами постоянно наступают на свои грабли: 21-й век — это 2000-е, причём начинается он с 2001 — они сами в этом путаются, но всё равно рьяно защищают свой дебильный 1-бейс. И ни чуть не смущаются!
Два главнейших врага разума — это привычки и инстинкты…
big endian идет в сети, там это весьма оправданно. А вот чтоб распарсить число прочитанное из сети — на little endian приходится swap делать. Неудобно!
Оправдано, что в момент зарождения сети большинство было big-endian, а остальные под них подстраивались? Современные протоколы уже опираются на little-endian, вроде sbe/protobuf.
Два главнейших врага разума — это привычки и инстинкты…
У человека инстинктов не так уж и много, и наблюдать их можно в полном объёме уже у новорождённых.

Да их и у моей кошки не так уж и много. Я как-то считал, что она руководствуется от силы двумя дюжинами стимулов, притом отклик у неё — почти всегда на инстинктах.


То же и у человека: в зависимости от обстоятельств, есть «непреодолимые» желания, которые один из двух главнейших врагов разума не даёт называть инстинктами, несмотря на объективные данные. Только у человека пути воплощения этих желаний могут быть изощрённее. А если подумать, глобальные цели людей почти всегда можно свести к инстинктам. Лучше жить (в частности, иметь больше зарплату, изобретать новые полезные вещи или, наоборот, сжигать вышки 5G) → иметь больше шанс завести потомство, обеспечить его лучшей жизнью, дать ему больше шансов на выживание.

Если бы так, то после окончания репродуктивного возраста люди бы самоуничтожались, чтобы не конкурировать за ресурсы со своим потомством.
Если бы так, то после окончания репродуктивного возраста люди бы самоуничтожались, чтобы не конкурировать за ресурсы со своим потомством.
Ну так, в момент формирования оных это же примерно так и было? )))
Плюс надо учитывать, что в целом стадо тех же слонов тем успешнее, чем старше и опытнее у них вожак — он больше помнит. В этом случае старые особи помогали выживать своим потомкам.
То, что можно наблюдать у новорожденных — это рефлексы.
Весьма забавно порою получать проблемы из-за ребят, которые считают, что в 16-битной переменной старший бит имеет номер 1, а младший — номер 16. Это с одной стороны. А с другой стоит программный пакет, который привычным образом нумерует от 0 до 15, от младшего к старшему.
Такая же беда была у Texas Instruments в их старых разработках — например, в TMS9918, где мозг взрывается от нелогичности нумерации при чтении документации, пока не сообразишь, что биты адреса у них нумеруются в одну сторону, а биты данных — в другую. Что, впрочем, логичности не добавляет. :)

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

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

Тем не менее даты в европейской традиции озвучиваются от младших разрядов к старшим (а у китайцев вполне логично год — месяц — день).

Время традиционно тоже (25 минут двенадцатого).
Или «одиннадцать часов двадцать пять минут».
До появления электронных часов такая форма не была особо распространенной. Так выражались разве что военные («наступление в три часа ноль минут»).
Запись времени, так или иначе, была и остаётся именно такой. Устно эта форма употреблялась гражданскими лицами и институтами везде, где важна была точность. Самый простой и понятный пример — транспорт. Да, если вы когда-нибудь набирали на дисковом телефоне «08», то должны были бы вспомнить формат ответа. :)
Запись времени, так или иначе, была и остаётся именно такой.

Где-то была, где-то не была.

Да, если вы когда-нибудь набирали на дисковом телефоне «08», то должны были бы вспомнить формат ответа. :)

Там это было вызвано техническими ограничениями, чтобы из пары десятков записанных слов собирать все возможные ответы.

ну логика тут двояковыпуклая — раньше то что чаще меняется, а так то вы конечно правы, год-месяц-число было бы как цифры

UFO landed and left these words here
Особые извращённые

Ага, и имя им «американцы» :)
И ещё несколько стран, например Филиппины.
на территории России тоже, до определённого года.
Еще особо извращённые в HTTP трафике зачем-то вписывают не только формат даты, который надо угадывать, но и часовой пояс и, о хоспади, день недели! который однозначно из даты вычисляется. Нет бы таймстемпом обойтись и тулзами, парзящими хедер. И это в модемные времена, когда максимально экономили на сетевом трафике.
И я даже могу представить себе как бы это могло выглядеть и использовалось бы при «правильной» записи слева-направо. Но не хватает фантазии представить как бы это звучало в устной речи (и записи чисел словами).

В немецком, например, 42 произносится «два и сорок», в чем проблема?
Справедливости ради заметим, что это применимо только для двух младших разрядов.
Для двух младших разрядов из каждых трёх.
Кстати, да, но ведь не число целиком читается справа налево, а только эти два младших разряда в каждой тройке. Отчего, между прочим, читать число ещё сложнее.
Это вы ещё французское произношение не видели…
Заголовок спойлера
image
мне больше интересно как будет 2411 справа налево — один десять четыреста две тысячи?
Как вообще произносить десятки сотни и другие разряды, если они идут после?

Это вам к лингвистам. Как правильно произносить они решают. Мы тут решаем как удобнее считать.


Чтобы два раза не вставать. Статья великолепна.

Язык не подчиняется никаким лингвистам. Разве что они сами его придумывают — типа Логлана. Там как раз числа очень логично называются — просто по цифрам.

123 = раз два три

А цифры называются тоже логично:

2 to 3 te 4 fo 5 fe и т.п.
Я думаю, что лингвистам следует прогибаться под счет, а не наоборот. Да, собственно, так оно скорее всего и было. Нюанс в инерции. Так же люди чаще сравнивают числа, чем складывают/вычитают/умножают (особенно когда цифры описывают деньги). Ну и, возможно, под эту более частую операцию сравнения на предмет меньше/больше и заточили порядок.
2 to 3 te 4 fo 5 fe и т.п.

Почему-то в голове сразу ассоциация с DTMF пошла :-)

Ну как раз один-надцать, две-надцать, три-надцать и далее, так и произносятся — сначала младший разряд, потом старший.
Ну в немецком, например, двадцать один — это ein und zwanzig (буквально — «один и двадцать»), и никто не удивляется…

А в японском (и, наверное, китайском тоже) есть отдельные группировки и для других порядков, например 1万 = 10000, в английском в обратку встречаются конструкции вида "$2500 = twenty-five hundred bucks". Думаю, нам про все эти форматы ещё многое предстоит узнать...


ЗЫ. В японском при этом слово, обозначающее "забитость, полную занятость" читается так же, как и "десять тысяч" — "ман", но имеет разное написание; напр. 満車 — парковка занята, 満席 — мест нет. Интересно, это тоже как-то связано? :-)

Там просто система исчисления в принципе имеет основу инкрементации степени в 10^kn, k=4, а не как у нас k=3. Потому у них 10^4=万(ман), 10^8=億(оку), а у нас 10^3 — тысяча, 10^6 — миллион, 10^9 — миллиард. На 150000 они говорят 15 манов, а миллион — 100 манов, и это — не «вариант», а правило.

А ещё, по поводу степеней 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
Это ещё не выходя за пределы программистской математики. Мне музыканты не могли объяснить, почему на 12 полутонов 7 белых и 5 чёрных клавиш. Да и нагуглить ответ не просто было

А сколько надо? 6+6? Тогда же ориентироваться в них сложно будет))


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

Мне музыканты не могли объяснить, почему на 12 полутонов 7 белых и 5 чёрных клавиш.
Гамма Ля (первая в западной теории) белыми и полутона которые в нее не входят черными.

А как быть с ре# и ля#?
Так-то под эту гипотезу можно натянуть много сов.

А причем тут минор? В западной теории в нотацию тонического аккорда с большой буквы вшит мажор.

Там не просто так. Если сыграть только по белым клавишам — звучать будет мелодично, но именно потому, что между белыми клавишами не равные интервалы. А черные — как бы добавочные. Но есть подозрение, что да — это вопрос привычки.
ru.wikipedia.org/wiki/Лад_(музыка)
Не только привычка. Квинта — однозначный консонанс, а от примы до квинты — 3 с половиной тона, и в целотоновую гамму (6+6) она не входит.
Во многом это все привычка, конечно, да и «теория музыки» — это на самом деле «Теория европейской музыки 18го столетия».
Тоже долго не мог найти нормальное объяснение. Мне больше всего понравилась теория, что белые клавиши были выбраны для полутонов с номерами i, для которых 2^(i/12) хорошо приближается рациональной дробью со знаменателем из степеней 2, 3 (а эти знаменатели пришли из пифагорова строя). Вот картинка, строка 12-TET. Это не объясняет все белые клавиши, но большинство.
Лучше вообще не вскрывать эту тему. А то рано или поздно кто-нибудь случайно произнесёт «432 герца» и всё заверте…
Учился не на фортепьяно, а на баян. Не смотря на то, что клавиши правой руки имеют общепринятую расцветку, расположение 12 клавиш идет как-бы «подряд», без разделения, но по «спирали». И в определенный момент обнаружил, что любую мелодию можно играть на полтона или на 1 тон, или 1,5 тона выше или ниже простым геометрическим смещением первой ноты — просто ставим на грифе палец выше-ниже или левее-правее.
Так что если судить по звучанию (на слух), а не по цветам клавиш, то 12 тонов вполне себе имеет смысл.
Но после баяна на фортепьяно перейти не смог — мозг категорически сопротивляется нелогичности расположению клавиш.

Та же фигня на гитаре. Транспонирование порядком легче, чем на фортепиано.

Людям нравятся сложности. Люди при всей глобализации до сих пор на метры и килограммы не перешли, и розетки до сих пор разные.
Видимо мы ещё долго будем «есть кактус» создавая проблемы сами себе, потому что «так исторически сложилось».
Кстати по работе при анализе процессов фраза «мы так всегда делали» основа 40% технологий.
Люди при всей глобализации до сих пор на метры и килограммы не перешли, и розетки до сих пор разные.

Не "людям нравятся сложности", а "рефакторинг такого масштаба слишком дорог" и "необходимо поддерживать совместимость с уже имеющимися на рынке решениями". Давайте хотя бы розетки: представим, что у нас страна, где в розетках привычные ~230 вольт, просто форма штекера своя. Давайте прикиним, сколько нужно времени и денег, чтобы заменить эти розетки во всех домах страны, потом на всех производствах техники, а потом — сколько ещё вбухать деньги в переходники для старой техники. В дальней перспективе наверное круто, но кто здесь и сейчас за это платить будет? ;-)

Думал про этот кейс. В принципе если всем миром определиться что например РФ переходит на US/CH стандарт вилок (плоские прямоугольные), не вижу ничего супер сложного. С 01.01.20ХХ переходим на тотальное производство вилок и розеток под новый стандарт. В течении 5 лет ко всей технике прикладываем переходник. Расходы даже близко не сравнятся с затратами на один фейерверк в столице.
Некоторые страны в этом веке уже меняли стронность движения и ничего. Недавно в течении нескольких лет у нас в стране все приборы давления к системе СИ приводили.
что например РФ переходит на US/CH стандарт вилок (плоские прямоугольные)
Дурацкие вилки, кстати. Маломощные и небезопасные. Да и в целом энергетика у буржуев так себе…
Уж нам переходить на американские стандарты так же полезно как переходить на дюймы…
Согласен дурацкие вилки, хуже только Мальта/UK. ТАм вообще бредовая конструкция.
НА самом деле круче было бы провести исследование какая вилка более оптимальна с учётом практики и т.д.
У плоской вилки есть свои плюсы, кстати на некоторых есть отверстия на конце и они зажимаются в розетке. Тут нужен мега- ТРИЗ исследование.
Ну не знаю, мне система в UK кажется очень продуманной. Выключатель на розетке, предохранитель в вилке, удлиненный земляной контакт открывает шторки на ноль и фазу, сами ноль и фаза всегда разведены однозначно… Разве только размер не самый компактный.

Вы просто на британскую ночью в темноте не наступали, после этого любая будет иметь преимущество :-)


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

При наличии выключателя в розетке вытаскивать вилку и бросать ее на пол совершенно ни к чему.
Розетка одна, потребителей 3, подключаются по мере надобности, например. Но я за свою жизнь не могу вспомнть случая, когда наступал на европейскую вилку.
Недавно в течении нескольких лет у нас в стране все приборы давления к системе СИ приводили.

а еще более недавно — два раза в 1/5 части суши меняли TZ… Туда и назад.

Давайте прикиним, сколько нужно времени и денег, чтобы заменить эти розетки во всех домах страны, потом на всех производствах техники, а потом — сколько ещё вбухать деньги в переходники для старой техники.
Так прямо сейчас это происходит(или произошло), когда одновременно сосуществуют вилки типа C и F, когда не каждую вилку не в каждую розетку вставишь. И если современные вилки от лампы или смартфона втыкаются и туда и туда, то советские приборы, как впрочем и современные с заземлением входят только в своё родное. В несколько меньшем масштабе это происходит с usb при переходе с b на c.
В дальней перспективе наверное круто, но кто здесь и сейчас за это платить будет? ;-)
А кто простых людей спрашивает? Их просто перед фактом ставят. В том же Казахстане алфавит меняют(или не меняют, не слежу за новостями), уже третий раз за последние сто лет, с арабской вязи на кириллицу и теперь на латиницу. При чём, если с переходниками и удлинителями можно пользоваться ещё не одно десятилетие, то это будет полной потерей обратной совместимости.
При чём, если с переходниками и удлинителями можно пользоваться ещё не одно десятилетие, то это будет полной потерей обратной совместимости.

в РФ сделали реформу языка в 1917 вроде. И ничего. Все скушали это

Открыв старую книгу я вполне могу читать даже без дополнительного обучения, за счёт долгой практики, просто догадываясь как будет читаться тот или иной знак, но это для «современных» текстов, без всяких юсов, там потребуется дополнительное обучение. А вот другой алфавит ещё учить надо, так что текст на глаголице сходу я точно не осилю.
я вам больше скажу. после арабской была латиница, и только потом кириллица. а нынешняя латиница как минимум третья по счету после кириллицы. только все равно говно говнянское нелогичное и тупое: букву С исключили — она типа есть только в русском языке (Цаплины идут нахер, они какие-то неправильные граждане), теперь POLISIA пишут, но это не главный прикол. Есть в алфавите _буква_ CH — которая вместо Ч стала, да, буква, которая состоит из двух символов, одного их которых в алфавите нет. Ну и мелочи типа того, что три буквы выглядят одинаково в заглавном исполнении.
я вам больше скажу. после арабской была латиница, и только потом кириллица.
«Назад в будущее» там точно снимать нельзя.
Кириллицу недолюбливают (как минимум в Чехии) из-за того, что многие привычные по начертанию буквы звучат по-другому относительно латиницы. Примеры — Р, H, В, У, Х. Так же странно выглядит И как развёрнутая N. И не исключаю, что З взяли как цифру три — т.е. как будто Кирилл с Мефодием намеренно сделали «рельсы другой ширины». С другой стороны, в кириллице есть полезные Ж, Ч, Ш и Щ в то время, как на латинице приходится изголяться через zh, ch, sh, sch либо через умляуты. Я думаю, и войны вокруг буквы Ё идут из-за того, что она и Й единственные с умляутами в алфавите.
И не исключаю, что З взяли как цифру три — т.е. как будто Кирилл с Мефодием намеренно сделали «рельсы другой ширины»

Нет, это было задолго до прихода индийских-арабских цифр. Хвостик у Z в скорописи загнулся вниз и удлинился.


Кирилл с Мефодием, сейчас считается, сделали глаголицу, а кириллицу в нынешнем смысле породили их ученики, заменив все символы, для звука которых были буквы в греческом, на греческие.


А что недолюбливают (кто? не думаю, что все чехи — большинству пофиг) — точно так же можно и латиницу недолюбливать. Зачем потребовалось западным грекам (и вслед латинянам) заворачивать хвостик у П так, что она превратилась в Р, отчего исходная Р потребовала нового элемента и превратилась в R? Зачем было устранять K и искусственно создавать новую букву G, хотя исторически именно C выполняла роль Г (и это она же по происхождению, только переведена в плавную форму)? Многие прочие замены понятны, но зачем было тут вводить несовместимость на пустом месте?

Да, кстати, еще забыл упомянуть, что Я — это развёрнутая R. Кто и когда накосячил — мне доподлинно неизвестно. Сам факт наличия этих перевёртышей в 2020 налицо.
Да, кстати, еще забыл упомянуть, что Я — это развёрнутая R.

Изменение форм букв: H, N, Ѧ на И, Н, Я соответственно — реформа письменности 1708 года, закрепившая упрощённые формы из уже привычной скорописи. Дальше вслед за русской кириллицей это изменение постепенно было принято всеми прочими. Это общеизвестный факт, прослеженный многими исследователями по источникам.


Так что откуда вы взяли про "развёрнутую R" — непонятно, но давайте не делать поспешных упрощений. А то так можно придраться и к тому, что у немцев V значит [f], Z — [ts], а в английском и французском вообще фиг поймёшь, как читать какие-нибудь anxious/anxiety или eaux...

Есть и другие минусы. Ширина букв слишком различается, а вот высота очень часто одинаковая, и получается много слов «в ряд», когда ни снизу ни сверху ничего не торчит, а значит и распознается такое слово сложнее. В латинском алфавите буквы в ширину различаются намного меньше, зато вверх и вниз буквы расползаются намного чаще.
А в двухбуквенных/трехбуквынных сочетаниях ничего плохого нет, как мне кажется. Минусы бывают только если чтение будет неоднозначным, но это от языка зависит.
А в двухбуквенных/трехбуквынных сочетаниях ничего плохого нет, как мне кажется.

Проблемы с сортировкой: либо слова на «Х» идут посередине слов на «Ц», либо сочетания надо выделять и обрабатывать как отдельные буквы.
Ещё проблемы, когда сочетания идут подряд, как в фамилии Chruschtschow.
Ээээ, и почему это проблема? Я немецкий в школе учил, там S частенько читается как «ш» в сочетаниях с T и P (ну и в случае sch), и никаких проблем с сортировкой нет. А вы сейчас придумываете проблему на ровном месте. В литературном русском «Япония» не читается «йапония», звучит ближе к «йипония» или «йэпония», но никто не ставит Японию после Италии. По какой-то _неведомой_ причине. Буквы ё, я, ю — тоже сочетание двух звуков в некоторых случаях — в начале слова особенно — и опять, никто в здравом уме не говорит, что надо сортировать по типу йо, йа, йу — в середине алфавита.
Я немецкий в школе учил, там S частенько читается как «ш» в сочетаниях с T и P (ну и в случае sch), и никаких проблем с сортировкой нет

Ну, я не знаю… В том же венгерском — сначала идет Z (и все слова с него), а потом ZS (потому что это диграф). Ну, не хватило в латинице знаков для обозначения всех звуков

О, у венгров есть ещё и буква DZS между DZ и E =)

Это не буква ( в смысле нет символа «dzs» — это «d» + «zs», в противовес к d + z

Справедливости ради, её отдельной буквой признали только в 1984.
А чего мне представлять, у нас на работе старые розетки в куче мест были
Вооот такие
image
и дикая куча переходников с и на евро стандарт.
Но вообще, такие мне даже больше понравились, удлинители и тройники компактнее можно же делать.
Внутри сделано очень прилично. Помещается туда же, где стояла «советская» розетка, только вместо одной становится три. Вставляются любые вилки. Очень удобно. Купил лет десять назад две штуки и с тех пор больше не видел. Вроде турецкого производства.

image
А ещё есть такая вещь, как модуль часов RTC в микроконтроллерах. В большинстве случаев он для «удобства» считает в секундах, минутах, часах, причём нет отдельного 32-битного счётчика для unix-формата. И вот, если тебе надо узнать количество времени до события, или завести аларм через некоторое время, ты переводишь программно всю эту красоту в unix-формат, выполняешь сложение или вычитание, и переводишь обратно в BCD, чтобы положить в регистры аларма… Производителям контроллеров даже в голову не приходит, что программистам нафиг не нужен этот BCD, дайте нам 32-битный регистр, ну не делает никто будильник с сегментными индикаторами на пол-гигагерцном проце, а те, кому надо — легко преобразуют в BCD даже на 4-битном контроллере…
Операция целочисленного деления дорогая. Т.е. переход от uint32 к dd:hh:mm:ss требует деления/остатка на 60. А это энергетически дорого. В первых процессорах операции деления не было. Думаю, первоначально в этом причина была.
Операция целочисленного деления дорогая.

srsly? Я то думал, что остаток легко считается циклом ) Чай — не операции с плавающей точкой (там ад). И, да, будто паковка и распаковка из BCD не требует энергии (да, я помню, что есть аппаратные операции для этих операций)

Скорее всего, RTC в компьютерах произошли от электронных часов, которые внутре имели 60-ричные счетчики ;)
srsly? Я то думал, что остаток легко считается циклом )

На очень мелких числах — да. Но уже на десятках тысяч это становится слишком дорого.


А целочисленное деление, да, самая дорогая операция в этой группе.


Чай — не операции с плавающей точкой (там ад).

Сейчас уже наоборот: Goldschmidt division — требует тщательной подгонки точности, но из-за характера чисел сейчас выполняется дешевле, чем целочисленное деление при тех же размерах значений.

Деление делалось столбиком, поделить на 60 — это всего лишь 6 вычитаний и 6 сдвигов. И я не говорю, что надо отменить BCD формат — просто добавьте ещё один 32-битный регистр, который будет считать синхронно с BCD счётчиками. Можно даже не синхронизировать их аппаратно. Для современных нанометров лишний счётчик — ничто, а сколько проблем решает…
:) Согласен. Хороший пример.
Есть еще один момент, где 1..N индексация даёт себя знать по сравнению с [0;N) индексацией – это работа с float’ами.


Не понял, чем работа с массивами float принципиально отличается от массивов int.
А так да, legacy наше всё.
Я не про массив int, а про сам индекс. Допустим, у нас есть набор отрезков. 1..N нотация вкупе с [first;last] мышлением приводит к тому, что программист пишет цикл A1..A2;A2+1..A3;A3+1..A4. Когда нотация в голове [0;N) — имеем дело только с контрольными точками A1,A2,A3,A4, т.е. меньше магических чисел в коде. Плюс эти +1 перескоки не подойдут под float'ные смещения. Я согласен, что это больше про [a;b] vs. [a;b) подход, чем про base0 vs base1.
Ещё есть число пи. Отношение длины плоской окружности к её диаметру. На практике намного чаще нужно отношение длины окружности к радиусу, и повсюду возникают всякие 2пи. Знаю людей, которые применяют «число тау», как раз равное двум пи, чтобы не загромождать формулы ненужными коэффициентами.
Вот только число пи находит применение не только при рассчёте длин окружностей. И тогда пришлось бы не домножать на 2, а делить на 2, что намного хуже.

На 2 числа с плавающей точкой делить легко — просто -1 к показателю степени. И если 2 это константа, ничто не мешает так и скомпилировать.
А вот если бы был выбор между умножать на 3 и делить на 3, скажем — тут деление действительно намного хуже.

Всюду где нужно описание цикличиских процессов (физика колебаний, радиотехника) и идёт работа с углами (полярные координаты, радианы, комплексные числа) переход от 2пи к тау = 6,28 был бы чистым подарком. Пожалуй единственная формула которая проще с константой 3,14 это вычисление площади круга. Хотя, если задуматься, многие школьные формулы растут из интегрирования:
— кинетическая энергия 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-ричная еще норм — как я писал, у нее много делителей. Если бы ее использовали для всего, мир был бы чуточку лучше. А пальцы не ноге неудобно использовать.

Ну я бы не сказал, что у меня какие-то сверхгибкие руки (скорее, наоборот), но дотянуться большим пальцем до каждой фаланги мизинца — не вижу проблем. Но профессиональные музыканты могут сильно больше.
Хотя, да, согласен, что есть разные варианты. Я спокойно нажимаю на стандартной десктопной клавиатуре 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, почему не считался большой палец, если он тому причиной ;)

откуда древний счёт по 4, почему не считался большой палец, если он тому причиной ;)
Им считали при счёте одной рукой?
С учетом сгибания 4-х пальцев для отмечания количество четверок, можно считать вплоть до 20, где большим пальцем показываешь на число в итоговой четверке)
Откуда пошло лево/право по первичной оси X – я думаю, что из письменности.

Если мне не изменяет память, то какая-то из первых вавилонских письменностей вообще была феерическая: они пераую строку писали слева направо, а вторую — справа налево, чтобы взгляд не бегал на начало строки, а плавно перемещался по буквам.

А что, удобно наверное. Правда как определять, в какую сторону читать произвольную строку…

Для машины не удобно определять, да. Человеку проще — увидит "абырвалг", подсознательно распознает слово и чуть более сознательно перескочит на другой конец строки.

Это для азбуковой письменности. Для иероглифической придётся парсить минимум пару слов.

Ага, вот я сам в ловушку инерционности мышления и попался. :D


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

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

ну, с анаграммами и палиндромами народ вовсю играется )))

Для иероглифической придётся парсить минимум пару слов.

Только для симметричных кандзи, которых не так уж и много, плюс за раз человек читает гораздо больше чем один символ.
Предлагаете зеркалить кандзи при таком написании? Я думал они как «абырвалг» будут, только последовательность обратная.
commons.wikimedia.org/wiki/File:Crete_-_law_of_Gortyn_-_boustrophedon.JPG

Алфавитная письменность, но всё равно в каждой строке знаки «смотрят» в направлении письма.
Хотя даже симметричные кандзи, при традиционном написании с помощью кисти(или перьевой ручки) будут различаться, поскольку там важно направление письма. То есть достаточно одного единственного символа, и вопрос между R или Я не встанет.image
Нет, потому что при записи «в обратную сторону» знаки отражали зеркально.
Счастливые древние вавилоняне, при таком способе письма у них не было причин для наших проблем с различными кодировками CRLF/CR/LF. Кстати, это ещё одна тема для этой статьи, в жизни разброд в кодировках перевода строки напрягает гораздо чаще, чем little/big endian.
А именно поэтому 'to be continued' стоит. Готовлю вторую часть :) Там будет как раз про даты, кодировки, обратные слэши и т.п.
Древние греки тоже так пописывали. Бустрофедон называется (т.е. ход вола на пашне).
Если требуется собрать несколько сегментов встык

А какое отношение это имеет именно к индексации?
То что диапазоны бывают удобны в таком виде, понятно, но от способа индексации в используемом ЯП это не зависит. «Магические» единицы вовсе не магические, и вылазят они независимо от индексации. Например, в том же цикле FOR i := 0 TO LEN(ARR) - 1 DO
Вы будете везде вычитать единицу, где нужен последний элемент. Просто сдвинули неудобство в другую сторону. А где нужен предпоследний, там вообще 2.
Что еще? Например, мы любим отрезать префиксы так (go или python):
x = s[len(prefix):]
Единицы нету, но ее нету не потому что индексация такая удачная, а потому что len() тут выступает в качестве оператора «индекс на 1 больше последнего». Магический тут именно len(), а вовсе не 1, с которой код наоборот прямолинейно выражает что мы делаем.
Не исключаю, что именно магия len() и очаровала впечатлительных технарей в свое время. Магия из разряда x = y++;, и прочих игрушек для самовыражения, от которых новые языки уже отказываются.
Но в некоторых случаях действительно удобно делать с 0. Когда, например, вычисляем i = y*w+x. Тут y должен быть с нуля, а вот x уже без разницы. Такой расчет будет при любом варианте индексации.

Машинам с 0 проще, это да. Но людям все таки удобнее мыслить с 1. Когда я хочу чтоб мне дали второй слева предмет, я так и прошу (и мыслю). Сколько бы я не программировал, мыслю я все равно иначе. И len() удобнее мыслить как последний индекс. len()-1 предпоследний, len()+1 следующий за последним и т.д.

Диапазоны [i, j) тоже надо использовать только когда они реально нужны.
Насколько быстро вычислите в уме?
s = "abcdefg"
s[2:5]+s[1:3]

представьте насколько лучше читались бы срезы, если не привлекать тут концепции, которые на самом деле не к месту:
s = "abcdefg"
s[3:5]+s[2:3]

С 3 буквы по 5, плюс со 2 буквы по 3. Чем же питоновый вариант лучше этого?

Я сам много лет, как и большинство программистов, использую индексацию с 0, и она прошита уже в подкорке. Но удобство ее все таки считаю притянутым за уши. В том же питоне и срезы и range() сделаны так, будто всеми силами натягивали сову на глобус, лишь бы «магические» единицы не вылезли. И что, удобно оно в питоне? Честно говоря, не ощущается.

ps Я не агитирую за индексацию с 1. Мне без разницы вообще. Просто так картина полнее.
pps А индексация с 0 никуда не денется потому что уже стандарт.
Черт его знает, но когда на первом курсе универа мне пришлось переходить с индексации [1..n] на [0..n-1] оказалось, что вторая — гораздо удобнее в вычислениях.
Индекс в массивах ведь задает не номер элемента а смещение от начала. Подумайте об этом.
Это удобство имхо ощущается только на c/c++ из-за индексируемых указателей. В других языках уже не так. В том же Lua, например, никаких проблем с индексацией нет (она там с 1). Мне довелось много лет пользоваться обоими вариантами. Никакой разницы в удобстве программирования не замечаю. Есть небольшая разница только в когнитивной нагрузке при чтении кода.
Есть разница в том, что процессору приходится тратить лишние такты на преобразование этой единицы в смещение. Но ALU нынче дешёвое.
Индекс в массивах ведь задает не номер элемента а смещение от начала. Подумайте об этом.

Ситуация как раз обратная: обычно индекс массива — это номер элемента, а не смещение. По крайней мере в прикладном программировании, за системное не скажу.


Под вычислениями с индексами вы имеете в виду что-то в духе перевода между одномерной и многомерной индексацией одного и того же массива и т.п.? Этого в коде лучше избегать в явном виде, независимо от старта с 0/1, и пользоваться соответствующими абстракциями написанными один раз (хорошо если они в стандартной библиотеке). И багов меньше будет, и код понятнее.

Я согласен, что смешал base-1 и [A;B) аргументацию в одном флаконе. В целом это разные вещи.

Сенсационное открытие, при эволюционном развитии новое базируется на уже существующем!


Из-за этого паскалевские конструкции вида 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.

Нет, современные компиляторы обычно сдвигают индексацию в таких случаях. Не уверен, что это всегда полезно, но, видимо, явно такое добавили в правила.

Я не FOR i:=1 TO N часть ассемблерного кода имел в виду, а про работу дальше с ним по какому-нибудь массиву, т.е. A[i]. который определён как [1..100]. Либо придётся лишний элемент вставлять в начало массива, чтобы 'i' сразу было применимо, либо каждый раз выполнять DEC/SUB ESI/EDI. Либо SIB выкрутасы. Либо цикл умно компилировать, чтобы он для программиста выглядел как 1..N, а для процессора как 0..N-1.
Либо цикл умно компилировать, чтобы он для программиста выглядел как 1..N, а для процессора как 0..N-1.

Скажу больше — в асме оно зачастую идёт в обратную сторону, от N-1 до 0, по соображениям каких-то там оптимизаций.
Тут очень просто — при счете до 0 не надо в каждой итерации вспоминать значение конечной точки отсчета и сравнивать с ним, оно фиксировано:

счетчик = 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 бит со знаком).

Недавно смотрел «Культурную одиссею» с Баумейстером и Соловьевым на ютубе. Они утверждают, что по археологическим данным за последние двадцать лет (со ссылками на источники) люди в пещерах не жили, а отправлялись туда как в священные места для исправления ритуалов. В связи с этим утверждение «сначала в пещерах были палочки/насечки, чтобы научиться считать и освоить базовую арифметику» выглядит спорным. На какие источники вы опираетесь?
Это просто как общепринятая точка отсчёта, когда люди только послезали с деревьев и математики еще не было — т.е. некий вакуум сформировавшихся привычек. Альтернативное метамодель — «когда я только родился и еще не наслушался местного общепринятого», т.е. был tabula rasa :)
Пожалуйста, не используйте
(int&)++floatVariable
— это undefined behavior. Используйте
std::nextafter
Часовая стрелка движется именно в привычном нам направлении потому, что так двигался указатель в солнечных часах. При этом полный оборот привычного стрелочного циферблата составляет 12 часов, а не 24, как у солнечных. Просто кто-то так решил, что будет удобней. А если бы оставили «правильный» 24 часовой циферблат, то по нему было бы удобно ориентироваться по сторонам света по солнцу. Но нет, исторически не сложилось.
Ну не знаю, у меня вот так:
Скрытый текст

Это как раз подтверждает, что потребность в 24 часовом циферблате есть, но по традиционным причинам они крайне редки. Привычки пользователей порождают спрос, спрос порождает предложение, предложение не позволяет пользователям поменять привычки. Замкнутый круг.
Я думал, кстати, командирские часы воткнуть картинкой. Не стал на случай перевода на английский.
Западному читателю вспомнятся часы из фантастического фильма Метрополис.

В 1927 году часы будущего представлялись вот так


Тут и новые десятичные часы и 24-часовая шкала для привыкших к «старому стилю», если я правильно интерпертирую замысел Фрица Ланга.

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

У других (OpenGL) в глаз

В OpenGL настраивается

Технически — да, и в DirectX тоже. Речь про «дефолтную» парадигму, которая прошивается в мозг начинающему 3D программисту.
А чем дальше, тем круче. Люди не смогли договориться о том, как писать вектора – в строку или в столбец.

Хм… есть вектор-строка, есть вектор-столбец, и если надо, то один в другой можно волшебным путем превратить с помощью транспонирования. Дело в том, что вектором-то является любой элемент линейного пространства и могут быть представлены как угодно: матрицами, столбцами, строками, отрезками и т.д. и т.п., в обще что угодно. На уровне программирования под вектором понимается вообще любая упорядоченная последовательность однородных объектов. Так что запись может быть любая, но обычно вектор записывают строкой, если это возможно (и не имеет глубинного смысла).
Дело не в вертикали/горизонтали (кстати, вдаль вектора еще никто не рисовал (от себя по Z) — но это, я думаю, особенности местного магратейского восприятия :), а в том — будет ли последовательное преобразование вектора чередой матриц иметь последовательный вид VxM1xM2xM3 или
извращённый вывернутый вид M3xM2xM1xV. Вертикальная форма записи провоцирует второй вариант.
Там на самом деле все упирается в то, как используются вектора и матрицы и какой смысл в это вкладывается, с учетом того, что умножение матрицы происходит всегда слева на право, которая включает в себя действие умножения каждого вектора-строки одной матрицы на каждый вектор-столбец другой матрицы, а сама операция умножения не является коммутативной.

Например, если мы рассматриваем матрицы как линейные отображение (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. Все идет оттуда — из алгебры, потом уже удобный вычислительный инструментарий алгебры применяется к другим областям математики, например, к геометрии.
Я в курсе всего, что вы написали :) Тут больше разговор о том, что мозги приходится вертеть туда-сюда при восприятии формул. Посыл в том, чтобы порядок преобразований максимально соответствовал движению глаз слева-направо, поэтому v1*A*B+v2*C*D предпочтительней — исключая знак плюс (но это уже двумерность формулы сказывается) глаз бежит слева-направо
---> -> --->
В случае B(A(v1)) + D(C(v2)) порядок чтения формулы получается
< — -> <---
Это по идее восходит к тому, что сама запись применения функции/оператора взялась как sin(x), а не x->sin к примеру (и в каком-то языке программирования так и сделали).
Коммутативность сложения позволяет читать вторую формулу непрерывно справа налево.

Не только применение, но и композиция функций записывается всегда справа налево: g∘f(x) = g(f(x))
Но тогда логично и «верхний» уровень сделать справа налево — т.е. чтобы
g(f(x)) — g(f(y)) подразумевало вычитание левой части из правой.

Если возвращаться к тотальной слева-направо форме, то композицию я бы записал как
x->(f->g)
Тут больше разговор о том, что мозги приходится вертеть туда-сюда при восприятии формул.

Ну, иначе никак. Такова особенность алгебра-прона: ради оптимизации вычислительной сложности (да и просто для решения задач), приходится крутить-вертеть, да гонять по местам все эти матрички. И эта проблема еще и исторически осложняется еще несовершенством парсеров — это у Матлаба вменяемый синтаксис с точки зрения математики, а вот все эти ваши Си-плюс-плюс только скалярными величинами оперировать и могут, а массивы не более чем структура данных, полноценных матриц нет, память плоская и т.д. и т.п. Работа с графикой уже подразумевает наличие векторных операций, однако видеокарты предназначены в первую очередь для того чтобы быстро отрендерить сцену и когда появились первые шейдеры (а я даже немного застал эти времена) их функционал был мягко говоря ограниченным, и понятное дело, что весь синтаксис был заточен под то, чтобы все транслировалось в высокоэффективный код. Отсюда тот же, например, column-major order, ну просто потому что при порядке row-major будет O(N^3) кэш-промахов, а это нехорошо, ща правда появилась возможность настраивать порядок, но там есть ньюанс, связанный с тем, что просто компиляторы поумнели, но это случилось далеко не сразу. Отсюда же идет мода реверсить порядок матриц (которые уже заранее будут транспонированы), так как начиная каскад умножений с вектора 1x4, мы сократим число умножителей и сумматоров для этого вычислительного потока, на сумматоры, конечно пофиг, а вот умножалка — она дорогая.

Это по идее восходит к тому, что сама запись применения функции/оператора взялась как sin(x), а не x->sin к примеру (и в каком-то языке программирования так и сделали).


Весь секрет в типичном порядке слов в человеческий языках, и в 42% языков используется именно SVO (subject-ver-object) порядок, например, в таких языках как греческий, русский, английский, китайский и т.д. и т.п. для которых простые предложения будут иметь следующий вид:
Кошка пьёт молоко

Уильям любит водку

Васян играет на фортепьяно

В общем что-то совершает действие над чем-то — субъект => действие => объект
image
Такой порядок является единственно-верным базовым порядком для английского языка и основным порядком слов для романских языков. Не смотря на то, что в славянских языках, кроме болгарского, порядок слов вроде бы свободный свободный, но нейтральным и дефолтным вариантом является именно 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-го века.

"Местами" он и сейчас есть. А вот чтобы латынь преобладала как "язык международного общения" — таки после классического средневековья уже не факт.

Что же касается HLSL и OpenGL, то на самом деле оба шейдерных языка работают примерно одинаково и их цель севершить такую операцию над вершиной:
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-ых.
Да, про это я и говорил в аспекте row-major/col-major деклараций в HLSL как минимум.
Поэтому работает такая штука, как «кармическое воздаяние» — моторолы, 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 кроме привычности других доводов нет», но не согласен с оценкой этого: машины перепрограммировать на новый порядок гораздо проще, чем людей, так что привычность — решающий фактор.
Кстати, еще вспомнилось, что google protobuf — тоже little-endian, хоть и «сетевой протокол». Тут вряд ли можно сослаться на оптимизацию под x86 железо, т.к. он всё равно base-128. Верной дорогой идут товарищи.
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 делать всему и вся.
Как и у вас в статье :)
У меня хотя бы конструктивно :) А «эмоции» — это чтобы было интересно/весело читать. типа кдпв :)
А если цифр на 137 байт? т.е. не кратно ни 4, ни 8.

И что? Всё равно нужно обнулить хвост не кратный 4. В обоих случаях.
Либо работать с байтами.
Only those users with full accounts are able to leave comments. Log in, please.