Метка: Data

Навигация по магнитному полю: технология будущего | 2026-01-10T17:41:09

Узнал сегодня, что сейчас есть и активно используется технология навигации по магнитному полю Земли. Используется как замена или как расширение GPS.

Например, есть скандинавский паром Express 5 компании Bornholmslinjen, который страхуется от проблем с GPS (а они происходят) тем, что использует навигацию MagNav. В отличие от GPS, магнитное поле Земли невозможно заглушить или подменить — оно просто существует. Паром ездит по одному и тому же маршруту, и в целом, там можно навигацию даже через бытовые рыболовные эхолокаторы сделать.

Но вот есть несколько стартапов, которые используют эту технологию для навигации внутри помещения, куда сигнал от GPS не пробивается. Утверждается, что точность навигации — 1 метр. Вот это интереснее.

GiPStech, Oriient, Mapsted.

В основе этой технологии лежит процесс, называемый магнитным фингерпринтингом. Инженеры или роботы-картографы обходят здание со смартфоном, записывая уникальные искажения магнитного поля в каждой точке. Эти искажения создаются стальным каркасом здания, арматурой в стенах и крупным электрооборудованием. Формируется база данных, где каждой координате (x, y, z) соответствует свой уникальный вектор магнитного поля (интенсивность, наклон, отклонение).

Собранные данные загружаются в облачную платформу компании-провайдера. Там они проходят очистку от шумов и «сшиваются» с цифровым планом этажа (Floor Plan). Когда пользователь идет по ТЦ, его смартфон в реальном времени считывает данные со встроенного магнитометра. Специальное ПО (SDK) сравнивает текущие показания с теми, что хранятся в базе данных. Чтобы точность была 1–2 метра, система не полагается только на магниты. Она использует сенсорную фузию — объединяет данные магнитного поля с инерциальными датчиками (акселерометр считает шаги, гироскоп определяет повороты) и иногда сигналами Wi-Fi/Bluetooth для грубой привязки к зоне.

Для дронов эта технология наверняка сейчас активно внедряется. Главная техническая сложность там — собственные помехи и учет того, что магнитное поле меняется, и нужно постоянно обновлять карты. Электрика, двигатели создают сильные магнитные поля, которые «забивают» естественный фон Земли. Но пишут, что используются всякие алгоритмы фильтрации (включая нейросети), которые в реальном времени «вычитают» помехи от моторов из общих показаний датчика. Как я также понимаю, на большой высоте (километры) магнитное поле более «гладкое», поэтому точность ниже (около 1–5 км). Но если дронов несколько летит и они обмениваются сигналами, то в целом они вместе могут дать очень хорошую точность каждого. Кроме того, группа дронов может измерять градиент (скорость изменения) магнитного поля в пространстве, и привязывать местонахождение не к абсолютным значениям, а относительным. По сути, использование группы дронов превращает навигационную систему из набора отдельных приемников в распределенную фазированную антенную решетку, способную фильтровать глобальные помехи и работать с гораздо более слабыми полезными сигналами. Учитывая, что небольшие дроны, способные долго находиться в воздухе, могут выпускаться в воздух сотнями (и стоить копейки), это довольно перспективная область для военных.

Есть интересный стартап, Zerokey. Они выпускают QUANTUM RTLS 2.0. Эта штука дает пространственную точность в 1.5мм. Используется на производстве, например. Их ролик например показывает «часы» на руках рабочего, которые следят за корректностью сборки чего-то там на столе. Тут уже ультразвуковой принцип, и понятно, что к этим «часам» даются стационарные датчики и дальше мультилатерация.

Создание и визуализация волейбольных схем | 2026-01-01T21:37:01

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

Детали реализации тут:

preview
Facebook
https://www.facebook.com/raufaliev/posts/pfbid0njrqH8oLcWGFsZcgE5o2pj3NcDNaYSQeCMY6twXNbZn6dc38m9kjhsBqA4YsMozcl

Перевод Excel-организма в код: стратегия и исполнение | 2025-12-17T18:56:17

Все мы с этим сталкивались — «Главная Excel-Таблица, Управляющая Бизнесом». Та самая, которую B2B-компании используют, чтобы считать котировки на миллионы долларов. В ней 12 вкладок, 1000+ вложенных формул и ноль документации. Десять лет туда лепили «быстрые фиксы» и прятали константы. Это уже не файл, а живой организм, который уже никто до конца не понимает кроме того чела, уволившегося годы назад. Вот такой я был озадачен. Более того, там еще была неопределенность нужна ли вообще половина формул, или это рудименты прошлого.

Типичная ячейка:

