Aspiring Data Science – Telegram
Aspiring Data Science
386 subscribers
465 photos
12 videos
12 files
2.15K links
Заметки экономиста о программировании, прогнозировании и принятии решений, научном методе познания.
Контакт: @fingoldo

I call myself a data scientist because I know just enough math, economics & programming to be dangerous.
Download Telegram
#trading #williams

Сегодня при просмотре видео по трейдингу услышал ссылку на Ларри Вильямса. Этот американский трейдер, который говорит о себе как "сделал сколько-то миллионов из $10 тысяч". Немедленно вспомнил его книжку, которую купил ещё в 2000-х, и в которой он типа делился своими секретами успешной торговли. Вся книжка сводилась к тому, что он на дневках подбирал правила, которые давали несколько сделок в год (!!). Он суммировал эти виртуальные сделки за 20 лет, и делал таким образом выводы об эффективности правил. Это и были его "секретные рекомендации". Уже тогда мне казалось странным делать выводы по 30 объектам, а узнав о подгонке под кривую и статистической значимости, я понял, что Ларри Вильямс является не гениальным трейдером, а, в терминологии Талеба, опасным идиотом. Ну либо он в своей книге лукавил, но это не делает ему больше чести. Так что, когда слышу о правилах, почерпнутых от Ларри, губы мои искривляются в усмешке.

https://www.youtube.com/watch?v=K4DtSpD649g
👍1😁1
#astronomy #lifeorigin

"Повторный анализ данных с космического аппарата НАСА «Вояджер-2» и новое компьютерное моделирование позволили специалистам NASA сделать вывод, что четыре крупнейшие луны Урана, вероятно, содержат океанический слой между ядром и ледяной корой. Это исследование стало первым, в котором подробно описывается эволюция внутреннего состава и структуры всех пяти крупных лун Урана: Ариэли, Умбриэли, Титании, Оберона и Миранды. По результатам работы делается вывод, что на четырёх из этих лун имеются океаны, глубина которых может составлять десятки километров.

У Урана известны 27 лун, четыре самых крупных из них — это Ариэль (1160 км в поперечнике), Умбриэль (1170 км), Оберон (1520 км) и Титания (1589 км). Давно считалось, что Титания, как самая крупная, могла сохранить достаточно внутреннего тепла от радиоактивного распада, чтобы поддерживать подлёдный океан тёплым и даже потенциально пригодным для поддержания в нём жизни. Остальные луны считались недостаточно большими для сохранения тепла и воды в жидкой фазе. Новая работа даёт надежду, что жидкие океаны могут быть также на трёх других крупных спутниках Урана. Следовательно, будущая миссия должна это учитывать и готовить соответствующие научные приборы.

Приборы в миссии к Урану должны уметь определять как химический состав вещества на поверхности планеты, так и заглянуть под её поверхность. Для твёрдой породы необходим один диапазон сканирования, для поиска воды — другая методика. Например, о наличии воды подо льдом можно судить по регистрации токов, которые создают магнитные поля спутников. Также спектральный анализ вещества на поверхности вблизи вероятных разломов расскажет о содержании недр и о химическом составе подлёдной воды.

Наконец, обнаружение относительно свежих разломов — это также верный признак тектонической активности лун и теплоты её недр (как вариант, наличие тёплого океана). Учитывая вновь вскрывшиеся возможности, NASA сможет лучше спланировать миссию к Урану."

https://3dnews.ru/1086242/chetire-krupneyshih-sputnika-urana-mogut-sodergat-podlyodnie-okeani-pokazalo-novoe-modelirovanie-i-tam-moget-bit-gizn
#openai #gpt #costs

"Согласно оценкам Дилана Пателя (Dylan Patel), главного аналитика консалтинговой фирмы SemiAnalysis, использование ChatGPT может стоить OpenAI около $700 тыс. в день, учитывая затраты, связанные с использованием вычислительных ресурсов. Председатель совета директоров Alphabet (материнская компания Google) Джон Хеннесси (John Hennessy), ранее заявил, что поиск в Bard, собственном чат-боте Google, обходится в 10 раз дороже, чем обычный поиск.

