Pull to refresh
1
0
Александр Косенков @kosiakk

User

Send message

Я бы попробовал сделать тот же анализ при помощи очень старого и очень доброго SQL. Если все данные в одной таблице то ClickHouse точно так же сработает за миллисекунды (на практике видел это на 4 TB данных). А если в запросе нужно совместить несколько таблиц, то я ожидаю что классический PostgreSQL сможет найти более эффективный план запроса и сделать join быстрее чем самый быстрый Rust но "в лоб".

Вот чуть более полный бенчмарк, где Polars сравнивают с ClickHouse https://h2oai.github.io/db-benchmark/. ClickHouse там оказывается в полтора раза медленнее, действительно. Однако тест проходит лишь на 50 GB данных, хотя даже для одного сервера Clickhouse это не ощутимая нагрузка, не говоря уже о кластере.

Наверно, если портировать какой-нибудь неплохой SQL движок на Rust, то будет совсем хорошо. Например https://surrealdb.com/ так делают, но с нуля (и пока что без оптимизации запросов)

Сколько строчек или мегабайт в flights-data?

Я как раз недавно замерял - на localhost выдаёт 30 отдельных Select в одном потоке. Если запустить 32 потока по числу процессоров, то получается 400 отдельных запрос-ответов. Каждую миллисекунду. Т.е. 400'000 запросов в секунду на базе 0.3 ТБ. Если послать большие аналитические запросы, то будет ещё быстрее - один поток агрегирует 9 миллионов строк в секунду. Не ClickHouse, конечно, но для бизнес-данных этого достаточно с лихвой.

Я бы купил такую обёртку вокруг PG, просто чтобы предоставить привычный GUI Экселя для бизнес-аналитиков. Кстати, возможно, MS Access может интегрироваться с внешними БД?

Классная идея! Хотя Pivot в Excel считается уже очень продвинутой технологией, всё равно база пользователей больше, чем у любого другого инструмента.

На мой взгляд, такой адаптер будет полезнее даже не BigData, а для обычных SQL движков. Если в фирме уже есть ClickHouse, это скорее всего означает что там есть необходимость, и возможность (профессионалы, которые установили и заполняют).

Но ведь есть несравнимо больше компаний, где данные прекрасно умещаются в Postgres! И там как раз есть потребность в понятном GUI.

Через 15 дней в кошельке всё ещё 1.76182100 BTC, максимум тысяча долларов.
Как-то не живо идёт аукцион
Matlab нумеруется как 2015a, 2015b, 2016a и тд.
Они обычно выпускают два релиза в год.

Это лучше, т.к. нет путаницы с месяцами.
Убунту же пишет именно месяц: 14.04 (апрель), 14.10 (октябрь)
> Так как чуть ли не каждый слот памяти заворачивается в атом, то реализация атомов должна быть максимально быстрой и компактной.

Сразу напомнило Datomic — это очень приятная база данных, похожая на RDF, OrientDB или Node4j — только с ещё более простыми и фундаментальными концепциями
Захватывающе!

А вы пробовали использовать не движение камеры, а перемещение объекта? Ведь в реальности оба движения происходят одновременно.
Я представляю, что в таком случае смещение будет ещё нагляднее: неподвижный «плоский» фон без движения и «выпуклый» объект. Тут же бонусом и отделение объекта от фона получится.

Насколько гласит легенда, некоторые хищники именно так и видят: им тяжело классифицировать неподвижные предметы.

Вашу систему уравнений, мне кажется, можно расширить, для каждого кадра видео:

новая точка i (t+1) = (старая точка i (t) + движение точки i (t) ) * движение камеры (t)

не уверен что за операция там вместо звёздочки — умножение или сложение.
Добавим ограничения из физического мира:
— движение точки равномерно
— движение камеры равномерно (и есть априорная оценка)
— движение точки совпадает с движением её «группы» (принадлежность точки группе получаются кластеризацией точек по вектору движения)

В общем случае движение камеры это все 6 степеней свободы, а для точек достаточно 3.

И будет полноценный решатель: видео -> трёхмерная модель пространства и камеры :-)
Действительно, не знал. Спасибо!
Я как-то пользовался random-shuffle, но не понял, почему функция не возвращает новый gen? Получается, что эта функция — «тупик» для генератора случайных чисел? Как это обойти, если нужно, допустим, два случайных поля?
Кажется, весь смысл bugbounty в том, чтобы не объявлять о таких ошибках публично (и зарабатывать карму), а писать им лично (и зарабатывать доллары).
Мы не придираемся к словам, нет :-)