=IF($D11=$D10,»», IF(ISNUMBER( INDEX(Data!$T$10:$U$17,

MATCH(TabCalc!$F11,Data!$T$10:$T$17,0),2)),

INDEX(Data!$T$10:$U$17, MATCH(TabCalc!$F11,Data!$T$10:$T$17,0),2),

INDEX(TabProd!$C$8:$U$112,TabCalc!$D11,I$1)))

Мне поручили перенести эту логику в код, чтобы все считалось софтом. Excel-файл как бы все имел что надо, но по факту — это был сложнораспутываемый черный ящик. 1069 формул.

Челлендж был в том, как перевести тысячу взаимозависимых формул в чистый код и не потерять ни одного пограничного случая (edge case).

В итоге вот что я сделал.

Вместо того чтобы переписывать всё с нуля одним махом с неопределенными перспективыми наплодить багов, я использовал стратегию ленивых вычислений и моков.

Я построил структуру на Groovy, которая имитировала поведение Экселя. Каждое вычисление (из ячейки) я определил как функцию, которая выполняется только тогда, когда её вызывают. А функциями был многомерный dictionary.

Я пошел с конца графа вычислений: от результатов к входным данным. Если формула зависела от чего-то, что я еще не написал, я «мокал» это в коде, просто подставляя значение из Excel-листа.

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

Другими словами, движение шло от результата к исходным данным. На каждом шаге было ясно, какие моки надо превратить в код, и можно было сравнить версию +1 с версией -1 — результат должен был совпадать. Как только все моки заменились на вызовы — задача была готова.

Настоящим «секретным ингредиентом» стала динамическая природа Groovy для создания многомерной карты функций. Вместо статических переменных я использовал глубоко вложенную структуру, где каждый «лист» был замыканием (closure). Это позволило обращаться к любой части таблицы — будь то входной параметр, константа конфига или сложный промежуточный результат — через простой, унифицированный синтаксис, причем некоторые компоненты были динамическими.

Вот пример:

conf[«group»] = { x -> [«a», «b», «c»] }

conf[«group»]().each {

calculate[«Group»][«Subgroup»][it][«TotalQuantity»] =

{

x -> calculate[«Group»][«Subgroup»][it][«Someparameter»]() * conf[«someConstant»]()

}

}

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

Тестировать можно было прямо сразу после начала переноса формул. Прелесть была в том, что ты вроде как как бы к ячейке обращаешься через синтаксис типа calculate[«Totals»][«A»](), а на самом деле запускаешь целое дерево вычислений в этот момент. И это дико удобно в отладке.

Через две недели «Черный ящик» превратился в прозрачную, модульную библиотеку с понятной логикой, которая выдавала ровно тот же результат, что и оригинальная таблица.

P.S. Ну и конечно, все данные на всех скриншотах тщательно обфусцированы, а точнее сказать, написаны с нуля для этого текста.

Каждое дерево на карте: Открытые данные графства | 2025-12-15T15:40:16

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

Читаем больше: Как изменилась структура потребления информации с 1980 по 2008 год | 2025-12-14T22:33:27

Интересное исследование попалось на глаза, аж 2009 года. Согласно ему, современный человек действительно читает значительно больше, чем в прошлом, хотя формат этого чтения изменился. Согласно ему, на 2008 год, среднестатистический амеканец потребляет около 100000 слов в день (примерно чертверть «Войны и мира») — это приблизительное количество слов, которые прошли через сознание за день (через уши или глаза), рассчитанное на основе хронометража активности. Это на 140% больше, чем в 1980 году.

Таким образом, вопреки мифу о деградации чтения, как минимум в 2008 мы обрабатывали в 2.4 раза больше текстовой информации, чем поколение наших родителей. Причем исследование учитывало только информацию, потребляемую вне работы (дома, в пути, на отдыхе) .

Структура чтения — если в 1960 году 26% слов приходило с бумаги, то к 2008 году эта доля упала до 9%. Однако цифровые носители (интернет, электронная почта, соцсети) не только компенсировали этот спад, но и утроили общее время чтения. Причина — интернет, так как это преимущественно текстовая среда (веб-серфинг, email)

Но интересно, что Интернет обеспечивает 25% потребляемых слов, но лишь 2% байтов (так как видео в интернете в 2008 году было низкого качества). То есть, они там прикинули информационный поток с разных каналов и перевели его в байты 🙂 Радио занимало 19% времени, но генерировало лишь 0,3% байтов (аудио требует мало данных). Голосовая связь (телефон) — это всего 5% слов и ничтожная доля байтов, но это единственный полностью интерактивный канал до эпохи интернета. ТВ оставалось на 2008 год главным источником информации по времени (41% всех часов) и количеству слов (45%), однако по объему данных (байтам) телевидение занимало только второе место (35%), уступая компьютерным играм.

