Такую информацию сложно принять, ведь она противоречит базовой интуиции и всей физике, известной на тот момент.
Мне кажется дело было не совсем так.
После того, как стало понятно, что эфира, т.е. среды, где распространяется э.-м. волна, нет, встал принципиальный вопрос: чем одна система отсчёта отличается от другой.
Базовая мысль теории относительности, в т.ч. Галилея, что не должно быть уникального места в пространстве, и системы отсчёта не должны отличаться друг от друга. Если представить, что скорость света зависит от скорости движения, то всё ломается.
Мне кажется, относительность Галилея, СТО и ОТО Эйнштейна - это развитие одной и той же идеи, физические законы одинаковы во всех системах отсчёта.
Не понятно как связан объем поступающих новых данных и Anchor modeling. Классический пример, click stream, данных очень много, и скорее всего это будет одна таблица, никак не нормализованная. Кажется, большие таблицы противопоказаны для Anchor modeling. База просто их не соединит.
Тезис про значительную экономию места в связи с отсутствием нулевых значений (null) и дублирования у Anchor modeling тоже сомнительный. Это скорее характерно для колочного хранения, и без дублирования ключа у каждого атрибута.
Думаю, Anchor modeling это про небольшие хранилища в смысле объема, но с большим разнообразием атрибутов, их источников и "текучести".
m оценивается исходя из размера множества и требуемой точности оценки. То есть не является константой. Реальная потребляемая память будет O(log n) при фиксированной точности. Подробнее на википедии
Под грандами ты имеешь в виду пакеты типа cplex? Нет, не пробовал. Пробовал наоборот, с помощью cplex решить эту задачу. Но не удалось быстро разобраться в API. Решил лучше докрутить решение на or-tools, нежели начинать в третий раз заново.
Тоже думал в сторону кластеризации узлов, но показалось очень сложным, чтоб успеть за время конкурса.
В задаче с самокатами ограничения на количество самокатов в автомобиле заводили солвер в тупик, даже в мягкой форме. Мне кажется, это в первую очередь из-за количества таких ограничений. Как будто солвер в самом начале скатывался в локальный минимум и никак не мог из него выбраться. Только хорошее начальное решение позволяло продвинуться. Собственно для получения начального решения и решал без ограничений на вместимость.
Clickhouse хранит и читает информацию блоками. Поэтому для подобных запросов будем видеть значительно больше прочтённых строк, чем ожидаем
Мне кажется дело было не совсем так.
После того, как стало понятно, что эфира, т.е. среды, где распространяется э.-м. волна, нет, встал принципиальный вопрос: чем одна система отсчёта отличается от другой.
Базовая мысль теории относительности, в т.ч. Галилея, что не должно быть уникального места в пространстве, и системы отсчёта не должны отличаться друг от друга. Если представить, что скорость света зависит от скорости движения, то всё ломается.
Мне кажется, относительность Галилея, СТО и ОТО Эйнштейна - это развитие одной и той же идеи, физические законы одинаковы во всех системах отсчёта.
Не понятно как связан объем поступающих новых данных и Anchor modeling. Классический пример, click stream, данных очень много, и скорее всего это будет одна таблица, никак не нормализованная.
Кажется, большие таблицы противопоказаны для Anchor modeling. База просто их не соединит.
Тезис про значительную экономию места в связи с отсутствием нулевых значений (null) и дублирования у Anchor modeling тоже сомнительный. Это скорее характерно для колочного хранения, и без дублирования ключа у каждого атрибута.
Думаю, Anchor modeling это про небольшие хранилища в смысле объема, но с большим разнообразием атрибутов, их источников и "текучести".
Как websocket сказывается на батарее мобильного устройства по сравнению с нативным для ОС транспортом?
m оценивается исходя из размера множества и требуемой точности оценки. То есть не является константой. Реальная потребляемая память будет O(log n) при фиксированной точности. Подробнее на википедии
Под грандами ты имеешь в виду пакеты типа cplex? Нет, не пробовал. Пробовал наоборот, с помощью cplex решить эту задачу. Но не удалось быстро разобраться в API. Решил лучше докрутить решение на or-tools, нежели начинать в третий раз заново.
Тоже думал в сторону кластеризации узлов, но показалось очень сложным, чтоб успеть за время конкурса.
В задаче с самокатами ограничения на количество самокатов в автомобиле заводили солвер в тупик, даже в мягкой форме. Мне кажется, это в первую очередь из-за количества таких ограничений. Как будто солвер в самом начале скатывался в локальный минимум и никак не мог из него выбраться. Только хорошее начальное решение позволяло продвинуться. Собственно для получения начального решения и решал без ограничений на вместимость.