Хотя финансовое положение OpenAI укрепилось, главным образом благодаря многомиллиардным инвестициям Microsoft, растущий спрос на её чат-бот, число активных пользователей которого выросло только за два первых месяца после запуска до 100 млн, приведёт к дальнейшему росту затрат компании. Ранее на этой неделе гендиректор OpenAI Сэм Альтман (Sam Altman), говоря о росте затрат, заявил, что это «будет самый капиталоёмкий стартап в истории Кремниевой долины», пишет The Information.

Как указано в публикации The Information, Альтман «в частном порядке предположил», что OpenAI может попытаться привлечь около $100 млрд в ближайшие годы, поскольку компания работает над развитием общего искусственного интеллекта (AGI) — столь же мощного ИИ, как человеческий мозг.

По прогнозам Reuters, выручка OpenAI значительно вырастет в этом году на фоне ажиотажного роста популярности её технологии. Ожидается, что выручка компании достигнет $200 млн в этом году, а затем вырастет до $1 млрд в 2024 году."

https://3dnews.ru/1086282/publikatsiya-1086282
#opticloud

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

Пока оно позволит клиентам получить ответ на вопрос вида "где сейчас взять 20 самых дешёвых воркеров Intel с 2 Гб RAM на ядро для моего Dask кластера".

Я видел несколько сайтов с похожей инфой, но:
1) нигде не учитывается текущая доступность инстансов, т.к. AWS полностью не раскрывает эту инфу
2) нет либо деталей архитектуры, либо кросс-регионного сравнения цен. надо вручную выписывать варианты в табличку.

Таким образом, уже бета-версия моего сервиса может быть полезной.

Следующим шагом собираюсь прикрутить в API (по модели процессора) общедоступные бенчмарки, чтобы можно было искать серверы с "железом, самым дешёвым на единицу производительности для Linpack/ Stockfish/CL/CUDA etc".

Потом кастомные реальные бенчмарки, другие облака, ML для предсказания долгосрочной доступности и цен, но это всё, конечно, если появятся клиенты.
2
#marketingbullshit

Всё-таки как иногда "маркетинговая херня" прокрадывается в документы даже серьёзных компаний.

Мне лично неизвестны СУБД, выполняющиеся на GPU, а Вам? Так и представляю себе неосведомлённого клиента, который купил сервера на GPU чтобы получить "high performance database".

Уточню, СУБД в промышленной эксплуатации и на реальных проектах. Про экспериментальные ветки типа PgStrom я читал.
#ml #datasets #openregistry #python

Бывает, для академических целей срочно нужны датасеты )
В таких случаях можно поискать в Registry of Open Data on AWS. 400+ датасетов (табличные, тексты, изображения) хостятся на s3. Есть описания, зачастую примеры использования на Питоне. Акустика, космос, медицина, отзывы, карты, разметки, всё, что душе угодно )

https://registry.opendata.aws/
#python #codegems

Понадобилась структура кольцевого буфера, самому делать на списках и указателях не хотелось, я смутно вспомнил что-то про очереди, ну и быстро нашёл такой красивый пример:

>>> import collections
>>> d = collections.deque(maxlen=10)
>>> d
deque([], maxlen=10)
>>> for i in xrange(20):
... d.append(i)
...
>>> d
deque([10, 11, 12, 13, 14, 15, 16, 17, 18, 19], maxlen=10)

Вообще, из модуля я collections я часто использую defaultdict, ну и эпизодически Counter.

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

# inits
SKIP_PROBABILITY = 0.5
HIST_TRACE_LENGTH = 2

def make_deque():
return deque(maxlen=HIST_TRACE_LENGTH)

last_known_capacities = defaultdict(make_deque)

