2. В комментариях к этим "продолжениям" активно обсуждался вопрос о пользе posit-вычислений для физиков/математиков. Так вот, как физик, добавлю к этим обсуждениям свои пять копеек:
В формате posit нет “NaN” (нечисел), вместо этого, вычисления прерываются (...) Если программист видит необходимость в использовании значений NaN, это показывает, что программа пока не завершена (...)
Как физик, скажу, что при работе с ЭКСПЕРИМЕНТАЛЬНЫМИ временными рядами (= любой долговременный мониторинг) такая концепция категорически неприемлема. У нас NaN - это вовсе не ошибка вычислений, а совершенно легальное значение входных данных. Да, часто такие значения как-то интерполируют (заполняют) перед проведением вычислений... но с методологической точки зрения это крайне сомнительный подход. Понятно, что иногда (например, при вычислении БПФ) без интерполяции пропусков обойтись невозможно. Но огромное множество алгоритмов вполне допускает возможность работы с рядами, содержащими NaN. Поэтому при работе с данными незачем их заполнять без крайней нужды! Везде, где этом возможно, надо работать только с реальными наблюдениями. Избегая искусственного придумывания всяких вымышленных значений в тех случаях, когда наблюдение почему-то не проводилось...
Например, если моменты возникновения NaN случайны, то та же АКФ вычисляется на ура без всякой интерполяции. После чего можно и спектр оценить. Правда, оба этих вычисления будут тогда стоить O(n*n), а не O(n*log(n))... но в спектральном анализе любой "сыр" всегда платный :-(
3. И про хранение данных. У нас очень часто при наблюдениях встречаются значения с относительно низкой точностью, полученные с 16-битного АЦП. Или с 24-битного, но где не все разряды задействованы (ну или в младших битах нет ничего, кроме шума). По физическому смыслу это real-значения... но отводить на их хранение 32 бита нет смысла. Впервые эта задачка у меня возникла еще в 1986 году. Я тогда сидел высоко горах и делал систему хранения и анализа экспериментальных временных рядов сначала на СМ-4 (она же PDP-11), а затем на первых IBM PC. И на обоих машинах у нас не было других real, кроме real*4. В общем, я тогда сделал линейное отображение нужного диапазона real на 16-битные целые, которые и хранились в БД. Диапазоны данных у нас были фиксированы, и точности вполне хватало.
А недавно у меня возникла задача упаковать еще менее точные real в минимум бит. Причем, несмотря на очень большую погрешность этих real, там периодически попадались экстремальные выбросы (например, при землетрясениях), которые тоже надо было хранить, а не выбраковывать. В общем, я стал смотреть варианты и наткнулся на 8-битный posit. Который практически сразу же был отвергнут по той простой причине, что для нас критически важны NaN - значения, а их там попросту нет. Ну и еще у нас обычно пакуются сразу тройки таких чисел (три компоненты), которые потом удобно запихнуть в 32-битное целое, поэтому вместо 8 бит можно использовать 10. В итоге я сделал
свой формат компактного хранения real
Если кому-то интересен исходный код, его можно найти вот тут, файл CHARLIB.FOR, функцииPACK_R_TO_INT(R)и UNPACK_R_FROM_INT(I) (функции пакуют real-число в диапазоне от 1 до 140000 в целую переменную в диапазоне 1..1024 и обратно).
Кстати, та самая (из 1986г!) упаковка real в 16-бит у нас тоже до сих пор крутится в продакте. См. там же файл ABD_DB.FOR.
В каком-то смысле это тоже аналог posit-формата. Только в нашем случае нет выделенного "магического числа" 1, около которого точность максимальна (и плавно уменьшается при удалении от него в обе стороны). Вместо этого у нас есть "рабочий диапазон" (где шкала представимых чисел линейная) и "зона выбросов", где шаг между представимыми числами растет даже быстрее, чем в posit.
А мораль этой истории такова. Если уж даже для нашей задачки (которая, казалось бы, прямо напрашивается на решение в рамках posit-подхода) этот формат оказался непригодным, то тут есть большой повод задуматься: а так ли он универсален, как описано в этой статье? В общем, у меня есть такое подозрение, что posit-вычисления весьма хороши только для довольно узкого круга задач. А вот насчет их универсальности возникают большие сомнения. Имхо, по этому показателю плавающая точка IEEE соревнование с posit-форматом явно выигрывает.
Буд рад, если навел на какие-то полезные мысли ;-)
измерять в секундах это очень долго (...) внедрить поддержку вплоть до микросекунд.
Мы свою систему начинали пилить в те далекие времена, когда деревья были большими integer был двухбайтным ;-) Поэтому для универсальности шкалы времени дату оформили в виде структуры из "общечеловеческих ценностей": года, месяца, дня и т.д. Идея была в том, что все даты, кроме ключей, не хранятся наравне с данными, а вычисляются по мере необходимости. То есть, каждое значение данных сопоставляется с датой динамически, а в базе (в памяти) хранятся только характеристики сигнала в целом (ну или его фрагмента). Соответственно, при длине сигнала от 100 точек и более размер структуры даты не важен вообще.
Для манипуляций с такими датами пришлось запилить собственную библиотеку со всякими оптимизациями скорости типичных (для нас!) операций: инкремент даты с разным шагом, пересчет номера точки в дату и обратно, сложение-вычитание дат (интервалов) и т.д. Которая так с тех пор и работает (если интересно, она лежит вот тут среди прочих кодов - файлы clib.inc и clib.for).
Сейчас мы бы уже ядро библиотеки попроще сделали, на основе 16-байтовых (а не 16-битных) вычислений ;-). С конверсией даты в человеческий формат и обратно на уровне интерфейса, как это принято "у взрослых". Но тут уж, что называется, не буди лихо, пока легаси работает - ;-)
Вдогонку. Спасибо всем, кто меня заминусовал, за Ваше мнение... но, все-таки, я был бы благодарен за уточнение причины минусов.
Топикастер задал провокационный вопрос:
...какой язык выбрать в качестве стартового?
Уточнив при этом, что речь идет о "начинающих программистах", но не наложив формальных ограничений. А мне вот всегда казалось, что хороший стиль программирования - это когда ты готов обрабатывать не только типичные, но и крайние случаи. Ну вот я и написал про свой личный "крайний случай", для которого
оба предложенных топикастером языка не очень подходят:
Мой "начинающий программист" - слева
Она же вылезает из иглу особой конструкции - ее можно построить даже в Подмосковье при полном отсутствии наста для кирпичей
P.S. Конечно, я понимаю, что тут идет
серьезный разговор серьезных людей,
а не всяческих чайников со всего-то полумиллионом строк кода в продакте, которым априори нечего лезть со своими шуточками в деловую беседу даже в праздничный выходной
Я же имею дело с по-настоящему начинающим программистом, а не с переростком из дошкольной группы детского сада ;-)
В моем случае, когда обучаемый еще не умеет читать и писать, и вынужден всю программу держать в голове, освоить всякие скобки-кавычки-отступы-списки ему будет непросто. Поэтому я и предлагаю отложить эти темы на чуть попозже. Так что для самого первого знакомства с программированием мой самодельный язык все-таки лучше ;-)
Боюсь, что меня сейчас заклюют сторонники двух обсуждаемых языков, но лично я в качестве стартового все-таки выбрал бы что-то другое. Но поскольку в контексте статьи это уже почти оффтопик, продолжение спрячу под спойлер.
Простой язык для обучения программированию
Я исходил из того, что САМЫЙ первый язык все-таки должен быть минималистичным. Вообще без библиотек, модулей, крейтов и прочего, так как для некоторых обучаемых (при самомпервом знакомстве с темой) эти концепции могут быть сложноваты. Как и понятие компилятора. Имхо, на начальном этапе освоения базовых элементов важна не столько мощь языка, его скорость или обилие возможностей, сколько прозрачная связь между кодом и результатом. Чтобы обучаемый сразу видел, как та или иная процедура работает "под капотом".
В общем, я остановился на интерпретаторе с минималистичной системой команд, предельно приближенных к "железу". Сейчас в моем языке всего 8 команд, что позволяет реализовать их на 3-битной архитектуре.
Сами команды такие
наШею, Вправо, Влево, Вперед, Стоп, Опустить.
Ну и синтаксический сахар (куда ж без него): это команды "Кругом" и "кМаме". Причем, последнюю обрабатывает макропроцессор, раскладывая ее на "элементарные" процедуры из первого списка. А фича в том, что перед исполнением каждая из этих команд озвучивается специальным динамиком. Имхо, такая озвучка здорово помогает освоению языка.
Несмотря на минимальный функционал, язык позволяет прокладывать довольно сложные маршруты по трехкомнатному лабиринту с мебелью. Правда, я не настолько силен в электронике, чтобы изготовить настоящий трехбитный процессор с необходимой периферией, поэтому сейчас наши первые программы работают на эмуляторе, в качестве которого выступаю я сам.
А вот насчет Rust или C/C++ в качестве первого языка у меня есть большие сомнения в связи с тем, что обучаемому на данный момент два года и пара месяцев. Посмотрим, за какое время дочке удастся освоить описанный выше микроязык хотя бы на уровне Middle. (Senior в моем представлении - это когда она начнет сама обучать этому языку свою куклу). А пока что (на первой неделе обучения) нам
труднее всего нам дается команда Стоп
Боюсь, что это мой архитектурный баг... Ведь в отличие от других команд, выполняющих разовую операцию и сразу возвращающих управление, команда Вперед запускает бесконечный цикл движения, выходить из которого надо отдельной командой (ну или с помощью препятствия на пути). Поэтому остановиться на середине коридора напротив двери, в которую хочется повернуть, у нас пока что не получается. Впрочем, вопросы синхронизации - это одна из самых сложных тем в любом языке...
UPD: Вдогонку: не успел написать, как мне тут уже Lisp посоветовали ;-)
Совет интересный, но проблема в том, что обучаемый пока не умеет ни читать, ни писать. Да и разговаривает с трудом. Поэтому всю программу нам пока приходится держать в голове... С учетом этого, наличие в языке всяких служебных символов типа кавычек выглядит большим минусом...
Ну сход и сдох. Купи нормальный Samsung, например oem PM9a1, у самсунгов с надёжностью получше.
Спасибо за попытку помочь... но мне уже давали такие советы в разных местах и не один раз. Но, у меня ведь изначально тоже был SSD с довольно неплохой репутацией. Проблема, по-видимому, не в производителе, а в том, что в моем режиме эксплуатации (постоянная перезапись всего SSD целиком на максимально возможной скорости), никакой "бытовой" SSD долго не выдержит. Нужны на порядок более дорогие устройства, которые рассчитаны именно на такое использование. И, желательно, с дополнительным охлаждением именно SSD (которое в обычном десктопе обеспечивается далеко не всегда).
Вообще у меня возникает подозрение теория заговора, что общепринятое впечатление о высокой скорости и надежности SSD - это в первую очередь следствие грамотного маркетинга. Когда никто не акцентирует внимание, что эти надежность и скорость достигаются лишь при определенных сценариях использования. Да, эти сценарии довольно типичны (системный диск, например), однако жизнь ими далеко не исчерпывается. Мой случай, как я написал выше, это потоковая обработка больших файлов. Скользящее окно бежит по группе сигналов, они читаются, обрабатываются и перезаписываются, формируя другую группу сигналов. И так круглосуточно. Мое подозрение состоит в том, что вот именно для такого сценария применения стандартные SSD-шки непригодны чуть больше, чем полностью. Можно хоть каждый месяц покупать и убивать хорошие, вроде бы SSD, и наивно удивляться потом: ну что же могло пойти не так в n-й раз подряд?
Так что мой случай - это вовсе не "исключительное невезение", когда прекрасная железяка внезапно отказывает на ровном месте. Нет, имхо это наиболее ожидаемое поведение такой железяки в не совсем типичных для нее условиях.
Короче, после того случая я купил себе дополнительный винт, работаю с данными теперь только на нем, и горя не знаю. А второй SSD, который мне подарили после "совершенно невероятной внезапной смерти первого на ровном месте", использую для системы. Где он прекрасно функционирует без каких-либо нареканий.
В общем, мой опыт говорит, что при покупке SSD надо не просто читать хвалебные отзывы, но и не забывать о такой штуке, как "сценарий использования". Чтобы не ошибиться с выбором, поддавшись на
маркетинговые уловки
Хотя, логику маркетологов тоже можно понять.
Зачем пугать 99% возможных клиентов, рассказывая про довольно редкий сценарий катастрофически быстрого отказа SSD при слишком интенсивной эксплуатации? Ведь эти 99% никогда с такими сценариями не столкнутся... а вот "червь сомнения" у них зародится, и на продажи это вполне повлияет....
Ну, а тот 1%, которой все-таки в такую ситуацию "вляпается", и начнет (не понимая причин) голосить о ненадежности SSD, он будет сам виноват. Маркетингу он точно не помешает, так как в любом форуме всегда найдутся 99% клиентов, которые объективно своей SSD-шкой довольны и не имеют ни малейших причин на что-либо жаловаться. У них-то все хорошо. Точно такая же нога - и не болит. Поэтому маргиналы, которые кричат про сдохшие SSD, быстро окажутся в бане. Причем такой бан будет, с точки зрения общественности, вполне справедлив: они ведь действительно несут всякий бред, который явно противоречит эмпирически бесспорному опыту. Короче, маркетинг не пострадает ;-)
Мораль
С одной стороны, выбраковка аномальных данных при анализе наблюдений - это стандартный прием. Но, с другой, если те люди, которые годами успешно складывали кучи разных металлов большого размера, проигнорируют редкие сообщения, что с плутонием может не получиться, то они потеряют довольно интересную информацию (и хорошо, если только ее ;-).
Так вот, поскольку у нас тут все-таки Хабр, то я очень надеюсь, что присутствующие тут специалисты помогут объективно разобрать мои опасения, что вероятность отказа SSD может катастрофически увеличиваться при определенных (да, не очень типичных, но все же возможных) сценариях использования. И что это случится еще до того, как меня тут завалят советами "выбрось брак, купи новый" или вообще забанят за ересь про SSD ;-)
VRackDB - это простая In Memory Graphite like база данных, предназначенная для хранения временных рядов (графиков). (TypeScript)
Просто интересно, а сколько человеко-дней занимает такая разработка сейчас (в наше время)?
Мы лет 30-40 назад написали примерно то же самое на фортране, только с акцентом на анализ/визуализацию ретроспективно накопленных данных. Система до сих пор используется, и после нескольких рефакторингов насчитывает несколько сотен тысяч строк кода. Она тоже достаточно быстрая (пока ряды содержат меньше миллиона измерений, все делается "на лету"), с минимальными требованиями к "железу", но есть и некоторые отличия:
рабочее пространство (а тем более данные) у нас хранятся на диске, так что при внезапном отключении света не теряется вообще ничего, кроме результатов текущей операции;
ОП у нас не используется вообще ;-) Ну то есть на самом деле там хранятся текущие графики (смешное количество точек), а при обработке рядов - скользящее окно, которое бежит по ряду (тут уже требования намного серьезнее). Но вот практически вся остальная доступная память напрямую программой не задействуется, а используется для кэширования дисковых файлов с данными, причем этим занимается ОС. Даже под DOS-ом это позволяло нам спокойно работать с миллионами точек. А сейчас у нас не редкость ряды из миллиардов значений. При этом они спокойно крутятся но компе с 8Гб памяти, где параллельно висит еще тьма всякой рутины от браузера до VS;
Но наиболее интересное в контексте вашей системы отличие в том, что данные для графика у нас возвращаются в двух вариантах: это либо обычный набор точек в соответствии с запрошенной детальностью (обычно она соответствует разрешению экрана) либо
набор "диапазонов" (т.е. пар {min,max}) той же размерности
Поясню, зачем нужен диапазон. Пусть, например, у нас есть ряд с опросом в 1 сек, а длина ряда 5 лет. Тогда каждый пиксел экрана (пойнт графика) должен показать пользователю фрагмент сигнала, состоящий из примерно 100 000 первичных (секундных) отсчетов данных. Понятно, что за 100 тыс. отсчетов ряд мог довольно сильно гулять вверх-вниз. В такой ситуации показывать юзеру одно лишь только среднее значение... ну,такое себе. У нас в графиках поэтому сделаны два режима (чуть подобнее здесь): можно показывать либо среднее, либо размах колебаний (он рисуется вертикальной палочкой). Вот сравнение двух графиков одного и того же ряда с генерализацией среднего либо размаха:
На первый взгляд даже и не скажешь, что это один и тот же сигнал...
генерализация с отображением среднего
генерализация с отображением размаха
В общем, крайне рекомендую добавить в вашу БД такую опцию - возврат диапазона значений для графика с генерализацией размаха. Для наших геофизических данных возможность "на лету" переключаться между двумя режимами визуализации - это просто незаменимая фича. Она на порядок полезнее, чем возможность игры со "слоями", приведенными к разным частотам опроса. Думаю, что и для любых других негладких либо высокочастотных данных эффект будет впечатляющим.
Кстати, сейчас мы готовим статью, где будет подробное обсуждение этих нюансов на примере рядов наклономерных наблюдений в журнал Сейсмические приборы. Включая и сравнение динамической генерализации и "слоев" с очевидными преимуществами первой для широкого круга задач. Так что если Вы описанную фичу у себя соберетесь делать, советую
туда заглянуть
вроде, статья должна осенью выйти. В elibary она за paywall-ом, но на сайте ИФЗ-шных журналов доступ к статьям свободный. Короче, если статья понравится, не забудьте сослаться. Вам не сложно, а нам будет приятно ;-)
А вот "слои" у нас не прижились как-то. Хотя один из юзеров предлагал такой вариант. Но... небольшие ряды данных (до миллиона значений) на современных компьютерах агрегируются "на лету", поэтому на таких масштабах просто нет смысла заморачиваться с предвычисленными слоями. Когда рисовалка запрашивает у БД нужный ей фрагмент данных, то проще сделать все расчеты в динамике и вернуть данные в точности с нужной детальностью, а не подбирать наиболее подходящий слой (который вдобавок может оказаться не совсем подходящим). А для гигабайтных рядов мы обычно делаем всего один промежуточный слой, да и то вручную.
Ну и еще из отличий - шкала времени у нас начинается не с секунд, а с микросекунд, т.к. в геофизике в последнее время внедряются все более высокочастотные регистрирующие системы.
Так вот, я сейчас попытался прикинуть, сколько же времени у нас ушло на разработку всей этой системы. Очень грубо - несколько тысяч человеко-дней. Правда, основное время все-таки было потрачено не на СУБД, а на разные инструменты анализа временных рядов. Но вклад СУБД и визуализации в общие времязатраты тоже вполне заметный. С другой стороны, первоначально мы все писали под DOS, не имея многих сегодняшних инструментов. Ну и еще один нюанс - у нас абсолютно все алгоритмы поддерживают наличие в рядах данных пропущенных наблюдений. При написании своего алгоритма это часто увеличивает времязатраты втрое-вчетверо. А то и вообще на порядок, когда вместо готового библиотечного алгоритма приходится делать свой полный аналог просто потому, что в библиотечном Nan-ы обрабатываются не так, как нам хочется...
В общем, несмотря на все различие между системами, некоторая аналогия между ними проглядывается. Поэтому и интересно: насколько быстрее и проще сейчас можно "собрать" такую систему, как ваша, из почти готовых кубиков, по сравнению с самостоятельным изготовлением продукта "с нуля".
Злободневное и довольно глубокое замечание! Но свои мысли по этому поводу я все же
спрячу под спойлер
Начну с древней истории. Лет 25 назад я активно водил в походы детей - своих и "соседских", и народ там был очень разный. Некоторые жили скромно (неполные семьи), и при планировании походной раскладки включали туда то, чего им недоставало дома. Как-то раз новый завхоз под давлением коллектива решил взять в поход газировку. Я попросил более опытных девочек (которые уже понимали, что даже в водном походе лишний вес - это не здорово, да и вообще, что польза от газировки сомнительная) придумать аргументы, почему так делать не надо. У нас тогда каждый второй ребенок был в чем-нибудь гением, поэтому аргументов придумали много - хороших и разных. Но самым действенным оказался такой (у старших детей уже началась в школе химия, и, видимо, у них был хороший учитель): "Пить газировку вообще не стоит, так как там в каждой бутылке полно окислов водорода!" Это подействовало, газировку в поход
решили не брать ;-)
Кстати, на этот аргумент многие взрослые до сих пор тоже ведутся ;-))
И только много позже я понял, что в момент этого обсуждения младшие участники еще не начали изучать химию... Получается, их мы попросту развели. Может, для здоровья оно и полезно, но все равно получилось как-то не очень честно :-((
А мораль этой истории такова: сейчас нам на полном серьезе очень часто вещают что-то похожее на эти "окислы водорода". Почти любая нашумевшая в СМИ страшилка последних десятилетий такие элементы содержит. Когда правдивые, но непонятные научные данные подаются специальным образом, - так, чтобы у слушателя сложилось совершенно искаженное впечатление о реальности. И надо признать, что для тех, кто не знает матчасть, такие аргументы звучат очень действенно и пугающе. А особенно страшно, когда таких (некомпетентных в деталях) слушателей большинство... К сожалению, это сейчас почти неизбежно в силу все более узкой специализации научного знания. Специалистов по определению крайне мало, они не могут быть большинством практически ни в каком общественном месте, кроме узкопрофильных форумов. Которые, в свою очередь, на массовое сознание вообще никак не влияют в силу своей узкопрофильности и малочисленности участников (с одной стороны, там объективно высокий порог вхождения, с другой - в таких форумах умышленно отсеивают дилетантов, чтобы они не мешали серьезному обсуждению. А заодно еще могут отсеивать и весь "немэйнстрим", стимулируя тем самым распространение всяких теорий заговора. Но это уже отдельная тема).
В результате в нашем "облачно-ориентированном" общественном сознании в первую очередь распространяются именно мифы. Сначала они овладевает массами, а затем становится руководством к действию. И это уже не просто детский прикол, а вполне реальная
угроза нашей цивилизации
Дальше уже будет совсем оффтопик, но тем не менее напишу. Моя гипотеза состоит в том, что в нашем интернет-мире "виртуализированного" социума различные идеи начинают конкурировать между собой по законам, аналогичным законам биологической эволюции. В результате выживают не самые разумные идеи, а наиболее приспособленные к среде. То есть мифы.
Все очень просто. Чтобы понять и передать научную концепцию, надо быть специалистом в этой области. Но таких "узлов" в сети коллективного разума ничтожно мало. Ведь каждый индивид (узел) специализируется на чем-то своем... Во всех остальных отраслях знаний он дилетант. Которому гораздо проще воспринять-передать миф, чем научное знание. Итог - любые продвинутые (=узкоспециализированные) знания вытесняются из "коллективного сознания" мифами.
Раньше (пока знания были приближены к практике) на пути многих мифов вставала практика. Сейчас практика в каждой конкретной области - это тоже удел избранных. Подавляющее большинство землян пользуются технологиями (= интерфейсами), не вникая в детали реализации. Обычному человеку гораздо понятнее объяснение, что компьютер работает на "белом дыме" (и что если этот дым вышел, то все), чем какие-то там двоичные коды, транзисторы, литографы и всякая прочая заумная казуистика, не объясняющая (для него) вообще ничего. А с дымом по крайней мере понятно. Человек не может без воды и еды, а Алиса - без "белого дыма". Спорить с этой железной (и жизненной) логикой могут только дебилы, ведь правда?
А теперь самое важное.
Вышеописанный "пользователь Алисы", верящий в "белый дым" - это вовсе не идиот!!! Наоборот, он может быть высококлассным вирусологом или климатологом и т.д.. Он искренне недоумевает, глядя, как массами овладевает чудовищный бред, относящийся к его профессиональной области. Потом этот миф достигает правительства, и превращается в обязательные для всех законы. Тут поневоле поверишь, что мир сходит с ума.
Так вот, моя гипотеза состоит в том, что ситуации, подобные вышеописанным, это не досадные недоразумения, а логичное следствие ускоренной специализации знаний + революции в коммуникациях (=создание "коллективного разума"). Просто этот коллективный общечеловеческий разум вовсе не будет кратно умнее нас. Наоборот, он будет лишь самую малость умнее "среднего человека". Просто потому, что в любом конкретном вопросе подавляющее большинство его "обучающей выборки" - это не специалисты, а дилетанты.
Если я хоть в какой-то степени прав, то отсюда вытекает целая куча весьма неприятных угроз. С которыми надо немедленно и упорно бороться, т.к. будучи пущенными на самотек, эти процессы ведут нас к очень нехорошим финалам. Например, эта модель дает объяснение, почему современная экономика выливается именно в такую политику. Или почему парадокс Ферми - это вовсе не парадокс, а наиболее вероятный исход :-(
У меня даже как-то возникла мысль - не написать все это системно в виде статьи. Но потом я подумал, что такая статья неизбежно коснется политики, что на Хабре совсем неуместно. А другого ресурса, где возможно адекватное обсуждение такой "философии", я просто не знаю :-(
Если все перейдут на водород, то количество дождей в странах, где много автомобилистов - увеличится. Звучит странно, но посчитайте количество водяного пара, которое будет уходить в атмосферу с каждого автомобиля и умножьте на количество машин.Сам не считал, ибо лень, только примерно прикинул,
Думаю, зря Вы свои прикидки сюда не выложили. Так как по моим прикидкам получается наоборот. А именно, дополнительное увлажнение атмосферы от водородных двигателей будет настолько ничтожно, что всерьез говорить про него не приходится. Вот они:
Первый метод подсчета (Важное замечание: все расчеты ниже - по порядку величины, т.е. коэффициентами порядка 2 мы пренебрегаем. Для наших целей этого хватит:)
1. Общая добыча нефти и газа в мире в год порядка 6Е+12 кг/год. Мы сильно не ошибемся (расчет ведь по порядку величины), если примем, что все добытые углеводороды идут в топку. И точно также в грубом приближении можно принять, что при сгорании нефтегазобензина выделяется примерно такая же масса воды, сколько было (по массе) исходного вещества. Итого, современные автомобили вместе с электростанциями-котельными-пароходными выбрасывают в атмосферу Е+12 .. Е+13 кг воды в год.
2. Общее количество влаги в атмосфере Земли меняется в разные сезоны года, но грубо его можно принять равным Е+16кг. В среднем испаренная вода остается в атмосфере 10 дней. Итого за год через атмосферу проходит 4Е+18кг воды. Итого вклад "углеводородных" вод в общий массообмен составляет порядка Е-6 от общего цикла. То есть, 0.0001%. Учитывая, что естественные колебания количества атмосферной влаги (например, сезонные) достигают первых процентов, на этом фоне заметить эффект человеческого воздействия в глобальном масштабе невозможно в принципе: он на три порядка меньше дисперсии.
3. Я не химик, поэтому в первом приближении могу только прикинуть, что теплота сгорания а) водорода и б) нефте-газо-бензина в расчете на массу выделившейся воды вроде бы одного порядка. Но если это и правда так, то значит, то замена одного топлива на другое кардинально изменит только объем выбросов CO2, но в гораздо меньшей степени - H20.
Кстати
если тут есть химики, было бы интересно узнать более точные цифры: сколько воды выделяет на километр пробега бензиновый, дизельный и водородный мотор? Может кто-нибудь подсказать?
UPD: пока я писал свой ответ, @Antocyan уже подсказал, что в расчете на единицу массы топлива, водородное выделяет гораздо меньше воды, чем традиционные. Но нам-то важна масса воды на единицу выделенной энергии, а не сожженного топлива. И вот с этим все уже не так просто. Было бы здорово, если кто-нибудь уточнит.
Итого, первый способ подсчета говорит, что переход на водородное топлива а) не изменит кардинально количество выбрасываемой в атмосферу воды, и что б) это количество пренебрежимо мало по сравнению с глобальным круговоротом.
Второй метод подсчета
Теперь попробуем посчитать то же самое локально. Допустим, у нас есть мегаполис на 1 млн автомобилей. Пусть в среднем каждый автомобиль проезжает за сутки 100км и выбрасывает в атмосферу 20кг воды (не важно, на каком топливе). Итого получается около Е+10 кг воды в год
Количество осадков сильно меняется в разных географических поясах. В среднем по планете это 1000 мм/год, что соответствует Е+9 кг/км2/год. Считая размер нашего мегаполиса 100х100км, получаем, что там за год выпадает Е+13 кг осадков. Итого, если бы вся выделенная автомобилями влага выпадала в пределах города, то это могло бы оказать небольшой, но потенциально измеримый эффект на климат: около 0.1%. Правда, для его фиксации потребовались бы достаточно длительные наблюдения, так как межгодовая изменчивость количества осадков раз в сто раз больше. То есть, нам потребуются многолетние наблюдения.
Однако, на практике в атмосфере почти всегда дует ветер. Поэтому выделенная транспортом влага рассеивается на гораздо большей площади, что многократно ослабит эффект и сильно затруднит его выделение методами статистики. Во-вторых, большинство крупных городов находится в прибрежных районах, где осадков больше, а ветер сильнее. В общем, вне зависимости от используемого топлива, заметить в воздухе дополнительную влагу от транспорта в большинстве городов малореально (можно пренебречь без потери точности). Единственное исключение - это замкнутые межгорные котловины с резко континентальным климатом в зимний период. В этом случае воздух в котловине очень сухой, ветра нет в силу температурной инверсии, и влага от автомобилей может давать существенный вклад. Например, такая ситуация потенциально возможна в Красноярске и других подобных местах. Но там уже надо считать более точно, а не по порядку величины.
Итого: приведенный выше расчет по порядку величины говорит, что:
1) глобальный эффект выбросов водяного пара автомобилями и прочими сжигателями углеводородов ничтожно мал. Им можно пренебречь всегда и везде.
2) локальный эффект выброса влаги автомобилями может стать заметным только при определенных достаточно редких условиях. Дальше надо считать точнее, но это явно не типичная ситуация для большинства городов.
3) Влагу выбрасывают все традиционные двигатели, а не только двигатель, сжигающий водород. В каком отношении - не скажу (надеюсь, химики уточнят).
Ну и последний момент: метеоданные вроде бы подтверждают, что количество осадков в городах больше, чем в их окрестностях (ссылки с ходу не нашел, кроме вот этой, которая не совсем по делу. Но помню, что такие данные вроде были). Но, этот рост зависит не столько от выбросов водяного пара, сколько от других факторов: загрязнения атмосферы (=наличия центров конденсации), конфигурации термических восходящих потоков (подстилающая поверхность и тепловое загрязнение), высоких зданий (искажение воздушных потоков) и пр.
Да не парьтесь Вы так ;-) Статья неплохая, свой плюс от меня она получила ;-) А ошибки такого плана у всех бывают. Мы же почти всегда (увы!) живем в условиях дефицита времени, а вовсе не только на собеседовании... А возможность вылизывать статью до бесконечности сейчас мало у кого есть. Главное-то сказано правильно, и опечатка на эту суть не влияет.
Так что давайте смиримся с тем, что написание идеальной (в т.ч. безошибочной) статьи - это тоже одна из "неразрешимых задач современной индустрии" ;-) Для этого и нужна критика в комментариях. Я пытался сделать ее не обидной, а цифры меня даже немного повеселили. Надеюсь, Вас тоже ;-)
Если мы бросили монету два раза, то с большой вероятностью можем получить “все орлы” или “все решки”. А тысячу раз, то вероятность “всех орлов” или “всех решек” одна миллионная.
Такое впечатление, что тут автор немного погорячился ;-)
Если бросить монету тысячу раз, то вероятность “всех орлов” или“всех решек” будет 1/2^1000, что очень грубо (по порядку величины) равно 1/10^300 (Считаем, что в килобайте тысяча байт ;-) Напомню, одна миллионная - это 1/10^6. То есть, в нашем случае "немного" - это 10^294. Для сравнения, число нуклонов в видимой части Вселенной
порядка 10^80.
То есть, если каждый нуклон в нашем мире заменить на Метагалактику, а в затем в каждой из них сделать еще раз то же самое, то общее число нуклонов в такой "Метагалактике в кубе" будет всего лишь в 1000000000000000000000000000000000000000000000000000000 раз меньше, чем та ошибка, которую совершил автор ;-)
А вот чтобы получить вероятность “всех орлов” или “всех решек” порядка одной миллионной, монету надо бросить всего лишь раз 20...
С одной стороны, ловушка безвозвратных затрат (ЛБЗ) описана правильно - все по делу. Но, с другой стороны, когда мы задаем вопрос "Почему срабатывает ЛБЗ"?, то тут очень легко перегнуть палку и найти ЛБЗ там, где ее и в помине нет. То есть свести все к субъективной нерациональности даже там, где на самом деле есть вполне рациональные факторы. Проиллюстрирую это утверждение на своем любимом примере ;-)
А именно, когда-то давно меня убеждали (чуть ли не здесь же на Хабре), что я сам стал жертвой ЛБЗ, покупая велосипед. Я тогда написал, что мне нужно дополнительно купить к новому велу седло, так как имеющееся не очень подходит. А еще уточнил, что хотя вел был куплен за 100р, но я не продам его даже за 150. Что вместо этого я лучше добавлю к 100 рублям еще 10 на замену седла.
Понятно, что после такой провокации я был тут же заклеван. Логика критиков была примерно такая: я попал в ЛБЗ, так как продолжаю вкладывать деньги в свой неидеальный велосипед, вместо того, чтобы забыть про него, как про страшный сон и пойти купить новый.
Однако, этот совет не учитывает следующие обстоятельства:
1) Да, оппоненты были правы в том, что велосипед за 100 р меня не совсем устраивает. Но откуда уверенность, что покупка нового седла - это ЛБЗ? Ведь все остальное в велосипеде мне подошло. И с новым седлом я точно получу хороший работающий продукт. Дополнительные 10р на седло - это не ЛБЗ, а улучшение имеющегося у меня вполне годного ресурса.
2) Более того, если я соглашусь с ЛБЗ-гипотезой и побегу за другим новым велосипедом, то нет никаких гарантий, что он будет лучше первого. Ведь там запросто могут обнаружиться какие-то другие скрытые дефекты, устранение которых обойдется мне не в 10р, а во все 50. Так чего ради я буду менять шило на мыло? Я же ведь свой "первый" новый вел не по ГСЧ выбирал. Нет, я его долго изучал, проверял и тестировал - насколько это можно сделать до реальной покупки. Так какие есть основания надеяться, что в следующий раз я выберу велосипед лучше?
3) В третьих, сама процедура выбора и покупки нового велосипеда обошлась мне в довольно приличное время и деньги. Просто доехать от меня до веломагазина и обратно "стоит" 25р плюс полный день времени. Да, это действительно "безвозвратные затраты" (БЗ), но при покупке нового велосипеда они для меня они неизбежны. Покупая следующий "новый вел", я их понесу точно так же и в таком же количестве.
4) В-четвертых, после покупки велосипеда я еще целый день его подгонял и настраивал под свой стиль езды и свои задачи. Например, прикрутил к нему свой любимый багажник и кучу других мелочей. Да, это тоже "БЗ". Но если я откажусь от этого вела, то то мне придется все эти детали переставлять на следующий (еще день работы). А на этом - все уже стоит. Так что с одной стороны это, конечно, "БЗ", но с другой стороны, это вполне объективная причина, стимулирующая меня НЕ менять вел.
Вот и получается, что хотя я купил велосипед за 100р, да еще выяснилась необходимость потратить +10р на седло, но объективнаяценность этого велосипеда для меня значительно превосходит 110р. Грубо говоря, мне совершенно невыгодно продавать его за 150р (и даже за 200 тоже, наверно, не выгодно). Так как вложив в этот велик кучу денег и сил, я все-таки получил в итоге нечто близкое к идеалу. Причем, что важно: если бы я НЕ потратил эти 10р на седло, то ездить на новом велосипеде вообще бы не смог. Он бы действительно остался мусором (кто много катается - знает, как важен выбор правильного седла).
А теперь рассмотрим альтернативный вариант действий.
Что было бы, если бы я с самого начала (как только обнаружил неудачность седла) поддался на увещевания, и поверил, что я попал в ЛБЗ? И побежал бы покупать новый вел?
Тогда мне бы пришлось дополнительно на него потратить вовсе не 100р, а значительно больше (см. полную "смету" выше). Причем с непредсказуемым результатом. (Например, если там геометрия/жесткость рамы окажутся чуть менее подходящими к моему стилю, то я могу хоть 300р вложить дополнительно - идеального для меня вела все равно не получится).
Ну так и где же тут ЛБЗ, а где - рациональные рассуждения?
.
Ну и напоследок еще один интересный "диалектон".
С одной стороны, хотя я купил этот вел за 100р, но мне объективно невыгодно его продавать даже за 150. И это не психологическая иллюзия, а вполне объективный факт.
Но, с другой стороны, в то же самое время какому-то моему коллеге по хобби точно так же невыгодно покупать этот вел у меня даже за 50 р (вместо 100). Так как он же не знает, вдруг я уже успел что-то сломать или нашел скрытый дефект - поэтому для него покупка аналога за 100р в магазине будет выгоднее, чем покупка у меня за 50. А еще ему, может, багажник не нужен, как и другие установленные мной финтифлюшки (для него они просто увеличивают вес вела и ухудшают его потребительские качества).
Такое вот единство противоположностей повышения и снижения цен ;-))
Разумеется, любой по-древнемухороший язык программирования должен уметь стрелять себе в ногу очередью из граблей ;-)) Более того, заложенная в фортран совместимость со старым кодом прямо требует, чтобы у программиста было такое право (в теории, наш код из 1956г все еще до сих пор обязан компилироваться и работать ;-)
Но на практике так уже никто не пишет сейчас. Вместо этого есть понятие модуля, где все переменные и структуры описываются один раз, и затем они по необходимости используются в разных местах (со стандартными в современных языках средствами ограничения видимости). Причем, оператор USE сразу оказался намного удобнее всяких includ-ов, так как он автоматически контролирует, чтобы блок включался (и компилировался) ровно один раз (привет, $IF DEFINED ;-). Одно только это обстоятельство было для многих фортранщиков достаточным аргументом сменить стиль, даже еще ничего не понимая в ООП. А еще сейчас принято методы работы с модульными данными тоже писать в тех же модулях. Фактически получаются те же объекты-классы, только с привычным для первобытных людей интерфейсом.
С учетом этого, теперь программисту на фортране необходимо достичь определенного уровня квалификации, чтобы прострелить именно свою ногу, а не ногу соседа ;-)
А вообще, язык, конечно стал заметно другим даже не в плане спецификаций, а скорее по стилю. Например, я знаю только фортран, и вроде бы знаю довольно неплохо. Но прочитать старую (из 1980-х гг) программу на фортране мне порой намного сложнее, чем аналогичную современную (=адекватно оформленную) программу на незнакомом мне (и весьма непростом!) С++. Просто потому, что тот старый фортран порой по читаемости напоминает Brainfuck. Уж не знаю, умышленно, или нет...
Я из своей фортрановской камеры иногда подглядываю в плюсовые статьи... Сейчас честно порадовался обычаям своего заповедника ;-) Все-таки, у нас с массивами
как-то попроще
Например, вот так будет для массивов с тремя измерениями (код можно легко обобщить на n-мерные массивы):
! Объявляем трехмерные "динамические" массивы: real, allocatable :: A(:,:,:), B(:,:,:) integer :: n = 42 (...) ! Выделяем память (с этого момента размер массивов ! и диапазоны изменения индексов зафиксированы): allocate (A(1:n, 4, 3), B(0:n-1,41:44,1:3)) ! Передаем их в какую-нибудь процедуру: call myfunc(A,B) ....................... .......................
! А это где-то внутри myfunc(A,B): ... integer :: Ashape(3), Bshape(3), dShape(3) integer :: A_min_index(3), B_min_index(3) Ashape=shape(A); Bshape=shape(B) dShape=Ashape-Bshape A_min_index=lbound(A); B_min_index=lbound(B)
! теперь вектора (массивы) Ashape и Bshape ! содержат размер массивов A и B ! по каждому измерению (т.е.[42,4,3]), ! dShape хранит различия в размерах массивов, ! а A_min_index и B_min_index хранят ! нижнюю границу каждого индекса ! Например, B_min_index=[0,41,1] (...) ! поэлементное умножение:
if (maxval(abs(dShape)) == 0) A=B*13
! но только ЕСЛИ все три размера у массивов ! одинаковые (модули разностей = 0). ! Диапазоны индексов при этом могут не совпадать - ! главное, чтобы размерчики совпадали
...
Ну и отдельным бонусом есть ключ компилятора, который включает проверку, что массив B инициализирован, либо выключает ее (если программа хорошо отлажена и очень торопится, это ее немного ускорит). Кстати, если проверка выключена, а значения каких-то элементов в массиве B не присвоены, то с помощью A=B*13 у нас в фортране тоже можно добиться UB!
UPD: а вот с форматированием кода я по-прежнему справиться не могу. Пробелы как глотались хаброредактором, так и глотаются. Причем в непредсказуемых местах и количестве. Да, у нас в фортране компилятор пробелы игнорит... но вообще-то мы их используем для форматирования и удобочитаемости кода.
Откройте на телефоне ваш комментарий и все спойлеры до конца. Последний прочитать уже нереально.
К сожалению, я не могу это проверить - у меня Нокия 1101. В цивилизации я всегда и везде работаю только с десктопа, в крайнем случае с ноута, а вне цивилизации надо не работать, а отдыхать ;-)
Но в любом случае спасибо за замечание - постараюсь в дальнейшем учесть.
Но и у изгиба вперед тоже есть недостатки. Во-первых, он сближает точки опоры (верхнюю и нижние), там вместо прямого угла из ЦМ к опорам будет острый). Вырастет усилие на опоры (и стойки) при вихлянии ЦТ вверх-вниз. Во-вторых, увеличивается рычаг, при вихляниях вправо-влево, т.к. ЦТ оказывается далеко сзади точек крепления. Конечно, все это можно компенсировать увеличением прочности разных деталей. Но глупо спорить, что конструкция, где этих проблем нет вообще, заведомо лучше, чем та, где их надо решать...
Из старого советского опыта - старые советские вообще не тормозят.
У меня нет стенда, чтобы изменить в цифрах, есть только возможность сравнить разные колодки визуально, раскрутив и остановив колесо. Такие тесты говорят, что современные колодки хуже. Возможно, у Вас другие колодки были. Ну или влияет конструкция тормоза, материал/состояние обода и т.д.
Зато умеют залипать при сильном торможении из-за деформации колодки.
Не сталкивался с таким. Вообще, у меня гораздо чаще были проблемы из-за недостаточного сцепления колеса с дорогой, чем колодок с ободом. Возможно, я недостаточно агрессивно катаюсь.
Что для вас "максимальный уклон"? На 45 градусах да, не прокатит.
Не надо утрировать до абсурда. Спуск на 45 градусах - это уже называется акробатика, а не путешествие. А спортивный поход - это про "просто ехать". Далеко, быстро, по плохим высокогорным дорогам, но именно ехать. А не триалить. Даже если такой участок вдруг встретился (скажем, дорогу размыло, или надо пересечь какой-то хребет), он вообще не засчитывается в сложность велосипедной части маршрута. И это не глюк, это сделано специально (если интересно - можем обсудить, почему).
Если же речь не о спорте, а про обычное велопутешествие (чем мы и занимаемся, в основном), то там тем более 99.9% времени - это дороги. Даже если маршрут идет по Памиру, Тянь-Шаню, Тибету, Алтаю, Кавказу и пр. Тут как с горным туризмом и скалолазанием: глядя издалека, дисциплины вроде похожие... но можно всю жизнь ходить в горные походы высоких категорий, и ни разу не встретить там именно скалолазный участок. Поэтому снаряжение для первого и второго, как бы это поточнее сказать, несколько отличается ;-)
На 15-20 вполне можно вызвать занос задней оси и боком затормозить. Проверено. Будет безопаснее, чем лететь кувырком
Я вообще-то сравнивал диски с VB на шоссе. То есть, речь шла про асфальтовые дороги. Там максимальный уклон 10 градусов. В моем случае "большой" уклон - это там, где велосипед самопроизвольно разгоняется, если не тормозить с заметным усилием. Вы сперва переставили меня в совершенно нетипичные для похода условия (которые в реальных путешествиях встречаются чуть реже, чем вообще никогда), а потом объясняете, что в этих условиях мои привычки неправильные.
Да, в походе бывают короткие куски камней, троп и т.п. Но затачивать под них наши велосипеды - это абсурд. Нам гораздо важнее, чтобы велосипед позволял комфортно проехать (с грузом) 100-150 км в день по нормальной дороге, чем адаптировать его под изредка встречающиеся экстремальности. Которые нам в любом случае придется идти пешком, и часто в две ходки (так как велосипед и рюкзак там обычно надо нести отдельно).
Нагрузка на задний тормоз в разы меньше, чем на передний. На спуске - разница ещё больше.
Не знаю, как это происходит в триале, но вот при стационарном спуске по шоссе оптимальный вариант наиболее эффективно превратить mgh в тепло - это когда нагрузка на оба тормоза одинаковая. Ничего личного, это физика. Если один из дисков нагрет не до максимума, то он отдаст меньше тепла, чем мог бы. Тут просто не о чем спорить.
Если же говорить о динамике, то, конечно, правильный стиль - это тормозить задним тормозом прежде всего. Так как занос заднего колеса часто можно парировать, а вот занос (блокировка) переднего - это почти гарантированное падение. Особенно на груженом веле. Вы, вероятно, пишете про мегауклоны, где ЦТ смещен вперед относительно базы велосипеда, и поэтому вес распределяется между колесами неравномерно? Тогда конечно, просто в силу ограничения коэффициента трения приходится тормозить передним колесом больше, чем задним. Но это совершенно другие задачи и стиль, чем в нашем, походном случае. Где все критерии оптимизации совершенно другие. Например, в походе сзади всегда едет рюкзак, причем его центр тяжести максимально приближен к оси заднего колеса (стандартное правило: самое тяжелое - в штанах снизу). И стационарная нагрузка на заднее колесо обычно заметно больше, чем на переднее. И даже на спуске они лишь выравниваются.
А еще после чтения Ваших постов люди, недавно севшие на велосипед, могут подумать, что тормозить передним тормозом - это правильно. И начнут летать через голову просто на городской улице. Благо, заблокировать колесо запросто можно не только диском, но и VB, и крабом.
В общем, не надо без нужды намекать на квантор всеобщности ;-) Тем более, когда имеются совершенно очевидные контрпримеры. И особенно в том случае, когда речь изначально шла именно про такой контрпример ;-)
Тем, что выносить не надо. Там нужен лишь небольшой изгиб.
Ну вот Вы сами себе и ответили. Я имею в виду слово "изгиб".
А теперь расскажите, как изогнутая (и поэтому более длинная) стойка при одинаковом материале и весе может быть крепче и надежней прямой? При условии, что основная нагрузка приложена строго вдоль стойки. Даже не буду отсылать к сопромату, тут все очевидно, по-моему. Добавлю лишь один небольшой факт, что поломка багажника (даже если стойки нормальные, без изгибов) - это одна из наиболее типичных проблем с "железом" в
окологорных велопоходах
На первом месте, понятно, проколы, но это считай расходный материал. На втором, пожалуй, все-таки спицы-восьмерки. Но вот дальше точно багажники. Втулки-звездочки-переклюки и тормоза их по аварийности даже близко не догоняют...
Причем ее не так просто решить без существенного увеличения веса. Я уж не говорю, что такие изгибы ощутимо увеличивают вероятность проблем с багажником при транспортировке, падениях и т.п. А также габариты рамы по толщине (что в новом плацкарте весьма актуально...)
Про обод не готов ничего сказать без расчётов. Обдув там хуже
Вот тут не понял. Как у огромного, аэродинамически несовершенного обода обув может быть хуже, чем у диска?! Нам же важна суммарная теплоотдача. А обод, помимо прочего, еще и часть тепла рассеивает через спицы-резину.
да и контакт с нагревшейся от торможения резиной тоже непонятно как действует.
Ну почему непонятно - очень даже понятно, что плохо ;-)
Главный плюс в том, что это "плохо" полностью контролируемое. Более того, варьируя состав резины в колодках, можно оптимизировать те или иные параметры. Например, старые советские резиновые колодки (увы, не любые), обеспечивают на порядок лучшее сцепление с ободом, чем стандартные современные пластики. Но - и изнашиваются тоже на порядок быстрее (а то и на два). При перегреве - особенно.
Вопрос в том, что колодки на ободе я могу контролировать непрерывно (читай - на ходу), а вот на диске - не очень. И свобода выбора материала колодок в случае VB явно шире...
> Диск потрогать тоже можно :)
Что, на ходу!? Я восхищаюсь такими навыками, но сам пробовать не рискну ;-)
> Вряд-ли вы это на ходу делаете.
А, так все-таки значит диски - на остановке ;-)
Нет, температуру обода я вполне себе щупаю на ходу, причем на обоих колесах. Не в динамическом повороте, понятно, но слезать с вела для этого вовсе не обязательно. Передняя рука на бараньих рогах при спуске вообще в 20см от обода расположена. Ну а чтобы задний потрогать, надо чуть выпрямиться. Но у меня почему-то передний обод обычно греется больше...
Пугает даже не столько тот факт, что диск может перегреться, а то, что это происходит внезапно
> Даже если это случится - на обычной дороге можно затормозить просто ботинком об колесо.
Ну, так на "обычной дороге" такая проблема не актуальна вообще, если я правильно понимаю. У меня все описанное относится к перевалам с высотами от 2000 и перепадом под 1000, и с максимальным уклоном. Там ботинком не особо затормозишь... Уж лучше сгруппироваться и "лечь" аккуратно. Если впереди, разумеется, не крутой поворот над обрывом... :-(
> Ну и маловероятно, что сразу оба откажут
Вот именно это моего приятеля тогда и спасло. Но меня весьма напрягает, что наиболее оптимальный режим рассеивания тепла - это когда оба диска имеют примерно одинаковую температуру. А значит, что после отказа первого диска, когда нагрузка на второй возрастет, он может уже заранее быть очень близок к критическому состоянию.
На самом деле, даже в такой ситуации вероятность двойного отказа может быть сильно меньше, чем 100%. Но меня крайне пугает, что если это все же случится, последствия могут оказаться слишком фатальными...
Но я вообще велосипедист не типичный
старюсь ездить крайне осторожно и всех остальных в группе тоже к этому призываю. За довольно большую кучу многодневных походов (пара экваторов наберется) у нас серьезных ЧП почти не случалось. Хотя,
в самом начале
ездил с нами один товарищ, назовем его М. Замечательный парень, но слишком уж бесшабашный. Сперва на него на спуске в Крыму какая-то дикая бабушка бросилась. Она до последнего пряталась в подворотне, и выскочила, когда уже сделать ничего нельзя было.
А в другой раз мы ехали по крутой грунтовой тропинке к морю близ Идокопаса (это еще до всех тамошних строек было). Когда-то там тракторная дорога была, потом обвалилась частично, но полноценный метр между "стенкой" и "пропастью" нам оставили. Сперва вроде все хорошо было - нормально ехали. Потом дорога покруче стала, я притормозил малость. Кругом лес нависает, впереди - поворотик закрытый, может там вообще эту старую дорогу размыло. И вдруг смотрю - меня в куче пыли этот самый М. на всем ходу обгоняет. Хотя уговор твердый был, что я еду первый, а все за мной. Ну, руки-ноги мелькают, крики какие-то, в пыли ничего разобрать невозможно.... Я кое-как прижался к обочине, остановился, перевожу дух. И тут смотрю - меня на почти той же скорости велосипед этого самого М. обгоняет, уже как-то боком слегка...
Спасло, что до моря там уже совсем близко осталось. Говорят, в соленой воде переломы хорошо заживают. А может, и не было у него переломов - сам М. потом говорил, что только царапины. Кто ж его бесшабашного разберет. Вел его мы тоже привели быстро в чувство: в ремкомплекте запасной петух и запасной переклюк завалялись. А вот арбуз в его рюкзаке такого спуска не выдержал... Но это, впрочем, уже совсем другая история...
А касательно вибрейков - извините, но из МТБ они уже давно ушли и остались лишь на китайских поделиях (...)
Да, да, вот именно!! Больше того, Вы сейчас не первый мне эти слова говорите!! Так что спасибо Вам за погружение в мир добрых воспоминаний ;-))
А теперь самое интересное. Дело в том, что в прошлый раз я все это слышал почти дословно около 20 лет назад, причем сразу от целой кучи уважаемых и мудрых людей! Единственное отличие - Вы пишете про дивный мир дисковых тормозов, а передо мной в прошлый раз разворачивался дивный мир MTB $-)
Не поленюсь, расскажу эту историю.
Дело было в самом начале 2000-х, когда МТБ только завоевывали наш рынок. Тогда я катал на гибриде - очень сильно переделанном ХВЗ, где были устранены почти все "врожденные" недостатки, кроме разве что ограничения по резине. А все окружающие крутили у виска пальцем и называли это все мракобесием и скрытым умственным кретинизмом. Ибо я вложил в ХВЗ столько денег, что на них можно было купить не самый плохой MTB. (На котором я, кстати, тоже поездил, но через год отказался). В общем, я пытался пропагандировать совершенно дикую на тот момент точку зрения, что в спортивном походе гибрид с колесами 28" очень часто гораздо лучше, чем 26" MTB.
По общему убеждению тех времен, критика моих взглядов была безоговорочно справедлива и абсолютно убийственна. Отношение ко мне было примерно как к плоскоземельщику в начале 20 века. Когда все очные и интернет-магазины завалены МТБ, а их преимущества очевидны на каждом углу; когда открой любой сайт, и там тьма статей от крутых профи, которые по полочкам, до мелочей разъясняют тотальное превосходство МТБ в любом спортивном велопоходе. А я, мол, несу какую-то дичь на основании своего субъективного опыта, да еще здравым смыслом пытаюсь прикрыться. Кончилось тем что для очередного сложного похода (где я шел участником) руководитель специально для меня нашел высококачественный 26" МТБ, чтобы только я туда на своем 28" гибриде не поехал. Как я на нем мучился - надо отдельный рассказ написать, хотя велосипед мне подогнали совсем неплохой. В итоге на фоне нескольких сходов в команде я даже проехал тот маршрут до конца и, надеюсь, был там не пассажиром.
Только вот прошло много лет... и оказалось, что маятник золотую середину тогда перелетел очень сильно. Профессионалы, которые писали те статьи, оказались профессионалами в чем-то еще (возможно, в продажах?), но вовсе не в велотуризме. Начиная с 2015 примерно года, целая куча спортивных групп стала ходить сложные велопомаршруты именно на 28" гибридах. Так как их преимущества очень даже весомы при определенных условиях. (Что вовсе не отменяет достоинства MTB, просто они оказались и близко не такими универсальными в спортивном велотуризме, как сначала казалось).
Кстати, наша команда, где почти у всех есть два байка, в свой наиболее крутой поход по Памиру поехала именно на 28" гибридах. Просто потому, что у нас 1) был опыт использования и того, и другого, и 2) было умение правильно готовить не-MTB для похода. Лишь один парень, с очень сильной физподготовкой, но наименьшим из всех велоопытом, поехал на 26". И субъективно ему почти везде было намного тяжелее, чем девушкам на гибридах. Между прочим, по результатам того велопохода мы стали чемпионами РФ по спортивному велотуризму.
Короче, не надо путать тренды и моду, и объективную реальность, которая очень часто намного сложнее простой, распиаренной и наглядной картинки. Я вообще убежден, что за исключением компьютерных и близких к ним технологий (телекоммуникации и т.п.), крайне редко бывает так, что новая техника абсолютно по всем параметрам лучше, чем предыдущая. Наоборот, очень часто на три новые очень полезные фичи, которые дают явный выигрыш, приходится один баг, где проигрыш настолько же очевиден (в определенных условиях). Просто эти фичи и баг идут в неразрывном комплекте, и невозможно выбрать одно, не выбирая другое...
Как бы и индустрия развивается с технологиями, и качество торможения гораздо лучше в условиях специфики мтб, и надёжность выше.
Вот Вы сами себе и ответили: "в условиях специфики мтб". Но я-то пишу про велопоходы. И там есть своя специфика. Например, более высокая надежность резко теряет в ценности, если она ухудшает ремонтопригодность "в поле". Хотя есть тьма ситуаций, когда все
ровно наоборот
Например, на обычных соревнованиях 1% выигрыша в надежности гораздо полезнее двухкратного проигрыша в ремонтопригодности
А про конкретные плюсы и минусы диска vs VB c моей точки зрения я подробно написал тут же рядом вот в этом комменте. Это не значит, что Вы должны со мной согласиться. Но я надеюсь на понимание, что альтернативная точка зрения возникла не на совсем пустом месте, и что при некоторых условиях в ней тоже могут присутствовать рациональные зерна.
Так а что за бонки-то? На фото их не видно совсем. Если это "горизорнтальный" вынос от рамы за диск, то я как раз именно их "болтами" и обозвал, для наглядности. Именно они и ломаются в сложном походе со стопроцентной гарантией. Если не в первом, то в следующем.
Я не уверен про овчарок, - что они все поголовно наиболее смышленые из всех. Да, конечно, есть явно туповатые породы и есть "более продвинутые". Но среди "умных" пород имхо гораздо больше зависит от индивидуальных особенностей конкретной собаки. Как он (она) развивался, что получил (именно поведенчески-интеллектуально) от родителей, с какого возраста среди людей, и как они общались с ним и друг с другом и т.д.
Что касается Весты, то, говоря научным языком, это метис. Без четких преобладающих признаков какой-то породы. В детстве она была бездомной, потом она приглянулась характером кому-то из наших турклубовцев, ее взяли в клуб и стали активно искать хозяев. После недели жизни в клубе (когда ее кормили и гуляли по очереди) она стала нашей.
Привет всем, кто прокрутил комментарии до конца ;-)
1. На правах заинтересованного читателя, для удобства публики добавлю сюда две ссылки на "продолжения" этой статьи от Вадима Румянцева @vadimr ::
Испытания Posit по-взрослому
Испытания Posit по-взрослому. Спектральный анализ
2. В комментариях к этим "продолжениям" активно обсуждался вопрос о пользе posit-вычислений для физиков/математиков. Так вот, как физик, добавлю к этим обсуждениям свои пять копеек:
В формате posit нет “NaN” (нечисел), вместо этого, вычисления прерываются (...)
Если программист видит необходимость в использовании значений NaN, это показывает, что программа пока не завершена (...)
Как физик, скажу, что при работе с ЭКСПЕРИМЕНТАЛЬНЫМИ временными рядами (= любой долговременный мониторинг) такая концепция категорически неприемлема. У нас NaN - это вовсе не ошибка вычислений, а совершенно легальное значение входных данных. Да, часто такие значения как-то интерполируют (заполняют) перед проведением вычислений... но с методологической точки зрения это крайне сомнительный подход. Понятно, что иногда (например, при вычислении БПФ) без интерполяции пропусков обойтись невозможно. Но огромное множество алгоритмов вполне допускает возможность работы с рядами, содержащими NaN. Поэтому при работе с данными незачем их заполнять без крайней нужды! Везде, где этом возможно, надо работать только с реальными наблюдениями. Избегая искусственного придумывания всяких вымышленных значений в тех случаях, когда наблюдение почему-то не проводилось...
Например, если моменты возникновения NaN случайны, то та же АКФ вычисляется на ура без всякой интерполяции. После чего можно и спектр оценить. Правда, оба этих вычисления будут тогда стоить O(n*n), а не O(n*log(n))... но в спектральном анализе любой "сыр" всегда платный :-(
3. И про хранение данных. У нас очень часто при наблюдениях встречаются значения с относительно низкой точностью, полученные с 16-битного АЦП. Или с 24-битного, но где не все разряды задействованы (ну или в младших битах нет ничего, кроме шума). По физическому смыслу это real-значения... но отводить на их хранение 32 бита нет смысла. Впервые эта задачка у меня возникла еще в 1986 году. Я тогда сидел высоко горах и делал систему хранения и анализа экспериментальных временных рядов сначала на СМ-4 (она же PDP-11), а затем на первых IBM PC. И на обоих машинах у нас не было других real, кроме real*4. В общем, я тогда сделал линейное отображение нужного диапазона real на 16-битные целые, которые и хранились в БД. Диапазоны данных у нас были фиксированы, и точности вполне хватало.
А недавно у меня возникла задача упаковать еще менее точные real в минимум бит. Причем, несмотря на очень большую погрешность этих real, там периодически попадались экстремальные выбросы (например, при землетрясениях), которые тоже надо было хранить, а не выбраковывать. В общем, я стал смотреть варианты и наткнулся на 8-битный posit. Который практически сразу же был отвергнут по той простой причине, что для нас критически важны NaN - значения, а их там попросту нет. Ну и еще у нас обычно пакуются сразу тройки таких чисел (три компоненты), которые потом удобно запихнуть в 32-битное целое, поэтому вместо 8 бит можно использовать 10. В итоге я сделал
свой формат компактного хранения real
Если кому-то интересен исходный код, его можно найти вот тут, файл CHARLIB.FOR, функции
PACK_R_TO_INT(R)и UNPACK_R_FROM_INT(I) (функции пакуют real-число в диапазоне от 1 до 140000 в целую переменную в диапазоне 1..1024 и обратно).Кстати, та самая (из 1986г!) упаковка real в 16-бит у нас тоже до сих пор крутится в продакте. См. там же файл ABD_DB.FOR.
В каком-то смысле это тоже аналог posit-формата. Только в нашем случае нет выделенного "магического числа" 1, около которого точность максимальна (и плавно уменьшается при удалении от него в обе стороны). Вместо этого у нас есть "рабочий диапазон" (где шкала представимых чисел линейная) и "зона выбросов", где шаг между представимыми числами растет даже быстрее, чем в posit.
А мораль этой истории такова. Если уж даже для нашей задачки (которая, казалось бы, прямо напрашивается на решение в рамках posit-подхода) этот формат оказался непригодным, то тут есть большой повод задуматься: а так ли он универсален, как описано в этой статье? В общем, у меня есть такое подозрение, что posit-вычисления весьма хороши только для довольно узкого круга задач. А вот насчет их универсальности возникают большие сомнения. Имхо, по этому показателю плавающая точка IEEE соревнование с posit-форматом явно выигрывает.
Есть некоторые вещи которые я у вас подметил.
Буд рад, если навел на какие-то полезные мысли ;-)
измерять в секундах это очень долго (...) внедрить поддержку вплоть до микросекунд.
Мы свою систему начинали пилить в те далекие времена, когда
деревья были большимиinteger был двухбайтным ;-) Поэтому для универсальности шкалы времени дату оформили в виде структуры из "общечеловеческих ценностей": года, месяца, дня и т.д. Идея была в том, что все даты, кроме ключей, не хранятся наравне с данными, а вычисляются по мере необходимости. То есть, каждое значение данных сопоставляется с датой динамически, а в базе (в памяти) хранятся только характеристики сигнала в целом (ну или его фрагмента). Соответственно, при длине сигнала от 100 точек и более размер структуры даты не важен вообще.Для манипуляций с такими датами пришлось запилить собственную библиотеку со всякими оптимизациями скорости типичных (для нас!) операций: инкремент даты с разным шагом, пересчет номера точки в дату и обратно, сложение-вычитание дат (интервалов) и т.д. Которая так с тех пор и работает (если интересно, она лежит вот тут среди прочих кодов - файлы clib.inc и clib.for).
Сейчас мы бы уже ядро библиотеки попроще сделали, на основе 16-байтовых (а не 16-битных) вычислений ;-). С конверсией даты в человеческий формат и обратно на уровне интерфейса, как это принято "у взрослых". Но тут уж, что называется, не буди лихо, пока легаси работает - ;-)
Вдогонку. Спасибо всем, кто меня заминусовал, за Ваше мнение... но, все-таки, я был бы благодарен за уточнение причины минусов.
Топикастер задал провокационный вопрос:
...какой язык выбрать в качестве стартового?
Уточнив при этом, что речь идет о "начинающих программистах", но не наложив формальных ограничений. А мне вот всегда казалось, что хороший стиль программирования - это когда ты готов обрабатывать не только типичные, но и крайние случаи. Ну вот я и написал про свой личный "крайний случай", для которого
оба предложенных топикастером языка не очень подходят:
P.S. Конечно, я понимаю, что тут идет
серьезный разговор серьезных людей,
а не всяческих чайников со всего-то полумиллионом строк кода в продакте, которым априори нечего лезть со своими шуточками в деловую беседу даже в праздничный выходной
Но, вообще-то, в каждой шутке есть ДОЛЯ шутки.
Включая и шутку про "крайние случаи"
Lisp!
Не, в моем случае Lisp - это перебор ;-)
Я же имею дело с по-настоящему начинающим программистом, а не с переростком из дошкольной группы детского сада ;-)
В моем случае, когда обучаемый еще не умеет читать и писать, и вынужден всю программу держать в голове, освоить всякие скобки-кавычки-отступы-списки ему будет непросто. Поэтому я и предлагаю отложить эти темы на чуть попозже. Так что для самого первого знакомства с программированием мой самодельный язык все-таки лучше ;-)
...какой язык выбрать в качестве стартового?
Боюсь, что меня сейчас заклюют сторонники двух обсуждаемых языков, но лично я в качестве стартового все-таки выбрал бы что-то другое. Но поскольку в контексте статьи это уже почти оффтопик, продолжение спрячу под спойлер.
Простой язык для обучения программированию
Я исходил из того, что САМЫЙ первый язык все-таки должен быть минималистичным. Вообще без библиотек, модулей, крейтов и прочего, так как для некоторых обучаемых (при самом первом знакомстве с темой) эти концепции могут быть сложноваты. Как и понятие компилятора. Имхо, на начальном этапе освоения базовых элементов важна не столько мощь языка, его скорость или обилие возможностей, сколько прозрачная связь между кодом и результатом. Чтобы обучаемый сразу видел, как та или иная процедура работает "под капотом".
В общем, я остановился на интерпретаторе с минималистичной системой команд, предельно приближенных к "железу". Сейчас в моем языке всего 8 команд, что позволяет реализовать их на 3-битной архитектуре.
Сами команды такие
наШею, Вправо, Влево, Вперед, Стоп, Опустить.
Ну и синтаксический сахар (куда ж без него): это команды "Кругом" и "кМаме". Причем, последнюю обрабатывает макропроцессор, раскладывая ее на "элементарные" процедуры из первого списка. А фича в том, что перед исполнением каждая из этих команд озвучивается специальным динамиком. Имхо, такая озвучка здорово помогает освоению языка.
Несмотря на минимальный функционал, язык позволяет прокладывать довольно сложные маршруты по трехкомнатному лабиринту с мебелью. Правда, я не настолько силен в электронике, чтобы изготовить настоящий трехбитный процессор с необходимой периферией, поэтому сейчас наши первые программы работают на эмуляторе, в качестве которого выступаю я сам.
А вот насчет Rust или C/C++ в качестве первого языка у меня есть большие сомнения в связи с тем, что обучаемому на данный момент два года и пара месяцев. Посмотрим, за какое время дочке удастся освоить описанный выше микроязык хотя бы на уровне Middle. (Senior в моем представлении - это когда она начнет сама обучать этому языку свою куклу). А пока что (на первой неделе обучения) нам
труднее всего нам дается команда Стоп
Боюсь, что это мой архитектурный баг... Ведь в отличие от других команд, выполняющих разовую операцию и сразу возвращающих управление, команда Вперед запускает бесконечный цикл движения, выходить из которого надо отдельной командой (ну или с помощью препятствия на пути). Поэтому остановиться на середине коридора напротив двери, в которую хочется повернуть, у нас пока что не получается. Впрочем, вопросы синхронизации - это одна из самых сложных тем в любом языке...
UPD: Вдогонку: не успел написать, как мне тут уже Lisp посоветовали ;-)
Совет интересный, но проблема в том, что обучаемый пока не умеет ни читать, ни писать. Да и разговаривает с трудом. Поэтому всю программу нам пока приходится держать в голове... С учетом этого, наличие в языке всяких служебных символов типа кавычек выглядит большим минусом...
;-)
Ну сход и сдох. Купи нормальный Samsung, например oem PM9a1, у самсунгов с надёжностью получше.
Спасибо за попытку помочь... но мне уже давали такие советы в разных местах и не один раз. Но, у меня ведь изначально тоже был SSD с довольно неплохой репутацией. Проблема, по-видимому, не в производителе, а в том, что в моем режиме эксплуатации (постоянная перезапись всего SSD целиком на максимально возможной скорости), никакой "бытовой" SSD долго не выдержит. Нужны на порядок более дорогие устройства, которые рассчитаны именно на такое использование. И, желательно, с дополнительным охлаждением именно SSD (которое в обычном десктопе обеспечивается далеко не всегда).
Вообще у меня возникает подозрение
теория заговора, что общепринятое впечатление о высокой скорости и надежности SSD - это в первую очередь следствие грамотного маркетинга. Когда никто не акцентирует внимание, что эти надежность и скорость достигаются лишь при определенных сценариях использования. Да, эти сценарии довольно типичны (системный диск, например), однако жизнь ими далеко не исчерпывается. Мой случай, как я написал выше, это потоковая обработка больших файлов. Скользящее окно бежит по группе сигналов, они читаются, обрабатываются и перезаписываются, формируя другую группу сигналов. И так круглосуточно. Мое подозрение состоит в том, что вот именно для такого сценария применения стандартные SSD-шки непригодны чуть больше, чем полностью. Можно хоть каждый месяц покупать и убивать хорошие, вроде бы SSD, и наивно удивляться потом: ну что же могло пойти не так в n-й раз подряд?Так что мой случай - это вовсе не "исключительное невезение", когда прекрасная железяка внезапно отказывает на ровном месте. Нет, имхо это наиболее ожидаемое поведение такой железяки в не совсем типичных для нее условиях.
Короче, после того случая я купил себе дополнительный винт, работаю с данными теперь только на нем, и горя не знаю. А второй SSD, который мне подарили после "совершенно невероятной внезапной смерти первого
на ровном месте", использую для системы. Где он прекрасно функционирует без каких-либо нареканий.В общем, мой опыт говорит, что при покупке SSD надо не просто читать хвалебные отзывы, но и не забывать о такой штуке, как "сценарий использования". Чтобы не ошибиться с выбором, поддавшись на
маркетинговые уловки
Хотя, логику маркетологов тоже можно понять.
Зачем пугать 99% возможных клиентов, рассказывая про довольно редкий сценарий катастрофически быстрого отказа SSD при слишком интенсивной эксплуатации? Ведь эти 99% никогда с такими сценариями не столкнутся... а вот "червь сомнения" у них зародится, и на продажи это вполне повлияет....
Ну, а тот 1%, которой все-таки в такую ситуацию "вляпается", и начнет (не понимая причин) голосить о ненадежности SSD, он будет сам виноват. Маркетингу он точно не помешает, так как в любом форуме всегда найдутся 99% клиентов, которые объективно своей SSD-шкой довольны и не имеют ни малейших причин на что-либо жаловаться. У них-то все хорошо. Точно такая же нога - и не болит. Поэтому маргиналы, которые кричат про сдохшие SSD, быстро окажутся в бане. Причем такой бан будет, с точки зрения общественности, вполне справедлив: они ведь действительно несут всякий бред, который явно противоречит эмпирически бесспорному опыту. Короче, маркетинг не пострадает ;-)
Мораль
С одной стороны, выбраковка аномальных данных при анализе наблюдений - это стандартный прием. Но, с другой, если те люди, которые годами успешно складывали кучи разных металлов большого размера, проигнорируют редкие сообщения, что с плутонием может не получиться, то они потеряют довольно интересную информацию (и хорошо, если только ее ;-).
Так вот, поскольку у нас тут все-таки Хабр, то я очень надеюсь, что присутствующие тут специалисты помогут объективно разобрать мои опасения, что вероятность отказа SSD может катастрофически увеличиваться при определенных (да, не очень типичных, но все же возможных) сценариях использования. И что это случится еще до того, как меня тут завалят советами "выбрось брак, купи новый" или вообще забанят за ересь про SSD ;-)
VRackDB - это простая In Memory Graphite like база данных, предназначенная для хранения временных рядов (графиков). (TypeScript)
Просто интересно, а сколько человеко-дней занимает такая разработка сейчас (в наше время)?
Мы лет 30-40 назад написали примерно то же самое на фортране, только с акцентом на анализ/визуализацию ретроспективно накопленных данных. Система до сих пор используется, и после нескольких рефакторингов насчитывает несколько сотен тысяч строк кода. Она тоже достаточно быстрая (пока ряды содержат меньше миллиона измерений, все делается "на лету"), с минимальными требованиями к "железу", но есть и некоторые отличия:
рабочее пространство (а тем более данные) у нас хранятся на диске, так что при внезапном отключении света не теряется вообще ничего, кроме результатов текущей операции;
ОП у нас не используется вообще ;-) Ну то есть на самом деле там хранятся текущие графики (смешное количество точек), а при обработке рядов - скользящее окно, которое бежит по ряду (тут уже требования намного серьезнее). Но вот практически вся остальная доступная память напрямую программой не задействуется, а используется для кэширования дисковых файлов с данными, причем этим занимается ОС. Даже под DOS-ом это позволяло нам спокойно работать с миллионами точек. А сейчас у нас не редкость ряды из миллиардов значений. При этом они спокойно крутятся но компе с 8Гб памяти, где параллельно висит еще тьма всякой рутины от браузера до VS;
Но наиболее интересное в контексте вашей системы отличие в том, что данные для графика у нас возвращаются в двух вариантах: это либо обычный набор точек в соответствии с запрошенной детальностью (обычно она соответствует разрешению экрана) либо
набор "диапазонов" (т.е. пар {min,max}) той же размерности
Поясню, зачем нужен диапазон. Пусть, например, у нас есть ряд с опросом в 1 сек, а длина ряда 5 лет. Тогда каждый пиксел экрана (пойнт графика) должен показать пользователю фрагмент сигнала, состоящий из примерно 100 000 первичных (секундных) отсчетов данных. Понятно, что за 100 тыс. отсчетов ряд мог довольно сильно гулять вверх-вниз. В такой ситуации показывать юзеру одно лишь только среднее значение... ну, такое себе. У нас в графиках поэтому сделаны два режима (чуть подобнее здесь): можно показывать либо среднее, либо размах колебаний (он рисуется вертикальной палочкой). Вот сравнение двух графиков одного и того же ряда с генерализацией среднего либо размаха:
На первый взгляд даже и не скажешь, что это один и тот же сигнал...
В общем, крайне рекомендую добавить в вашу БД такую опцию - возврат диапазона значений для графика с генерализацией размаха. Для наших геофизических данных возможность "на лету" переключаться между двумя режимами визуализации - это просто незаменимая фича. Она на порядок полезнее, чем возможность игры со "слоями", приведенными к разным частотам опроса. Думаю, что и для любых других негладких либо высокочастотных данных эффект будет впечатляющим.
Кстати, сейчас мы готовим статью, где будет подробное обсуждение этих нюансов на примере рядов наклономерных наблюдений в журнал Сейсмические приборы. Включая и сравнение динамической генерализации и "слоев" с очевидными преимуществами первой для широкого круга задач. Так что если Вы описанную фичу у себя соберетесь делать, советую
туда заглянуть
вроде, статья должна осенью выйти. В elibary она за paywall-ом, но на сайте ИФЗ-шных журналов доступ к статьям свободный. Короче, если статья понравится, не забудьте сослаться. Вам не сложно, а нам будет приятно ;-)
А вот "слои" у нас не прижились как-то. Хотя один из юзеров предлагал такой вариант. Но... небольшие ряды данных (до миллиона значений) на современных компьютерах агрегируются "на лету", поэтому на таких масштабах просто нет смысла заморачиваться с предвычисленными слоями. Когда рисовалка запрашивает у БД нужный ей фрагмент данных, то проще сделать все расчеты в динамике и вернуть данные в точности с нужной детальностью, а не подбирать наиболее подходящий слой (который вдобавок может оказаться не совсем подходящим). А для гигабайтных рядов мы обычно делаем всего один промежуточный слой, да и то вручную.
Ну и еще из отличий - шкала времени у нас начинается не с секунд, а с микросекунд, т.к. в геофизике в последнее время внедряются все более высокочастотные регистрирующие системы.
Так вот, я сейчас попытался прикинуть, сколько же времени у нас ушло на разработку всей этой системы. Очень грубо - несколько тысяч человеко-дней. Правда, основное время все-таки было потрачено не на СУБД, а на разные инструменты анализа временных рядов. Но вклад СУБД и визуализации в общие времязатраты тоже вполне заметный. С другой стороны, первоначально мы все писали под DOS, не имея многих сегодняшних инструментов. Ну и еще один нюанс - у нас абсолютно все алгоритмы поддерживают наличие в рядах данных пропущенных наблюдений. При написании своего алгоритма это часто увеличивает времязатраты втрое-вчетверо. А то и вообще на порядок, когда вместо готового библиотечного алгоритма приходится делать свой полный аналог просто потому, что в библиотечном Nan-ы обрабатываются не так, как нам хочется...
В общем, несмотря на все различие между системами, некоторая аналогия между ними проглядывается. Поэтому и интересно: насколько быстрее и проще сейчас можно "собрать" такую систему, как ваша, из почти готовых кубиков, по сравнению с самостоятельным изготовлением продукта "с нуля".
воду .... причислили к вредным выбросам
Злободневное и довольно глубокое замечание! Но свои мысли по этому поводу я все же
спрячу под спойлер
Начну с древней истории. Лет 25 назад я активно водил в походы детей - своих и "соседских", и народ там был очень разный. Некоторые жили скромно (неполные семьи), и при планировании походной раскладки включали туда то, чего им недоставало дома. Как-то раз новый завхоз под давлением коллектива решил взять в поход газировку. Я попросил более опытных девочек (которые уже понимали, что даже в водном походе лишний вес - это не здорово, да и вообще, что польза от газировки сомнительная) придумать аргументы, почему так делать не надо. У нас тогда каждый второй ребенок был в чем-нибудь гением, поэтому аргументов придумали много - хороших и разных. Но самым действенным оказался такой (у старших детей уже началась в школе химия, и, видимо, у них был хороший учитель): "Пить газировку вообще не стоит, так как там в каждой бутылке полно окислов водорода!" Это подействовало, газировку в поход
решили не брать ;-)
Кстати, на этот аргумент многие взрослые до сих пор тоже ведутся ;-))
И только много позже я понял, что в момент этого обсуждения младшие участники еще не начали изучать химию... Получается, их мы попросту развели. Может, для здоровья оно и полезно, но все равно получилось как-то не очень честно :-((
А мораль этой истории такова: сейчас нам на полном серьезе очень часто вещают что-то похожее на эти "окислы водорода". Почти любая нашумевшая в СМИ страшилка последних десятилетий такие элементы содержит. Когда правдивые, но непонятные научные данные подаются специальным образом, - так, чтобы у слушателя сложилось совершенно искаженное впечатление о реальности. И надо признать, что для тех, кто не знает матчасть, такие аргументы звучат очень действенно и пугающе. А особенно страшно, когда таких (некомпетентных в деталях) слушателей большинство... К сожалению, это сейчас почти неизбежно в силу все более узкой специализации научного знания. Специалистов по определению крайне мало, они не могут быть большинством практически ни в каком общественном месте, кроме узкопрофильных форумов. Которые, в свою очередь, на массовое сознание вообще никак не влияют в силу своей узкопрофильности и малочисленности участников (с одной стороны, там объективно высокий порог вхождения, с другой - в таких форумах умышленно отсеивают дилетантов, чтобы они не мешали серьезному обсуждению. А заодно еще могут отсеивать и весь "немэйнстрим", стимулируя тем самым распространение всяких теорий заговора. Но это уже отдельная тема).
В результате в нашем "облачно-ориентированном" общественном сознании в первую очередь распространяются именно мифы. Сначала они овладевает массами, а затем становится руководством к действию. И это уже не просто детский прикол, а вполне реальная
угроза нашей цивилизации
Дальше уже будет совсем оффтопик, но тем не менее напишу. Моя гипотеза состоит в том, что в нашем интернет-мире "виртуализированного" социума различные идеи начинают конкурировать между собой по законам, аналогичным законам биологической эволюции. В результате выживают не самые разумные идеи, а наиболее приспособленные к среде. То есть мифы.
Все очень просто. Чтобы понять и передать научную концепцию, надо быть специалистом в этой области. Но таких "узлов" в сети коллективного разума ничтожно мало. Ведь каждый индивид (узел) специализируется на чем-то своем... Во всех остальных отраслях знаний он дилетант. Которому гораздо проще воспринять-передать миф, чем научное знание. Итог - любые продвинутые (=узкоспециализированные) знания вытесняются из "коллективного сознания" мифами.
Раньше (пока знания были приближены к практике) на пути многих мифов вставала практика. Сейчас практика в каждой конкретной области - это тоже удел избранных. Подавляющее большинство землян пользуются технологиями (= интерфейсами), не вникая в детали реализации. Обычному человеку гораздо понятнее объяснение, что компьютер работает на "белом дыме" (и что если этот дым вышел, то все), чем какие-то там двоичные коды, транзисторы, литографы и всякая прочая заумная казуистика, не объясняющая (для него) вообще ничего. А с дымом по крайней мере понятно. Человек не может без воды и еды, а Алиса - без "белого дыма". Спорить с этой железной (и жизненной) логикой могут только дебилы, ведь правда?
А теперь самое важное.
Вышеописанный "пользователь Алисы", верящий в "белый дым" - это вовсе не идиот!!! Наоборот, он может быть высококлассным вирусологом или климатологом и т.д.. Он искренне недоумевает, глядя, как массами овладевает чудовищный бред, относящийся к его профессиональной области. Потом этот миф достигает правительства, и превращается в обязательные для всех законы. Тут поневоле поверишь, что мир сходит с ума.
Так вот, моя гипотеза состоит в том, что ситуации, подобные вышеописанным, это не досадные недоразумения, а логичное следствие ускоренной специализации знаний + революции в коммуникациях (=создание "коллективного разума"). Просто этот коллективный общечеловеческий разум вовсе не будет кратно умнее нас. Наоборот, он будет лишь самую малость умнее "среднего человека". Просто потому, что в любом конкретном вопросе подавляющее большинство его "обучающей выборки" - это не специалисты, а дилетанты.
Если я хоть в какой-то степени прав, то отсюда вытекает целая куча весьма неприятных угроз. С которыми надо немедленно и упорно бороться, т.к. будучи пущенными на самотек, эти процессы ведут нас к очень нехорошим финалам. Например, эта модель дает объяснение, почему современная экономика выливается именно в такую политику. Или почему парадокс Ферми - это вовсе не парадокс, а наиболее вероятный исход :-(
У меня даже как-то возникла мысль - не написать все это системно в виде статьи. Но потом я подумал, что такая статья неизбежно коснется политики, что на Хабре совсем неуместно. А другого ресурса, где возможно адекватное обсуждение такой "философии", я просто не знаю :-(
Если все перейдут на водород, то количество дождей в странах, где много автомобилистов - увеличится. Звучит странно, но посчитайте количество водяного пара, которое будет уходить в атмосферу с каждого автомобиля и умножьте на количество машин.Сам не считал, ибо лень, только примерно прикинул,
Думаю, зря Вы свои прикидки сюда не выложили. Так как по моим прикидкам получается наоборот. А именно, дополнительное увлажнение атмосферы от водородных двигателей будет настолько ничтожно, что всерьез говорить про него не приходится. Вот они:
Первый метод подсчета
(Важное замечание: все расчеты ниже - по порядку величины, т.е. коэффициентами порядка 2 мы пренебрегаем. Для наших целей этого хватит:)
1. Общая добыча нефти и газа в мире в год порядка 6Е+12 кг/год. Мы сильно не ошибемся (расчет ведь по порядку величины), если примем, что все добытые углеводороды идут в топку. И точно также в грубом приближении можно принять, что при сгорании нефтегазобензина выделяется примерно такая же масса воды, сколько было (по массе) исходного вещества. Итого, современные автомобили вместе с электростанциями-котельными-пароходными выбрасывают в атмосферу Е+12 .. Е+13 кг воды в год.
2. Общее количество влаги в атмосфере Земли меняется в разные сезоны года, но грубо его можно принять равным Е+16кг. В среднем испаренная вода остается в атмосфере 10 дней. Итого за год через атмосферу проходит 4Е+18кг воды. Итого вклад "углеводородных" вод в общий массообмен составляет порядка Е-6 от общего цикла. То есть, 0.0001%. Учитывая, что естественные колебания количества атмосферной влаги (например, сезонные) достигают первых процентов, на этом фоне заметить эффект человеческого воздействия в глобальном масштабе невозможно в принципе: он на три порядка меньше дисперсии.
3. Я не химик, поэтому в первом приближении могу только прикинуть, что теплота сгорания а) водорода и б) нефте-газо-бензина в расчете на массу выделившейся воды вроде бы одного порядка. Но если это и правда так, то значит, то замена одного топлива на другое кардинально изменит только объем выбросов CO2, но в гораздо меньшей степени - H20.
Кстати
если тут есть химики, было бы интересно узнать более точные цифры: сколько воды выделяет на километр пробега бензиновый, дизельный и водородный мотор? Может кто-нибудь подсказать?
UPD: пока я писал свой ответ, @Antocyan уже подсказал, что в расчете на единицу массы топлива, водородное выделяет гораздо меньше воды, чем традиционные. Но нам-то важна масса воды на единицу выделенной энергии, а не сожженного топлива. И вот с этим все уже не так просто. Было бы здорово, если кто-нибудь уточнит.
Итого, первый способ подсчета говорит, что переход на водородное топлива а) не изменит кардинально количество выбрасываемой в атмосферу воды, и что б) это количество пренебрежимо мало по сравнению с глобальным круговоротом.
Второй метод подсчета
Теперь попробуем посчитать то же самое локально. Допустим, у нас есть мегаполис на 1 млн автомобилей. Пусть в среднем каждый автомобиль проезжает за сутки 100км и выбрасывает в атмосферу 20кг воды (не важно, на каком топливе). Итого получается около Е+10 кг воды в год
Количество осадков сильно меняется в разных географических поясах. В среднем по планете это 1000 мм/год, что соответствует Е+9 кг/км2/год. Считая размер нашего мегаполиса 100х100км, получаем, что там за год выпадает Е+13 кг осадков. Итого, если бы вся выделенная автомобилями влага выпадала в пределах города, то это могло бы оказать небольшой, но потенциально измеримый эффект на климат: около 0.1%. Правда, для его фиксации потребовались бы достаточно длительные наблюдения, так как межгодовая изменчивость количества осадков раз в сто раз больше. То есть, нам потребуются многолетние наблюдения.
Однако, на практике в атмосфере почти всегда дует ветер. Поэтому выделенная транспортом влага рассеивается на гораздо большей площади, что многократно ослабит эффект и сильно затруднит его выделение методами статистики. Во-вторых, большинство крупных городов находится в прибрежных районах, где осадков больше, а ветер сильнее. В общем, вне зависимости от используемого топлива, заметить в воздухе дополнительную влагу от транспорта в большинстве городов малореально (можно пренебречь без потери точности). Единственное исключение - это замкнутые межгорные котловины с резко континентальным климатом в зимний период. В этом случае воздух в котловине очень сухой, ветра нет в силу температурной инверсии, и влага от автомобилей может давать существенный вклад. Например, такая ситуация потенциально возможна в Красноярске и других подобных местах. Но там уже надо считать более точно, а не по порядку величины.
Итого: приведенный выше расчет по порядку величины говорит, что:
1) глобальный эффект выбросов водяного пара автомобилями и прочими сжигателями углеводородов ничтожно мал. Им можно пренебречь всегда и везде.
2) локальный эффект выброса влаги автомобилями может стать заметным только при определенных достаточно редких условиях. Дальше надо считать точнее, но это явно не типичная ситуация для большинства городов.
3) Влагу выбрасывают все традиционные двигатели, а не только двигатель, сжигающий водород. В каком отношении - не скажу (надеюсь, химики уточнят).
Ну и последний момент: метеоданные вроде бы подтверждают, что количество осадков в городах больше, чем в их окрестностях (ссылки с ходу не нашел, кроме вот этой, которая не совсем по делу. Но помню, что такие данные вроде были). Но, этот рост зависит не столько от выбросов водяного пара, сколько от других факторов: загрязнения атмосферы (=наличия центров конденсации), конфигурации термических восходящих потоков (подстилающая поверхность и тепловое загрязнение), высоких зданий (искажение воздушных потоков) и пр.
Да не парьтесь Вы так ;-) Статья неплохая, свой плюс от меня она получила ;-) А ошибки такого плана у всех бывают. Мы же почти всегда (увы!) живем в условиях дефицита времени, а вовсе не только на собеседовании... А возможность вылизывать статью до бесконечности сейчас мало у кого есть. Главное-то сказано правильно, и опечатка на эту суть не влияет.
Так что давайте смиримся с тем, что написание идеальной (в т.ч. безошибочной) статьи - это тоже одна из "неразрешимых задач современной индустрии" ;-) Для этого и нужна критика в комментариях. Я пытался сделать ее не обидной, а цифры меня даже немного повеселили. Надеюсь, Вас тоже ;-)
Если мы бросили монету два раза, то с большой вероятностью можем получить “все орлы” или “все решки”. А тысячу раз, то вероятность “всех орлов” или “всех решек” одна миллионная.
Такое впечатление, что тут автор немного погорячился ;-)
Если бросить монету тысячу раз, то вероятность “всех орлов” или “всех решек” будет 1/2^1000, что очень грубо (по порядку величины) равно 1/10^300 (Считаем, что в килобайте тысяча байт ;-) Напомню, одна миллионная - это 1/10^6. То есть, в нашем случае "немного" - это 10^294. Для сравнения, число нуклонов в видимой части Вселенной
порядка 10^80.
То есть, если каждый нуклон в нашем мире заменить на Метагалактику, а в затем в каждой из них сделать еще раз то же самое, то общее число нуклонов в такой "Метагалактике в кубе" будет всего лишь в 1000000000000000000000000000000000000000000000000000000 раз меньше, чем та ошибка, которую совершил автор ;-)
А вот чтобы получить вероятность “всех орлов” или “всех решек” порядка одной миллионной, монету надо бросить всего лишь раз 20...
С одной стороны, ловушка безвозвратных затрат (ЛБЗ) описана правильно - все по делу. Но, с другой стороны, когда мы задаем вопрос "Почему срабатывает ЛБЗ"?, то тут очень легко перегнуть палку и найти ЛБЗ там, где ее и в помине нет. То есть свести все к субъективной нерациональности даже там, где на самом деле есть вполне рациональные факторы. Проиллюстрирую это утверждение на своем любимом примере ;-)
А именно, когда-то давно меня убеждали (чуть ли не здесь же на Хабре), что я сам стал жертвой ЛБЗ, покупая велосипед. Я тогда написал, что мне нужно дополнительно купить к новому велу седло, так как имеющееся не очень подходит. А еще уточнил, что хотя вел был куплен за 100р, но я не продам его даже за 150. Что вместо этого я лучше добавлю к 100 рублям еще 10 на замену седла.
Понятно, что после такой провокации я был тут же заклеван. Логика критиков была примерно такая: я попал в ЛБЗ, так как продолжаю вкладывать деньги в свой неидеальный велосипед, вместо того, чтобы забыть про него, как про страшный сон и пойти купить новый.
Однако, этот совет не учитывает следующие обстоятельства:
1) Да, оппоненты были правы в том, что велосипед за 100 р меня не совсем устраивает. Но откуда уверенность, что покупка нового седла - это ЛБЗ? Ведь все остальное в велосипеде мне подошло. И с новым седлом я точно получу хороший работающий продукт. Дополнительные 10р на седло - это не ЛБЗ, а улучшение имеющегося у меня вполне годного ресурса.
2) Более того, если я соглашусь с ЛБЗ-гипотезой и побегу за другим новым велосипедом, то нет никаких гарантий, что он будет лучше первого. Ведь там запросто могут обнаружиться какие-то другие скрытые дефекты, устранение которых обойдется мне не в 10р, а во все 50. Так чего ради я буду менять шило на мыло? Я же ведь свой "первый" новый вел не по ГСЧ выбирал. Нет, я его долго изучал, проверял и тестировал - насколько это можно сделать до реальной покупки. Так какие есть основания надеяться, что в следующий раз я выберу велосипед лучше?
3) В третьих, сама процедура выбора и покупки нового велосипеда обошлась мне в довольно приличное время и деньги. Просто доехать от меня до веломагазина и обратно "стоит" 25р плюс полный день времени. Да, это действительно "безвозвратные затраты" (БЗ), но при покупке нового велосипеда они для меня они неизбежны. Покупая следующий "новый вел", я их понесу точно так же и в таком же количестве.
4) В-четвертых, после покупки велосипеда я еще целый день его подгонял и настраивал под свой стиль езды и свои задачи. Например, прикрутил к нему свой любимый багажник и кучу других мелочей. Да, это тоже "БЗ". Но если я откажусь от этого вела, то то мне придется все эти детали переставлять на следующий (еще день работы). А на этом - все уже стоит. Так что с одной стороны это, конечно, "БЗ", но с другой стороны, это вполне объективная причина, стимулирующая меня НЕ менять вел.
Вот и получается, что хотя я купил велосипед за 100р, да еще выяснилась необходимость потратить +10р на седло, но объективная ценность этого велосипеда для меня значительно превосходит 110р. Грубо говоря, мне совершенно невыгодно продавать его за 150р (и даже за 200 тоже, наверно, не выгодно). Так как вложив в этот велик кучу денег и сил, я все-таки получил в итоге нечто близкое к идеалу. Причем, что важно: если бы я НЕ потратил эти 10р на седло, то ездить на новом велосипеде вообще бы не смог. Он бы действительно остался мусором (кто много катается - знает, как важен выбор правильного седла).
А теперь рассмотрим альтернативный вариант действий.
Что было бы, если бы я с самого начала (как только обнаружил неудачность седла) поддался на увещевания, и поверил, что я попал в ЛБЗ? И побежал бы покупать новый вел?
Тогда мне бы пришлось дополнительно на него потратить вовсе не 100р, а значительно больше (см. полную "смету" выше). Причем с непредсказуемым результатом. (Например, если там геометрия/жесткость рамы окажутся чуть менее подходящими к моему стилю, то я могу хоть 300р вложить дополнительно - идеального для меня вела все равно не получится).
Ну так и где же тут ЛБЗ, а где - рациональные рассуждения?
.
Ну и напоследок еще один интересный "диалектон".
С одной стороны, хотя я купил этот вел за 100р, но мне объективно невыгодно его продавать даже за 150. И это не психологическая иллюзия, а вполне объективный факт.
Но, с другой стороны, в то же самое время какому-то моему коллеге по хобби точно так же невыгодно покупать этот вел у меня даже за 50 р (вместо 100). Так как он же не знает, вдруг я уже успел что-то сломать или нашел скрытый дефект - поэтому для него покупка аналога за 100р в магазине будет выгоднее, чем покупка у меня за 50. А еще ему, может, багажник не нужен, как и другие установленные мной финтифлюшки (для него они просто увеличивают вес вела и ухудшают его потребительские качества).
Такое вот единство противоположностей повышения и снижения цен ;-))
Я бы не сказал... когда доходило до common blocks
;-)
Вы правы, конечно!
Разумеется, любой по-древнему хороший язык программирования должен уметь стрелять себе в ногу очередью из граблей ;-)) Более того, заложенная в фортран совместимость со старым кодом прямо требует, чтобы у программиста было такое право (в теории, наш код из 1956г все еще до сих пор обязан компилироваться и работать ;-)
Но на практике так уже никто не пишет сейчас. Вместо этого есть понятие модуля, где все переменные и структуры описываются один раз, и затем они по необходимости используются в разных местах (со стандартными в современных языках средствами ограничения видимости). Причем, оператор USE сразу оказался намного удобнее всяких includ-ов, так как он автоматически контролирует, чтобы блок включался (и компилировался) ровно один раз (привет, $IF DEFINED ;-). Одно только это обстоятельство было для многих фортранщиков достаточным аргументом сменить стиль, даже еще ничего не понимая в ООП. А еще сейчас принято методы работы с модульными данными тоже писать в тех же модулях. Фактически получаются те же объекты-классы, только с привычным для первобытных людей интерфейсом.
С учетом этого, теперь программисту на фортране необходимо достичь определенного уровня квалификации, чтобы прострелить именно свою ногу, а не ногу соседа ;-)
А вообще, язык, конечно стал заметно другим даже не в плане спецификаций, а скорее по стилю. Например, я знаю только фортран, и вроде бы знаю довольно неплохо. Но прочитать старую (из 1980-х гг) программу на фортране мне порой намного сложнее, чем аналогичную современную (=адекватно оформленную) программу на незнакомом мне (и весьма непростом!) С++. Просто потому, что тот старый фортран порой по читаемости напоминает Brainfuck. Уж не знаю, умышленно, или нет...
Я из своей фортрановской камеры иногда подглядываю в плюсовые статьи... Сейчас честно порадовался обычаям своего заповедника ;-) Все-таки, у нас с массивами
как-то попроще
Например, вот так будет для массивов с тремя измерениями (код можно легко обобщить на n-мерные массивы):
! Объявляем трехмерные "динамические" массивы:real, allocatable :: A(:,:,:), B(:,:,:)
! Выделяем память (с этого момента размер массивовinteger :: n = 42
(...)
! и диапазоны изменения индексов зафиксированы):
allocate (A(1:n, 4, 3), B(0:n-1,41:44,1:3))
! Передаем их в какую-нибудь процедуру:call myfunc(A,B)
.......................
.......................
! А это где-то внутри
myfunc(A,B):...
integer :: Ashape(3), Bshape(3),dShape(3)integer :: A_min_index(3), B_min_index(3)
Ashape=shape(A); Bshape=shape(B)
dShape=Ashape-Bshape
A_min_index=lbound(A); B_min_index=lbound(B)
! теперь вектора (массивы) Ashape и Bshape
! содержат размер массивов A и B
! по каждому измерению (т.е.[42,4,3]),
! dShape хранит различия в размерах массивов,
! а A_min_index и B_min_index хранят
! нижнюю границу каждого индекса
! Например, B_min_index=[0,41,1]
(...)
! поэлементное умножение:
if (maxval(abs(dShape)) == 0) A=B*13
! но только ЕСЛИ все три размера у массивов
! одинаковые (модули разностей = 0).
! Диапазоны индексов при этом могут не совпадать -
! главное, чтобы размерчики совпадали
...
Ну и отдельным бонусом есть ключ компилятора, который включает проверку, что массив B инициализирован, либо выключает ее (если программа хорошо отлажена и очень торопится, это ее немного ускорит). Кстати, если проверка выключена, а значения каких-то элементов в массиве B не присвоены, то с помощью
A=B*13у нас в фортране тоже можно добиться UB!UPD: а вот с форматированием кода я по-прежнему справиться не могу. Пробелы как глотались хаброредактором, так и глотаются. Причем в непредсказуемых местах и количестве. Да, у нас в фортране компилятор пробелы игнорит... но вообще-то мы их используем для форматирования и удобочитаемости кода.
Откройте на телефоне ваш комментарий и все спойлеры до конца. Последний прочитать уже нереально.
К сожалению, я не могу это проверить - у меня Нокия 1101. В цивилизации я всегда и везде работаю только с десктопа, в крайнем случае с ноута, а вне цивилизации надо не работать, а отдыхать ;-)
Но в любом случае спасибо за замечание - постараюсь в дальнейшем учесть.
Изгиб вперёд габариты рамы не меняет.
Да, для габаритов важен изгиб наружу.
Но и у изгиба вперед тоже есть недостатки. Во-первых, он сближает точки опоры (верхнюю и нижние), там вместо прямого угла из ЦМ к опорам будет острый). Вырастет усилие на опоры (и стойки) при вихлянии ЦТ вверх-вниз. Во-вторых, увеличивается рычаг, при вихляниях вправо-влево, т.к. ЦТ оказывается далеко сзади точек крепления. Конечно, все это можно компенсировать увеличением прочности разных деталей. Но глупо спорить, что конструкция, где этих проблем нет вообще, заведомо лучше, чем та, где их надо решать...
Из старого советского опыта - старые советские вообще не тормозят.
У меня нет стенда, чтобы изменить в цифрах, есть только возможность сравнить разные колодки визуально, раскрутив и остановив колесо. Такие тесты говорят, что современные колодки хуже. Возможно, у Вас другие колодки были. Ну или влияет конструкция тормоза, материал/состояние обода и т.д.
Зато умеют залипать при сильном торможении из-за деформации колодки.
Не сталкивался с таким. Вообще, у меня гораздо чаще были проблемы из-за недостаточного сцепления колеса с дорогой, чем колодок с ободом. Возможно, я недостаточно агрессивно катаюсь.
Что для вас "максимальный уклон"? На 45 градусах да, не прокатит.
Не надо утрировать до абсурда. Спуск на 45 градусах - это уже называется акробатика, а не путешествие. А спортивный поход - это про "просто ехать". Далеко, быстро, по плохим высокогорным дорогам, но именно ехать. А не триалить. Даже если такой участок вдруг встретился (скажем, дорогу размыло, или надо пересечь какой-то хребет), он вообще не засчитывается в сложность велосипедной части маршрута. И это не глюк, это сделано специально (если интересно - можем обсудить, почему).
Если же речь не о спорте, а про обычное велопутешествие (чем мы и занимаемся, в основном), то там тем более 99.9% времени - это дороги. Даже если маршрут идет по Памиру, Тянь-Шаню, Тибету, Алтаю, Кавказу и пр. Тут как с горным туризмом и скалолазанием: глядя издалека, дисциплины вроде похожие... но можно всю жизнь ходить в горные походы высоких категорий, и ни разу не встретить там именно скалолазный участок. Поэтому снаряжение для первого и второго, как бы это поточнее сказать, несколько отличается ;-)
На 15-20 вполне можно вызвать занос задней оси и боком затормозить. Проверено. Будет безопаснее, чем лететь кувырком
Я вообще-то сравнивал диски с VB на шоссе. То есть, речь шла про асфальтовые дороги. Там максимальный уклон 10 градусов. В моем случае "большой" уклон - это там, где велосипед самопроизвольно разгоняется, если не тормозить с заметным усилием. Вы сперва переставили меня в совершенно нетипичные для похода условия (которые в реальных путешествиях встречаются чуть реже, чем вообще никогда), а потом объясняете, что в этих условиях мои привычки неправильные.
Да, в походе бывают короткие куски камней, троп и т.п. Но затачивать под них наши велосипеды - это абсурд. Нам гораздо важнее, чтобы велосипед позволял комфортно проехать (с грузом) 100-150 км в день по нормальной дороге, чем адаптировать его под изредка встречающиеся экстремальности. Которые нам в любом случае придется идти пешком, и часто в две ходки (так как велосипед и рюкзак там обычно надо нести отдельно).
Нагрузка на задний тормоз в разы меньше, чем на передний. На спуске - разница ещё больше.
Не знаю, как это происходит в триале, но вот при стационарном спуске по шоссе оптимальный вариант наиболее эффективно превратить mgh в тепло - это когда нагрузка на оба тормоза одинаковая. Ничего личного, это физика. Если один из дисков нагрет не до максимума, то он отдаст меньше тепла, чем мог бы. Тут просто не о чем спорить.
Если же говорить о динамике, то, конечно, правильный стиль - это тормозить задним тормозом прежде всего. Так как занос заднего колеса часто можно парировать, а вот занос (блокировка) переднего - это почти гарантированное падение. Особенно на груженом веле. Вы, вероятно, пишете про мегауклоны, где ЦТ смещен вперед относительно базы велосипеда, и поэтому вес распределяется между колесами неравномерно? Тогда конечно, просто в силу ограничения коэффициента трения приходится тормозить передним колесом больше, чем задним. Но это совершенно другие задачи и стиль, чем в нашем, походном случае. Где все критерии оптимизации совершенно другие. Например, в походе сзади всегда едет рюкзак, причем его центр тяжести максимально приближен к оси заднего колеса (стандартное правило: самое тяжелое - в штанах снизу). И стационарная нагрузка на заднее колесо обычно заметно больше, чем на переднее. И даже на спуске они лишь выравниваются.
А еще после чтения Ваших постов люди, недавно севшие на велосипед, могут подумать, что тормозить передним тормозом - это правильно. И начнут летать через голову просто на городской улице. Благо, заблокировать колесо запросто можно не только диском, но и VB, и крабом.
В общем, не надо без нужды намекать на квантор всеобщности ;-)
Тем более, когда имеются совершенно очевидные контрпримеры. И особенно в том случае, когда речь изначально шла именно про такой контрпример ;-)
Тем, что выносить не надо. Там нужен лишь небольшой изгиб.
Ну вот Вы сами себе и ответили. Я имею в виду слово "изгиб".
А теперь расскажите, как изогнутая (и поэтому более длинная) стойка при одинаковом материале и весе может быть крепче и надежней прямой? При условии, что основная нагрузка приложена строго вдоль стойки. Даже не буду отсылать к сопромату, тут все очевидно, по-моему. Добавлю лишь один небольшой факт, что поломка багажника (даже если стойки нормальные, без изгибов) - это одна из наиболее типичных проблем с "железом" в
окологорных велопоходах
На первом месте, понятно, проколы, но это считай расходный материал. На втором, пожалуй, все-таки спицы-восьмерки. Но вот дальше точно багажники. Втулки-звездочки-переклюки и тормоза их по аварийности даже близко не догоняют...
Причем ее не так просто решить без существенного увеличения веса. Я уж не говорю, что такие изгибы ощутимо увеличивают вероятность проблем с багажником при транспортировке, падениях и т.п. А также габариты рамы по толщине (что в новом плацкарте весьма актуально...)
Про обод не готов ничего сказать без расчётов. Обдув там хуже
Вот тут не понял. Как у огромного, аэродинамически несовершенного обода обув может быть хуже, чем у диска?! Нам же важна суммарная теплоотдача. А обод, помимо прочего, еще и часть тепла рассеивает через спицы-резину.
да и контакт с нагревшейся от торможения резиной тоже непонятно как действует.
Ну почему непонятно - очень даже понятно, что плохо ;-)
Главный плюс в том, что это "плохо" полностью контролируемое. Более того, варьируя состав резины в колодках, можно оптимизировать те или иные параметры. Например, старые советские резиновые колодки (увы, не любые), обеспечивают на порядок лучшее сцепление с ободом, чем стандартные современные пластики. Но - и изнашиваются тоже на порядок быстрее (а то и на два). При перегреве - особенно.
Вопрос в том, что колодки на ободе я могу контролировать непрерывно (читай - на ходу), а вот на диске - не очень. И свобода выбора материала колодок в случае VB явно шире...
> Диск потрогать тоже можно :)
Что, на ходу!? Я восхищаюсь такими навыками, но сам пробовать не рискну ;-)
> Вряд-ли вы это на ходу делаете.
А, так все-таки значит диски - на остановке ;-)
Нет, температуру обода я вполне себе щупаю на ходу, причем на обоих колесах. Не в динамическом повороте, понятно, но слезать с вела для этого вовсе не обязательно. Передняя рука на бараньих рогах при спуске вообще в 20см от обода расположена. Ну а чтобы задний потрогать, надо чуть выпрямиться. Но у меня почему-то передний обод обычно греется больше...
> Даже если это случится - на обычной дороге можно затормозить просто ботинком об колесо.
Ну, так на "обычной дороге" такая проблема не актуальна вообще, если я правильно понимаю. У меня все описанное относится к перевалам с высотами от 2000 и перепадом под 1000, и с максимальным уклоном. Там ботинком не особо затормозишь... Уж лучше сгруппироваться и "лечь" аккуратно. Если впереди, разумеется, не крутой поворот над обрывом... :-(
> Ну и маловероятно, что сразу оба откажут
Вот именно это моего приятеля тогда и спасло. Но меня весьма напрягает, что наиболее оптимальный режим рассеивания тепла - это когда оба диска имеют примерно одинаковую температуру. А значит, что после отказа первого диска, когда нагрузка на второй возрастет, он может уже заранее быть очень близок к критическому состоянию.
На самом деле, даже в такой ситуации вероятность двойного отказа может быть сильно меньше, чем 100%. Но меня крайне пугает, что если это все же случится, последствия могут оказаться слишком фатальными...
Но я вообще велосипедист не типичный
старюсь ездить крайне осторожно и всех остальных в группе тоже к этому призываю. За довольно большую кучу многодневных походов (пара экваторов наберется) у нас серьезных ЧП почти не случалось. Хотя,
в самом начале
ездил с нами один товарищ, назовем его М. Замечательный парень, но слишком уж бесшабашный. Сперва на него на спуске в Крыму какая-то дикая бабушка бросилась. Она до последнего пряталась в подворотне, и выскочила, когда уже сделать ничего нельзя было.
А в другой раз мы ехали по крутой грунтовой тропинке к морю близ Идокопаса (это еще до всех тамошних строек было). Когда-то там тракторная дорога была, потом обвалилась частично, но полноценный метр между "стенкой" и "пропастью" нам оставили. Сперва вроде все хорошо было - нормально ехали. Потом дорога покруче стала, я притормозил малость. Кругом лес нависает, впереди - поворотик закрытый, может там вообще эту старую дорогу размыло. И вдруг смотрю - меня в куче пыли этот самый М. на всем ходу обгоняет. Хотя уговор твердый был, что я еду первый, а все за мной. Ну, руки-ноги мелькают, крики какие-то, в пыли ничего разобрать невозможно.... Я кое-как прижался к обочине, остановился, перевожу дух. И тут смотрю - меня на почти той же скорости велосипед этого самого М. обгоняет, уже как-то боком слегка...
Спасло, что до моря там уже совсем близко осталось. Говорят, в соленой воде переломы хорошо заживают. А может, и не было у него переломов - сам М. потом говорил, что только царапины. Кто ж его бесшабашного разберет. Вел его мы тоже привели быстро в чувство: в ремкомплекте запасной петух и запасной переклюк завалялись. А вот арбуз в его рюкзаке такого спуска не выдержал... Но это, впрочем, уже совсем другая история...
А касательно вибрейков - извините, но из МТБ они уже давно ушли и остались лишь на китайских поделиях (...)
Да, да, вот именно!! Больше того, Вы сейчас не первый мне эти слова говорите!! Так что спасибо Вам за погружение в мир добрых воспоминаний ;-))
А теперь самое интересное. Дело в том, что в прошлый раз я все это слышал почти дословно около 20 лет назад, причем сразу от целой кучи уважаемых и мудрых людей! Единственное отличие - Вы пишете про дивный мир дисковых тормозов, а передо мной в прошлый раз разворачивался дивный мир MTB $-)
Не поленюсь, расскажу эту историю.
Дело было в самом начале 2000-х, когда МТБ только завоевывали наш рынок. Тогда я катал на гибриде - очень сильно переделанном ХВЗ, где были устранены почти все "врожденные" недостатки, кроме разве что ограничения по резине. А все окружающие крутили у виска пальцем и называли это все мракобесием и скрытым умственным кретинизмом. Ибо я вложил в ХВЗ столько денег, что на них можно было купить не самый плохой MTB. (На котором я, кстати, тоже поездил, но через год отказался). В общем, я пытался пропагандировать совершенно дикую на тот момент точку зрения, что в спортивном походе гибрид с колесами 28" очень часто гораздо лучше, чем 26" MTB.
По общему убеждению тех времен, критика моих взглядов была безоговорочно справедлива и абсолютно убийственна. Отношение ко мне было примерно как к плоскоземельщику в начале 20 века. Когда все очные и интернет-магазины завалены МТБ, а их преимущества очевидны на каждом углу; когда открой любой сайт, и там тьма статей от крутых профи, которые по полочкам, до мелочей разъясняют тотальное превосходство МТБ в любом спортивном велопоходе. А я, мол, несу какую-то дичь на основании своего субъективного опыта, да еще здравым смыслом пытаюсь прикрыться. Кончилось тем что для очередного сложного похода (где я шел участником) руководитель специально для меня нашел высококачественный 26" МТБ, чтобы только я туда на своем 28" гибриде не поехал. Как я на нем мучился - надо отдельный рассказ написать, хотя велосипед мне подогнали совсем неплохой. В итоге на фоне нескольких сходов в команде я даже проехал тот маршрут до конца и, надеюсь, был там не пассажиром.
Только вот прошло много лет... и оказалось, что маятник золотую середину тогда перелетел очень сильно. Профессионалы, которые писали те статьи, оказались профессионалами в чем-то еще (возможно, в продажах?), но вовсе не в велотуризме. Начиная с 2015 примерно года, целая куча спортивных групп стала ходить сложные велопомаршруты именно на 28" гибридах. Так как их преимущества очень даже весомы при определенных условиях. (Что вовсе не отменяет достоинства MTB, просто они оказались и близко не такими универсальными в спортивном велотуризме, как сначала казалось).
Кстати, наша команда, где почти у всех есть два байка, в свой наиболее крутой поход по Памиру поехала именно на 28" гибридах. Просто потому, что у нас 1) был опыт использования и того, и другого, и 2) было умение правильно готовить не-MTB для похода. Лишь один парень, с очень сильной физподготовкой, но наименьшим из всех велоопытом, поехал на 26". И субъективно ему почти везде было намного тяжелее, чем девушкам на гибридах. Между прочим, по результатам того велопохода мы стали чемпионами РФ по спортивному велотуризму.
Короче, не надо путать тренды и моду, и объективную реальность, которая очень часто намного сложнее простой, распиаренной и наглядной картинки. Я вообще убежден, что за исключением компьютерных и близких к ним технологий (телекоммуникации и т.п.), крайне редко бывает так, что новая техника абсолютно по всем параметрам лучше, чем предыдущая. Наоборот, очень часто на три новые очень полезные фичи, которые дают явный выигрыш, приходится один баг, где проигрыш настолько же очевиден (в определенных условиях). Просто эти фичи и баг идут в неразрывном комплекте, и невозможно выбрать одно, не выбирая другое...
Как бы и индустрия развивается с технологиями, и качество торможения гораздо лучше в условиях специфики мтб, и надёжность выше.
Вот Вы сами себе и ответили: "в условиях специфики мтб". Но я-то пишу про велопоходы. И там есть своя специфика. Например, более высокая надежность резко теряет в ценности, если она ухудшает ремонтопригодность "в поле". Хотя есть тьма ситуаций, когда все
ровно наоборот
Например, на обычных соревнованиях 1% выигрыша в надежности гораздо полезнее двухкратного проигрыша в ремонтопригодности
А про конкретные плюсы и минусы диска vs VB c моей точки зрения я подробно написал тут же рядом вот в этом комменте. Это не значит, что Вы должны со мной согласиться. Но я надеюсь на понимание, что альтернативная точка зрения возникла не на совсем пустом месте, и что при некоторых условиях в ней тоже могут присутствовать рациональные зерна.
Так а что за бонки-то? На фото их не видно совсем. Если это "горизорнтальный" вынос от рамы за диск, то я как раз именно их "болтами" и обозвал, для наглядности. Именно они и ломаются в сложном походе со стопроцентной гарантией. Если не в первом, то в следующем.
Я не уверен про овчарок, - что они все поголовно наиболее смышленые из всех. Да, конечно, есть явно туповатые породы и есть "более продвинутые". Но среди "умных" пород имхо гораздо больше зависит от индивидуальных особенностей конкретной собаки. Как он (она) развивался, что получил (именно поведенчески-интеллектуально) от родителей, с какого возраста среди людей, и как они общались с ним и друг с другом и т.д.
Что касается Весты, то, говоря научным языком, это метис. Без четких преобладающих признаков какой-то породы. В детстве она была бездомной, потом она приглянулась характером кому-то из наших турклубовцев, ее взяли в клуб и стали активно искать хозяев. После недели жизни в клубе (когда ее кормили и гуляли по очереди) она стала нашей.