Здравствуйте, -Cheese-, Вы писали:
C>К сожалению нужно именно 12-значное... Случайность желательна... но главное, просто чтобы не прослеживался принцип формирования числа
Ты всё еще мучаешься? Корректное решение было подсказано неделю назад. На его реализацию нужен примерно час. В чем проблема-то?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, _d_m_, Вы писали:

___>>Что тебе конкретно непонятно: число знаков или что уникальное? То что уникальное, поверь на слово или почитай по технологиям шифрования — объяснять долго.
S>Зато я могу быстро: 12значных десятичных чисел всего лишь 10^12. Это примерно 2^36. А гуидов — 2^128.
S>Поэтому одному числу соответствуют примерно 2^92 гуидов. Поэтому мне совершенно непонятно, откуда возьмется уникальность этого числа.

Неа, не можешь быстро.
Она берется от гуидов Ясен пень, что уникальность 12 разрядного десятичного числа будет меньше, чем у 39 разрядного десятичного числа. И что хэш будет совпадать для некоторых гуидов.

Здравствуйте, Sinclair, Вы писали:


___>>Что тебе конкретно непонятно: число знаков или что уникальное? То что уникальное, поверь на слово или почитай по технологиям шифрования — объяснять долго.
S>Зато я могу быстро: 12значных десятичных чисел всего лишь 10^12. Это примерно 2^36. А гуидов — 2^128.

Прежде чем лепить минусы, может сначала подумать стОит? Частотная характеристика моего метода будет соответствовать частотной характеристике генератора гуидов, но в заданном диапазоне — 10^12. И если имеем белый шум на входе, то мы его имеем и на выходе. Так в чем недостаток моего метода? Хотелось бы увидеть нормальные аргументы, а не вопросы в ламерском стиле "откуда уникальность" . Плюс мое решение можно улучшить — хэш алгоритмов множество, я же предлагаю способ решения, а не готовую реализацию.

Здравствуйте, _d_m_, Вы писали:

___>Неа, не можешь быстро.
___>Она берется от гуидов Ясен пень, что уникальность 12 разрядного десятичного числа будет меньше, чем у 39 разрядного десятичного числа. И что хэш будет совпадать для некоторых гуидов.

Муахахаха, ты в одном посте пишешь:
>>> Бери uniqueidentifier и соединяй куски XOR-ом.
>>А почему ты решил, что после соединения получится уникальное 12-значное?
>... То что уникальное, поверь на слово

А затем ты пишешь "хэш будет совпадать для некоторых гуидов". Ты либо используй слово "уникальное" в общепринятых смыслах, либо не используй вообще. Тогда будет проще тебя понять.

Но это все лирика, ты не объясняешь главного. Чем твой метод все-таки лучше, чем предложенный ранее вариант генерировать числа рандомом+хранить таблицу уже использовавшихся чисел? Он быстрее, надежнее, проще в реализации?

Здравствуйте, yogi, Вы писали:

Y>Здравствуйте, _d_m_, Вы писали:

Y>А затем ты пишешь "хэш будет совпадать для некоторых гуидов". Ты либо используй слово "уникальное" в общепринятых смыслах, либо не используй вообще. Тогда будет проще тебя понять.

А что такое уникальность в общепринятом смысле? Никакой тебе генератор ни GUID-ов и ни что-либо еще не обеспечит уникальность в общепринятом смысле. Для этого используются в БД уникальные ключи.

Y>Но это все лирика, ты не объясняешь главного. Чем твой метод все-таки лучше, чем предложенный ранее вариант генерировать числа рандомом+хранить таблицу уже использовавшихся чисел? Он быстрее, надежнее, проще в реализации?

Мой способ — это и есть рэндом для 12-ти разрядных чисел.
Нахрена еще одна таблица, когда уже есть таблица — осталось на это поле с числами повесить уникальный индекс и:
— либо проверять запросом существует ли такое значение;
— либо ловить исключение violation unique бла-бла-бла и обрабатывать специальным образом;
Второй вариант предпочтительнее. Объяснить почему?