# API monitoring
for combination in tqdm(combinations):
# check stable combinations less often
recent_capacities = last_known_capacities.get(combination)
if recent_capacities and (len(recent_capacities) >= HIST_TRACE_LENGTH):
if np.std(np.array(recent_capacities)) == 0.0:
if random.random()<SKIP_PROBABILITY:
nskipped += 1
continue

# call the API
new_score = API(combination)
# track result
last_known_capacities[combination].append(new_score)
#git #modularity #advicewanted

Товарищи, а как правильно расшарить репозиторий гит с другими репозиториями? Или хотя бы один модуль. На pip выкладывать нет смысла т.к. код слишком заточен под конкретную группу проектов. API репошка читает из базы, ETL репошка делает процессинг, один и тот же код коннекта к базе хочется как-то без copy-paste использовать и там и там. Как бы это сделать, кто сталкивался?

P.S. Решил пробовать субмодули. Мой накопленный опыт:
1) нужно создать общий репо с как минимум 1 коммитом, например, base
2) в одном из главных репо делаем git submodule add https://github.com/myacc/base
в результате появляется папка base со всеми файлами из общего репо.
обращаемся к коду как from base.xxx import y
3) если общий репо Вы обновили, git всё равно будет использовать в главных репо старые коммиты.
поэтому в каждом основном репо надо будет сделать git submodule update --remote
4) похоже, хуки github actions по умолчанию не работают с сабмодулями, и нужно настраивать submodules: true. Проверяю. Проверил, действительно, в .github\workflows\docker-image.yml надо прописывать
jobs:
build:
name: Build container image
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v3
with:
submodules: 'true'

тогда хуки не ломаются.

Поправка: лучше вроде бы использовать git submodule add -b <branch> <repository> , что должно позволить родительскому репо привязываться не к коммиту, а к голове ветки. Но я не понял, когда этот механизм должен включиться.

В целом, сабмодули (или подмодули?) позволили избежать повторяющегося кода. Я уже наступил на грабли, когда код одной и той же функции в разных репо рассинхронизировался, теперь такой ерунды не будет. Пара команд git submodule update --remote - небольшая цена за это удобство, мне кажется.
#war #poetry

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

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

Лёд укрыл лужи стужей – блестящий и тонкий щит.
И я шла, примечая уставших сутулых седых мужчин,
скорбных женщин в платках, телогрейках, сетях морщин.
Каждый третий груз смерти в себе, на плечах тащил.

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

К. Вернер
Forwarded from Борис опять
#лабораторный_журнал

В прошлый раз я писал о том, что запустил свой проект на работе. Система используется. Очень приятное чувство когда смотришь на дашборд и там квадратики окрашиваются в зеленый или красный цвет (в зависимости от того, нашли агрономы проблему в этой локации или нет).

Мир дал мне обратную связь по моим инженерным скиллам: я ушел в отпуск на две недели, а мне никто не звонил и не писал и даже джун пару вещей допилил не сломав прод.

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

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

Начал экспериментировать по части ML. Выкачал семпл в 10к изображений и попробовал самый тупой бейзлайн предсказания возраста растений: Random Forest на гистограммах цвета. Внезапно получились предсказания с типичной ошибкой в +-1 день, MAE 0.8. Посмотрел примеры где предсказанный возраст сильно отличается от настоящего и там часто встречаются разного рода аномалии. Правда чаще всего технические проблемы. Если такой подход способен хоть что-то предсказывать, то нейронки должны легко решить проблему. Поэтому я пишу пайплайны для сбора датасета на 500к изображений и получения frozen features с помощью CLIP. Накинем сверху логрегрессию и будет счастье.

Но это конечно просто эксперименты, а параллельно будет идти настоящее построение ML системы. В первую очередь сбор требований. Скорее всего сформируем задачу поиска одного типа аномалий, утвердим какой нам нужен precision и будем максимизировать recall системы. Далее будем думать как именно придти к этому: через предсказание роста растений или как-то еще.
#ml #eugeneyan #designpatterns