Вот с играми интересно. Главная находка отчета: Игры генерируют (или генерировали в 2008) 55% всех «байтов», потребляемых домохозяйствами. При этом они занимают лишь 8% времени пользователя. Это довольно спорная штука в их отчете.

Те 100500 слов — это оценка реальных слов, которые человек либо прочитал, либо услышал. Это не метафорический «эквивалент», а попытка подсчитать именно вербальную информацию. Они взяли время потребления каждого медиа и умножили на среднюю скорость поступления слов для этого канала. Чтение (книги, газеты, интернет-тексты): 240 слов в минуту. Электронная почта и веб-серфинг — 240 слов в минуту. Телевидение (диалоги в шоу/фильмах): 153 слова в минуту. Радио: 80 слов в минуту (меньше, так как много пауз и музыки). Музыка: 41 слово в минуту (тексты песен).

Ссылка в комментах

GPU против CPU: Революция в обработке данных | 2025-12-13T01:16:30

Мучаю свой суперкомпьютер. Иллюстрация того, что GPU — не только для машинного обучения и какой-то сложной математики.

Мой скрипт берет толстый словарь английского языка (Webster) и множит его 30 раз, получается список из 12 млн слов. Далее алгоритм просматривает все 12 млн слов и заменяет все гласные буквы на звездочки через regex. Далее чтобы добавить нагрузки, добавляется колонка «длина слова», и затем берем слова длиннее 10 букв и ищем самые частые (top5).

То есть, на питоне это

df[‘masked’] = df[‘text’].str.replace(r'[aeiou]’, ‘*’, regex=True)

df[‘len’] = df[‘masked’].str.len()

res = df[df[‘len’] > 10][‘masked’].value_counts().head(5)

и вот этот код выполняется сначала через основной процессор, а затем через GPU.

Основной процессор (у меня это топовый Intel i9 285k) выполняет эту задачу за 24 секунды, а Nvidia RTX 5090 — за 0.51 секунд. То есть, разница в 46 раз!

[Pandas CPU] Top Patterns:

masked

s*r w. sc*tt. 23280

s*r t. br*wn*. 23220

j*r. t*yl*r. 16140

bl*ckst*n*. 10860

b***. & fl. 10830

Name: count, dtype: int64

[Pandas CPU] Computation Time: 23.5596 sec.

Transferring data to GPU…

Transfer complete in 1.16s

— Running Benchmark: cuDF GPU —

[cuDF GPU] Top Patterns:

masked

s*r w. sc*tt. 23280

s*r t. br*wn*. 23220

j*r. t*yl*r. 16140

bl*ckst*n*. 10860

b***. & fl. 10830

Name: count, dtype: int64

[cuDF GPU] Computation Time: 0.5108 sec.

TOTAL SPEEDUP: 46.12x

Сердце информационного хранилища: дата-центр NSA в Блаффдейле | 2025-09-20T20:06:05

Я ж тут живу в долине датацентров, типа 80% интернет-трафика через нас проходит (опасное место!). Проезжал сегодня мимо одного из них, и уже дома, когда гуглил всякое про датацентры, наткнулся на датацентр агентва нацбезопасности США в Блаффдейле, Юта.

Является хранилищем данных разведывательного сообщества США. Емкость — что-то типа 5 триллионов террабайт. 5,000,000,000,000,000 гигабайт. В 2013 там было в 100-1000 раз меньше, но и 12 лет прошло, закон Мура и все такое. Жесткие диски в датацентрах обычно имеют срок службы 3-5 лет. То есть, их с момента запуска датацентра по несколько раз уже все поменяли на очевидно большей емкости.

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

Сколько данных может хранить этот объект, конечно, засекречено, но оценки «несколько йоттабайт». Йоттабайт = 1000 зеттабайтов = 1 000 000 эксабайтов = 1 триллион терабайт. Для хранения всех книг, когда-либо написанных на любом языке, потребовалось бы всего 400 терабайт.

В 2013 году потреблял не меньше 65 МВт с потенциалом в 100Мвт. Вода — ~1,5–1,7 млн галлонов (5,7–6,4 млн литров) в день для охлаждения серверов. Вода обрабатывается химикатами (для предотвращения коррозии) и сбрасывается, что вызывает критику в засушливом Юте — особенно на фоне рекордной жары 2022–2025 годов и дефицита пресной воды. Нет замкнутого цикла, и это остаётся «горячей» темой в местных дискуссиях.