Здравствуйте, _d_m_, Вы писали:

Y>>Но это все лирика, ты не объясняешь главного. Чем твой метод все-таки лучше, чем предложенный ранее вариант генерировать числа рандомом+хранить таблицу уже использовавшихся чисел? Он быстрее, надежнее, проще в реализации?

___>Мой способ — это и есть рэндом для 12-ти разрядных чисел.
Чем он лучше, чем вызов стандартных процедур для генерации равномерно распределенного псевдослучайного числа?


___>Нахрена еще одна таблица, когда уже есть таблица — осталось на это поле с числами повесить уникальный индекс и:
Ну вот ты наконец и упомянул, что в твоем способе используется-таки что-то дополнительное (тыблица, индекс и т.п.) для обеспечения уникальности. Раньше ты об этом ничего не писал, а мысли я читать не умею.

___>- либо проверять запросом существует ли такое значение;
___>- либо ловить исключение violation unique бла-бла-бла и обрабатывать специальным образом;
___>Второй вариант предпочтительнее. Объяснить почему?
Нет, мне не интересно.

Здравствуйте, yogi, Вы писали:

Y>Здравствуйте, _d_m_, Вы писали:

Y>>>Но это все лирика, ты не объясняешь главного. Чем твой метод все-таки лучше, чем предложенный ранее вариант генерировать числа рандомом+хранить таблицу уже использовавшихся чисел? Он быстрее, надежнее, проще в реализации?

___>>Мой способ — это и есть рэндом для 12-ти разрядных чисел.
Y>Чем он лучше, чем вызов стандартных процедур для генерации равномерно распределенного псевдослучайного числа?

Назови мне стандартную процедуру для генерации числа не более 12 десятичных разрядов в MS SQL 2005.

___>>Нахрена еще одна таблица, когда уже есть таблица — осталось на это поле с числами повесить уникальный индекс и:
Y>Ну вот ты наконец и упомянул, что в твоем способе используется-таки что-то дополнительное (тыблица, индекс и т.п.) для обеспечения уникальности. Раньше ты об этом ничего не писал, а мысли я читать не умею.

В разработке БД — это основы: для обеспечения уникальности используются unique key/primary key.
Здесь форум, а не ликбез по основам СУБД.

Здравствуйте, _d_m_, Вы писали:

___>>>Мой способ — это и есть рэндом для 12-ти разрядных чисел.
Y>>Чем он лучше, чем вызов стандартных процедур для генерации равномерно распределенного псевдослучайного числа?
___>Назови мне стандартную процедуру для генерации числа не более 12 десятичных разрядов в MS SQL 2005.

Знаешь, я не специалист по MSSQL, а ты меня все упорно втягиваешь в обсуждение технической реализации. Тем не менее, коротокий поиск в google показывает, что в MSSQL есть функция RAND(). Если ты не знаешь, как из случайной величины, распределенной равномерно на [0,1) получить случайную величину, равномерно распределенную на [X,Y), то это объясняет твое желание использовать GUID



___>>>Нахрена еще одна таблица, когда уже есть таблица — осталось на это поле с числами повесить уникальный индекс и:
Y>>Ну вот ты наконец и упомянул, что в твоем способе используется-таки что-то дополнительное (тыблица, индекс и т.п.) для обеспечения уникальности. Раньше ты об этом ничего не писал, а мысли я читать не умею.
___>В разработке БД — это основы: для обеспечения уникальности используются unique key/primary key.
___>Здесь форум, а не ликбез по основам СУБД.

Тем не менее, это твое сообщение выглядело так, что достаточно взять GUID, применить к нему магический XOR, и сразу(!) получится уникальное число.

Резюмируя, скажу, что я так и увидел преимуществ предложенного тобой способа. Вижу только много понтов и агрессии.

_d_m_ wrote:

