Почему при выборке элементов SQLite в Android studio суммируемые числа округляются до целого?

Надо сменить тип данных. Я отпишу в ответы.

Почему при выборке элементов SQLite в Android studio суммируемые числа округляются до целого?

А что у тебя покажет

SELECT typeof(x) FROM table

?

Как решить проблему с уникальностью ключей?

Можно. В Postgres поддерживается синтаксис insert ... on conflict ....

Читай здесь https://www.postgresql.org/docs/current/sql-insert.html

Как решить проблему с уникальностью ключей?

Георгий Кузнецов, очисти таблицу и загрузи все заново.

Как решить проблему с уникальностью ключей?

Георгий Кузнецов, таблицу обычно создают с помощью скрипта. Типа CREATE table .... primary key. .... unique.
И вот там где стоят primary/unique - надо искать твою ошибку. Названия полей.

Я могу предположить что ты просто второй раз загружаешь данные и ловишь uniq constr violation. Но я не люблю гадать и смотреть в хрустальные шары. Я хочу видеть названия таблиц и колонок.

Будь так любезен.

Как решить проблему с уникальностью ключей?

Покажи как была создана таблица.

Почему двумерные массивы работают чуть быстрее одновременых?

Даниил, помогло? У меня нет шарпов под рукой. Я не могу проверить.

Как сделать много вставок в HashMap за минимальное время?

Многие новички впадают в максимализм. Если мы строим БД с обратной связью (грузим данные за 4 секунды) на 5 секунде хотим уже делать доступ к этой БД - то я спрашиваю что это за системая такая? Что за ТЗ которое обеспечит 3 миллиона RPC (транзакций) за 4 секунды и сразу-же пойдет запрашивать их? Что за дата-центр такое в состоянии создать? Я не знаю. Не видел никогда.

Задачи быстрой загрузки (bulk/batch load) да такие были. Но загрузить такой рандомный шум что автор придумал - можно было и в кольцевой буфер или в массив и потом в фоновом режиме спокойно положить в хеш-табличку. Даже системы реального времени не обязаны стартовать за реальное время. Всегда есть компромисс. Биржевые системы работают с сутошным циклом. Днем работают. Ночью - на техобслуживании. Вот вся ночь впереди. Ребутай систему. Грузи справочники хоть 8 часов. Время есть.

Лет 10 назад в одном из форумов рунета один юноша строил свою ин-мемори БД с нано-секундным откликом. Вобщем приводил много синтетических тестов. Но физика все порешала по другому. Нет сегодня
хорошей оперативной памяти с таким доступом. Есть кеши но они не для БД а для других дел.

Наносекунда - это кстати краеугольный камень перформанса. Если перевести на язык оптики - то
это 30 сантиметров пролёта света. Вот смотрите на свой системный блок и ищите сколько
пролетит свет за это маленькое время.

Вобщем новички вместо реальной задачи - создают себе синтетический тест и ловят на нем парадоксальные
эффекты. То измеряют производительность toString. То измеряют ре-аллокацию хеш-таблички. То
создают параллельные потоки.

Почему двумерные массивы работают чуть быстрее одновременых?

Даниил, я честно говоря не помню как DotNet расставляет элементы в памяти. Но ты словил эффект удачного попадания в кеш для многомерных массивов а для одномерного почему-то расклад был неудачен.

Почему двумерные массивы работают чуть быстрее одновременых?

Сделай тест подлиннее. Хотя-бы в 1 минуту на каждую матрицу.
И попробуй перевернуть индексы местами (i,j).

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

Как сделать много вставок в HashMap за минимальное время?

Eugene-Usachev, в мае месяце ты хотел вкатиться в айти а в июле уже критикуешь структуры данных Rust.

Молодца..

Вообще async созданы для операций I/O. Условия таковы. Есть к примеру одно устройсво. Сетевушка или диск.
Оно не параллелится нифига. Такова его природа. И оно блокирует 1000000 потоков. Потоки-ждуны.
Сидят и ждут пока медленное устройство раздуплиться. Вот. Но ждать можно по разному. Вот технология
async это один из видов ожидания.

А ты чего хотел вообще от асинка получить в данном примере?

Как сделать много вставок в HashMap за минимальное время?

В синхронной версии всё работает, но медленно (во-первых, я вынужден вызывать get у map дважды, во-вторых, писать синхронно в целом долго).

Сколько времени у тебя занимает загрузка 3 млн ключей в синхронной версии?

Как приложение синхронизирует данные с разных операционных систем?

Saashmalysh, я не смог. Для решения моих задач надо сливать этому чяту бизнес информацию. Так вот чтоб закинул вопрос и получил ответ - не выходит. Груминг на пару дней. А какие с ним пару дней когда у него 16 килобайт контекста всего.

Как приложение синхронизирует данные с разных операционных систем?

Saashmalysh,

