Простите, или я не понял, или вы не раскрыли мысль из начала статьи — "для воспроизведения 16 битных записей начали применять 18 и даже 20 битные цифро-аналоговые преобразователи". Зачем повышать разрядность ЦАП, если передискретизация позволяет, напротив, обойтись меньшей разрядностью (вплоть до "однобитных" дельта-сигма, которые тут уже упоминали)?
Или маркетинг в том, что взяли 16-битный ЦАП на 176 кГц и стали продавать, как 18-битный?
Меня лет пять-восемь назад динамика изменений Сбера (с точки зрения клиента) тоже радовала. К сожалению, в последние несколько лет пошёл регресс: терминалы ухудшили (штрих-код не принимают + раньше хотя бы можно было сдачу распределять по другим платежам — это, конечно, приводило к забавным вещам типа того, что если тебе надо оплатить два счёта по 700р, а у тебя есть купюры 500 и 1000 — то надо вначале вставлять 500, иначе сможешь оплатить только один) и другие проблемы (тут я говорю только про проблемы ПО).
Я понимаю, что те, кто занимаются Data Science, за это не в ответе (и вообще то, как себя ведут терминалы, определяется скорее «эффективными менеджерами»), но, надеюсь, у вас есть хоть какие-то связи с другими ИТ-шниками банка, и вместе вы сможете добиться разрешения хоть что-то улучшить.
А ещё надеюсь, что те, кто _молча_ гадил в карму — не ограничатся этим и постараются мне доказать, что всё не так плохо и IT-шники Сбербанка действительно могут сделать его лучше. Всего-то надо — протолкнуть несколько улучшений в терминалы, да и интернет-банк тоже не идеален ;-). Если будут хоть какие-то улучшений — готов лично поблагодарить каждого минусовавшего :-D
Куда сбербанку в data science лезть, если они терминалы для приёма денег нормально сделать не могут? (не умеет давать сдачу — ну, допустим, это техническое ограничение; не умеет объединять несколько платежей, чтобы оплатить одной купюрой — безумие; считывание штрих-кодов с квитанций отключили, а qr-кодов так и не сделали — безумие в квадрате; регулярно не может провести платёж по квитанции, по которой раньше мог)
В общем, держались бы подальше от сложной техники, у них всё равно плохо получается.
В первую очередь потому, что одна из классических рекомендаций для увеличения скорости чтения — стараться не водить глазами по строке, а схватывать её целиком.
Т.е. палец будет не увеличивать скорость, а ограничивать её.
Угу (насчёт матрицы я писал по памяти и поленился проверить)
Единственное — из-за длинной арифметики там вроде не O(log(n)), а поболее получалось (но и алгоритмы «в лоб» тоже были не O(n)).
Напомнило старую историю, как схлестнулись адепты ассемблера с адептами оптимизирующих компиляторов. И решили посоревноваться. В качестве задачи взяли вычисление миллионного, кажется, числа Фибоначчи (а может, миллиардного — не суть, в любом случае нужна длинная арифметика, а работы с памятью немного).
И тут пришёл какой-то чувак, написавший решение не через суммирование F[n+1] = F[n]+F[n-1], а через возведение матрицы ((1,1),(0,1)) в степень. Чуть ли не на бейсике. И, соответственно, порвавший всех.
К сожалению, проблема — не дрожание телефона относительно Земли, а дрожание телефона относительно глаз. Т.е. стабилизировать изображение на экране — мало, надо стабилизировать движение головы. Как это можно сделать — лично мне непонятно, единственная идея — фронтальной камерой ловить положение глаз (что-то не соображу, даст ли это достаточно информации).
Но к подходу поставленной задачки вы подошли серьёзно, приятно было посмотреть =)
«Более плавно» оно двигается только относительно экрана. Относительно глаз — рывками (ВЧ-составляющие движения не убираются из-за недостаточного быстродействия).
Ну и да, даже если бы удалось сделать идеально (скажем, датчик движения -> аппаратная обработка -> аппаратное смещение изображения на экране), и, допустим, сам экран достаточно быстродействующий — всё равно получили бы две проблемы:
1. Двигающаяся в поле зрения рамка экрана (и держащая её рука)
2. Голову-то при тряске тоже мотает! Т.е. как ни стабилизируй — картинка в поле зрения будет дёргаться. Привязываться надо к глазам, для этого крепить что-то на голову — что естественным образом приводит к идее очков.
18650 — типоразмер, в котором есть и стандартные LiIon, и LiFePO4 (с меньшей ёмкостью, но более безопасные, трудноубиваемые и морозоустойчивые). Не знаю, что задействовано в Tesla.
Есть серьёзный довод против изучения JS в качестве первого языка: он устроен не так, как кажется на первый взгляд (и не так, как большинство других языков).
Да, он устроен просто — но prototype-based наследование легко понять, когда у тебя уже есть изрядный опыт, а в начале обучения это может сломать мозг. То же — насчёт областей видимости и замыканий в JS.
По мне, так лучше бы начинать с какого-то языка, где всё устроено именно так, как кажется на первый взгляд. Правда, в голову приходит только покойный Паскаль…
Насчёт данных по чекам — как минимум при распознавании штрих-кода издаётся характерный звук, не относящийся к персональным данным, но позволяющий отследить «скорость покупок» (в первом приближении — серия пиков с не очень большим интервалом на покупки одного покупателя, потом, кажется, характерный звук открытия кассы и пауза, потом серия пиков для следующего покупателя и так далее). Таким образом, на кассе можно малой кровью отследить не только очередь, но и скорость работы кассы.
А правило «практически любое существительное в английском можно использовать как глагол» тут не срабатывает?
Т.е. слитное написание вместо раздельного совсем недопустимо или просто получается некий жаргонизм?
А за процессами следили? (загрузка проца, трафик). Чтобы на радиомодуль уходило больше 250 mA — он должен активно качать данные. Иначе типовой смартфон садился бы за день просто от лежания в кармане (аккумулятор 3000 mAh / 250 mA = 12 часов). Наиболее вероятно — у вас в этих условиях почему-то и данные качаются, и проц загружен на полную. Синхронизации какие, или ещё что… Или это вы мерили, что в _вашем приложении_ происходит? Тогда, наверное, есть резон посчитать расход энергии на мегабайт трафика (и потом сможете упереться в уменьшение трафика, пользователи лишний раз спасибо скажут)
Да и 50 mA просто от включения радиомодуля imho тоже многовато (для телефонов характерно отнюдь не 60 часов чистого standby).
А насчёт «если есть wifi — лучше сидеть на wifi» — лично я подумываю настроить tasker, чтобы дома и в офисе телефон переключался на 2G (вроде бы при этом меньше жрёт в фоне).
Заранее спасибо. Данные крайне интересные, но заморачиваться с разборкой своего телефона, дабы подключиться последовательно с батарейкой, очень не хотелось.
Если ещё и замерите потребление в зависимости от текущей частоты CPU (на андроиде, наверное, удобнее их для этого зафиксировать настройками governor), загрузки процессора и количества задействованных ядер для основных чипсетов — будет вообще праздник, ибо есть подозрение, что в power_profile.xml у производителей телефонов обычно числа от балды.
Ну и реальное потребление WiFi, Bluetooth и т.п. тоже интересно…
Что-то меня нервирует момент с функцией Wrap в разделе «функторы»:
внутри неё определёна статическая переменная W — значит, для всех вызовов с одинаковым аргументом темплейта (Func) будет работать с одной и той же переменной W (проинициализирована она будет только при первом вызове для данного Func).
Т.е. вызов Wrap для нескольких функторов одного типа вернёт один и тот же результат.
Afaik не обязательно.
1. Для FFT есть эффективные алгоритмы не только для степеней двойки, но и для простых чисел и для произведения небольших простых чисел (они сложнее, чем для степени двойки) — вероятно, для MDCT они тоже есть.
2. Для небольших значений размера делаются свои алгоритмы со специфическими оптимизациями (типа учёта того, что cos(pi/4)=sin(pi/4) или что sin(pi/6)=1/2).
Они и в 1s есть (пользуюсь с программой Mi Band Notify & Fitness), но, увы, датчик не очень хорош. Вот, сегодня ехал на работу на самокате — пульс «колбасило» от 49 до 155 (реально вроде был в районе 100, поднимался до 120, когда заезжал на мост — но 155 показало совсем не в то время). Браслет затянут так, что прилегает плотно, запястье под ним побрито :-)
(кстати, шутки шутками, но вроде именно после бритья запястья хотя бы в покое начало стабильно мерить).
Как я понимаю, это общая проблема подобных датчиков (хотя вроде в mio alpha добились какого-то прогресса — коллега бегает в часах с их датчиком), для тренировок лучше нагрудный датчик (chest strap) купить.
Кстати, а хоть кто-нибудь обратил внимание на сам код?
Прибавлять пробелы по одному к строке слева — мягко говоря, не самая эффективная реализация. Можно предположить: авторы пакетов, зависящих от left-pad, код не читали, да и code review никто не делал.
Очень, очень печально.
Простите, или я не понял, или вы не раскрыли мысль из начала статьи — "для воспроизведения 16 битных записей начали применять 18 и даже 20 битные цифро-аналоговые преобразователи". Зачем повышать разрядность ЦАП, если передискретизация позволяет, напротив, обойтись меньшей разрядностью (вплоть до "однобитных" дельта-сигма, которые тут уже упоминали)?
Или маркетинг в том, что взяли 16-битный ЦАП на 176 кГц и стали продавать, как 18-битный?
Я понимаю, что те, кто занимаются Data Science, за это не в ответе (и вообще то, как себя ведут терминалы, определяется скорее «эффективными менеджерами»), но, надеюсь, у вас есть хоть какие-то связи с другими ИТ-шниками банка, и вместе вы сможете добиться разрешения хоть что-то улучшить.
А ещё надеюсь, что те, кто _молча_ гадил в карму — не ограничатся этим и постараются мне доказать, что всё не так плохо и IT-шники Сбербанка действительно могут сделать его лучше. Всего-то надо — протолкнуть несколько улучшений в терминалы, да и интернет-банк тоже не идеален ;-). Если будут хоть какие-то улучшений — готов лично поблагодарить каждого минусовавшего :-D
Куда сбербанку в data science лезть, если они терминалы для приёма денег нормально сделать не могут? (не умеет давать сдачу — ну, допустим, это техническое ограничение; не умеет объединять несколько платежей, чтобы оплатить одной купюрой — безумие; считывание штрих-кодов с квитанций отключили, а qr-кодов так и не сделали — безумие в квадрате; регулярно не может провести платёж по квитанции, по которой раньше мог)
В общем, держались бы подальше от сложной техники, у них всё равно плохо получается.
Т.е. палец будет не увеличивать скорость, а ограничивать её.
Единственное — из-за длинной арифметики там вроде не O(log(n)), а поболее получалось (но и алгоритмы «в лоб» тоже были не O(n)).
И тут пришёл какой-то чувак, написавший решение не через суммирование F[n+1] = F[n]+F[n-1], а через возведение матрицы ((1,1),(0,1)) в степень. Чуть ли не на бейсике. И, соответственно, порвавший всех.
Но к подходу поставленной задачки вы подошли серьёзно, приятно было посмотреть =)
Ну и да, даже если бы удалось сделать идеально (скажем, датчик движения -> аппаратная обработка -> аппаратное смещение изображения на экране), и, допустим, сам экран достаточно быстродействующий — всё равно получили бы две проблемы:
1. Двигающаяся в поле зрения рамка экрана (и держащая её рука)
2. Голову-то при тряске тоже мотает! Т.е. как ни стабилизируй — картинка в поле зрения будет дёргаться. Привязываться надо к глазам, для этого крепить что-то на голову — что естественным образом приводит к идее очков.
Да, он устроен просто — но prototype-based наследование легко понять, когда у тебя уже есть изрядный опыт, а в начале обучения это может сломать мозг. То же — насчёт областей видимости и замыканий в JS.
По мне, так лучше бы начинать с какого-то языка, где всё устроено именно так, как кажется на первый взгляд. Правда, в голову приходит только покойный Паскаль…
А правило «практически любое существительное в английском можно использовать как глагол» тут не срабатывает?
Т.е. слитное написание вместо раздельного совсем недопустимо или просто получается некий жаргонизм?
Да и 50 mA просто от включения радиомодуля imho тоже многовато (для телефонов характерно отнюдь не 60 часов чистого standby).
А насчёт «если есть wifi — лучше сидеть на wifi» — лично я подумываю настроить tasker, чтобы дома и в офисе телефон переключался на 2G (вроде бы при этом меньше жрёт в фоне).
Если ещё и замерите потребление в зависимости от текущей частоты CPU (на андроиде, наверное, удобнее их для этого зафиксировать настройками governor), загрузки процессора и количества задействованных ядер для основных чипсетов — будет вообще праздник, ибо есть подозрение, что в power_profile.xml у производителей телефонов обычно числа от балды.
Ну и реальное потребление WiFi, Bluetooth и т.п. тоже интересно…
внутри неё определёна статическая переменная W — значит, для всех вызовов с одинаковым аргументом темплейта (Func) будет работать с одной и той же переменной W (проинициализирована она будет только при первом вызове для данного Func).
Т.е. вызов Wrap для нескольких функторов одного типа вернёт один и тот же результат.
Я где-то ошибся? (проверять сейчас некогда)
1. Для FFT есть эффективные алгоритмы не только для степеней двойки, но и для простых чисел и для произведения небольших простых чисел (они сложнее, чем для степени двойки) — вероятно, для MDCT они тоже есть.
2. Для небольших значений размера делаются свои алгоритмы со специфическими оптимизациями (типа учёта того, что cos(pi/4)=sin(pi/4) или что sin(pi/6)=1/2).
И модулятор, скорей всего, тоже не надо: фототранзистор должен справиться сам. Но надо проверять.
(кстати, шутки шутками, но вроде именно после бритья запястья хотя бы в покое начало стабильно мерить).
Как я понимаю, это общая проблема подобных датчиков (хотя вроде в mio alpha добились какого-то прогресса — коллега бегает в часах с их датчиком), для тренировок лучше нагрудный датчик (chest strap) купить.
Прибавлять пробелы по одному к строке слева — мягко говоря, не самая эффективная реализация. Можно предположить: авторы пакетов, зависящих от left-pad, код не читали, да и code review никто не делал.
Очень, очень печально.