A
А с хранением в одном словаре все равно нужно самому следить за синхроннстью прямых и обратных ключей, так что выгода по сравнению с 2мя словарями вообще не понятна
Size: a a a
2020 September 23
A
Можно еще извратиться и сделать чуть посложнее, но более обще, чтобы можно было трех и больше направленный словарь делать 🙂 Хранить сами данные в виде списка кортежей, а рядом держать словари по нужным ключам с указателями на кортежи. Т.е. по сути сделать аналог индексов в БД
KT
по-моему, в какой-то момент проще взять dataframes )
A
В DataFrames же вроде нет индексации в этом смысле. Там lookup быстрый это да, но если нужны точечные запросы (в смысле получить одну запись по значению ключа) как в словарь, то это явно не вариант.
АО
О! Спасибо кстати за идею 😊
А то у меня в немного другой задаче был сложный ключ, я делал словарь словарей.
Кортеж вроде пошустрее должен быть.
А то у меня в немного другой задаче был сложный ключ, я делал словарь словарей.
Кортеж вроде пошустрее должен быть.
A
Да не за что. Большинство классических БД так построено - есть длинный список строк таблицы в том или ином виде где-то на диске более-менее отсортированный по первичному ключу. А вторичные ключи лежат отдельно либо как хеш-мапы, либо (чаще всего) как деревья.
ЕП
Alexandr
А с хранением в одном словаре все равно нужно самому следить за синхроннстью прямых и обратных ключей, так что выгода по сравнению с 2мя словарями вообще не понятна
За прямым ключом вроде не надо следить - это же и есть сам словарь?
АО
Ну, имеется в виду, что вставку/удаление всё равно надо будет вручную доопределять.
АО
Никто же не хочет всю машинерию в верхнеуровневом апи каждый раз писать.
Хочется, чтобы было так
а обратная пара прописывалась автоматически
Хочется, чтобы было так
d = BiDict{String, String}()
d["hello"] = "world"а обратная пара прописывалась автоматически
KH
https://twitter.com/julialanguage/status/1308436062688153604?s=21
Если кто-нибудь хочет участвовать. Может будет получить эту красивую футболку
Если кто-нибудь хочет участвовать. Может будет получить эту красивую футболку
2020 September 24
VG
Странное приведение типа:
julia> Int64(-2) + UInt64(0x1)
0xffffffffffffffff
julia> Int32(-2) + UInt32(0x1)
0xffffffff
julia> Int16(-2) + UInt16(0x1)
0xffff
julia> Int8(-2) + UInt8(0x1)
0xff
julia> Int64(-2) + UInt32(0x1)
-1
julia> Int32(-2) + UInt16(0x1)
-1
julia> Int16(-2) + UInt8(0x1)
-1
Д
Как я понимаю в этом примере, Джулия выбирает такой тип данных результата, чтобы он желательно включал в себя оба типа данных суммы.
А есть общее правило или алгоритм выбора типа данных результата?
А есть общее правило или алгоритм выбора типа данных результата?
AP
смотрите в сторону promote_type:
julia> promote_type(Int, UInt)
UInt64
julia> promote_type(Int, UInt32)
Int64
julia> promote_type(Int, UInt)
UInt64
julia> promote_type(Int, UInt32)
Int64
Д
Спасибо, пойду поковыраюсь
2020 September 25
АО
А, ну кстати да, логично же получается.
АО
UInt32 - 4 байта, Int - 8
АО
Общий тип помещается в 8 байтах
АО
Правда не очень понятно, что такое UInt
АО
Хм, нет, все наверное сложнее, просто размером не объясняется