Да, исправление после этого поста произошло очень оперативно! Тут разработчики Яндекса молодцы, вопрсов нет.

В 23:16 появился пост, через полтора часа (ночью) появился комментарий «исправили». Это здорово и оперативно.
Знаем? Исправим?

Эти два слова совершенно не вяжутся в одном предложении про безопасность.
Если вы сами знали о проблеме, и осознанно решили отложить исправление, то это кромешный ад.

АД
general ledger это круто, да. Я тоже пришёл к тому, что этот подход обязан быть в любой рассчётной системе, не только в банках.

Вот ещё интересные мыли на эту тему: habrahabr.ru/post/244465/
А как в байткоде представлены отложенные присвоения?

final int a;
if (...) a = 5; else a = 6;

Будет ли анализатор рассматривать эту переменную, в качестве константы? А если без final?
А возможно линеаризовать эти уравнения?
Если представить её как модель в пространстве состояний, то многие свойства системы (те же гармоники) можно вычислить почти аналитически, вообще без интеграции по времени.
Ну да, в итоговом отчёте на конец месяца нужны именно две тонны.
А в операционном отчёте на любую конкретную дату, в т.ч. «на сегодня» — отдельно плюс и минус.

Разве не так?

Причём, большинство вещей может иметь (для транзакционной целостности) лишь положительный баланс. Какие-то (вроде выданных кредитов) — только отрицательный баланс.
Скорее наоборот, каждая валюта это отдельная сущность в базе! «Вещь», если хотите.
Деньги в кассе тоже совершенно отдельная вещь с суб-счетами по каждой валюте.

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

Так что ответы на ваш вопрос в такой системе полностью возможны. Решение о группировке и пересчёте принимается в момент составления отчёта, а не записи в БД. Просто бухгалтер не должен просить систему приводить всё к рублям, а оставить «как есть».

Более того, валюта в разной форме / счетах — это разные вещи. 100 руб в Сбербанке и 100 руб в ПСБ это разные вещи. Особенно они разные при обвале банка. Транзакция про будущую страховую выплату:

— 1 млн 200 тыс единиц «Рубль в банке Рога и Копыта» (произошло вчера)
+ 700 тыс единиц «Рубль в Сберьбанке» (произойдёт через 3 месяца)

Извините, если спутано объясняю, но в своей «методологии» я хотел избежать лишнего приведения всего в деньгам, а по-максимуму сохранять натуральные единицы.
Вот здорово! Бухгалтерский учёт без придурей. Ну и изучение ЯП до такого достойного уровня вызывает глубокое уважение!

Я для себя упрощал БУ так:
1. С помощью отрицательных чисел: у меня -2 яблока = я должен 2 яблока
Сумма каждой проводки аксиоматически принимается равной нулю, так что sum(Credit) = sum(Debit)
sum(Credit) — sum(Debit) = 0.
Какие-то счета удобнее вести, помножив всё уравнение на -1, но это нужно лишь для преставления пользователю.

А вы учитываете отрицательные значения?

2. Применения единиц измерения в расширенном физическом смысле.

Цена это коэффициент преобразования одной величины в другую.
2 яблока — 1 груша = 0 рублей (баланс операции обмена)
это можно решить, например, если ввести коэффициенты преобразования яблок и груш в рубли — их цены.

Таким образом, денежное представление баланса является лишь одним из возможных. Для управленческого учёта можно представлять базу сразу в натуральных единицах. Это как выбор единиц измерения для графиков — кг или граммы. Меняются коэффициенты и числа, но «суть» остаётся той же.
Возможно, workflowy.com подойдёт для текстовых записей значительно лучше.
Возможно ли автоматическое аннотироване подходящих функций?
Допустим, в контексте того же LLVM. На этапе, когда все основные оптимизации (вроде выноса инвариантного кода за цикл) уже выполнены, но код ещё не векторизован — оптимизатор может попробовать оценить пригодность метода для каждого очевидного цикла…

Ещё круче может оказаться применимость для JVM или V8 — их JIT-компилятор уже умеет анализировать циклы и применяет loop unrolling для «небольших» циклов. Я могу представить, что туда можно дописать «else» и попробовать оценить применимость вашей опимизации к тому циклу.

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

Information

Rating
Does not participate
Location
Zürich, Zürich, Швейцария
Date of birth
Registered
Activity