Про это я и пишу - обход дейкстрой (flood fill это немного про другое) сделать несложно, а вот весь интерес в разработке алгоритма, учитывающий физику процесса движения. Помню фурор, когда впервые отошли от тупого прохождения лабиринта по кратчайшему пути к более длинному маршруту, но учитывающими ограничения робота.
А допуски откуда брать? Измерил ты что-то длинной 28.9 единиц, и дальше думай это 29±0.1 или 28.9±0.1 или еще какой-то вариант. Без оригинальных чертежей весьма сложно спроектировать деталь для более-менее массового использования.
В зависимости от причины смерти. Если кто-то погиб на маршруте, то вытаскивают, а если был срыв и улетел в какой-нибудь "трупосборник" в трещину, то тело так и останется там. Эвакуация и очень трудоёмкая и весьма опасная.
ратрак до вершины не доезжает не из-за погоды, а из-за характера рельефа) занятное видео про поездку на вершину на специально модифицированном мотоцикле - https://www.youtube.com/watch?v=Qfci-w0fQhI
КО: лучше 100 раз развернуться чем один раз не развернуться когда нужно было)
В теории можно было сходить на вершину и догнать группу, если уверен в своих силах. Связки нужны только на небольшом участке 3900-4600.
Несколько моментов:
"Во-первых, на такой высоте ты не восстанавливаешься: организм использует накопленный прежде кислород, а его запас не восполняется" - это не так. Выше 7000 да, восстановление проблематично для большинства людей, но даже на 6500 вполне хороший отдых, а на 3800 вообще лафа.
В штурмовом лагере с Севера есть несколько опций проживания не в палатках, а в "домиках".
Лучше делать акклиматизационный выход до вертолёта (~4800) или чутка повыше до верхних скал Ленца.
Есть еще интересный проект https://github.com/yeokm1/graphics-gremlin-hdmi, но там используется отдельный DVI трансмиттер, поэтому менее круто) Но можно подсмотреть как реализуется CGA/MDA.
То, что кто-то назвал инструкцию как or.h не означает то, что это именно or.h а не lui. Грепнул листинг, во всех случаях этот or.h используется именно как lui. Все команды с этой инструкцией имеют вид or.h rX, r0, imm16, что как раз и является загрузкой imm16 в верхную часть регистра, ибо r0 - вседа 0.
Всё же не вижу отличий от MIPS'a, кроме ремапа опкодов (не проверял).
Разве? А как там подгружаются 32-битные числа в 32-битные регистры, если вся инструкция 32 бита? Насколько я помню, там как раз и используется схема lui/ori, когда первая команда заносит верхние 16 бит, а вторая - нижние.
Почти. Шина 8-битная, но она мультиплексирована и используется и для 8-битных данных и для 16-битного адреса. Поэтому и было как минимум 3 такта на команду - в первый такт 8008 отправлял первую половину адреса (8-бит), во второй еще 6 бит адреса + 2 контрольных бита, а уже только во время тертьего такта общая шина используется для обмена данными.
Но они выбрали мультиплексированные пины именно из-за ограничений корпусировки. В 8080/8086 тоже есть отголоски этого, но уже гораздо слабее.
Почему? Я не очень шарю, но когда разрабатываю платы, то сначала расставляю взаимодействющие инетрфейсные компоненты поближе друг к другу (скажем, микроконтроллер и USB-разьём), а потом уже где место осталось втыкаю контроллеры питания и менее важные компоненты. Есть ли что-то плохое в том, чтоб провести линии питания через всю плату на отдельном слое?
Про это я и пишу - обход дейкстрой (flood fill это немного про другое) сделать несложно, а вот весь интерес в разработке алгоритма, учитывающий физику процесса движения. Помню фурор, когда впервые отошли от тупого прохождения лабиринта по кратчайшему пути к более длинному маршруту, но учитывающими ограничения робота.
Очень упрощено. Физика робота сильно влияет на алгоритм - к примеру, инерция и возможность движения по диагонали совсем не учитывается.
Ради чего люди вообще ходят в горы? У всех разные мотивы. Не всем нужны первовосхождения.
Я писал не конкретно по случаю автора, а по ситауации, когда группа разворачивается.
А допуски откуда брать? Измерил ты что-то длинной 28.9 единиц, и дальше думай это 29±0.1 или 28.9±0.1 или еще какой-то вариант. Без оригинальных чертежей весьма сложно спроектировать деталь для более-менее массового использования.
В зависимости от причины смерти. Если кто-то погиб на маршруте, то вытаскивают, а если был срыв и улетел в какой-нибудь "трупосборник" в трещину, то тело так и останется там. Эвакуация и очень трудоёмкая и весьма опасная.
ратрак до вершины не доезжает не из-за погоды, а из-за характера рельефа)
занятное видео про поездку на вершину на специально модифицированном мотоцикле - https://www.youtube.com/watch?v=Qfci-w0fQhI
КО: лучше 100 раз развернуться чем один раз не развернуться когда нужно было)
В теории можно было сходить на вершину и догнать группу, если уверен в своих силах. Связки нужны только на небольшом участке 3900-4600.
Несколько моментов:
"Во-первых, на такой высоте ты не восстанавливаешься: организм использует накопленный прежде кислород, а его запас не восполняется" - это не так. Выше 7000 да, восстановление проблематично для большинства людей, но даже на 6500 вполне хороший отдых, а на 3800 вообще лафа.
В штурмовом лагере с Севера есть несколько опций проживания не в палатках, а в "домиках".
Лучше делать акклиматизационный выход до вертолёта (~4800) или чутка повыше до верхних скал Ленца.
Есть еще интересный проект https://github.com/yeokm1/graphics-gremlin-hdmi, но там используется отдельный DVI трансмиттер, поэтому менее круто) Но можно подсмотреть как реализуется CGA/MDA.
Прочёл целиком - пасхалки не заметил)
То, что кто-то назвал инструкцию как
or.hне означает то, что это именноor.hа неlui. Грепнул листинг, во всех случаях этотor.hиспользуется именно какlui. Все команды с этой инструкцией имеют видor.h rX, r0, imm16, что как раз и является загрузкой imm16 в верхную часть регистра, ибо r0 - вседа 0.Всё же не вижу отличий от MIPS'a, кроме ремапа опкодов (не проверял).
Занятно, недавно наткнулся на похожее видео - https://www.youtube.com/watch?v=KzT9I1d-LlQ
Разве? А как там подгружаются 32-битные числа в 32-битные регистры, если вся инструкция 32 бита? Насколько я помню, там как раз и используется схема lui/ori, когда первая команда заносит верхние 16 бит, а вторая - нижние.
Обычный же первый MIPS, не?
Почти. Шина 8-битная, но она мультиплексирована и используется и для 8-битных данных и для 16-битного адреса. Поэтому и было как минимум 3 такта на команду - в первый такт 8008 отправлял первую половину адреса (8-бит), во второй еще 6 бит адреса + 2 контрольных бита, а уже только во время тертьего такта общая шина используется для обмена данными.
Но они выбрали мультиплексированные пины именно из-за ограничений корпусировки. В 8080/8086 тоже есть отголоски этого, но уже гораздо слабее.
У меня не 3M, а Aries 28-6554-11, немного универсальнее.
Занятно, недавно тоже рисовал подобную панельку в Ondsel (FreeCAD с плюшками). Правда потом в KiCad её подгружал.
Почему? Я не очень шарю, но когда разрабатываю платы, то сначала расставляю взаимодействющие инетрфейсные компоненты поближе друг к другу (скажем, микроконтроллер и USB-разьём), а потом уже где место осталось втыкаю контроллеры питания и менее важные компоненты. Есть ли что-то плохое в том, чтоб провести линии питания через всю плату на отдельном слое?
И в обзоре ни одной мышки с КДПВ? :)
Пользуюсь MX Master 3S и вполне доволен.
Нет, не даст. 1024 это всего 16 цифр по 64 бита. Карацуба в зависимости от архитектуры начинает стрелять с 50+ цифр.