Pull to refresh
83
0.9
Алексей @adeshere

Чукча не читатель! И не писатель. Чукча СЧИтатель

Send message
Интересно, а насколько развит рынок таких батареек сейчас? И каков предполагаемый объем рынка в перспективе? Просто довольно распространенная реакция при чтении этой статьи — а можно ли ее (батарейку) поставить в часы, ну или в датчик охранной системы на даче. А меня такая перспектива бытового использования скорее пугает. Традиционный РИТЭГ — это довольно здоровая бандура, и их выпущено не так много пока что (сотни). Поэтому их использование удается более-менее контролировать, включая утилизацию после вывода из эксплуатации. Миниатюризация технологии приведет к тому, что счет таких батареек может пойти на сотни тысяч. Стоит ли пускать такие изделия в широкий оборот, заранее зная, что они в конце концов окажутся неизвестно где?
Ведь людям, к сожалению, свойственно раздолбайство. Гуляя по пригородному лесу, сплошь и рядом видишь там кучи мусора разного возраста, и не только бытового. Причем по какой-то недоступной для меня логике каждый следующий грузовик/трактор вываливает свой груз не на уже лежащую кучу, а всегда в новое место. Целые опушки прямо на глазах превращаются в импровизированные свалки. Было бы очень наивно надеяться, что в такой куче корпус изотопной батарейки всегда останется целым…
Это ведь только кажется, что такая груда мусора так и останется навсегда на своем месте. И для личной безопасности достаточно обходить ее стороной. У нас есть спортивная карта, которую я корректирую уже больше 20 лет, и хорошо вижу, как такие мусорные горы постепенно съезжают в овраг и разносятся весенней водой, или оседают из-за гниения, а потом распахиваются при корчевке заросшего поля и пр. Очень бы не хотелось, чтобы источники излучения, даже мягкого бета, неконтролируемо расползались… Учитывая, что найти их потом, учитывая длину свободного пробега электронов в воздухе, будет очень проблематично. А шанс получить какие-то фрагменты измельченной конструкции внутрь организма (например, плохо почистив собранные грибы или картошку) в случае массового загрязнения становится заметно не нулевым…
Совсем недавно мысль о негативных последствиях массового производства плохо разлагающейся пластиковой упаковки вообще никому в голову не приходила. А сейчас этим мусором полмира завалено. Хорошо хоть, что он не очень токсичный (в отличие от тех же химических батареек, к примеру), и ущерб от него в основном эстетический.
Не создадим ли мы себе еще одну искусственную проблему, если миниатюрные изотопные батарейки серьезно подешевеют и их начнут массово пользовать не только в космосе, но и во всяких наземных делах? Те же военные, нефтяники/газовики, геологоразведка и пр. уже сейчас не особо стеснены в средствах и наверняка заинтересуются этой технологией (а как они заботятся об окружающей среде, если речь не идет о пиар-проектах, известно). А потом все это и вовсе может войти в каждый дом. Конечно, нам сейчас может показаться сюрреализмом тот дивный мир, в котором дозиметр станет таким же бытовым атрибутом, как ныне мобильник, банковская карточка или транспортный проездной. Но совсем недавно нам и эти три вещи казались абсолютной фантастикой…
Вдогонку: пока мой комментарий висел на модерации, автор уже поправил цвет графиков. К сожалению, я уже не могу удалить этот абзац в своем комменте. Могу только извиниться, что так получилось :-((
К сожалению, я тут недавно и не имею возможности поставить плюсик. По
этому могу только поблагодарить ее автора, а заодно подчеркнуть своим «развернутым плюсиком» вот эту фразу:
Статья — статистическое, а не социологическое исследование. И она отлично демонстрирует, что утверждение о том, что черный преступник имеет больше шансов быть застреленным — ложь (а это — как раз то, во что пытаются заставить всех поверить активисты BLM).

К сожалению, одна из основных проблем современности — это игнорирование фактов. Иногда — от незнания, но часто умышленно. И это самое страшное.

Вообще, математика — лукавая штука. Как известно, в математике никакое число положительных примеров не доказывает утверждение, но единственный контрпример его однозначно опровергает (общеизвестно: «все нечетные числа — простые»). Но в быту все не так. Многократно опровергнутые контрпримером «теории» могут в действительности быть очень полезными. Так, я могу многократно ходить на березовые опушки и ничего там не находить, но от этого утверждение «на березовых опушках много белых грибов» не становится ложным, так как иногда их там действительно очень много. Гораздо больше, чем рядом в ельнике или в болотистом чернолесье. Ведь обычный человек не видит особой разницы между формулировками «на березовых опушках всегда много белых грибов» и «на березовых опушках иногда можно найти очень много белых грибов».
Именно из-за этого мы на бытовом уровне очень часто склонны игнорировать реальные факты. Нам просто кажется, что это не факт, а тот самый бытовой «контрпример» (пошел на опушку — ничего не нашел), который ничего не опровергает. Для грибника важнее другое: если сто раз сходить в лес, на опушке наберешь больше. Именно отсюда растут ноги известной шутки о «женском» споре, в котором истиной признается то утверждение, которое сказано чаще и громче (простите, девушки ;-).

Но вернемся к «нашим баранам».
Автор статьи провел достаточно аккуратный анализ, обобщил все доступные данные и вполне достоверно показал, что процитированное выше утверждение — ложь. Ну или иллюзия, если для кого-то такая формулировка более приемлема. Она противоречит эмпирическим фактам.

Как немного знакомый с математикой человек, я вполне понимаю, что этот анализ эквивалентен тому, чтобы сто раз сходить за грибами, и вывести матожидание результата для разных сценариев поиска. Лично для меня отсюда следует однозначный вывод: любое рассуждение, опирающееся на ложную посылку — бессодержательно. Оно не может ничего ни доказывать, ни опровергать. Вполне возможно, что BLM правы в своих утверждениях. Но после того, как некоторый эмпирический факт (точнее, эмпирическое обобщение) установлен, — пожалуйста, будьте добры учитывать его в своих рассуждениях и теориях. Иначе они гроша выеденного не стоят (простите за грубоватый жаргон).

Но к сожалению, большинство нормальных людей не вникают в такие тонкости. Они не видят разницы между статистически доказанным утверждением, и обычным одноразовым фактом. Именно поэтому они продолжают его игнорировать без малейших сомнений в своей правоте.

Именно в этом состоит одна из важнейших проблем современного мира: даже при принятии серьезных решений человечество все чаще исходит из иллюзий и мифов, а вовсе не фактов. И далеко не только в вопросе о BLM.

И я очень боюсь, что это не аномалия, а, увы, неизбежность. Ведь из-за углубляющейся специализации любой человек просто не может быть специалистом во всем. Выходя за пределы своих компетенций, я неизбежно вынужден доверяться мнению окружающих. Конечно, я очень хочу надеяться, что доверяюсь специалистам. Однако по факту мне почти неоткуда черпать подобную информацию, кроме как из виртуальных публичных пространств. А там, увы, правит бал именно массовость. И все чаще, как в женском споре, побеждает то утверждение, «которого больше». В силу объективных законов распространения информации, оно просто захватывает всю «экосистему» — точно так же, как первый появившийся штамм оккупирует чашку Петри, даже если у конкурентов были существенные эволюционные преимущества. Впрочем, на этом форуме вряд ли нужно приводить такие примеры — история развития компьютерных технологий перед глазами.

Что со всем этим делать — не знаю. Возможно, мы не наблюдаем во Вселенной сверхцивилизаций именно потому, что в определенный момент их развитие прекращается, если они, как и мы, начинают руководствоваться публичными мифами, а не фактами?

P.S. Извините, если я немного отклонился от темы статьи. Наболело :-(((

P.P.S. А автору, кроме огромного плюса, еще и крохотный щелчок по носу: на разных графиках один и тот же цвет обозначает то белых, то черных. Если бы это можно было поправить, то работа с материалом станет заметно удобнее для читателя…
Подскажите, пожалуйста, почему у меня может не работать ссылка:
«Итак, встречайте Tempus!»

Комп обычный, другие сайты работают… В каких настройках мне надо порыться?

Я лет 25 назад сделал свою библиотеку для работы с календарными интервалами для научных расчетов (она до сих пор используется). Но — на фортране. Одно время было желание как-то превратить этот проект в Open Source, но недостаток мозгов и отсутствие вменяемого английского не позволили сделать даже первый шаг в эту сторону :-((( А сейчас уже и смысла нет, очевидно.
Но посмотреть функционал Вашей библиотеки хочется. Хотя бы для того, чтобы добавить в свой пакет что-то полезное.
На каждом ходе игрока у нас есть выбор из максимум 38 возможных допустимых ходов,
Прошу прощения за вопрос, который к теме статьи не относится напрямую, но у Вас, кажется, тут какая-то опечатка. Максимум намного больше 38. Например, пусть все белые и черные фигуры стоят в начальной позиции, а все пешки съедены. Тогда у ладей есть 2*7=14 ходов, у ферзя 7+3+4=14, у слонов 2*(2+5)=14, у коней 2*3=6, и 2 хода у короля. Итого уже 50 возможных ходов! А ведь вдобавок к этому наши пешки могли остаться на полях, где они не мешают другим ходам (b4, b6, b7 и т.д.) Так что 38 — это не максимальное число ходов, а какое-то другое. Но какое? Возможно, речь шла о среднем количестве доступных ходов в течение партии? Но тогда, как мне кажется, 38 — слегка многовато. Ведь дебюте многие линии перекрываются пешками и чужими фигурами, и доступных ходов меньше. А в эндшпиле (который бывает длинным) фигур обычно мало и доступных ходов тоже…
Ну во-первых, человечество действительно деградирует ;-)
Например, в моей молодости фортран очень медленно работал со строками или с посимвольным выводом на экран (а нам хотелось интерфейс типа Norton Commander-а). Так у нас тогда было нормой некоторые функции на ассемблере переписать. И это практически каждый фортранист в какой-то степени мог. А сейчас вставки на ассемблере хорошо, если каждый сотый напишет. Вот и я уже давно не пишу.
Впрочем, возможно я зря обобщаю на все человечество, и деградация только лично у меня происходит ;-))

Но вообще, когда констант много, то просто для удобства чтения кода гораздо лучше числа писать с разделителями. Чтобы хотя бы в этом месте не терпеть и не напрягаться. В фортране это всегда было доступно (а для кого-то и нормой). Сейчас общая тенденция — чтобы всякие подобные мелкие удобства были доступны в любом языке. Чего в этом плохого? Тем более, что синтаксис в разных языках почти единообразный и даже новичку в языке такая запись понятна?
Ну а не если хочется — так никто не заставляет, можно и не использовать.
Само собой, в коде надо писать мнемонику, а не цифру. Но при инициализации этой константы все равно приходится цифры расписывать. То есть, вопрос о разделителях внутри числа не снимается, а только отодвигается в специальное место…
protected const YEAR_SECONDS = 60 * 60 * 24 * 365;

Все верно… ну а если год високосный? А астрономы и вовсе верят, что средний тропический год — это 31 556 925 с… Так что простое умножение не всегда спасает. Иногда приходится и константы писать…
Впрочем, с астрономами вообще лучше не связываться, у них даже сутки не всегда равны 60*60*24=86 400 с, т.к. Земля не совсем равномерно вращается ;-)
Также, пишут, что FORTRAN до версии 77 года вел себя аналогично.

Возможно, я не совсем понял текст по ссылке, но мне непонятно, откуда там взялась цифра Ф-77? Насколько я знаю, по умолчанию фортран до сих пор игнорирует пробелы. Проверил сейчас в компиляторе 2013г (стандарт языка Fortran 2008). И в нем две эти формы записи эквивалентны:
integer :: int_var = 1000000
и
integer :: i nt_v ar = 1 000 000

Возможно, в новых компиляторах есть ключи, позволяющие ограничить такие вольности, но с ходу я что-то ничего не нашел…

А символ подчеркивания в фортране используется, чтобы указать разрядность константы в байтах, например:
13_2! 16-битное целое
-1_8! 64-битное целое

Ну и с системами исчисления все стандартно и лаконично:

int_var=36#3z! присваивает int_var значение 143

Буквы A..Z обозначают цифры от 10 до 35 (соответственно основание может быть не более 36). Ну и упрощенная запись для наиболее частых случаев:

i=B'011'; j='010'B! присваивает i=3, j=2
i=O'011'; j='010'O! присваивает i=9, j=8
i=X'011'; j='010'X; k=Z'0A'! присваивает i=17, j=16, k=15

Даже не знаю, считать ли такую вариативность записи достоинством языка или его недостатком… Если речь идет о клавиатурных комбинациях-синонимах, то вроде бы мы их обычно приветствуем: хочешь, жми Ctrl+C, а хочешь — Ctrl+Ins. А в коде?
К сожалению, я здесь могу только спрашивать, а не отвечать, так как являюсь типичным динозавром, давно закостеневшим в развитии, и не вымершим вовремя только в силу какого-то недоразумения. Поэтому мой взгляд на этот вопрос совершенно односторонний…
Если подробно, то мы уже 30 лет пилим очень узконишевую программу для научных исследований, причем основная часть сделана на фортране, а интерфейс — на плюсах. Я сам программирую только на фортране, за плюсы отвечает другой человек (и его код я понимаю ровно настолько, чтобы вносить туда совершенно косметические изменения вроде исправления опечаток в комментах ;-)).
Но что касается именно перемалывания чисел, то у фортрана это получается очень даже неплохо. Второй важный нюанс — весь фортрановский код, написанный нами лет 20 назад, до сих пор не только работает, но и при необходимости модифицируется с расширением функционала, и это не требует сверхусилий. Хотя наверно это зависит не только от языка… но для данного конкретного применения фортран вполне адекватен.
C++ гораздо удобнее (нам)

Если можно, было бы интересно узнать — по каким критериям удобнее?
Я не уверен, что это самое удобное. Кроме того, мне нужно понять, как жить дальше именно c C++ :)

В статье был намек на соседей… это просто пример. Причем из языка, который достаточно широко используется для моделирования, и по эффективности мало кому уступает. Что позволяет писать вычислительную часть на фортране и цеплять эти функции к проектам на других языках. Но у С++ эффективность сравнима с фортраном (если сравнивать хорошие компиляторы), поэтому переписывать уже имеющийся проект смысла нет, разумеется. Особенно с учетом отсутствия разработчиков, владеющих этим хорошим, но очень уж узконишевым языком…
А вопрос удобства всегда имеет субъективный оттенок, естественно. Но массивы и их сечения в современном фортране действительно очень мощные. А элементы ООП, которые в него тоже недавно (лет 20 назад) добавили, позволяют делать большие проекты с хорошо читаемым кодом. Если, конечно, там нет унаследованных из древности простыней на фортране-66 с вычисляемыми GOTO и прочими подобными ужасами ;-). Которые хотя и признаны устаревшими (и категорически не рекомендуются к использованию), но до сих пор поддерживаются компиляторами «для совместимости»…
Мне одному кажется, что если значения можно разместить в массивах, то самое удобное оформление вложенных циклов реализовано в фортране? Например:

real a(10,10,10), b(10,10,10), c(5)
integer i,j,k
forall (i=1:10, j=2:10:2, k=6:8, b(i,j,k) /= 0)
a(i,j,k) = 3 * i / b(i,j,k) + c(j/2)
end forall
12 ...
29

Information

Rating
1,568-th
Location
Пущино, Москва и Московская обл., Россия
Registered
Activity