А как эти данные на этот сервер помещаются? Нужно как-то договариватся с какой-то серверной типо, чтобы она предоставила место для моего приложения? Я вот вообще не шарю. Это всё же программированием делается, нет? Как это вообще сделать короче, чтобы они там хранились?

Подожди годика полтора. Появиться искусственный интелект с No-Code. И будешь
устные приказы отдавать. Типа - а ну создай сервер! Синхронизируй! Так-то!

Я не шучу.

P.S. Оптимальность решения правда не гарантирована.

Как лучше развернуть двумерный массив?

А может тебе лучше исходный массив вот так задавать?

let arr =
    [
    1,2,3,
    1,2,3,
    1,2,3
    ]

Тогда формула проще выходит. И вращать и отражать и гиперкубы делать.

Идеальное хеширование без чтения из памяти параметров h2(k)?

floppa322,

А contains(k) у PerfectHashTable фактически единственный метод

если тебе нужен только contains - то посмотри в сторону Фильтра Блума. Это - probabalistic проверка но она
надежно работает для закрытие большего числа запросов.

Вобщем я выдохся. Я думаю что твой тюнинг он - очень специфичен. И его нельзя решать только теоретически.
У тебя должно быть как минмум 3 макета софта. Под open-adressing и под separate-chaining и под твой идеальный квадрат. Я напомню что самые лучшие реализации алгоритмов - обладают сильной когерентностью по памяти.
Это связано с кешами в железе. Поэтому твои теоретические обоснования могут сильно ошибаться в практике.
Вот. И результатом этих трех макетов должны быть 3 бенчмарка где ты показываешь практически
время инициализации структуры и среднее время доступа.

Вобшем все. Коллеги. Прошу отписать ваше мнение.

Идеальное хеширование без чтения из памяти параметров h2(k)?

floppa322, я все таки хочу понять мотивацию. Тебе нужна вспомогательная стуктура для алгоритма. Если ты уже дошел до такой ситуации что тебе нужна мемоизация расчетов (max(id)) то будь добр - потрать время на подготовку.
Основной алгоритм отработает быстро. Если хочешь идеальное хешировние - то по ссылке которую ты приводишь все равно нет гарантий что идеальная генерация закончится в 1 итерацию. Тоесть полюбому построение таблицы у тебя - слабое место. Ищи компромиссы.

Идеальное хеширование без чтения из памяти параметров h2(k)?

floppa322, дружище если ты оптимизируешь время загрузки данных в таблицу - то ты сразу проиграл. Бери метод списков и все будет работать чудесно.

Хочешь открытая адресация с майнингом - попробуй не удваивать а умножать на 10% размер массива. Там именно массив а не бакеты. Я думаю что через 2-3 итерации все сойдется.

By the way. Я понимаю что ты - теоретик. Но мне всегда интересна практическая сторона вопроса. Какие ключи
ты хочешь хранить? Строки? Числа? Сколько из будет? Какой лимит времени ты хотел-бы потратить на
инициализацию системы? Вот меня как дата-инженера это в первую очередь беспокоит. А вовсе не нелинейность.

Идеальное хеширование без чтения из памяти параметров h2(k)?

floppa322, вот вики пишет

Данная технология применяется в различных словарях и базах данных, в алгоритмах со статической (известной заранее) информацией.

я вот как себе это понимаю. Есть справочники которые редко меняются. Страны. Валюты. Языки. Всякие там биржевые тикеры. У тебя всегда есть достаточно времени чтобы расчитать эту таблицу почти идеально.

Вариант с 2 таблицами я-бы сразу выкинул. Неэффективное использование памяти. И выигрыш - ничтожный.

Идеальное хеширование без чтения из памяти параметров h2(k)?

Пишу как-бы мозговой штурм по теме.

Хеш таблицы (ХТ) бывают двух видов. В основном. Это метод списков и открытая адресация.
В промышленности и в бизнесе (насколько я видел) в основном используется первый тип ХТ. У них
нет проблемы которую ты нарисовал. Никакие двухуровневые таблицы им не нужны. И этот тип реализован в С++/Java/C# e.t.c. библиотеках поддержки коллекций. В некоторых современных вариантах списки могут
превращаться в красно-черные деревья. Поэтому может быть гибрид хеш+R&B.

Второй тип подходит для редких кейсов типа хранения примитивов достаточно компактно. Но надо тонко
подбирать грань keys/capacity чтоб не попасть в ситуацию 3 и 4 и 5 обращения к памяти. Там будет резкий
рост времени отклика.

Твое идеальное хеширование в принципе сводится ко 2 типу. Надо только подбирать keys/capacity до тех пор пока нет коллизий и нет повторных чтений. Учитывая что у тебя идеальное хеширование (ключи не меняются) то можно майнить такие
конфигурации. Тоесть подбирать их длительное время для достижения почти идеального результата.

Эффективность твоего метода также зависит от выбора менеджмента памяти. Допустим для Java там возможностей не очень много а для С++/C можно играть union поинтеров и самих данных и достигать каких-то более лучших
результатов. Например делая вспомогательные структуры более компактными.