Pull to refresh
43
0.1
Валерий Дмитриев @rotor

Пользователь

Send message

Тоже зацепился глаз за это предложение.
Только функция знает допускает ли её параметр неинициализированную переменную. И это часть сигнатуры функции.
Давая возможность помечать переменные [[indeterminate]] мы потенциально делаем код неустойчивым к изменениям.
Если мы в какой то момент заменим void fill(int&) на void bar(int&), которая не предполагает использование неинициализированных переменных, то мы не получим диагностических сообщений.

Спасибо за действительно интересный обзор!

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

Wase тоже местами врёт, но не так ужасно, как Google. Хуже Гугла, наверное ничего нет

Hidden text

Посмотрите лекции Константина Владимирова на Ютубе. Они действительно потрясающие. Не только, кстати, для начинающих.

Ссылки поправил. Спасибо.
GitHub не смог отрендерить этот файл потому что там предопределённый unordered_map с 50000 значений. Я вкомпилировал словарь в бинарь библиотеки, что бы не нужно было загружать его отдельно. Это довольно большой файл.

Всё верно. Но не все используют Python для своих проектов.
Именно для этих случаев и нужны альтернативные решения.

Спасибо, что продолжаете делиться своими наработками.
Вы абсолютно правы, смысл опенсорса не в том, что вам будут присылать багрепорты или писать код за вас. Хотя и в этом тоже. Эти поводы легко объяснить далёким от IT менеджерам, но они не главные.
Смысл опенсрса -- счастье команды.
И это вполне разумный аргумент.
Высшее счастье инженера -- видеть как результатами его труда пользуются и они приносит пользу другим людям, а высшее несчастье -- работа в стол.
И если у вас команда профессионалов, то выкладка кода в открытый доступ безусловно принесёт удовлетворение, мотивирует работать лучше.
Кроме того, чего греха таить, когда мы знаем что наш код попадёт в опенсорс, мы прикладываем больше усилий, что бы код был максимально качественным.
А вот утаивание кода приносит меньше профитов, чем принято думать.
Ну и конечно, опенсорс повышает престиж компании. Ведь мы судим о компании в том числе по её коду.
Рад, что ответственные люди в Яндексе на стороне прогресса. И надеюсь, что эта практика понемногу станет нормой повсеместной.

Самый адекватный комментарий во всём этом паникёрском чате :)

То что он забывает контекст при запросах через API это абсолютно нормально. У него нет способа помнить контекст если вы ни как его не передали. Странности в ответах могут быть связаны с настройками. Например, там есть такие параметры как temperature и top_p. Нужно правильно выбрать параметр model для максимальной близости с чатом GPT нужно выбирать text-davinci-003.
Ну и наконец, вполне возможно что в чате используется модель недоступная в API.

У Олега сын Степан. У Степана сын Иван Фролов. Скажи ФИО Степана.

Степан Олегович Фролов.

То что я описал не применимо к временным рядам. По крайней мере напрямую. Поэтому сравнивать с авторегрессией неуместно -- это совершенно разные задачи. У меня же шла речь о классических задачах регрессии, когда по заданной обучающей выборке мы пытаемся предсказать некую непрерывную величину. Никакой привязки ко времени тут не предполагается.
Согласен, что пример на реальных данных был бы уместен. Я использовал предложенный алгоритм на своих рабочих задачах. И, к сожалению, не могу опубликовать здесь результаты. Возможно позже сделаю пример на каком-нибудь открытом датасете.

Немного дополню. На предыдущей работе делал систему детектирования атак на основании определения аномалий в трафике по логам веб сервера.
Основная концепция такая: атакующий будет стараться прикинуться добропорядочным пользователем, но распределения отдельных параметров трафика всегда очень специфичны и ему не известны. Т.е. невозможно подделать распределения.
Этот метод хорошо сработал и позволял почти молниеносно реагировать.

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

Плюс по сравнению с нейросетевыми подходами: во-первых скорость и простота реализации. Во-вторых интерпретируемость и возможность очень чётко понять в какой из систем что пошло не так.

Спасибо за перевод. Очень крутая статья.

он позже писал, что опирался на работы Пуанкаре.
Не стоит противоставлять Пуанкаре и Эйнштейна. Они оба гениальны.

В русскоязычной литературе Information Gain принято называть взаимной информацией.


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