Внимание зацепили концепция Data Flywheel, Feature Store из Process Raw Data Only Once, Curriculum Learning из паттерна Hard Negative Mining, Self-Attentive Sequential Recommendations, Behavior Sequence Transformers, BERT4Rec из паттерна Reframing, Calibrated Recommendations из паттерна Business Rules, и следующий пассаж из паттерна HITL:
"Recent studies have found large language models (LLMs) to perform on par, or better than, people at labeling ground truth.

For example, a study found that gpt-3.5-turbo outperformed Mechanical Turk workers for four out of five annotation tasks (relevance, topic detection, stance detection, and frame detection) on 2,382 tweets. Furthermore, the cost was less than $0.003/annotation, making it 5% of the cost of Mechanical Turk per annotation.

Another study used gpt-4 to classify the political affiliation of Twitter users based on their tweets. Here, LLMs not only outperformed experts and crowdsourced workers in terms of accuracy, they also had higher inter-rater reliability. Even when the crowdsourced and expert labels were ensembled via majority vote, LLMs still performed better."

https://eugeneyan.com/writing/more-patterns/
#krapivin #fantasy

Что же пишет Ерёма?
Я развернул лист и увидел раздёрганные строчки:

"Биригитес их они не люди Приход ити ввагон я расскажу я узнал Эрема".

Я перечитал записку. Почти ничего не понял, но стало опять зябко и неуютно. Ерёма никогда не шутил и никогда не тревожился зря. Что-то случилось. И я побежал!

Я не успел.

***

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

— Давай пиши, — сумрачно сказал мне Юрка. — Ты кистями работать привык…

Он дал мне кисточку и банку с чёрной несмываемой краской.

— Только не надо, что он был робот… — попросил Янка.

Я вывел на бетоне:

ЕРЁМА

Погиб 6 августа 210 г. к. э.

Ерёма погиб за час до того, как я сюда прибежал.

Он шёл через пути к вагону. По ближней от вагона колее мчался электровозик технической службы. Ерёма остановился метрах в двух от рельсов, чтобы пропустить его. Всё это было у Глеба на глазах. Ерёма стоял спокойно, на электровозик даже не смотрел. Когда машина проносилась мимо Ерёмы, из неё высунулось что-то длинное и тонкое — то ли рельс, то ли грузовая стрела. Концом она ударила Ерёму в спину, и он взлетел высоко в воздух… А падал уже отдельными кусками…

https://e-knigi.com/detskaya-literarura/detskaja-fantastika/page-2-212244-vladislav-krapivin-golubyatnya-na-zheltoi-polyane.html
#cron #bash

Столкнулся с проблемой запуска скрипта по расписанию, целая эпопея. В винде оно как-то проще настраивается, есть Task Scheduler, можно в GUI накидать команды и аргументы, указать учётки, выставить расписание и параметры (к примеру, галочку Do not start a new instance if the task is already running), и готово. В Linux всё оказалось не так просто. Вот работающий рецепт (к которому я пришёл методом проб и ошибок), который каждую минуту проверяет питоновский скрипт, если он не запущен - запускает:

ставим либу отправки емэйлов (т.к. крон шлёт уведомления на емэйл хозяина задачи, если что не так) и run-one чтобы не запускать новый процесс, если старый ещё выполняется

apt-get install postfix
apt-get install run-one

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

crontab -e
добавляем строчку
*/1 * * * * cd /your/dir/ && run-one bash yourtask.sh

причем последней в файле должна быть пустая строка (?). сохраняем.


в папке /your/dir/ должен быть файл yourtask.sh с содержанием

#!/bin/sh
export PYTHONPATH=/your/libspath
python3
yournoscript.py --yourparam="paramval" &> yourtasklogfile.log

&> yourtasklogfile.log перенаправляет вывод в соотв. файл, все ошибки пойдут туда же вместо емэйла.

https://www.hostinger.com/tutorials/cron-job
👀1
#python #langdetect #nlp

Кто пользуется либой langdetect для определения языка - она не очень точная (по кр мере, на коротких фразах). Можно проверять с помощью google translate api.