В описании механизма поворота автор, видимо, что-то напутал.
Если потянуть рычаг со стороны короткого плеча (А=1, Б=0), то смещение ряда будет больше, чем если потянуть со стороны длинного плеча. Т.е. поледовательность должна быть такая: Ряд 0: А=0, Б=0 Ряд 1: А=0, Б=1 Ряд 2: А=1, Б=0 Ряд 3: А=1, Б=1
Как это сделать с большим количеством рычагов - даже не представляю, было бы интересно сглянуть.
А в целом большое спасибо автору - было очень позновательно.
>>Вы заметите, что на самом деле клавиши смещены таким образом, чтоб нашим пальцам было удобно их нажимать.
Клавиши смещены так, потому что иначе нельзя было сделать механическую клавиатуру, в которой от каждой клавиши идет продольный рычаг. Удовства это не добавляет. И это не более чем вопрос привычки, которая тянется уже 150 лет и последние 70 лет такое расположение - не более чем рудемент.
Энергетически разница огромная. В отличае от крана, робот (как и человек) вынужден носить вместе с кирпичами свою тушку, которая сильно тяжелее носимого груза. Примерно 100 кг туши, на 20 кг груза. + куча энергии на балансировку от этого дурацкого прямохождения на 2х ногах.
Да там одни лишь gpu-хи на компьютер вижн будут как минимум 1000 Вт жрать.
Но все это не важно. Т.к. стоимость топлива на работу принебрежима мала в стоимости смены подъемного крана. В основном там оплата работы оператора и амортизация достаточно недорогой техники (тк производится массово)
У электродвигателя как раз проблемы с нулем оборотов.
При малых оборотах палое сопротивления двигателя приходится компенсировать включением последовательного сопротивления, которое просто перегоняет серьезную часть энергии в тепло, пока обороты не разгонятся.
Так что кривая зависимости эффективной мощности от оборотов там тоже есть, правда пошире чем у ДВС.
Размеры колонии в бенчмарке не особо репрезентативны, поэтому результата между разными размерами не видно (отклонения 61-81% в рамках погрешности измерения).
Объекты размером 24 байта в занимают 240000 байт, что влезает даже в L1 кэш (там как раз 256 Кб).
То, что ДОП тут лучше чем ООП видно, что зачем приводоить список на 100,1000 и 10000 не понятно, там разницы нет. И не будет, даже если мы вейдем за пределы кэша. Т.к. если к данным обращаются один, то в любос случае придется ходить в память.
А вот если обращаться к каждому муравью много раз, то там сразу ощутите, какая будет просадка в размере сильно больше 10000.
Тут скорее опеделяет тот фактор, что эволюция не может создать колесо.
Для эволюции важно, что любой развиваемый орган должен быть полузным на сколь угодно малой стадии своего развития. Конечность будучи отростком из двух клеток — уже полезна. А колесо полезно уже как завершенный девайс.
Поэтому даже если многие животные могли бы быть более быстрыми и энергоэффективными на колесах, у них могут быть только конечности.
Беглое чтение википедии говорит о том, что у Гипотезы эффективного рынка есть свои проблемы: Парадокс Гроссмана-Стагница, Парадокс объема сделок, Рыночные пузыри.
Чего достаточно чтобы не принимать данную гипотезу как доставерный закон. Так что у статьи весьма шаткое основание.
Для Яндекс.Такси как сервиса клиентами являются как заказчики, так и таксисты.
По аналогии можно сказать, что на фриланс биржах видется рейтинг как исполнителей, так и заказчиков. И совершенно нормально, что биржа готова защищать исполнителей от недобросовестных заказчиков, предупреждая из низким рейтингом.
Как видно, источники периодически врут.
На первом фото устройство чтения перфоленты реплики Z1, построенной лично Конрадом в 1989. Фото сделано лично мной.
Большое спасибо за статью. Открыл для себя несколько новых фактов, особенно о Z2. Ранее переводил подробную статью о Z3 на хабре, возможно вы уже ознакамливались: https://habr.com/post/210412/
В Вашей статье обнаружил несколько неточностей:
1)
Она (Z1) считывалась с бумажной перфоленты и по мере считывания происходило её выполнение
Дело в том, что насколько я знаю, Цузе перешел на бумажную перфоленту только с Z11. А в Z1 и Z3 использовались перфоленты из фотопленки. Это даже логично, т.к. Z1 считывала ленту механически и от ленты требовалось быть прочной, а машины в Z11 осуществляли уже электронное считывание, и лента смогла быть более дешевой и менее прочной.
В подтверждения прилагаю фото устройства чтения перфолент машины Z1 из Берлинского технического музея.
А это описание Z11 из того же музея, где указано, что в нем, уже успользовалась бумажная перфолента
2)
вывод результатов расчётов производился на перфоленту
Очень сомнительно утверждения, прошу сослаться на источник. Прежде всего стоит заметить, что в машине присутствовало только одно устройство чтения перфолент (на котором был код программы), никаких признаков дополнительного устройства работы с перфолентами нет, ни на фото, ни в статьях. К тому же, в наборе машинных команд отсутствуют какие-либо инструкции, связанные с вводом/выводом на перфоленту. Из ввода/вывода есть только команды вывода одного числа на консоль управления, после которого компьютер ждет, пока оператор перепишет результат и нажмет кнопку продолжения.
Но ведь можно поступить по другому. Для каждого человека настроить область гиперпространства где хранятся достоверные для него величины
В NIST FRVT сравниваются между собой не «лица», а «персоны». т.е. дескриптор строится именно на наборе фотографий одного человека и вендор имеет возможность параметризовать в дескрипторе область распределения данного лица.
Бесконтрольное производство товаров и услуг в любом количестве приведет к экологической катастрофе.
Так что так исключительно технологически этот вопрос не решает, все равно потребуется система принятия решений об ограничении производства и распределении товаров. И вот уже от этой системы зависит, будет-ли общество классовым или нет.
В описании механизма поворота автор, видимо, что-то напутал.
Если потянуть рычаг со стороны короткого плеча (А=1, Б=0), то смещение ряда будет больше, чем если потянуть со стороны длинного плеча.
Т.е. поледовательность должна быть такая:
Ряд 0: А=0, Б=0
Ряд 1: А=0, Б=1
Ряд 2: А=1, Б=0
Ряд 3: А=1, Б=1
Как это сделать с большим количеством рычагов - даже не представляю, было бы интересно сглянуть.
А в целом большое спасибо автору - было очень позновательно.
>>Вы заметите, что на самом деле клавиши смещены таким образом, чтоб нашим пальцам было удобно их нажимать.
Клавиши смещены так, потому что иначе нельзя было сделать механическую клавиатуру, в которой от каждой клавиши идет продольный рычаг. Удовства это не добавляет.
И это не более чем вопрос привычки, которая тянется уже 150 лет и последние 70 лет такое расположение - не более чем рудемент.
Энергетически разница огромная.
В отличае от крана, робот (как и человек) вынужден носить вместе с кирпичами свою тушку, которая сильно тяжелее носимого груза. Примерно 100 кг туши, на 20 кг груза.
+ куча энергии на балансировку от этого дурацкого прямохождения на 2х ногах.
Да там одни лишь gpu-хи на компьютер вижн будут как минимум 1000 Вт жрать.
Но все это не важно. Т.к. стоимость топлива на работу принебрежима мала в стоимости смены подъемного крана. В основном там оплата работы оператора и амортизация достаточно недорогой техники (тк производится массово)
У электродвигателя как раз проблемы с нулем оборотов.
При малых оборотах палое сопротивления двигателя приходится компенсировать включением последовательного сопротивления, которое просто перегоняет серьезную часть энергии в тепло, пока обороты не разгонятся.
Так что кривая зависимости эффективной мощности от оборотов там тоже есть, правда пошире чем у ДВС.
Объекты размером 24 байта в занимают 240000 байт, что влезает даже в L1 кэш (там как раз 256 Кб).
То, что ДОП тут лучше чем ООП видно, что зачем приводоить список на 100,1000 и 10000 не понятно, там разницы нет. И не будет, даже если мы вейдем за пределы кэша. Т.к. если к данным обращаются один, то в любос случае придется ходить в память.
А вот если обращаться к каждому муравью много раз, то там сразу ощутите, какая будет просадка в размере сильно больше 10000.
Для эволюции важно, что любой развиваемый орган должен быть полузным на сколь угодно малой стадии своего развития. Конечность будучи отростком из двух клеток — уже полезна. А колесо полезно уже как завершенный девайс.
Поэтому даже если многие животные могли бы быть более быстрыми и энергоэффективными на колесах, у них могут быть только конечности.
Чего достаточно чтобы не принимать данную гипотезу как доставерный закон. Так что у статьи весьма шаткое основание.
По аналогии можно сказать, что на фриланс биржах видется рейтинг как исполнителей, так и заказчиков. И совершенно нормально, что биржа готова защищать исполнителей от недобросовестных заказчиков, предупреждая из низким рейтингом.
GAN — это Generative Adversarial Nets. Штука, которая позволяет генерить изображения, к играм не имеет отношения.
А можно подробнее про «три перфокарты»? Прям хочется на код взглянуть.
Вот это ламповая панель вывода Z3:
Но работа с лампами, как минимам, требует реле, но Z1 была полностью механической. Устройство вывода там тоже состояло из механических индикаторов.
На первом фото устройство чтения перфоленты реплики Z1, построенной лично Конрадом в 1989. Фото сделано лично мной.
В Вашей статье обнаружил несколько неточностей:
1)
Дело в том, что насколько я знаю, Цузе перешел на бумажную перфоленту только с Z11. А в Z1 и Z3 использовались перфоленты из фотопленки. Это даже логично, т.к. Z1 считывала ленту механически и от ленты требовалось быть прочной, а машины в Z11 осуществляли уже электронное считывание, и лента смогла быть более дешевой и менее прочной.
В подтверждения прилагаю фото устройства чтения перфолент машины Z1 из Берлинского технического музея.
А это описание Z11 из того же музея, где указано, что в нем, уже успользовалась бумажная перфолента
2)
Очень сомнительно утверждения, прошу сослаться на источник. Прежде всего стоит заметить, что в машине присутствовало только одно устройство чтения перфолент (на котором был код программы), никаких признаков дополнительного устройства работы с перфолентами нет, ни на фото, ни в статьях. К тому же, в наборе машинных команд отсутствуют какие-либо инструкции, связанные с вводом/выводом на перфоленту. Из ввода/вывода есть только команды вывода одного числа на консоль управления, после которого компьютер ждет, пока оператор перепишет результат и нажмет кнопку продолжения.
И как это соотносится с NVidia TPU, интересно.
В NIST FRVT сравниваются между собой не «лица», а «персоны». т.е. дескриптор строится именно на наборе фотографий одного человека и вендор имеет возможность параметризовать в дескрипторе область распределения данного лица.
Это где-нибудь сейчас работает?
Статья — просто набор несвязных фактов ((
Так что так исключительно технологически этот вопрос не решает, все равно потребуется система принятия решений об ограничении производства и распределении товаров. И вот уже от этой системы зависит, будет-ли общество классовым или нет.