Я правильно тебя понял? Ты считаешь, что uuid это такое хеширование. Что можно скормить некой функции некий id в виде числа и получать на выходе один и тот же uuid. Если так, то ты ошибаешься.

но все равно спасибо этот ответ меня осветил)

но все равно спасибо этот ответ меня осветил)

Просто ты хочешь что-то странное. Зачем uuid вместо обычного инкрементирующегося айдишника? Хотите скрыть количество книг в базе?

нет, хотел попробовать uuid4 в деле, но понял что прогорел(

Я правильно тебя понял? Ты считаешь, что uuid это такое хеширование. Что можно скормить некой функции некий id в виде числа и получать на выходе один и тот же uuid. Если так, то ты ошибаешься.

Можно. Uuid3

Будет md5

Можно вообще uuid числом инициализировать.

Можно. Uuid3

Ну у него конкретно v4

Ну я вообще скептически к uuid отношусь

Ну я вообще скептически к uuid отношусь

Почему?

Вообще не понимаю зачем они. Как формат представления 128-битного id только если.

Ну я вообще скептически к uuid отношусь

Хватит ретроградствовать, начинай любить

Как правило тройка клиентский id+серверный id + id сервера надёжнее

Вообще не понимаю зачем они. Как формат представления 128-битного id только если.

Можно в разных инстансах БД генерировать pk и быть уверенным, что они уникальны.

Либо клиентский id + id сессии + id юзера

Можно в разных инстансах БД генерировать pk и быть уверенным, что они уникальны.

Нельзя. Можно быть уверенным, что они почти всегда уникальны.

Так чем плох uuid?

Скорее всего уникальны

Так чем плох uuid?

Uuid4?

Не люблю гарантию через вероятность

Хотя наверно риск неуникальности приближается к риску потери бд

Нельзя. Можно быть уверенным, что они почти всегда уникальны.

Можно. Ты посмотри на вероятность коллизий.

Это довольно интересный вопрос. А серийные ID?

Можно. Ты посмотри на вероятность коллизий.

Ну да, я понимаю. Что 128 бит вряд ли совпадут.

Они могут совпасть, но вроде pk, uniq не даст этому случится. Хотя тут от реализации зависит

Не люблю гарантию через вероятность

Криптовалюту, стало быть, тоже не уважаешь?

В том же mongo, нет serial.

Криптовалюту, стало быть, тоже не уважаешь?

Ну почему. Там есть алгоритмы исключения коллизий. И там не 128 бит, а побольше

Но однозначно serial и uuid4, со вторым все медленнее чем с serial, и чуток больше всего. Проверок, реализации

Ну почему. Там есть алгоритмы исключения коллизий. И там не 128 бит, а побольше

Ну всё равно вероятности же.

В интернет вообще утекла база со всеми приватными ключами от всех кошельков. https://lbc.cryptoguru.org/dio/1

Ну окей, окей

Пойду правда ещё гляну про uuid4 именно

Но с тишкой согласен вероятность совпадения есть, хоть 1 миллионная доля

Тут нужна стабильная стабильная реализация. Чтобы ничего не сломалось

> Set all the other bits to randomly (or pseudo-randomly) chosen values.

Отличный rfc

Всем привет

Нет там гарантии, если у тебя плохой генератор случайных чисел и сломанные часы

При определенных условиях вероятность совпадения можно до 100% довести

Можно. Ты посмотри на вероятность коллизий.

Вероятность коллизий только для реально рандомного uuid. Для псевдослучайных реализаций может быть совсем не так

Вероятность коллизий только для реально рандомного uuid. Для псевдослучайных реализаций может быть совсем не так

Для хороших псевдослучайных с достаточно большим сидом вероятность будет такая же

А это какой язык?

Для хороших псевдослучайных с достаточно большим сидом вероятность будет такая же

Да кто ж спорит. Только какие они реально - хз

С

++

О. Рекомендую всем codephoto.ru

Это не С++

а вот если совпадут, и упала БД на продакшне(

Это не си

Не упадет там ничего, просто инсерт не сработает

Не упадет там ничего, просто инсерт не сработает

всё равно боль ;0

Да кто ж спорит. Только какие они реально - хз

Сорцы открыты

Не упадет там ничего, просто инсерт не сработает

Сработает. Мы же про несколько шардов говорим. А потом блаблабла more than one row где-нибудь

Сработает. Мы же про несколько шардов говорим. А потом блаблабла more than one row где-нибудь

Можно в него включать номер шарда, тогда точно не совпадет

Сорцы открыты

Ух, это не криптография, тут не так парятся насчёт рандомов.

Можно в него включать номер шарда, тогда точно не совпадет

Если включать номер шарда, можно без uuid

Ух, это не криптография, тут не так парятся насчёт рандомов.

В криптографии из-за других свойств парятся, а равномерность везде одинаковая

Ну случится коллизия раз в сто лет. И что? Пускай транзакция упадёт. Никак не надо учитывать этот случай. С гораздо большей вероятностью оно всё наебнётся от тысячи других причин.

В криптографии из-за других свойств парятся, а равномерность везде одинаковая

Вот я что-то ни в доках ни в rfc не вижу про то, что рандом не как на картинке будет

Ребята, помогите с задачей. Есть список с координатами вершин графа: points = [(0,0),(12,55)(51,51)...] Необходимо взять две рандомные вершины из этого списка и найти между ними самый короткий путь по другим вершинам. Результат вывести в виде списка path, где path[0] == начальная точка, а path[-1] == конечная точка

Ну случится коллизия раз в сто лет. И что? Пускай транзакция упадёт. Никак не надо учитывать этот случай. С гораздо большей вероятностью оно всё наебнётся от тысячи других причин.

Это да, пусть. Если можно рассчитывать, что там равномерно, а не как попало

Ребята, помогите с задачей. Есть список с координатами вершин графа: points = [(0,0),(12,55)(51,51)...] Необходимо взять две рандомные вершины из этого списка и найти между ними самый короткий путь по другим вершинам. Результат вывести в виде списка path, где path[0] == начальная точка, а path[-1] == конечная точка

А ребра-то даны?

А ребра-то даны?

Нет, только координаты

ERROR: S client not available

Нет, только координаты

Тогда напрямую быстрее всего

А реально. Что за язык?

Тогда напрямую быстрее всего

Напрямую - это как?

Напрямую - это как?

По прямой, проведенной через эти точки

А реально. Что за язык?

Да псевдокод, похоже.

И не swift и не d и не c# вроже

По прямой, проведенной через эти точки

Не, не так понял

Походу java

Походу java

Нет

По прямой, проведенной через эти точки

По прямой другие точки не попадаются, они где-то рядом могут быть с прямой

Походу java

Нет в джаве таких циклов

По прямой другие точки не попадаются, они где-то рядом могут быть с прямой

Надо через все пройти обязательно?

Надо через все пройти обязательно?

Нет, только через те, по которым ближе всего

Нет, только через те, по которым ближе всего

Ближе всего по прямой

Ближе всего по прямой

Да не нужно по прямой) нужно по другим точками)