> Прежде чем лепить минусы, может сначала подумать стОит? Частотная
> характеристика моего метода будет соответствовать частотной
> характеристике генератора гуидов, но *в заданном диапазоне* — 10^12. И
> если имеем белый шум на входе, то мы его имеем и на выходе. Так в чем
> недостаток моего метода? Хотелось бы увидеть нормальные аргументы, а не
Он смысла не имеет. Проще взять просто первые 12 разрядов гуида и никаких ксоров не надо.

Мало того, гарантированность криптографически стойкую случайность гуидов сложно (или есть такая гарантия?). Лучше взять генератор, о котором точно известно.

> вопросы в ламерском стиле "откуда уникальность" . Плюс мое решение можно
Какой ещё ламерский стиль? Это требование задачи, читай самое первое сообщение.

> улучшить — хэш алгоритмов множество, я же предлагаю способ решения, а не
> готовую реализацию.
Конечно, но эти хеш-алгоритмы нафиг тут не нужны.

Здравствуйте, yogi, Вы писали:

Y>Здравствуйте, _d_m_, Вы писали:

___>>>>Мой способ — это и есть рэндом для 12-ти разрядных чисел.
Y>>>Чем он лучше, чем вызов стандартных процедур для генерации равномерно распределенного псевдослучайного числа?
___>>Назови мне стандартную процедуру для генерации числа не более 12 десятичных разрядов в MS SQL 2005.

Y>Знаешь, я не специалист по MSSQL, а ты меня все упорно втягиваешь в обсуждение технической реализации. Тем не менее, коротокий поиск в google показывает, что в MSSQL есть функция RAND(). Если ты не знаешь, как из случайной величины, распределенной равномерно на [0,1) получить случайную величину, равномерно распределенную на [X,Y), то это объясняет твое желание использовать GUID

Я то знаю. Но не вижу преимуществ по сравнению с моим методом. Характеристики используемого генератора rand() мне неизвестны, генератора newid() более менее известны.
Я не претендовал на то что мой метод самый правильный или что другие методы неправильны. Это ты своим минусом, своими "му-ха-ха" заявляешь, что мой метод неправильный и плохой и проявляешь агрессию. По поводу недостатков метода я никаких аргументов так и не услышал.

___>>>>Нахрена еще одна таблица, когда уже есть таблица — осталось на это поле с числами повесить уникальный индекс и:
Y>>>Ну вот ты наконец и упомянул, что в твоем способе используется-таки что-то дополнительное (тыблица, индекс и т.п.) для обеспечения уникальности. Раньше ты об этом ничего не писал, а мысли я читать не умею.
___>>В разработке БД — это основы: для обеспечения уникальности используются unique key/primary key.
___>>Здесь форум, а не ликбез по основам СУБД.

Y>Тем не менее, это твое сообщение выглядело так, что достаточно взять GUID, применить к нему магический XOR, и сразу(!) получится уникальное число.

Это всего лишь так тебе показалось. Даже на столбец GUID вешаем уникальный констрэйнт — это азы. Что уж говорить про хэш код GUID-а.

Y>Резюмируя, скажу, что я так и увидел преимуществ предложенного тобой способа. Вижу только много понтов и агрессии.

Но недостатков показать ты так и не смог. Слив засчитан.

Здравствуйте, ., Вы писали:

.>_d_m_ wrote:

>> Прежде чем лепить минусы, может сначала подумать стОит? Частотная
>> характеристика моего метода будет соответствовать частотной
>> характеристике генератора гуидов, но *в заданном диапазоне* — 10^12. И
>> если имеем белый шум на входе, то мы его имеем и на выходе. Так в чем
>> недостаток моего метода? Хотелось бы увидеть нормальные аргументы, а не
.>Он смысла не имеет. Проще взять просто первые 12 разрядов гуида и никаких ксоров не надо.

Это типа аргумент? Но от тебя я другого и не ожидал. Про первые 12 разрядов Ну-ну. Как же мы сразу не догадались.

.>Мало того, гарантированность криптографически стойкую случайность гуидов сложно (или есть такая гарантия?). Лучше взять генератор, о котором точно известно.

