All streams
Search
Write a publication
Pull to refresh
189
0

Expert C++ Engineer

Send message
А тут вопрос и не в «уме». Вопрос в двух препятствиях, причем оба сделаны искусственно и часто вызывают критику:

1. Сравнительно длительный процесс установки приложений «не из официального магазина»
2. Относительно долгий и сложный поиск пираченного софта

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

Это мы все говорим о софте, общая стоимость которого редко превышает 10$/мес. А скажем музыку и фильмы, стоящие значительно дороже, на планшет уже большинство не покупает. И чем выше стоимость товара, тем на большие неудобства готов пойти пользователь, чтобы воспользоваться «пираткой».
Стругацкие — это и КОМКОН-2 и ОЗ. Это не только Понедельник, но и Тройка и Пикник. Вообще, АБС — очень сложная и умная фантастика, и она имеет ну очень отдаленное отношение к тому что написано выше.

Разумное, доброе, светлое можно делать и без розовых очков. И более того, конечный результат будет лучше.
АЭС создают соответствующие амортизационные фонды, при строительстве их естественно учитывают, хотя оценка стоимости выведения АЭС из эксплуатации (включая утилизацию скопившихся на ней отходов), конечно, может быть ошибочной

Вопрос с утилизацией топлива, в общем-то, давным-давно решен. Его просто хоронят в специальных хранилищах. Существует чисто политический протест против строительства этих хранилищ но технологически — проблем нет. Есть и уже построенные и вполне себе работающие хранилища, например WIPP в США или VLJ в Финляндии. Стоит не особо дорого, особенно если начать строить подобные объекты не поштучно а достаточно массово.
Преимущества аккумуляторов тепла в том что они хорошо сочетаются с солнечными станциями, у ГАЭС КПД ниже а стоимость гораздо выше.
Преимущества и новаторство конкретно этой станции — в том что настолько крупных тепловых аккумуляторов, тем более с расплавленной солью еще никто не строил
>> о есть чтобы все атомные электростанции перевести на солнечные типа этой нужно 400/300*8 ~= 10 тыс кв километров

Вдвое-втрое больше на самом деле. 280 МВт — это пиковая мощность, в среднем выработка солнечной станции будет гораздо ниже

Но на Земле очень много пустынь, так что это возражение на самом деле нерелевантно. Гораздо актуальнее то что стоимость строительства и эксплуатации солнечных станций с текущими технологиями (и весьма вероятно с будущими тоже) неприемлемо высока.
Разница есть, если нужно сложить не два операнда, а, к примеру, тысячу. Если начать суммирование с больших чисел, то каждый раз к сумме будет прибавляться большая же погрешность и за тысячу операций общая погрешность набежит уже вполне себе серьезная по сравнению с самой суммой. Начиная суммирование с малых чисел сложение погрешностей начинается тоже с маленьких чисел и суммарная погрешность набегает уже вполне вменяемой.

Что до решения «грубой силой», то оно как правило работает неприемлемо медленно. Все же о вычислительных алгоритмах говорим (где еще нужно тысячи чисел суммировать?). Да и проблему Вы точно так же не решаете, если я её минимизирую, то Вы её просто задвигаете поглубже. И, что интересно, в реальной жизни подобный подход с задвиганием как раз на удивление часто не срабатывает. Даже в примитивной задаче обращения матриц если Вы возьмете «лобовой» подход, то там получается что с float-ами и не очень хорошими исходными данными он «ломается», скажем, на размерности 300, а с double-ами… на размерности 2000. А замена алгоритма на другой, который делает то же самое обращение, но использует другой порядок операций дает метод, который работает до 200.000 на double.
Еще это свойство применяется, если результат вычислений может быть не определен в определенных условиях. Например:

// count - число элементов, sum - их сумма
bool average_more_than_one = (count > 0) && (float(sum)/count > 1.f);
Не совсем хорошее представление. Эпсилон в Ваших формулах есть некая константа, тогда как в реальности эпсилон зависит от числа. Чем число больше — тем больше погрешность его представления.

Из этой особенности вытекает ряд важных практических следствий. В частности отсюда следует что очень плохой идеей является сложение float-ов с сильно разными значениями. То есть 1+1 — нормально, а 1+100000000 — плохо, погрешность сопоставима с прибавляемой величиной вплоть до того что получаем X+1==X. Это регулярно вызывает проблемы в такой простой казалось бы задаче как суммирование массива чисел — там надо либо все к более длинному типу приводить (скажем double для суммирования float), либо сортировать массив перед его суммированием, так чтобы мелкие числа суммировались бы первыми.

Зато с другой стороны, перемножение float-ов не вызывает никаких проблем :). Точность там получается как раз соответствующей результату умножения. Для обычных погрешностей это не так, там умножение тоже увеличивает погрешность.
И более того, это действительно зачастую (в математическом коде) удобно, так же как удобен определенный этим же стандартом NAN. Авторы IEEE 754 хорошо знали, что делали. Но к сожалению пользоваться этими свойствами на практике проблематично из-за очень плохой поддержки этого поведения компиляторами да и новым железом тоже.
Да, с определением частоты все именно так.

С амплитудой колебаний присутствующих лишь в половине сигнала — в первом приближении да. Однако там еще будет «размытие» колебания по соседним частотам.

«Кроме Фурье» колебания можно определять через частотные фильтры. Представим себе фильтр, который синусоидальный сигнал определенной частоты пропускает, а все остальные сигналы — подавляет. Тогда наличие в сигнале данной частоты можно определить по наличию синусоиды на выходе подобного фильтра при подаче на него сигнала.

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

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