Ещё есть работы, показывающие, как работают нейронные сети с точки зрения теории информации (https://adityashrm21.github.io/Information-Theory-In-Deep-Learning/)

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


Разбиение на кластеры подражает некоторое распределение. Можно считать (но не обязательно), что это распределение порождено некоторой случайной величиной.


Это означает, что мы можем посчитать взаимную информацию распределений.
Итак. Пусть X — истинное распределение, порождаемое С.В. x, а Y — модельное, порождаемое соответственно y.
Тогда мы можем посчитать их взаимную информацию по формуле


(Hx +Hy - Hxy) / Hxy

Здесь Hx — энтропия x, Hy — энтропия y, а Hxy — энтропия совместного распределения x и y.
Энтропия — это размерная величина (измеряется в битах или натах), зависит от основания логарифма, поэтому если нам нужна безразмерная метрика, то нужно нормировать.
Предложенный способ нормировки стандартный, но не единственный.
Можно показать, что определённое таким образом число всегда будет в интервале [0, 1]


Пример

imageddd


|   | a | b | c | d | e | f | g | h | i |
|---|---|---|---|---|---|---|---|---|---|
| x | 1 | 1 | 1 | 1 | 1 | 2 | 2 | 2 | 2 |
| y | 1 | 1 | 1 | 1 | 2 | 2 | 1 | 2 | 2 |

Px(1)=Py(1)=5/9 Px(2)=Py(2)=4/9
Pxy(1,1)=4/9 Pxy(1,2)=1/9 Pxy(2,1)=1/9 Pxy(2,2)=3/9


Hx = Hy = -5/9*ln(5/9) - 4/9*ln(4/9) = 0.687
Hxy = -4/9*ln(4/9) - 2/9*ln(1/9) - 3/9*ln(3/9) = 1.215
i_xy = (2*0.687-1.215)/1.215 = 0.13


Если бы точек было 90 и 2 различались, то i_xy = 0.73, а если 900, то i_xy = 0.95


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

Я как раз хотел предложить метрику на основе взаимной информации, но вы меня опередили :) сейчас ниже напишу что я придумал.

То что вы предлагаете описано в п 2.2. но там используется Precision и Recall, а вы предлагаете использовать Accuracy.
Практика показывает, что не смотря на кажущуюся интуитивность этой метрики, она плохо работает в случае дисбаланса классов.
Поэтому в ML не принято использовать Accuracy.

Часто пишу на D и C++ и как C++ разработчик вижу проблему D в неправильном позиционировании.
Слоган D: "write fast, read fast, run fast" и это в целом правда. На D действительно можно быстро писать читаемый код, который при этом будет относительно быстро исполняться. Есть режим "интерпретатора" для быстрой отладки и прототипирования.
Язык очень удобен, но ни как замена C++, а как замена Python!
Современный С++ самодостаточен и хорош для тех кто его знает. Пытаясь стать заменой C++ D плывёт против течения.
Высокая производительность C++ обусловлена:


  1. Возможностью полностью контролировать поток выполнения как на высоком так и на низком уровне
  2. Возможностью фронтенда компилятора выполнять оптимизации, недоступные в более безопасных языках. Все эти вещи, которые помечены в стандарте как UB дают компилятору возможность для оптимизаций.
    У D тоже получается собрать весьма эффективный код с ldc2, но оптимизаций бэкенда недостаточно. И он никогда не будет столь же быстр как C++. Даже без учёта GC.

А вот использовать D там, где используют, например Python, действительно круто.
У D достаточно много библиотек (хотя многие и весьма сырые). У D прогрессивная сложность. На нём легко начать писать с минимальной подготовкой. Код получается компактный и читаемый. Потрясающая шаблонная магия позволяет делать красивые библиотеки, которыми легко пользоваться. Встроенные юниттесты. Типобезопасность. Бинарь без зависимостей на выходе. И много много чего ещё.


D например, мог бы стать потрясающим языком для машинного обучения.

Ага. Ассоциативные массивы часто используют в динамически типизированных языках.
В D, как правило, можно обойтись более эффективным контейнером.
Структура вместо ассоциативного массива будет существенно эффективнее. Она аллоцируется на стеке. Кроме того, компилятор может делать проверки, которые не доступны при использовании словаря. Например в случае опечаток.
Ещё код можно сделать нагляднее и читабельнее, если используемые структуры данных заранее определить:


struct Dpt18Decoded
{
    ubyte learn;
    ubyte number;
}
// ...
Dpt18Decoded foo()
{
    return Dpt18Decoded( (raw[0] & 0x80) >> 7, raw[0] | 0x7f );
}

Information

Rating
3,261-st
Location
Уфа, Башкортостан(Башкирия), Россия
Date of birth
Registered
Activity