А для чего в данной задаче криптографическая стойкость?
И предложи нам здесь генератор, о котором тебе точно известно.

>> улучшить — хэш алгоритмов множество, я же предлагаю способ решения, а не
>> готовую реализацию.
.>Конечно, но эти хеш-алгоритмы нафиг тут не нужны.

Не нужны — не бери. XOR-а достаточно.

Не вижу смысла продолжать с тобой дискуссию, т.к. это опять превращаятся в простое перебрасывания словами. Мои аргументы до тебя не доходят, ты же в качестве аргументов приводишь фразы типа "он смысла не имеет", "хеш-алгоритмы нафиг тут не нужны".

Здравствуйте, _d_m_, Вы писали:

Y>>Резюмируя, скажу, что я так и увидел преимуществ предложенного тобой способа. Вижу только много понтов и агрессии.

___>Но недостатков показать ты так и не смог. Слив засчитан.

Твой метод банально требует больше операций, чем метод с rand(). Вот и недостаток. Теперь своя очередь. Приведи все-таки хоть одно преимущество, кроме "Характеристики используемого генератора rand() мне неизвестны"

Здравствуйте, yogi, Вы писали:

Y>Здравствуйте, _d_m_, Вы писали:

Y>>>Резюмируя, скажу, что я так и увидел преимуществ предложенного тобой способа. Вижу только много понтов и агрессии.

___>>Но недостатков показать ты так и не смог. Слив засчитан.

Y>Твой метод банально требует больше операций, чем метод с rand(). Вот и недостаток. Теперь своя очередь. Приведи все-таки хоть одно преимущество, кроме "Характеристики используемого генератора rand() мне неизвестны"

select top 10
    rand(),
    [name]
from
    sys.objects
;

select top 10
    newid(),
    [name]
from
    sys.objects
;

В результате мы получим на запрос 1 значение rand() и 10 разных значений гуидов.

Здравствуйте, _d_m_, Вы писали:

___>Здравствуйте, yogi, Вы писали:

Y>>Здравствуйте, _d_m_, Вы писали:

Y>>>>Резюмируя, скажу, что я так и увидел преимуществ предложенного тобой способа. Вижу только много понтов и агрессии.

___>>>Но недостатков показать ты так и не смог. Слив засчитан.

Y>>Твой метод банально требует больше операций, чем метод с rand(). Вот и недостаток. Теперь своя очередь. Приведи все-таки хоть одно преимущество, кроме "Характеристики используемого генератора rand() мне неизвестны"

___>

___>select top 10
___>    rand(),
___>    [name]
___>from
___>    sys.objects
___>;

___>select top 10
___>    newid(),
___>    [name]
___>from
___>    sys.objects
___>;
___>

___>В результате мы получим на запрос 1 значение rand() и 10 разных значений гуидов.

Согласен, это аргумент.

_d_m_ wrote:

> .>*Он смысла не имеет*. Проще взять просто первые 12 разрядов гуида и
> никаких ксоров не надо.
> Это типа аргумент?
Да, делай "просто, как только можно, но не проще".

> Но от тебя я другого и не ожидал. Про первые 12
> разрядов Ну-ну. Как же мы сразу не догадались.
Сам удивляюсь, просто не нужно заумничать.

> .>Мало того, гарантированность криптографически стойкую случайность
> гуидов сложно (или есть такая гарантия?). Лучше взять генератор, о
> котором точно известно.
> А для чего в данной задаче *криптографическая стойкость*?
"но главное, просто чтобы не прослеживался принцип формирования числа

Автор: -Cheese-
Дата: 14.07.08

"

> И предложи нам здесь генератор, о котором тебе точно известно.
/dev/random, CryptGenRandom

>> > улучшить — хэш алгоритмов множество, я же предлагаю способ решения, а не
>> > готовую реализацию.
> .>Конечно, но эти хеш-алгоритмы нафиг тут не нужны.
> Не нужны — не бери. XOR-а достаточно.
Но не необходимо.

