«Более плавно» оно двигается только относительно экрана. Относительно глаз — рывками (ВЧ-составляющие движения не убираются из-за недостаточного быстродействия).
Ну и да, даже если бы удалось сделать идеально (скажем, датчик движения -> аппаратная обработка -> аппаратное смещение изображения на экране), и, допустим, сам экран достаточно быстродействующий — всё равно получили бы две проблемы:
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 никто не делал.
Очень, очень печально.
Ну и да, даже если бы удалось сделать идеально (скажем, датчик движения -> аппаратная обработка -> аппаратное смещение изображения на экране), и, допустим, сам экран достаточно быстродействующий — всё равно получили бы две проблемы:
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 никто не делал.
Очень, очень печально.