Ну оно к тому стремится… Просто цель-то у него — "глобально уникальный", а не "случайный" т.е. менее зависим от тех же начальный и текущий сид, энтропии и т.п.
Если у вас там даже хэш от uuid хоста замешан будет оно уже менее зависимо от "случайностей"…
Я про то, что законы Мерфи еще никто не отменял — "если есть вероятность того, что какая-нибудь неприятность может случиться, ...." (я про коллизию, как бы мизерна не была вероятность последней).
Да я и не спорю: то просто замечание было про между прочим (ибо режет глаз). В любом случае придумывать собственную реализацию guid, да еще и триггером обернуть имхо как-то не комильфо (о чем и поведал, выразив свое мнение, с которым совсем не обязательно нужно быть согласным).
П.С. Вот в качестве примера: возьмем nginx-cache-модуль — раньше ключи там не сравнивали (т.е. тупо считалось, что т.к. вероятность коллизии хэша никакая, то достаточно сравнить хэш и все).
И всем известный персонаж спорил с пеной у рта, что оно достаточно, и не нужно это, про всякие "дни рождения" рассказывал и т.д.
Вот там я действительно спорил и настаивал, потому что во первых, хэш — это хэш — он там для скорости а не для крипто-стойкости, во вторых это очень просто и доп. сравнение стоит гроши. А в третьих я их (коллизии) там лично встречал (на очень большом и длинном кэш), причем доказуемо (хорошо еще что на тест-стенде, а не в продакшн).
При том что частью ключа кэша может быть например user-id и nginx тогда при возникновении той "невозможной" коллизии покажет к примеру приватную информацию другому пользователю.
И побоку тогда, что коллизии маловероятны — в корпоративном секторе вы за такое как минимум с работы вылетаете. Подробнее тут и в мэйл-архивах nginx можно поискать.
Фикс то пустяковый, но нужно же сперва поспорить… Вероятности, это такое дело — их нужно уметь готовить.
Все хотел про то статью тиснуть, да некогда — пусть побудет комментом.
Ну да SQLiteCustomFunction с рефлектом… А чему он хак-ом стал вдруг? Т.е. вы считаете trigger (который вообщето совсем для других целей придуман) менее хакиш вэй. Ну тады ОК.
Не используется там никакие источники энтропии — ибо GUID по определению криптографически нестоек.
Каким же образом это «исключено»? :) Вы сами себе противоречите.
Вы возможно слово "часть" пропустили в предложении "значительная часть которого действительно является псевдослучайной последовательностью".
Во всех известных мне реализациях оного, там еще замешивают pid, tid, mac, clicks и тому подобное.
Если бы вы внимательно читали, но заметили бы, что это невозможно на Android
Если вы чего-то не умеете (не можете) — это еще не значит, что оно не возможно.
И собственная сборка SQLite для этого абсолютно не нужна.
Ну делать-то я положим тоже так делаю (когда оно оправдано)…
А вы при случае на execution plan гляньте.
Вот простейший случай — без group by и т.д. (тупо слить из первой все, присутствующие и во второй таблице):
CREATE TABLE records (id BLOB PRIMARY KEY, data CHARACTER)
CREATE TABLE subrecords (subid BLOB, ...)
EXPLAIN QUERY PLAN
select * from records where id in (
select subid from subrecords
)
0 0 0 SEARCH TABLE records USING INDEX sqlite_autoindex_records_1 (id=?) (~25 rows)
0 0 0 EXECUTE LIST SUBQUERY 1
1 0 0 SCAN TABLE subrecords (~1000000 rows)
CREATE TABLE records2 (id INTEGER, id2 INTEGER, data CHARACTER, PRIMARY KEY (id, id2))}
CREATE TABLE subrecords2 (subid INTEGER, subid2 INTEGER, ...)}
EXPLAIN QUERY PLAN
select * from records2
inner join (select subid, subid2 from subrecords2) sub
on sub.subid = id and sub.subid2 = id2
0 0 1 SCAN TABLE subrecords2 (~1000000 rows)
0 1 0 SEARCH TABLE records2 USING INDEX sqlite_autoindex_records2_1 (id=? AND id2=?) (~1 rows)
Вопрос: почему и когда второй вариант может стать сильно медленнее (а главное когда это будет очень-очень критично). (Подсказка — N x M + concurrency).
GUID это уникальный ID, значительная часть которого действительно является псевдослучайной последовательностью (но он однозначно не является случайным).
Иначе вы теоретически могли бы сгенерировать 2-а одинаковых GUID на двух разных устройствах (что на самом деле технически исключено).
Про триггер: sqlite легко расширяется собственными функциями практически на любом языке программирования, т.е. триггер не нужен, достаточно добавить default (expr), вот пример на TCL:
% db function UUID {uuid -binary}
% db eval {CREATE TABLE records (id BLOB DEFAULT (UUID()) PRIMARY KEY, data CHARACTER)}
% db eval {insert into records (data) values ('test')}
% db eval {select * from records}
?º¢?Né3?↑?ÿX¥??÷ test
Ну и чтоб два раз не ходить, отвечу всем вышекомментировавшим про составной комби-PK по двум ключам:
сложнее делать выборку по ID, например если join нежелателен (или невозможен) типа подзапроса.
Попробуйте переписать с составным ID:
select * from records where id in (select rec_id from subrecords where ... group by ...)
будет не сильно но медленнее (как минимум если ID перерастут signed int32), вот ниже замеры для наглядности:
-- blob primary --
CREATE TABLE records (id BLOB PRIMARY KEY, data CHARACTER)
...
insert into records values (x'9bbaa28c4ee9b394189aff58a58f85f7', 'test')
insert into records values (x'bf8bdf314779cb74caac36844b60bd85', 'test')
--
select 1 from records where id = x'bf8bdf314779cb74caac36844b60bd85' limit 1
-- 1.061206 µs/# 9151569 # 942323 #/sec 9711.703 nett-ms
-- composite primary --
CREATE TABLE records2 (id INTEGER, id2 INTEGER, data CHARACTER, PRIMARY KEY (id, v1))
...
insert into records2 values (2147483647, 2147483647, 'test')
insert into records2 values (2147483648, 2147483648, 'test')
select 1 from records2 where id = 2147483647 and id2 = 2147483647 limit 1
-- 1.068456 µs/# 9091251 # 935929 #/sec 9713.603 nett-ms
select 1 from records2 where id = 2147483648 and id2 = 2147483648 limit 1
-- 1.111840 µs/# 8746288 # 899410 #/sec 9724.472 nett-ms
Если что измерял prepared, на in-memory базе, чисто время исполнения запроса.
Пользуюсь сто лет уже статическими генераторами (т.е. ни запоминать ни записывать не нужно от слова вовсе). Не сочтите за рекламу к примеру вот мой самописный плагин под лиса
Чем оно проще?
Строго говоря fixup это (несколько странный* имхо) хелпер для git rebase -i --autostash --autosquash...
Мне не нравится как минимум полное собрание всех месседжей от всех interim коммитов.
Во вторых если я не хочу "интерактивно" (а это как правило так, ибо нужно тупо смять все в одно)?
Ну и в третьих кто вам мешает оформить ваш любимый способ squash тоже как какой-нить алиас. ;)
* теперь почему он странный: ну вот я привык работать в ветке w, имеем там 3-и interim коммита (относительно мастер ветки).
Хочу слить все три сквашем до master и остаться в ветке w.
Интуитивно я бы вызвал это как-нибудь так: git commit --fixup master или git commit --squash master (и все).
А имеем то что имеем...
Поэтому есть собственный алиас sq2 (aka squashto) который делает то что выше описал… git sq2 master
или даже сложнее — слить только 2-а первых коммита и оставить последний отдельным… git sq2 master..w~1
я взял за привычку коммитить чуть ли не каждый чих.
+1
причесать с git rebase
Ну если полная история всех тех чихов изменений не нужна есть же commit --amend (сразу) или тот же "быстрый squash" (не знаю как по-русски его зовут): git reset --soft HEAD~3 && git commit — сошьет 3-и последних коммита в один.
Если взять за привычку всегда работать в ветке work, то ее можно сливать (в тот же master) опять же одним коммитом: git checkout master && git merge --squash work && git commit ...
Или чтоб остаться в ветке work: git reset --soft master && git commit ...
Да много еще как можно...
Тогда и git rebase нужен будет только чтобы ветки кидать туда сюда (для чего он собственно и делался)...
Не нужны тут "два хэша".
Во первых, в гит хэш для коммита берется от содержимого + мета-информации (как-то: parent-commit, меседж, автор, сабмитер, время и т.д.). Т.е. генерация по принципу описанному гуглем здесь априори не работает.
Во вторых, кроме хэш коммита в гит важен также и хэш предка (parent-commit).
Ну и last but not least — создать два коммита с одинаковым хэш-значением в одной ветке гит в принципе не возможно, т.е. оно не ломает гит-репозитарий (от слова совсем). Единственное что возможно это переписать его амендом (или push --force в remote). Однако при fetch/pull вы получите новую ветку на том коммите.
Дублирование, резервирование, перекрытие защиту функционала – это залог успеха в современной быстро развивающейся среде в области информационной безопасности.
Ну да и по два антивируса на воркстейшн (а нередко и на сервере, чего уж греха таить) — это уже реальность (в корпоративном секторе).
Только вот панацея ли это?
У меня где-то валялся "бизоний" питоний парсер, он тоже делает код гораздо мельче, к тому же еще и быстрее, но к сожалению (в свое время) кроме всякой мелочи еще и с сохранением того кода в бинарник были проблемы, так и не допилил, может раскопать снова...
Глупости не говорите: универсальное решение тут может быть только одно, в маппере чистить сегмент (нулями) как минимум за пределы реального перетащенного блока до размера сегмента банки, и как максимум по выделению и перед перетаскиванием блоков), что есть 1. геморрой, 2. вымывает кэша, 3. нереально "ускоряет" контекст-свич туды-сюды, ну и все сопутствующее безобразие в придачу сверху (сброс TLB, глобальных дескрипторов и т.д. и т.п.).
Ну или экзотика типа той же CBA (capability-based адресация), что тоже нереально весело, т.к. нужно будет переписать все, начиная от компиляторов и заканчивая ядром ОС и гипервизоров…
И последствия сего — бинарная (не)совместимость такого софта к примеру, тоже имеют место.
Одно вот только (что бы значит чуть сбавить градус истерии) — как применить на практике подобную "уязвимость" не ясно даже самим "первооткрывателям"… Ну и сколько звезд на небе для этого должны сойтись, история по видимому умалчивает...
вы таки не поняли или я не понятно объяснил: что меняет выбранная дверь, или вернее какого козла ведущий откроет — первого или второго? т.е. первоначальный выбор не изменяет ничего, дверь с козлом будет открыта все равно, второй выбор (ткнуить снова в ту же дверь или в другую) ничего не меняет… убрав одного из козлов, это ведущий изменил условия задачи, сравняв вероятности машины для обеих оставшихся дверей, вне зависимости от "клейма" предыдущего выбора.
"ваша" математика понятна и в случае команды игроков и многократных повторов, без обмана — все так, что не отменяет всего выше описанного для каждого конкретного игрока...
а теперь представим, что первый раз вы не выбирали дверь… ведущий же все равно откроет дверь с козлом. Т.е. что изменилось — вы тыкаете в какую-то дверь (вероятность выбора правильной в этом случае один к двум), как на это влияет выбрана она была до этого или нет?
нет про частотный анализ и мат ожидание не нужно, это понятно как раз, вы ответьте на прямо поставленный вопрос...
ПС Если, что вопрос не мой, задаёт профессор хановерского университета… я его втянул в дискуссию
Вооот! Искал этот комментарий (и дождался от человека, по его словам ничего не понимающего в "вероятностях" ;).
На самом деле спорящие стороны обе частично правы, ибо дилема происходит из-за неполного (вернее куцего что-ли) определения условий задачи… И голуби тут не совсем как-бы причём...
Если рассматривать вероятности угадывания при смене двери и без, при как минимум 3-х повторах (т.е. строго говоря соблюдая необходимое правило для оценки вероятности — массовый характер, желательно бесконечно долго), тогда — да все как написано — дверь нужно менять.
Если рассматривать вероятность угадывания один единственный конкретный раз (исключая условие "массовый характер" и предыдущие "опыты" других людей), то вероятности (нет уже нельзя говорить про вероятности, мат-ожидания и иже с ними), скорее необходимости что-ли менять дверь — как таковой — нет. Ибо равновероятно, что во втором туре именно в этот (важный для вас) раз — вы получите машину. Т.е. в этом конкретном туре она равна 1/2 (независимо от смены двери). И это кстати также видно на той же картинке из википедии — из 6-и человек 3-м досталась машина и 3-м — коза. Просто люди обращают внимание только на нижний левый угол (когда дверь меняли). Но… в том то и дело, что в одном единственном конкретном случае абсолютно не важно менялась дверь или нет, ибо изначально равновероятно она могла быть уже выбрана верно.
Комбинаторика наряду с теорией вероятностей, очень строгая наука, где для точного анализа, условия задачи должны быть строго оговорены. Многие кстати путают вернее иногда неверно связывают частотные и вероятностные характеристики (например количество равновероятных комбинаций и вероятности их выпадения в зависимости от различных условий).
В качестве примера чуть поменяем условия (исключая необходимое условие бесконечности проведения опытов): Это шоу происходит один единственный раз (от слова совсем). Поможет ли играющему смена двери выиграть машину, по сравнению с тем как если бы вы ее не меняли? Ответ — нет.
Другой пример: Ежедневное шоу. Насколько быстрее у компании, осуществляющей "бесплатную" раздачу машин, закончатся деньги, если каждый участник всегда будет менять дверь (по сравнению с тем как если бы ее всегда не меняли)? Ответ — в два раза быстрее (2/3 в сравнении к 1/3).
Ну и возвращаясь к голубям, учитывая что делая это раз за разом "смена двери" действительно повышает шансы добраться до корма, делается вывод — нужно менять дверь. Что не отменяет тот факт, что в единственном конкретном случае (а человек участвует в шоу ровно один раз), это абсолютно не важно (если не ставить целью разорить фирму, проводящую шоу).
Поэтому многие именитые математики и сделали такие заявления, т. к. подходя к задаче комбинаторно, они рассматривали единственное действие, т.е. выигрыш конкретного участника, а не общий игровой фонд всех участников за год, с целью разорения фирмы (т. е. при многократно повторяемых шоу).
на свеже поставленных ОС и фоксе офф-лайн, т.е. с гарантией, что не сядет троян?
Т.е. другими словами, вы знаете что у вас кейлоггер сидит и живете с этим? Т.е. случайное, до времени незамеченное, заражение — это одно, но это ж не норма...
Ну тогда вводите секрет как-нибудь "гарантированно" секьюрно (по частям, с копи-пастой, драг-дропом с яндекс клавиатуры и т.п.), т.е. максимально сложно — обфусцировано (один раз же)...
Ну оно к тому стремится… Просто цель-то у него — "глобально уникальный", а не "случайный" т.е. менее зависим от тех же начальный и текущий сид, энтропии и т.п.
Если у вас там даже хэш от uuid хоста замешан будет оно уже менее зависимо от "случайностей"…
Я про то, что законы Мерфи еще никто не отменял — "если есть вероятность того, что какая-нибудь неприятность может случиться, ...." (я про коллизию, как бы мизерна не была вероятность последней).
Да я и не спорю: то просто замечание было про между прочим (ибо режет глаз). В любом случае придумывать собственную реализацию guid, да еще и триггером обернуть имхо как-то не комильфо (о чем и поведал, выразив свое мнение, с которым совсем не обязательно нужно быть согласным).
П.С. Вот в качестве примера: возьмем nginx-cache-модуль — раньше ключи там не сравнивали (т.е. тупо считалось, что т.к. вероятность коллизии хэша никакая, то достаточно сравнить хэш и все).
И всем известный персонаж спорил с пеной у рта, что оно достаточно, и не нужно это, про всякие "дни рождения" рассказывал и т.д.
Вот там я действительно спорил и настаивал, потому что во первых, хэш — это хэш — он там для скорости а не для крипто-стойкости, во вторых это очень просто и доп. сравнение стоит гроши. А в третьих я их (коллизии) там лично встречал (на очень большом и длинном кэш), причем доказуемо (хорошо еще что на тест-стенде, а не в продакшн).
При том что частью ключа кэша может быть например user-id и nginx тогда при возникновении той "невозможной" коллизии покажет к примеру приватную информацию другому пользователю.
И побоку тогда, что коллизии маловероятны — в корпоративном секторе вы за такое как минимум с работы вылетаете.
Подробнее тут и в мэйл-архивах nginx можно поискать.
Фикс то пустяковый, но нужно же сперва поспорить… Вероятности, это такое дело — их нужно уметь готовить.
Все хотел про то статью тиснуть, да некогда — пусть побудет комментом.
Ну да SQLiteCustomFunction с рефлектом… А чему он хак-ом стал вдруг? Т.е. вы считаете trigger (который вообщето совсем для других целей придуман) менее хакиш вэй. Ну тады ОК.
Не используется там никакие источники энтропии — ибо GUID по определению криптографически нестоек.
Вы возможно слово "часть" пропустили в предложении "значительная часть которого действительно является псевдослучайной последовательностью".
Во всех известных мне реализациях оного, там еще замешивают pid, tid, mac, clicks и тому подобное.
Если вы чего-то не умеете (не можете) — это еще не значит, что оно не возможно.
И собственная сборка SQLite для этого абсолютно не нужна.
Ну делать-то я положим тоже так делаю (когда оно оправдано)…
А вы при случае на execution plan гляньте.
Вот простейший случай — без group by и т.д. (тупо слить из первой все, присутствующие и во второй таблице):
Вопрос: почему и когда второй вариант может стать сильно медленнее (а главное когда это будет очень-очень критично). (Подсказка — N x M + concurrency).
GUID это уникальный ID, значительная часть которого действительно является псевдослучайной последовательностью (но он однозначно не является случайным).
Иначе вы теоретически могли бы сгенерировать 2-а одинаковых GUID на двух разных устройствах (что на самом деле технически исключено).
Про триггер: sqlite легко расширяется собственными функциями практически на любом языке программирования, т.е. триггер не нужен, достаточно добавить default (expr), вот пример на TCL:
Ну и чтоб два раз не ходить, отвечу всем вышекомментировавшим про составной комби-PK по двум ключам:
Попробуйте переписать с составным ID:
Если что измерял prepared, на in-memory базе, чисто время исполнения запроса.
Пользуюсь сто лет уже статическими генераторами (т.е. ни запоминать ни записывать не нужно от слова вовсе).
Не сочтите за рекламук примеру вот мой самописный плагин под лисаЧем оно проще?
Строго говоря fixup это (несколько странный* имхо) хелпер для
git rebase -i --autostash --autosquash...Мне не нравится как минимум полное собрание всех месседжей от всех interim коммитов.
Во вторых если я не хочу "интерактивно" (а это как правило так, ибо нужно тупо смять все в одно)?
Ну и в третьих кто вам мешает оформить ваш любимый способ squash тоже как какой-нить алиас. ;)
* теперь почему он странный: ну вот я привык работать в ветке
w, имеем там 3-и interim коммита (относительно мастер ветки).Хочу слить все три сквашем до
masterи остаться в веткеw.Интуитивно я бы вызвал это как-нибудь так:
git commit --fixup masterилиgit commit --squash master(и все).А имеем то что имеем...
Поэтому есть собственный алиас
sq2(akasquashto) который делает то что выше описал…git sq2 masterили даже сложнее — слить только 2-а первых коммита и оставить последний отдельным…
git sq2 master..w~1+1
Ну если полная история всех тех
чиховизменений не нужна есть жеcommit --amend(сразу) или тот же "быстрый squash" (не знаю как по-русски его зовут):git reset --soft HEAD~3 && git commit— сошьет 3-и последних коммита в один.Если взять за привычку всегда работать в ветке work, то ее можно сливать (в тот же master) опять же одним коммитом:
git checkout master && git merge --squash work && git commit ...Или чтоб остаться в ветке work:
git reset --soft master && git commit ...Да много еще как можно...
Тогда и git rebase нужен будет только чтобы ветки кидать туда сюда (для чего он собственно и делался)...
Не нужны тут "два хэша".
Во первых, в гит хэш для коммита берется от содержимого + мета-информации (как-то: parent-commit, меседж, автор, сабмитер, время и т.д.). Т.е. генерация по принципу описанному гуглем здесь априори не работает.
Во вторых, кроме хэш коммита в гит важен также и хэш предка (parent-commit).
Ну и last but not least — создать два коммита с одинаковым хэш-значением в одной ветке гит в принципе не возможно, т.е. оно не ломает гит-репозитарий (от слова совсем). Единственное что возможно это переписать его амендом (или push --force в remote). Однако при fetch/pull вы получите новую ветку на том коммите.
Вам понятие "риторический вопрос" знакомо? Или это тонкий троллинг такой?
Ну да и по два антивируса на воркстейшн (а нередко и на сервере, чего уж греха таить) — это уже реальность (в корпоративном секторе).
Только вот панацея ли это?
У меня где-то валялся "бизоний" питоний парсер, он тоже делает код гораздо мельче, к тому же еще и быстрее, но к сожалению (в свое время) кроме всякой мелочи еще и с сохранением того кода в бинарник были проблемы, так и не допилил, может раскопать снова...
Не путайте, ибо в контексте статьи и патчей, важно сколько те скрипты через себя (питоньих) исходников или jit (eval и иже с ними) "прогоняют".
Глупости не говорите: универсальное решение тут может быть только одно, в маппере чистить сегмент (нулями) как минимум за пределы реального перетащенного блока до размера сегмента банки, и как максимум по выделению и перед перетаскиванием блоков), что есть 1. геморрой, 2. вымывает кэша, 3. нереально "ускоряет" контекст-свич туды-сюды, ну и все сопутствующее безобразие в придачу сверху (сброс TLB, глобальных дескрипторов и т.д. и т.п.).
Ну или экзотика типа той же CBA (capability-based адресация), что тоже нереально весело, т.к. нужно будет переписать все, начиная от компиляторов и заканчивая ядром ОС и гипервизоров…
И последствия сего — бинарная (не)совместимость такого софта к примеру, тоже имеют место.
Одно вот только (что бы значит чуть сбавить градус истерии) — как применить на практике подобную "уязвимость" не ясно даже самим "первооткрывателям"… Ну и сколько звезд на небе для этого должны сойтись, история по видимому умалчивает...
кстати, все бы изменилось, если бы первый выбор что-то менял, например вылет или выигрыш игрока, неравнозначность козлов А и Б, и т.д.
вы таки не поняли или я не понятно объяснил: что меняет выбранная дверь, или вернее какого козла ведущий откроет — первого или второго? т.е. первоначальный выбор не изменяет ничего, дверь с козлом будет открыта все равно, второй выбор (ткнуить снова в ту же дверь или в другую) ничего не меняет… убрав одного из козлов, это ведущий изменил условия задачи, сравняв вероятности машины для обеих оставшихся дверей, вне зависимости от "клейма" предыдущего выбора.
"ваша" математика понятна и в случае команды игроков и многократных повторов, без обмана — все так, что не отменяет всего выше описанного для каждого конкретного игрока...
а теперь представим, что первый раз вы не выбирали дверь… ведущий же все равно откроет дверь с козлом. Т.е. что изменилось — вы тыкаете в какую-то дверь (вероятность выбора правильной в этом случае один к двум), как на это влияет выбрана она была до этого или нет?
нет про частотный анализ и мат ожидание не нужно, это понятно как раз, вы ответьте на прямо поставленный вопрос...
ПС Если, что вопрос не мой, задаёт профессор хановерского университета… я его втянул в дискуссию
Вооот! Искал этот комментарий (и дождался от человека, по его словам ничего не понимающего в "вероятностях" ;).
На самом деле спорящие стороны обе частично правы, ибо дилема происходит из-за неполного (вернее куцего что-ли) определения условий задачи… И голуби тут не совсем как-бы причём...
Если рассматривать вероятности угадывания при смене двери и без, при как минимум 3-х повторах (т.е. строго говоря соблюдая необходимое правило для оценки вероятности — массовый характер, желательно бесконечно долго), тогда — да все как написано — дверь нужно менять.
Если рассматривать вероятность угадывания один единственный конкретный раз (исключая условие "массовый характер" и предыдущие "опыты" других людей), то вероятности (нет уже нельзя говорить про вероятности, мат-ожидания и иже с ними), скорее необходимости что-ли менять дверь — как таковой — нет. Ибо равновероятно, что во втором туре именно в этот (важный для вас) раз — вы получите машину. Т.е. в этом конкретном туре она равна 1/2 (независимо от смены двери). И это кстати также видно на той же картинке из википедии — из 6-и человек 3-м досталась машина и 3-м — коза. Просто люди обращают внимание только на нижний левый угол (когда дверь меняли). Но… в том то и дело, что в
одномединственном конкретном случае абсолютно не важно менялась дверь или нет, ибо изначально равновероятно она могла быть уже выбрана верно.Комбинаторика наряду с теорией вероятностей, очень строгая наука, где для точного анализа, условия задачи должны быть строго оговорены. Многие кстати путают вернее иногда неверно связывают частотные и вероятностные характеристики (например количество
равновероятныхкомбинаций и вероятности их выпадения в зависимости от различных условий).Ну и возвращаясь к голубям, учитывая что делая это раз за разом "смена двери" действительно повышает шансы добраться до корма, делается вывод — нужно менять дверь. Что не отменяет тот факт, что в единственном конкретном случае (а человек участвует в шоу ровно один раз), это абсолютно не важно (если не ставить целью разорить фирму, проводящую шоу).
Поэтому многие именитые математики и сделали такие заявления, т. к. подходя к задаче комбинаторно, они рассматривали единственное действие, т.е. выигрыш конкретного участника, а не общий игровой фонд всех участников за год, с целью разорения фирмы (т. е. при многократно повторяемых шоу).
"Back up" — разделяемый глагол (not obligatory), поэтому и так и так можно…
Однако, исходя из частоты употребления англоязычной публикой я бы сказал написанное рядом звучит "лучше"...
Хотя про ваш вариант некоторые немецкоговорящие товарищи сказали бы, что возможно это "denglisch наоборот" ;)
Т.е. другими словами, вы знаете что у вас кейлоггер сидит и живете с этим? Т.е. случайное, до времени незамеченное, заражение — это одно, но это ж не норма...
Ну тогда вводите секрет как-нибудь "гарантированно" секьюрно (по частям, с копи-пастой, драг-дропом с яндекс клавиатуры и т.п.), т.е. максимально сложно — обфусцировано (один раз же)...