> Не вижу смысла продолжать с тобой дискуссию, т.к. это опять превращаятся
> в простое перебрасывания словами. Мои аргументы до тебя не доходят, ты
> же в качестве аргументов приводишь фразы типа "он смысла не имеет",
> "хеш-алгоритмы нафиг тут не нужны".
А может ещё нужно B-Tree забабахать и алгоритм Дейкстры применить, не забыв эллиптические кривые и быстрое преобразование Фурье?

Здравствуйте, yogi, Вы писали:

Y>Здравствуйте, _d_m_, Вы писали:

Y>>>Резюмируя, скажу, что я так и увидел преимуществ предложенного тобой способа. Вижу только много понтов и агрессии.

___>>Но недостатков показать ты так и не смог. Слив засчитан.

Y>Твой метод банально требует больше операций, чем метод с rand(). Вот и недостаток. Теперь своя очередь. Приведи все-таки хоть одно преимущество, кроме "Характеристики используемого генератора rand() мне неизвестны"

Пошерстил инет по поводу генерации случайных чисел в MS SQL. Что в итоге: используются два генератора newid() и rand(). С newid() еще комбинируется checksum() — вычисление хэш кода rand() применять не рекомендуют, т.к.:
характеристики генератора неизвестны в отличии от newid()

здесь

Good thing is that NEWID() is "super-nondeterministic". It returns different value for each call, even within a single SELECT query

Стандартную хэш функцию я не использовал из-за требования 12 дес. знаков

Здравствуйте, ., Вы писали:

.>_d_m_ wrote:

>> .>*Он смысла не имеет*. Проще взять просто первые 12 разрядов гуида и
>> никаких ксоров не надо.
>> Это типа аргумент?
.>Да, делай "просто, как только можно, но не проще".

Твой случай — это "проще".

>> Но от тебя я другого и не ожидал. Про первые 12
>> разрядов Ну-ну. Как же мы сразу не догадались.
.>Сам удивляюсь, просто не нужно заумничать.

Ну ты пошукай как-бы по инету — и удивись везде гуиды с хэш функциями и ни разу никто 12 разрядов "просто" не отрезал Почему твоя мысль не гениальна, пусть кто-нибудь другой тебе объяснит.

_d_m_ wrote:

> .>Да, делай "просто, как только можно, но не проще".
> Твой случай — это "проще".
А обосновать?

>> > Но от тебя я другого и не ожидал. Про первые 12
>> > разрядов Ну-ну. Как же мы сразу не догадались.
> .>Сам удивляюсь, просто не нужно заумничать.
> Ну ты пошукай как-бы по инету — и удивись везде гуиды с хэш функциями и
> ни разу никто 12 разрядов "просто" не отрезал Почему твоя мысль не
> гениальна, пусть кто-нибудь другой тебе объяснит.
А сам не понимаешь что-ли? Или один аргумент: "Все так делают"?

Здравствуйте, ., Вы писали:
.>А обосновать?
Он имеет в виду тот забавный факт, что разные компоненты GUID имеют разную случайность. Xor имеет то преимущество над отбрасыванием разрядов, что изменение любого бита в исходном гуиде гарантированно изменит проксоренный результат, а вот изменение бита в отброшенном хвосте никак не повлияет на остаток. В результате ты рискуешь получить неожиданную корреляцию генерируемых чисел.

Sinclair wrote:

> .>А обосновать?
> Он имеет в виду тот забавный факт, что разные компоненты GUID имеют
> /разную/ случайность. Xor имеет то преимущество над отбрасыванием
> разрядов, что изменение любого бита в исходном гуиде гарантированно
> изменит проксоренный результат, а вот изменение бита в отброшенном
> хвосте никак не повлияет на остаток. В результате ты рискуешь получить
> неожиданную корреляцию генерируемых чисел.
В принципе да, можно согласится, хотя алгоритм генерации начиная с 3 версии использует хеш-функцию, mssql2000 использует 4 версию.
А вообще-то, xor никакой гарантии от корреляции не даёт, кроме как "скорее всего никто не заметит".