Уважаемые участники сообщества Хабр, добрый день!
Представляем вам инструмент для тестирования торговых стратегий с приближением к реальности и пути улучшения финансовых результатов (это не машинное обучение, не нейросети, не гадание и не астрология).
В первую очередь эта статья будет полезна, тем кто пишет торговых роботов, или разрабатывает стратегию для сигнальных ботов, и даже тем, кто в поисках чего то интересного и нового.
Итак, начнем.
Подход, выбранный в публикуемой работе для исследования составного числа, основан на концепции закона распределения делителей (ЗРД) числа в натуральном ряде чисел (НРЧ). Приводятся общая и каноническая модель числа, сохраняющая основные свойства, присущие большинству реализаций, но имеющая стандартный (наиболее простой) вид. Возвращаясь к прошлым публикациям, перечитал комментарии и принял решение создать эту.
Разнообразие множества исследуемых и различающихся реализациями моделей чисел вынуждает исследователя вводить для них типизацию (не классификацию). Два близких по значению нечетных числа могут иметь разный тип. Дело в том, что разработанная списочная многострочная модель (СММ) составного числа выявляет весьма тонкие, но существенные различия даже в очень близких числах из одного класса.
При введении (загрузке) в модель исходного значения N эти различия при их учете влекут использование отличающихся алгоритмов обработки, которые приспособлены к конкретному типу чисел. В работе приводится пример двух близких N1 = 1961 и N2 = 1963 чисел, тип которых не совпадает. Это, в свою очередь, приводит к выбору и исполнению соответствующих алгоритмов обработки этих чисел.
Цель публикации в первую очередь образовательная, познавательная, популяризация науки, а также стремление привлечь в ряды исследователей, в науку приток новых молодых умов, вызвать в таких умах стремление к поиску ответов на возникающие вопросы. Масштабность темы требует ввести разумные ограничения на излагаемый материал после краткого панорамного её рассмотрения.
Привет, Хабр! Я — Алексей Диянов, технический директор Nedra Digital. Мы — IT в нефтегазовой отрасли. Компании чуть больше трёх лет. Мы быстро выросли как в численности персонала, так и в количестве проектов, но не избежали классических проблем в виде трудностей внутренней коммуникации, регулярного тушения пожаров и принятия управленческих решений на основе субъективного мнения.
Поговорим о наблюдаемости качества разработки. Нужно ли измерять всё, что поддается измерению? И если нужно, то с чего начать, где брать исходные данные и с какими инженерными метриками работать, чтобы повысить управляемость разработки в будущем?
Сегодня я расскажу о том, как был подготовлен материал об одиночестве, «24 hours in an invisible epidemic», опубликованный на платформе Pudding.
Всё началось с моей одержимости материалами Американского обследования использования времени (American Time Use Survey, ATUS). Каждый год в ходе соответствующего мероприятия проводится опрос десятков тысяч американцев. Им предлагают проследить за одним днём своей жизни. Полученные данные позволяют получить некие общие показатели и, при желании, добраться до каждого респондента и узнать о том, чем занимался именно он.
TL;DR
Я написал тул для генерации постеров с маршрутами общественного транспорта, разные цвета для разных видов транспорта, толщина и прозрачность линий соответствуют количество поездок на сегменте маршрута. Репозитарий тут: https://github.com/dragoon/cityliner
Около 10 лет назад, Майкл Мюллер сделал проект gtfs-visualizations на смеси JavaScript/Node.js для обработки GTFS данных и Processing для отображения в PDF. Мне понравились эти постеры, и я доработал его код, добавив возможность создания постера, ограничения изображения по радиусу, и переделал обработку данных так чтобы файлы читались последовательно а не загружались полностью в память (это было проблематично для городов даже среднего размера).
Сейчас я полностью переписал этот проект c нуля на питоне, добавил разные цветовые темы и визуализацию водоемов, автоматизировал создание постера с иконками городов.
Анализ данных — один из ключевых драйверов роста для бизнеса. Аналитика позволяет выявить скрытые закономерности и тренды, прогнозировать будущие события и принимать обоснованные решения на основе фактов. Бизнес, основанный на данных, не просто реагирует на переменчивость, но и активно формирует свое будущее.
Сегодня мы подготовили для вас новую подборку книг с высоким читательским рейтингом, которые дают понимание, как собирать данные и извлекать из них ценность, как принимать обоснованные решения, определять сильные и слабые стороны различных инструментов.
Много лет существуют Google Earth + Street View и в свое время они вызвали восторг, когда можно виртуально погулять в заморских странах, в Гималая или же по двору детства. Это было очень необычно для тех времен, когда еще кругом щебетали dial-up модемы.
С тех пор прошло 20 лет: теперь трассировка лучей в играх это реальность и видеокарты нагревают воздух не только из-за трехмерной графики в UE5 или Unity, но и майнят крипту/запускают нейросети. Новомодные метавселенные - это хорошо забытое старое, когда маркетинг пытается донести потребителям что без взаимодействия в дополненной реальности общаться и вести бизнес в социальных сетях несовременно. А визуализация геоданных не так далеко ушла от изначальной идеи из Earth. Если вдруг эти сервисы окажутся недоступны, то с чем мы останемся вместо?
В мае этого года вышла первая версия streets-gl - отображение 3D карт OpenStreetMap в браузере. По качеству картинки и поддерживаемым тегам, на мой взгляд, это лучший проект!
Нам до сих пор не до конца понятны некоторые возможности больших языковых моделей. Приложения с большими языковыми моделями должны быть оснащены необходимыми инструментами и оставлять данные о событиях, произошедших в процессе работы. Более того, когда данные собраны, их необходимо оценить на предмет критических ошибок, таких как галлюцинации и токсичность.
В статье рассматривается open-source библиотека Phoenix, основная цель которой — помочь специалистам по данным понять и оценить сложные LLM-приложения, чтобы они могли узнать больше о внутренней работе системы.
Всем привет, меня зовут Зуев Алексей, и я работаю DevOps-инженером в компании Bimeister! Сегодня я расскажу вам о том, как мы облегчаем жизнь нашим разработчикам и как разработчик может отследить состояние своего микросервиса в namespace Kubernetes. Основная цель этой статьи - описать, как мы пришли к дашборду для персональных стендов разработчиков.
Как собрать pgmodeler, если о Qt вы услышали первый раз, а о существовании C++, знаете только то, что он существует?
Всем привет! Я — Никита Колганов из группы компаний «АСНА». Группа компаний «АСНА» — это современная экосистема сервисов и решений для фармацевтического рынка, позволяющая нам развиваться самим и способствовать развитию партнеров.
Зачем мы вообще внедряли BI‑систему?
В компании ежедневно делается множество отчетов, значительная часть которых — средствами Excel. Помимо того, что ручной сбор отчетов занимает массу времени, так и сам Excel, как контейнер доставки отчетности, обладает рядом недостатков. Это, как минимум:
Проблема централизации — в каждом Excel может быть как свой набор исходных данных, так и свои методики расчета;
Проблема доставки — расшарить файл на большое количество участников бывает проблематично. Особенно, если он большой и не пролезает в почту;
Проблема безопасности — непросто ограничить доступ к Excel‑файлу для определенного круга лиц
Отсутствие автоматизации алертов — на уровне Excel сложно настраивать оповещения в почту или корпоративные мессенджеры в случае изменения того или иного показателя.
Изначально в качестве BI‑системы мы хотели использовать Tableau и даже успели сделать несколько дашбордов, но случился февраль 2022 года, и Tableau стал недоступен. Вместе с тем, в компании назрела необходимость BI в концепции self‑service.
В случае, когда требуется оперативно (и вдумчиво) оценить ситуацию в целом и ответить на сложные комплексные вопросы, на помощь приходит визуализация. В нашем случае речь пойдет о метриках эффективности по большей части в области ИБ, но на самом деле все нижесказанное применимо и к бизнес-сегменту, так как логика настройки BI-решений схожая.
Визуализация результатов работы позволяет как дать оценку работы систем или людей, так и проиллюстрировать необходимость запроса, к примеру, потребность отдела в новых вакансиях или отказ от того или иного средства защиты.
Как-то я был на встрече, где участники громко спорили и не соглашались друг с другом. Причем все говорили об одном и том же, только с разных сторон. И тут один из участников взял маркер и начал рисовать на флипчарте квадратики, стрелочки, человечков. В какой-то момент спорившие обратили внимание на рисунки и начали подсказывать, что добавить, а где стрелочка не так идет. Всего через десять минут оживленный спор превратился в конструктивный диалог, который разворачивался вокруг изображения на флипчарте. Так я впервые столкнулся с визуальной фасилитацией.
Рисунки много раз спасали меня в сложных переговорах и проектах. Сегодня я расскажу про визуальные встречи, и как их проводить.
Всем привет! Меня зовут Анастасия Арсеньева, я аналитик данных в Swordfish Security. Наша команда разрабатывает модуль визуализации метрик DevSecOps в рамках развития платформы AppSec.Hub. В предыдущих статьях мы рассказывали вам о том, как можно оценить риски ИБ, зрелость подхода Shift Left и эффективность обработки обнаруженных уязвимостей. Сегодня мы разберем еще один дашборд для оценки процессов безопасности в разработке и поговорим о проекции метрик DORA на DevSecOps.
Привет, Хабр! На связи BI-команда Tele2. Ранее мы уже рассказывали о нашем опыте перехода на Fine BI и подходе к анализу действий пользователей на платформе.
В нашем случае мониторинг пользователей и объектов на платформе – вопрос жизненной необходимости. Fine BI пользуется популярностью у бизнес-пользователей, также мы активно развиваем подход self-service: лицензия Сreator предоставлена 300 сотрудникам, всего опубликовано около 400 дашбордов, а неопубликованных пользовательских ad-hoc дашбордов насчитывается несколько тысяч, доступ к платформе есть более чем у 2,5 тыс человек, а MAU стремится к 2000 пользователей.
Под катом про то, как мы усовершенствовали объединение таблиц из FineDB и LogDB в один датасет, решили проблему потери логов из-за замены уже опубликованных дашбордов и углубили возможности мониторинга действий пользователей и взаимосвязей пользовательских действий с объектами.
Была у нас тут история, когда легкий перфекционизм помог привести в порядок конструкторскую документацию и регулярно экономить инженерам кучу дней на прохождение бюрократических процедур. В ее основе – создание системы управления расчетными данными и переход от трудночитаемых и трудноинтегрируемых отчетов Mathcad к гибкой связке Jupyter Notebook с Python и Teamcenter. Но основной рассказ будет про то, как преобразовывать и экспортировать математические формулы, таблицы и другие элементы из Jupyter в красивый и удобный вид.
Я с детства испытывал тягу к знаниям. Смотрел шоу "Своя игра" и поражался тому, откуда можно знать о мире настолько широко. Невозможно было игнорировать тот факт, что гроссмейстеры были в основном, пожилыми, а я хотел все знать сейчас, а не когда я выйду на пенсию. Поэтому я много читал и не переставал мечтать о том, чтобы можно было загрузить информацию в голову напрямую.
Последние несколько лет, компания Neuralink, с Илоном Маском в роли сооснователя, активно работает над созданием такого чипа. Этот факт, однако, повлек дискуссии, что именно произойдет, если информация попадет на чип, к которому у вас есть доступ, однако нейронные связи в вашем мозгу не сформировались и вы эту информацию не обдумывали? Чем эта ситуация отличается от того, когда информация находится в книге, на жестком диске, в телефоне или на компьютере, но вы книгу еще не читали? Разве что простотой доступа?
Эта дискуссия заставила меня задуматься над тем, есть ли иной способ ускорить освоение информации, не подвергаясь рискам от установки чипа, которого, в любом случае, не существует и не появится в обозримом будущем? Так я начал изучать технологии обучения.
Методов обучения множество. Часть из них ориентированы больше на усиление запоминания информации, а другая часть на углубление понимания. Однако, меня интересовало то, что увеличило бы именно скорость. Само собой напрашивается скорочтение. Тут хотелось бы остановиться и обсудить этот метод. Есть многочисленные исследования различных вариаций скорочтения и все они показывают, что скорочтение это миф и те, кто его практикуют, просто водят глазами по странице. Более того, если мы говорим не о художественных произведениях или текстах полных воды, а о "нормальных книгах", то очевидно, что прочитать страницу занимает 1 минуту, а обдумать - 10. Если даже за счет техник скорочтения можно было бы научиться прочитывать страницу за секунду, все еще остается потратить 10 минут на обдумывание.
Кратко:
1. В оригинальном исследовании показано совсем не то, что люди думают.
2. Оригинальное исследование так криво сделано статистически, что просто не удовлетворяет критерию фальсифицируемости. Простыми словами - генератор случайных чисел демонстрирует такой же результат.
3. Единственное, что этот эффект демонстрирует - это любовь людей к красивым историям (а математику никто не любит … и вообще есть ложь, большая ложь и статистика).
В своей прошлой статье я анализировал разные параметры патентной активности в РФ в 2018–2022 годах. Выяснилось, что очень много патентов на полезные модели ничего не стоят, а вузы создали конвейер по патентованию полезных моделей ради отчетности и показателей.
В этой статье я анализирую наиболее ценные патенты — те, по которым были осуществлены распоряжения правами (заключены лицензионные договоры, сублицензионные договоры, договоры отчуждения или договоры залога). Это объективный индикатор ценности патента, так как если кто‑то платит за него деньги, то, значит, он действительно нужен на рынке. Конечно, есть патенты, которые используют сами правообладатели, и они действительно могут приносить им большую пользу, но выявить их и оценить на практике не представляется возможным, поэтому, вероятно, часть действительно ценных патентов в эту статью не попала.
Код и исходные данные здесь.
Как осуществлялось исследование
Из открытых данных была собрана база всех заявок и выданных по ним патентов, отобраны патенты, по которым осуществлялось распоряжение интеллектуальными правами, обеспеченными этими патентами. Далее этот массив патентов анализировался.