Спектрограммы действительно рисуют, порезав сигнал на кусочки и разлагая каждый кусочек отдельно (полагая функцию вне взятого кусочка равной нулю). При этом, как я писал выше, происходит «спектральная утечка» — чем «тоньше» нарезка, тем сильнее спектр, скажем, синусоиды, расплывается по частотам. Из-за этой утечки точно восстановить исходный сигнал по конечному отрезку этого сигнала без дополнительной информации невозможно (хотя приближенно, с довольно хорошей точностью, — можно).
Растиражировать можно, но зачем? Это уже получится другая функция, причем скорее всего разрывная (концы отдельных отрезков не идеально стыковаться будут)
А произвольную функцию и нельзя представить суммой синусоид. Довольно часто непрерывное преобразование Фурье пытаются интерпретировать именно подобным образом, но эта интерпретация неверна.

Вот периодический сигнал разложить в сумму синусоид можно. Дискретный сигнал (последовательность чисел) тоже в определенном смысле можно.
Я начинал с неизвестного самосборного компьютера, собранного отцом (радиоинженером). В качестве накопителя выступал бытовой магнитофон (использовавшийся и по прямому назначению), дисплеем небольшой кинескоп (возможно это когда-то был телевизор, но в этой роли он уже не работал), а «системник» был собран на живую нитку даже не знаю из чего. Штатной печатной платы не было, так все было аккуратно собрано на монтажной плате с колоссальным количеством распаянных проводков сзади.

Что за система была — до сих пор не знаю. В качестве ОС смутно вспоминается почему-то BASIC, причем кнопкам на клавиатуре соответствовали отдельные команды (нажал на кнопку — на экране появилась команда LOAD — ввод — включаем магнитофон, слушаем программу, работает!). Мне лет семь тогда наверное было, но проблем с подобным интерфейсом не возникало :). Чуть позже, наигравшись в игры, пробовал вводить программы из книжечки по BASIC-у с примерами. Работало не все (программа которая должна была рисовать развевающийся флаг почему-то не работала, до сих пор помню), но что-то получалось и позднее творчески перерабатывалось, скажем, в программку которая рисовала на экране кучу кругов или график. А еще интересно было баловаться со знакогенератором. Уже не помню как и где я этому научился, но его можно было перепрограммировать например на «конструктор» и «собирать» на экране дома в псевдографике, вводя символы с клавиатуры. А еще компьютер постоянно «сбрасывался» от статического электричества, из-за чего вокруг него ходили на цыпочках и перед тем как за него сесть хватались за батарею и снимали слишком электризующуюся одежду. Забавное было время ).

Ну а потом уже сразу был 386 и DOS. Там были интереснее игры, но компьютер считался очень дорогим приобретением и я его слегка поначалу побаивался. Когда он в первый раз «завис» — это была целая катастрофа :)

В школе тоже еще были советские компьютеры, но там все ограничивалось набором предустановленных развивающих программ типа «переливашки» или «ханойских пирамид».
О, спасибо за важное уточнение! Мнимая единичка действительно при переписывании потерялась. Поправлено.
Согласен, спасибо за замечание. Попробую подправить позднее
Спасибо за конструктивную критику!

1,3. Согласен. Я привык f обозначать функцию и стремился избежать путаницы, но действительно стоило упомянуть об этой детали и использовать более широко распространенные обозначения

2. Не согласен. Как раз наоборот, для амплитуды нужно умножать на 10, а для мощности — на 20. В первом случае — потому что ДЕЦИбелл, а во втором — потому что мощность есть квадрат амплитуды, а логарифм квадрата есть удвоенный логарифм

4,5,6. Исправлено

7. Не согласен, поскольку, во-первых, в большинстве современных ЦАПов (сигма-дельта) вообще всего 2 цифровых уровня сигнала на «цифровом» выходе, а во-вторых, при подобном подходе у ЦАПа получаются сильно субоптимальные характеристики. Так Кучумов в данном случае переупрощает.
Спасибо за комплимент :). С замечанием про утечку согласен, я просто исходил из предположения что статью будет читать более-менее обычный человек, который будет пытаться «находить» или «измерять» определенные частоты в исходном сигнале, предполагая их аналогичными по смыслу частотам синусоидальных сигналов. На Хабре было несколько статьей подобного плана, описывающих эксперименты с Фурье и Matlab-ом и я попробовал отталкиваться от примерно схожей схемы мышления. Но вышло похоже действительно переупрощенно, так что я постарался подправить текст чтобы сделать его более корректным.
С вейвлетами я знаком гораздо хуже :), но тема действительно интересная, так что если я со временем наберусь сил в ней основательно разобраться, то такую статью безусловно напишу. Но едва ли в ближайший месяц-два, к сожалению.
Я попробую дописать еще одну-две статьи на смежные темы. Правильно ли я понял, что основные затруднения были связаны со сверткой и дельта-функцией Дирака? Я напишу тогда одну небольшую статью про эту замечательную парочку и еще одну статью о том, как их используют при интерполяции и фильтрации сигналов и изображений

Information

Rating
Does not participate
Location
Россия
Registered
Activity

Specialization

Software Developer
Lead
From 600,000 ₽
C++
Qt
Algorithms and data structures
Multiple thread
Applied math
Computer vision
Python
Research work
CAD
English