Как стать автором
Обновить
393
0
Денис Кошман @Harkonnen

Пользователь

Отправить сообщение
Там целая система моддинга на LUA.
mods.factorio.com
Можно, к примеру, этот попробовать:
mods.factorio.com/mod/Hive_Mind
Судя по докам и гуглам, JavaScript все числа хранит как double. Чистых int'ов он не умеет. Может быть с этим связано.
Оно и так было в первых codepoints ASCII
Скрытый текст
image
Времена на столько другие, что косинус стал мнiмой -4.
Поддерживаю. Подача контента — уровень Джедай! :)
Тут мне ответить нечего :) Ваш комментарий достоен отдельной статьи, и самому пролил свет на некоторые аспекты. Собственно, из подобных «осколков знания», собранных по жизни, и родился исходный контент. Большое спасибо! :)
Т.е. сесть за руль в 40, а съехать от родителей в 50 :)
Не всегда, раньше по крайней мере клики по дороге (а не в дом) адрес не давали. Ну и всё это не очень в тему за рулём — несколько раз так уже сбивал себе маршрут.
А если нужно эти числа поделить? :)
Если поделить, их всё равно придётся целиком принять до первых телодвижений — хоть в little, хоть в big постановке, realtime стриминг там нереален.
На big-endian процессоре эти числа из того же самого потока будут складываться точно так же. Обычно есть инструкции bswap или что-то подобное
А если цифр на 137 байт? т.е. не кратно ни 4, ни 8.
Что-то более близкое к реальности есть?
Собс-но в 8008 оно возникло из-за схожих причин. Из современного резко на ум не приходит — хотя заморочки с trailing non-4-byte уже могут доставить. Ну и всё равно «математичеки» коробит, когда макро-порядок в длинной арифметике всегда little-endian, а внутренний может быть big-endian. Макро-порядок на little-endian — чтобы можно было инкрементнуть ++ или добавить += что-нибудь в длинное число и потом realloc дёргать с того же базового адреса, а не memmove делать всему и вся.
Как и у вас в статье :)
У меня хотя бы конструктивно :) А «эмоции» — это чтобы было интересно/весело читать. типа кдпв :)
Речь больше о том, что на длинной улице текст с её названием будет километрах в двух дальше того места, где находишься — при зумауте текст может пропасть, поэтому приходится скроллить вдоль по улице, чтобы доскроллить до её названия, а потом скроллить обратно туда, где был.

Связано, скорее всего, с заранее подготовленным на сервере tile render'ом, куда названия вписываются, но по идее мобилы уже доросли до того, чтобы названия самим сверху рисовать по нужным кривым.
Кстати, еще вспомнилось, что 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 всё это очень некрасиво вылазит.
Почему-то вы проигнорировали все места, которые я выделил :)
Ну там выделены эмоциональные всплески, без конструктивизма :)
Честно говоря, не ожидал такого от «отца 8086».
Тут речь шла не о поддержке двух вариантов в коде
Я не про код, а про мир — чтобы не было двух разных парадигм, что в сети одно, а в железе другое. «Идиотией» он видимо это посчитал из-за того, что на рынке тогда уже были big-endian процы и на них кто-то уже начал равняться.
But if I had made the break with the past and stored the bytes more logically
Так в том и дело, что оно ни фига не «logically», а «habitually» :) об этом и статья.
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 кроме привычности других доводов нет.
Но тогда логично и «верхний» уровень сделать справа налево — т.е. чтобы
g(f(x)) — g(f(y)) подразумевало вычитание левой части из правой.

Если возвращаться к тотальной слева-направо форме, то композицию я бы записал как
x->(f->g)
Я в курсе всего, что вы написали :) Тут больше разговор о том, что мозги приходится вертеть туда-сюда при восприятии формул. Посыл в том, чтобы порядок преобразований максимально соответствовал движению глаз слева-направо, поэтому v1*A*B+v2*C*D предпочтительней — исключая знак плюс (но это уже двумерность формулы сказывается) глаз бежит слева-направо
---> -> --->
В случае B(A(v1)) + D(C(v2)) порядок чтения формулы получается
< — -> <---
Это по идее восходит к тому, что сама запись применения функции/оператора взялась как sin(x), а не x->sin к примеру (и в каком-то языке программирования так и сделали).
Да, про это я и говорил в аспекте row-major/col-major деклараций в HLSL как минимум.
Дело не в вертикали/горизонтали (кстати, вдаль вектора еще никто не рисовал (от себя по Z) — но это, я думаю, особенности местного магратейского восприятия :), а в том — будет ли последовательное преобразование вектора чередой матриц иметь последовательный вид VxM1xM2xM3 или
извращённый вывернутый вид M3xM2xM1xV. Вертикальная форма записи провоцирует второй вариант.
Пространственное воображение делает многие вещи очевидными в то время как на уровне цифр и уравнений их приходится доказывать чуть ли не перебором.

Информация

В рейтинге
Не участвует
Откуда
Россия
Дата рождения
Зарегистрирован
Активность