Вот вам для примера статья о том как разрабатывают и испытывают колеса для марсохода.
Я разве утверждал что не испытывали? Только испытания никогда не предвидят все варианты реального использования. Вон камень не предугадали что может кататься. А может и видели такие варианты — но не было времени менять конструкцию колеса или посчитали что ну катается и катается — фиг с ним.
Доказывать что-то в комментариях на хабре по этому поводу не очень продуктивно — по моим сведениям инженеры НАСА не очень часто тут их читают.
Боже упаси что бы я что то там советовал НАСА. Где НАСА, а где ноунейм из интернетиков.
Единственная причина почему я здесь веду диалог (помимо простого убийства времени в развлекательных целях), это то что лично я бы, если конструировал колёса, сделал бы подругому, с защитой от подобных камней. И я защищаю эту идею.
Я привёл причину почему камни опасны. Привёл вариант как конструктивно легко избежать этой опасности. И готов был выслушать возражения в предметной области.
Вместо этого на меня начали давить исключительно авторитетом. И больше ничего. Если НАСА так сделало — значит это истина в последней инстанции. Может и истина — но только подтверждение этой истины тут не привёл никто.
Ну сделай не внутри а снаружи ребро жёсткости. Мало 1? Сделай 2 — 3.
А при движении назад этот винт будет наоборот нагребать песок внутрь колеса.
Я могу привести куча вариантов избежать этого. И вообще это просто был пример придуманный за секунду.
Факт же остаётся только одни — текущая конструкция неудачна, т.к. благодаря неё внутри колеса катаются абразивные камни, которые стачивают само это колесо.
Тут мне всё пытаются доказать мол это фигня, марсоход мол много не ездит — колесо не успеет развалится.
Вот только предыдущий марсоход ездил пока колёса реально не начали разваливаться на лохмотья и отказывать один за другим. И продлить жизнь на пару другую солов, простым конструктивным решением не позволяющим камням внутри кататься — это следующий шаг доработки этих колёс.
А вы все тут доказываете — что мол ни чего делать не надо. И так сойдёт.
Ok. Камни в колёсах которые стачивают тонкий титан или что там за метал — ЭТО ХОРОШО. А если при очередном кульбите он упадёт и заклинит место соединения колеса и оси — это вообще великолепно.
А как изменить колесо я описал в первом своём посте — которым вообще я НИКОМУ ничего доказывать не хотел, а просто написал ничему не обязывающую заметку, которая должна была сгинуть в миллионе однотипных постов.
И т.к. вы это упорно не замечаете, вывод однозначный — главная цель доказать что белое это чёрное.
Поражаюсь. Пытаются доказать что белое это черное, а чёрное это белое. Имеем факт — в колёсах застревают камни. Причём этот факт дорос до обсуждения в сети (уверен что там есть ещё куча всяких проблем которые даже не дошли до обсуждения).
Я заметил что застревание грязи в колёсах можно было бы предвидеть сразу — достаточно поездить этими колёсами в земной грязи при испытаниях. И что эту проблему можно было бы решить изменив минимальную конструкция колеса.
Мне собственно наплевать на эти колёса.
Но тут же на меня ополчились мол как я червь посмел усомнится в гениальности решений НАСА. И раз там застревают камни — значит так и должно быть. Так изначально и запроектировали — что бы все камни там застряли нафиг.
А что касается 100км. Так тут тоже не сферический конь в вакууме. Вон Маск хочет поселение на Марсе сделать в ближайшем будущем. И ездить там на марсаходах будут как раз сопоставимые цифры. И для решения проблем там можно посмотреть на то какие проблемы возникают сейчас уже на существующих марсаходах. И я очень сомневаюсь что Маск даст добро на камне-колёса.
Т.е. то что там камни болтаются и работают как наждак стачивая колесо это так и задумывалось? Даже на фотографиях уже видны процарапанные борозды. А эксплуатируется годами, т.к. ездит метры. Проедь с таким камнем километров 100 за день — так колёса на 2 части развалятся.
Странное конструктивное решение для колёс. Да ещё и с бортиком. Неужели сразу не понятно что это идеальное место для мусора? А всего то надо было убрать бортик и сделать внутреннюю поверхность под углом наружу.
Ну или рёбра жёсткости добавить на внутреннюю поверхность в виде скошенных наружу линий. Получится бы своеобразный винт при движении которого всё бы вышвыривалось. Вон в протекторе на шинах так и делают для вышвыривания воды из под шины. Там даже есть параметр сколько литров за единицу времени. И величине этой позавидовали бы самые крупные насосы.
Как то раз в жизни тоже приходилось заниматься таким шитьём. В бедные 90 годы, имея на руках единственный компьютер (вроде PII) на котором был спален 1 COM порт. А мне для экспериментов нужны был 2 штуки. Под подозрение попала мохнатая микросхема всей периферии, ног наверно на 150.
Найдя донора но в другом форм факторе, с «трясущимися руками» и надеждой не убить окончательно единственную рабочую машину, я всё же решился на пересадку.
В результате на мат плате нарисовался похожий ёжик, как в статье. И какая же была радость когда работал и LPT — через который я программировал, и заработали оба COM порта. Ностальжи…
Во времена спектрумов у меня был аналог. При включении в ПЗУ находился интерпретатор бейсик. И всё.
И что бы поиграть, мне приходилось писать простенькие игры. Карточные, змейки, стрелялки и прочее… Запускать, играть. После выключения всё удалялось. В следующий раз всё по новой ))))
Глянул статью и увидел классную картинку из классной книги, которую мне посчастливилось в детстве получить. Ностальгия… Ещё там был крутой компьютер нарисован в виде ноутбука. Раскроешь книгу — и представляешь как будто за реальным компом сидишь.
Неправда. Во первых никогда не бывает абсолютных утверждений. И это абсолютно. Шутка.
Во вторых. Например я никогда не оставляю код с предупреждениями. И в 99% случаях они правильные. Но всегда есть нестандартные случаи. Например навскидку:
Компилятор C# всегда ругается на не инициализированные переменные. Но проблема в том что он не смотрит вглубь кода больше чем на 1 уровень. И если инициализация будет после двух if — он этого не увидит.
Опять же у меня в практике был случай когда статические классы инициализировать через рефлексию — тоже была ругань. Ну и так по мелочи.
Опять же если речь про C# — то это живой язык и там чуть лине через день прилетают обновы. И порой прилетает такое — что вполне рабочий код становится жёлтым на половину. А всё потому что решили ввести новое предупреждение — не помню что, что то с null связано было. Пришлось отключать это через настройки глобально.
Вся проблема в том что естественный язык он общий. А в программировании приходится описывать все случаи.
Например есть человеческая фраза: «Не лезь в розетку — убъёт!»
В программировании будет выглядеть так:
Не лезь в розетку — убъёт!
ЕСЛИ ты электрик — то можешь лезть
ЕСЛИ в розетки есть напряжение 220 и ты электрик — не лезь
ЕСЛИ ты электрик но в перчатках — то лезь
ЕСЛИ напряжении 10kV и ты в перчатках — не лезь
ЕСЛИ напряжении 10kV и ты используешь клетку Фарадея и специальный уравнивающий щуп…
И т.д. миллион вариантов
Что бы не писать миллион букв (привет бейсику )) просто всё заменяется на X,Y,Z и прочие переменные, а условия на операторы if,for и другие.
И вуаля! Получаем язык С. На котором удобно писать программы и понимать их. И не нужны никакие прослойки.
Тоже хотел написать про это. Процы в видеокартах нередко работают при температуре выше 100С и выделяя мощность на квадратный сантиметр раз в 10 больше чем сопло ракеты.
А с радиацией я вообще не понял взаимосвязь. Она разрушает процы путём открытия двух противополярных комплементарных транзисторов которые образуют КЗ. И собственно проц разрушает не сама радиация, а короткое замыкание и в следствии разрушительное выделения тепла. И современные радио-стойкие процы, они радио-стойкие не потому что какие то другие материалы используются, а потому как схема там строится так что бы отлавливать такие КЗ и отключать эти участки, что бы сами себя не поджарили.
Может взаимосвязь в том что новый метериал выдерживает больше температуры (300C)? Но кз нагревает локально участки до тысячи градусов.
Да я про это и пишу же. Вся проблема в размере массива, а именно таблицы. А они и на миллиард бывают строк. В этом случае надо на те же пару миллиардов служебных колонок зависти.
Плюс делать не одну простую проверку за цикл, а как минимум 3 — на предмет удаления строки, на предмет новой строки, на предмет изменения данных. И это только что всплыло в обсуждении. Что там ещё при разработке всплывёт?
Это я не упоминаю про индексы. Это те же самые массивы. Для них тоже придётся всякие служебные колонки вводить. И вообще непонятно что будет с раздвоенным индексом, в варианте вставки/удалении строк.
Я не говорю что идея плохая. Просто в представленном виде она имеет критичный оверхед. Но зерно в ней есть, надо подумать над ней, может получится усовершенствовать.
Поразмыслив над вашей идеей всплыло куча подводных камней.
Например как учитывать новые добавленные строки? В старой таблице не будет этих строк и собственно не будет 4-го поля для анализа.
Как учитывать удалённые строки? Это придётся ещё тогда служебный столбец добавлять типа deleted. И его тоже анализировать при каждом цикле?
Одновременно транзакция write может работать только 1. Потому как на каждый write придётся дублировать все эти поля.
Понял вашу идею.
И что получаем. На каждый цикл проверки делать дополнительную проверку 4 поля. И того если имеем миллион строк. Проверок делаем 2 миллиона при переборе (в случае когда условие например придётся на последнюю строку). А если учесть что это будут if с переходом — то скорее всего поломается оптимизация в проце для чистого перебора массива.
Далее мы должны в каждой таблице загруженной в RAM делать дополнительную колонку — например int. И того на 1M строк имеем лишние 4Mб данных.
Меня больше всего волнует потеря производительности для двойной проверки каждой строки.
Я разве утверждал что не испытывали? Только испытания никогда не предвидят все варианты реального использования. Вон камень не предугадали что может кататься. А может и видели такие варианты — но не было времени менять конструкцию колеса или посчитали что ну катается и катается — фиг с ним.
Боже упаси что бы я что то там советовал НАСА. Где НАСА, а где ноунейм из интернетиков.
Единственная причина почему я здесь веду диалог (помимо простого убийства времени в развлекательных целях), это то что лично я бы, если конструировал колёса, сделал бы подругому, с защитой от подобных камней. И я защищаю эту идею.
Я привёл причину почему камни опасны. Привёл вариант как конструктивно легко избежать этой опасности. И готов был выслушать возражения в предметной области.
Вместо этого на меня начали давить исключительно авторитетом. И больше ничего. Если НАСА так сделало — значит это истина в последней инстанции. Может и истина — но только подтверждение этой истины тут не привёл никто.
Ну сделай не внутри а снаружи ребро жёсткости. Мало 1? Сделай 2 — 3.
Я могу привести куча вариантов избежать этого. И вообще это просто был пример придуманный за секунду.
Факт же остаётся только одни — текущая конструкция неудачна, т.к. благодаря неё внутри колеса катаются абразивные камни, которые стачивают само это колесо.
Тут мне всё пытаются доказать мол это фигня, марсоход мол много не ездит — колесо не успеет развалится.
Вот только предыдущий марсоход ездил пока колёса реально не начали разваливаться на лохмотья и отказывать один за другим. И продлить жизнь на пару другую солов, простым конструктивным решением не позволяющим камням внутри кататься — это следующий шаг доработки этих колёс.
А вы все тут доказываете — что мол ни чего делать не надо. И так сойдёт.
А как изменить колесо я описал в первом своём посте — которым вообще я НИКОМУ ничего доказывать не хотел, а просто написал ничему не обязывающую заметку, которая должна была сгинуть в миллионе однотипных постов.
И т.к. вы это упорно не замечаете, вывод однозначный — главная цель доказать что белое это чёрное.
Знаю там вроде есть лазер для испарения породы. Согласен на то что бы на какой-нибудь скале выжгли «Здесь был
Васяdevelope7»Я заметил что застревание грязи в колёсах можно было бы предвидеть сразу — достаточно поездить этими колёсами в земной грязи при испытаниях. И что эту проблему можно было бы решить изменив минимальную конструкция колеса.
Мне собственно наплевать на эти колёса.
Но тут же на меня ополчились мол как я червь посмел усомнится в гениальности решений НАСА. И раз там застревают камни — значит так и должно быть. Так изначально и запроектировали — что бы все камни там застряли нафиг.
А что касается 100км. Так тут тоже не сферический конь в вакууме. Вон Маск хочет поселение на Марсе сделать в ближайшем будущем. И ездить там на марсаходах будут как раз сопоставимые цифры. И для решения проблем там можно посмотреть на то какие проблемы возникают сейчас уже на существующих марсаходах. И я очень сомневаюсь что Маск даст добро на камне-колёса.
Ну или рёбра жёсткости добавить на внутреннюю поверхность в виде скошенных наружу линий. Получится бы своеобразный винт при движении которого всё бы вышвыривалось. Вон в протекторе на шинах так и делают для вышвыривания воды из под шины. Там даже есть параметр сколько литров за единицу времени. И величине этой позавидовали бы самые крупные насосы.
Найдя донора но в другом форм факторе, с «трясущимися руками» и надеждой не убить окончательно единственную рабочую машину, я всё же решился на пересадку.
В результате на мат плате нарисовался похожий ёжик, как в статье. И какая же была радость когда работал и LPT — через который я программировал, и заработали оба COM порта. Ностальжи…
И что бы поиграть, мне приходилось писать простенькие игры. Карточные, змейки, стрелялки и прочее… Запускать, играть. После выключения всё удалялось. В следующий раз всё по новой ))))
Во вторых. Например я никогда не оставляю код с предупреждениями. И в 99% случаях они правильные. Но всегда есть нестандартные случаи. Например навскидку:
Компилятор C# всегда ругается на не инициализированные переменные. Но проблема в том что он не смотрит вглубь кода больше чем на 1 уровень. И если инициализация будет после двух if — он этого не увидит.
Опять же у меня в практике был случай когда статические классы инициализировать через рефлексию — тоже была ругань. Ну и так по мелочи.
Опять же если речь про C# — то это живой язык и там чуть лине через день прилетают обновы. И порой прилетает такое — что вполне рабочий код становится жёлтым на половину. А всё потому что решили ввести новое предупреждение — не помню что, что то с null связано было. Пришлось отключать это через настройки глобально.
Например есть человеческая фраза: «Не лезь в розетку — убъёт!»
В программировании будет выглядеть так:
Не лезь в розетку — убъёт!
ЕСЛИ ты электрик — то можешь лезть
ЕСЛИ в розетки есть напряжение 220 и ты электрик — не лезь
ЕСЛИ ты электрик но в перчатках — то лезь
ЕСЛИ напряжении 10kV и ты в перчатках — не лезь
ЕСЛИ напряжении 10kV и ты используешь клетку Фарадея и специальный уравнивающий щуп…
И т.д. миллион вариантов
Что бы не писать миллион букв (привет бейсику )) просто всё заменяется на X,Y,Z и прочие переменные, а условия на операторы if,for и другие.
И вуаля! Получаем язык С. На котором удобно писать программы и понимать их. И не нужны никакие прослойки.
А с радиацией я вообще не понял взаимосвязь. Она разрушает процы путём открытия двух противополярных комплементарных транзисторов которые образуют КЗ. И собственно проц разрушает не сама радиация, а короткое замыкание и в следствии разрушительное выделения тепла. И современные радио-стойкие процы, они радио-стойкие не потому что какие то другие материалы используются, а потому как схема там строится так что бы отлавливать такие КЗ и отключать эти участки, что бы сами себя не поджарили.
Может взаимосвязь в том что новый метериал выдерживает больше температуры (300C)? Но кз нагревает локально участки до тысячи градусов.
Плюс делать не одну простую проверку за цикл, а как минимум 3 — на предмет удаления строки, на предмет новой строки, на предмет изменения данных. И это только что всплыло в обсуждении. Что там ещё при разработке всплывёт?
Это я не упоминаю про индексы. Это те же самые массивы. Для них тоже придётся всякие служебные колонки вводить. И вообще непонятно что будет с раздвоенным индексом, в варианте вставки/удалении строк.
Я не говорю что идея плохая. Просто в представленном виде она имеет критичный оверхед. Но зерно в ней есть, надо подумать над ней, может получится усовершенствовать.
Например как учитывать новые добавленные строки? В старой таблице не будет этих строк и собственно не будет 4-го поля для анализа.
Как учитывать удалённые строки? Это придётся ещё тогда служебный столбец добавлять типа deleted. И его тоже анализировать при каждом цикле?
Одновременно транзакция write может работать только 1. Потому как на каждый write придётся дублировать все эти поля.
И что получаем. На каждый цикл проверки делать дополнительную проверку 4 поля. И того если имеем миллион строк. Проверок делаем 2 миллиона при переборе (в случае когда условие например придётся на последнюю строку). А если учесть что это будут if с переходом — то скорее всего поломается оптимизация в проце для чистого перебора массива.
Далее мы должны в каждой таблице загруженной в RAM делать дополнительную колонку — например int. И того на 1M строк имеем лишние 4Mб данных.
Меня больше всего волнует потеря производительности для двойной проверки каждой строки.