Это знаете откуда. Решали задачи с acmp.ru

Да не нужно по прямой) нужно по другим точками)

По нулю точек подойдет?

Тут что-то типа Дейкстры нужно наверно

Ты задачу сначала сформулируй внятно, а потом решение придумывай

Все внятно написано

Ничего подобного

Какие требования на путь накладываются?

Какие требования на путь накладываются?

Необходимо найти самый короткий путь

Ребята, помогите с задачей. Есть список с координатами вершин графа: points = [(0,0),(12,55)(51,51)...] Необходимо взять две рандомные вершины из этого списка и найти между ними самый короткий путь по другим вершинам. Результат вывести в виде списка path, где path[0] == начальная точка, а path[-1] == конечная точка

Координаты вершин -> вероятно есть связь любой с любой. А раз "самый короткий" надо ещё искать, а не просто взять первую попавшуюся - вероятно длина ребра - евклидовая метрика.

Так?

Полное задание давай

Необходимо найти самый короткий путь

Это все требования или еще есть?

Координаты вершин -> вероятно есть связь любой с любой. А раз "самый короткий" надо ещё искать, а не просто взять первую попавшуюся - вероятно длина ребра - евклидовая метрика.

Все верно, нужно искать

Это все требования или еще есть?

Вывести результат в виде списка точек, по которым проложен путь

Если полная связность - цикл по всем ребрам и путь с одной пересадкой

Вывести результат в виде списка точек, по которым проложен путь

print([a, b])