sebres
0

Вы правда считаете что для пруфа 290 лярдов != 1.5 мильена важно что там в каком-то шестом порядке стоит?
Ну-ну...

sebres
0

я стесняюсь спросить — вы число Пи до которого знака пишете?
А по теме, кто его знает как високосные года через столько лярдов лет считать начнут...

sebres
+1

Опа! Бага нашлась! Видать софтина которая тут пользовалась где-то чего-то переполняет при расчете (подозреваю что собственно год или количество julian days)…
Т.к. год много больше должен быть в случае __int64:


1970 + 0x7fffffffffffffff / int(365.25 * 24*60*60) == 1583316
292271025015 != 1583316
sebres
–1

Не страшно… это для своих токма.


Unix epoch (also known as POSIX time or epoch time)

sebres
+4

Уточните тип, пожалуйста...


0x7fffffff         => Tue Jan 19 03:14:07 GMT 2038
0xffffffff         => Sun Feb 07 06:28:15 GMT 2106
0x7fffffffffffffff => Sun Apr 24 15:30:07 GMT 1583316
...
sebres
0

Ну так он выпадает на 12-е (из-за високосности), официально то празднуется все равно 13-го числа, нет? Или он в России все-таки плавающий?

sebres
+1

Ну так совпало. Пятница… повод...

sebres
+1

Как вариант — разносить по разным доменам (суб-доменам)… + SOP + не юзать кросс-доменные куки ...

sebres
0

Побуду кэпом чуть-чуть...


c -"c++" -"cpp" -"c#" standard library


Найдите там C++ и ко...

sebres
–2

А теперь подумайте еще раз про то, что вы спросили… 70% от чего? (мы еще помним, что TTT монополист, правда?)
Для математиков: 70% от трафика != 70% от новостей...


И потом:


  • сколько тех 70% просто потому, что если чел не пришел вовсе, то он и дальше не стал кликать
  • сколько по вышеупомянутой причине (ака точка входа — чел смотрит новости начиная с агрегатора и уходит к "конкуренту" издателя)
  • сколько упало по причине снижения рейтинга (честно-честно просто таким образом работает наш "секретный" алгоритм, который учитывает ленту новостей...)
  • сколько из тех 70% правда (сколько раздули и т. п.)

Это на вскидку, а если подумать то таких сколько...

sebres
0
Аналогия...

Ну вы тут немного передергиваете (либо еще не совсем поняли, либо нарочно путаете теплое с мягким): в качестве контр-примера...


Другая аналогия: Телекомпания ТТТ — монополист. Размещая чужой контент в блоке новостей она лишает людей его изготовивших заработка. При этом она не хочет никому ничего отчислять и в случае обращения просто забывает про издателя от слова совсем (т.е. не размещая чужой контент, но и не упоминая его вовсе), при этом снова тем самым лишая людей заработка (а мы помним что ТТТ — монополист).
Вопрос: Как долго ТТТ сможет размещать чужой контент, когда все те люди его создающие пойдут по миру?
Другой вопрос: как при этом затронут интерес другой группы — потребителя (не лишает ли их монополист ТТТ тем самым возможности узнать про новость, чтобы прочитать/посмотреть ее где-нибудь у издателя), а в долгосрочной перспективе и новостей совсем?


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


Размещает новости целиком и без ссылки на источник?

А вот это уже хороший вопрос ибо где та граница, когда ссылка остается еще интересна. Если новость сама по себе — новость и выжимки google практически достаточно, то на ту ссыль нажмут единицы.

sebres
0

А там вовсе не про рекламу в прямом смысле — google используется потребителем как агрегатор новостей, и он действительно фактически монополист, т.е. избирательно "выбросив" кого-либо из выборки, он тем самым практически "исключает" издателя для огромной аудитории.
Т.е. понять можно обе стороны:


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

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

sebres
+2
Axel Springer не оставалось ничего другого, как разрешить Google ссылаться на тексты бесплатно.

Оно еще вовсе не закончилось — т.е. этот спор вышел на новый (юридический) уровень.
И как бы там не только Шпрингер, там еще с десяток-другой всяческих контор подвизались...


Т.е. если коротко, то:


  • Издатели утверждают, что google — фактически монополист, и поэтому обязан размещать (но и посему платить в соответствии с новым положением от 2013 в Leistungsschutzrecht).
  • В google настаивают на — либо бесплатно, либо не размещаем вовсе.

Как мне видится — это еще очень на долго...


Статья про это на немецком от марта 2016 — weiter auf Deutsch (и с выключенным адблокером).

sebres
0
Максимальная размерность… RAW = 4000 байт

Небольшая поправка:
Лимит для RAW = 2000 байт (если MAX_STRING_SIZE = STANDARD)

sebres
+1

А это художественное произведение и есть...

sebres
+3
Гению откажет… Искать и удерживать.

Ну вот не откажет, а через год-два "гения" собьет машиной, или он с Эвереста скувыркнётся, тем самым не "удержится". Как вам такая альтернатива?.. Оцените риски?


Тут как-бы стоит не про гениальность соискателя поговорить… Дело вот в чем: написать jvm-ный байт-код (а то и в с десяток других, включая питоний или нативный, ака asm например) смогут возможно многие, и из моего окружения в том числе, но при этом:


  • они сделают это без лишнего литья воды вокруг (я про собственный загрузчик и ко, что как минимум не имеет никакого прикладного значения в рамках поставленной задачи, т. е. не комильфо оно тут — вы же не будете писать ОС с дровами и шлюзами, если вас просят прочитать из channel)
  • постараются сначала или в процессе выяснить уровень "мальчика" Тима, чтобы разговор шел хотя бы на одном языке, тем самым...
  • не выставят человека полным нубом (ну или если хотите не покажут ему своего к нему "отношения")
  • будут вести разговор в продуктивном ключе (т. е. найдут возможность "блеснуть" так, чтобы собеседующий это хотя бы понял и проникся уровнем "гениальности")
  • покажут уровень "взрослости" собеседуемого (потому что, шутки-шутками, но вот-это сильно тянет на "я вчера сбежал с детского сада", уровня "кулхацкер" в абсолюте)
  • ну или как минимум уточнят рамочные условия, тем самым покажут ему что "из пушки по воробьям" для них знакомое словосочетание, а фирма не получит такого "все-на-свете-оптимизирующего" в ущерб читабельности, совместимости, безопасности (и еще с десяток ...-сти) того-самого "кода".

А так, да… как красивая история для бложика — возможно (т.е. написано-то и правда красиво, + понты, эго… все дела)…
Но как "реальная" история из жизни, — упаси боже от таких гениев-коллег.

sebres
+5
systemd-escape

может просто не надо писать баш-скрипты в systemd?
Т.е. я про то, почему это должно быть непременно частью something.service, а не частью например something.sh, который отробатывает в ExecStart...


IMHO systemd-escape сделана как helper, чтобы писать динамические systemd-скрипты (т.е. не руками, а "машинным" способом).

sebres
+1

А чего тут подробнее — Tcl.


Ну а реализация конкретно этого http-server'a — собственная, асинхронная, на tpool-потоках, используя один пул listener/auth/supplier и второй пул workers, между ними асинхронный tcl reflected channel…
Реализаций коих штук двадцать на просторах (и не думаю что моя быстрее). Так же как думаю, что и tcl нисколько не быстрее erlang (просто elixir, хмм..., ну да ладно не хочется холиварить)...


Если совсем лень что-то делать (а тикль юзать или пробовать хочется), да и нужно еще быстрее — nginx + tcl по fastcgi (с некоторой обвязкой) порвет на таких хэлловордских задачах все вышеперечисленное, как тузик грелку.


Я его так и юзаю обычно, http-server на чистом тикле нужен когда тащить nginx тяжело или низя (embedded).


Писать мне лично на тикле удобнее чем на erlang, нодах, рюстах и сях вместе взятых (даже питон думаю не сравним, я про удобство и лаконичность)… Но я немного предвзят, ибо уже сто лет как в TCT (разраб в tcl core team), т.е. я его делаю (и если что-то не нравится переделываю сам;).
Но это не node.js, порог вхождения много-много выше (как минимум при "сборке" сервера)...

sebres
+2
статически скомпилированная программа просто обязана быть быстрее виртуальной машины с интерпретатором

Оно как бы да, но это смотря а) как скомпилированна и б) с каким интерпретатором сравнивать...


Вот вам для сравнения на чистом тикле (tcl, threaded, full-async), jit-интерпретатор в quad-code (если что;)
Ответ запроса чуть побольчее в размере, но не критично (ну headers у меня там многовато, лень править да и throughput тут важнее запрос/сек.)...


$ wrk -t10 -c100 -d10s http://172.18.105.109:80/app/empty.htm
Running 10s test @ http://172.18.105.109:80/app/empty.htm
  10 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    15.00ms    8.18ms 145.16ms   95.58%
    Req/Sec   702.82    197.54     6.07k    96.68%
  69539 requests in 10.10s, 24.34MB read
Requests/sec:   6885.13
Transfer/sec:      2.41MB

Для сравнения то-же (подогнал по размеру) на Elixir (результаты немного лучше чем у вас, я про Latency и ко):


$ wrk -t10 -c100 -d10s http://172.18.105.109:8085/test-elixir
Running 10s test @ http://172.18.105.109:8085/test-elixir
  10 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    33.86ms   30.49ms 281.11ms   82.70%
    Req/Sec   376.13    283.00     5.25k    77.16%
  36967 requests in 10.10s, 12.94MB read
Requests/sec:   3660.63
Transfer/sec:      1.28MB

Причем на tcl 2 из 4-х cpu спят, справляется практически 2-мя потоками 30-40% usage (чтобы загрузить на все 100% надо wrk -t100 юзать).


на Elixir же — все 4-е ядра под 100% busy и контекст-свич кернел-таймом погоняет.


Так-что реализация тоже важна (я не думаю, что tcl "шустрее" elixir)...


Ну и не компиляторами едиными…
П.С. Go не держу, так что сравнить не можу...

sebres
0

Я могу конечно ошибаться, но думается мне почему-то, что это ASLR (и-или DEP).
Если на машинках, где обоих можно выключить, баг не воспроизводится — оно говорит за-то...


Ну и если да, решения два (кроме как не юзать винду):


  • не использовать абсолютных указателей (только относительные, не думаю что вариант для mingw)
  • или бороться как я например тут для nginx делал, т.е. грубо говоря переалоцировать base, пока не выравняем блок у всех caller по одному адресу (good luck with its implementation;).

Ну или тот-же воркараунд на секции .text (MEM_WRITE как сделал Jason Bell), хотя не сукьюрно оно как-то.

sebres
+2
Для расшифровывания файлов действуйте в соответствии с одним из следующих сценариев

Ну да, в этом конкретном "детском" случае — возможно что-то и получится.
(Хотя гораздо проще тут было бы настроить "прокси" через роутинг к другому серверу, который вернет 1 по заданному адресу)


Однако в основной своей массе — шифровальщики:


  • либо используют асимметричное шифрование, где для расшифровки нужен другой ключ (т.е. вызов URL как в примере вернет не 0/1, а ключик для расшифровки).
  • либо портят все насмерть (т.е. вовсе не предусмотрено восстановление, даже так сказать по факту оплаты)

Ну и попробуйте подобрать даже 512-байтный ключ какой-нибудь эллиптической кривой (не обязательно стандартной кстати), встретимся через сотню лет (сколько там х-тилионов MIPS-лет нужно).


Тут только или свезло (как в вашем случае)… или (правильно настроенный) бэкап спасает…
Ну или 101 способ предотвратить запуск подобной нехорошей софтины (например тот же SRP и ко, если винда).

sebres
+2

because it's the bug of mingw, вернее ее реализация вокруг mark_section_writable.
Поэтому и не собираются, ибо нефиг плодить воркараунды.
Т.е. баг делегирован дальше, имхо абсолютно правилно, см. MinGW-w64 — for 32 and 64 bit Windows / Bugs / #537 pseudo_reloc fails to mark pages writable

sebres
+1

Вот только не надо про вероятности, интуитивное восприятие и т.п.


Вы кстати не поняли этот парадокс — он говорит как раз про обратное, что совпадения более вероятны, чем интуитивно воспринимается (ибо например для 23-х людей — на самом деле сравниваем 253 возможные пары).
И закроем тему интуитивного восприятия на этом. Расскажите про "день рожденья" кому-нибудь другому (когда поймете).


Теперь по теме: лично видел два одинаковых UUID, созданных на двух разных хостах в одном (правда большом и сильно нагруженном пуле) кластера.
И то было в industries API 80-го уровня. Я бы вам даже имя сказал, но низя (связан подписью о не разглашении)…
Однако с тех пор там та конкретная реализация UUID-api (рандомная кстати, ибо v4) — под строжайшим запретом (бьют по рукам если что).
А так-то да — теоретически невероятно...


Раз уж слово вероятность упало, попробуйте оценить разницу вероятностей:
1) что два каких-то "случайных" 128-ми битных числа будут равны;
2) например в сравнении с вероятностью, что два случайных 52-битных числа + цикличный инкремент (8 бит) про процесс, созданных в течении тех же десяти миллисекунд (48 бит), с одинаковым хэшем (20 бит) взятым от fqdn + thread-id — в результате тоже будут одинаковы;


Вам сразу вопрос: тут фактор времени или количества чисел вообще в выборке важен или нет? Т.е. вопрос два числа из скольких...


Поэтому, сделаем тут некоторые допущения — уточнения условий задачи:


  • одно-поточно реально создать максимально 1000 ключей за одну миллисекунду (только вот что с ними делать с такой-то скоростью, ну да пусть)
  • имеем 256 потоков на машинке
  • имеем ну пусть будет 100 машин в кластере
  • все это добро работает десятилетия.

И не забываем что:
Все это абсолютно не градиентно в первом случае, но чисто для оценки порядка:
(1000 * 1000000 * 256 * 100) — уже 2 в 45-й — и это прошу заметить в секунду.
И крайне важно во втором.

sebres
0
технически исключено

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


Да я и не спорю: то просто замечание было про между прочим (ибо режет глаз). В любом случае придумывать собственную реализацию guid, да еще и триггером обернуть имхо как-то не комильфо (о чем и поведал, выразив свое мнение, с которым совсем не обязательно нужно быть согласным).


П.С. Вот в качестве примера: возьмем nginx-cache-модуль — раньше ключи там не сравнивали (т.е. тупо считалось, что т.к. вероятность коллизии хэша никакая, то достаточно сравнить хэш и все).
И всем известный персонаж спорил с пеной у рта, что оно достаточно, и не нужно это, про всякие "дни рождения" рассказывал и т.д.
Вот там я действительно спорил и настаивал, потому что во первых, хэш — это хэш — он там для скорости а не для крипто-стойкости, во вторых это очень просто и доп. сравнение стоит гроши. А в третьих я их (коллизии) там лично встречал (на очень большом и длинном кэш), причем доказуемо (хорошо еще что на тест-стенде, а не в продакшн).
При том что частью ключа кэша может быть например user-id и nginx тогда при возникновении той "невозможной" коллизии покажет к примеру приватную информацию другому пользователю.
И побоку тогда, что коллизии маловероятны — в корпоративном секторе вы за такое как минимум с работы вылетаете.
Подробнее тут и в мэйл-архивах nginx можно поискать.
Фикс то пустяковый, но нужно же сперва поспорить… Вероятности, это такое дело — их нужно уметь готовить.
Все хотел про то статью тиснуть, да некогда — пусть побудет комментом.

sebres
0

Ну да SQLiteCustomFunction с рефлектом… А чему он хак-ом стал вдруг? Т.е. вы считаете trigger (который вообщето совсем для других целей придуман) менее хакиш вэй. Ну тады ОК.

sebres
+1
Если используется аппаратный источник энтропии

Не используется там никакие источники энтропии — ибо GUID по определению криптографически нестоек.


Каким же образом это «исключено»? :) Вы сами себе противоречите.

Вы возможно слово "часть" пропустили в предложении "значительная часть которого действительно является псевдослучайной последовательностью".
Во всех известных мне реализациях оного, там еще замешивают pid, tid, mac, clicks и тому подобное.


Если бы вы внимательно читали, но заметили бы, что это невозможно на Android

Если вы чего-то не умеете (не можете) — это еще не значит, что оно не возможно.
И собственная сборка SQLite для этого абсолютно не нужна.

sebres
0

Ну делать-то я положим тоже так делаю (когда оно оправдано)…
А вы при случае на 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).

sebres
+1
GUID это случайное "число"

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 базе, чисто время исполнения запроса.

sebres
–1

Пользуюсь сто лет уже статическими генераторами (т.е. ни запоминать ни записывать не нужно от слова вовсе).
Не сочтите за рекламу к примеру вот мой самописный плагин под лиса

Комментарий из публикации, перенесённой в черновики.
Комментарий из публикации, перенесённой в черновики.
sebres
0

Не нужны тут "два хэша".
Во первых, в гит хэш для коммита берется от содержимого + мета-информации (как-то: parent-commit, меседж, автор, сабмитер, время и т.д.). Т.е. генерация по принципу описанному гуглем здесь априори не работает.
Во вторых, кроме хэш коммита в гит важен также и хэш предка (parent-commit).
Ну и last but not least — создать два коммита с одинаковым хэш-значением в одной ветке гит в принципе не возможно, т.е. оно не ломает гит-репозитарий (от слова совсем). Единственное что возможно это переписать его амендом (или push --force в remote). Однако при fetch/pull вы получите новую ветку на том коммите.

sebres
0

Вам понятие "риторический вопрос" знакомо? Или это тонкий троллинг такой?

sebres
+1
Дублирование, резервирование, перекрытие защиту функционала – это залог успеха в современной быстро развивающейся среде в области информационной безопасности.

Ну да и по два антивируса на воркстейшн (а нередко и на сервере, чего уж греха таить) — это уже реальность (в корпоративном секторе).
Только вот панацея ли это?

sebres
0

У меня где-то валялся "бизоний" питоний парсер, он тоже делает код гораздо мельче, к тому же еще и быстрее, но к сожалению (в свое время) кроме всякой мелочи еще и с сохранением того кода в бинарник были проблемы, так и не допилил, может раскопать снова...

sebres
+1
скриптов на питоне, которые быстро прогоняют через себя сотни мегабайт логов или скл данных

Не путайте, ибо в контексте статьи и патчей, важно сколько те скрипты через себя (питоньих) исходников или jit (eval и иже с ними) "прогоняют".

sebres
0

Глупости не говорите: универсальное решение тут может быть только одно, в маппере чистить сегмент (нулями) как минимум за пределы реального перетащенного блока до размера сегмента банки, и как максимум по выделению и перед перетаскиванием блоков), что есть 1. геморрой, 2. вымывает кэша, 3. нереально "ускоряет" контекст-свич туды-сюды, ну и все сопутствующее безобразие в придачу сверху (сброс TLB, глобальных дескрипторов и т.д. и т.п.).
Ну или экзотика типа той же CBA (capability-based адресация), что тоже нереально весело, т.к. нужно будет переписать все, начиная от компиляторов и заканчивая ядром ОС и гипервизоров…
И последствия сего — бинарная (не)совместимость такого софта к примеру, тоже имеют место.


Одно вот только (что бы значит чуть сбавить градус истерии) — как применить на практике подобную "уязвимость" не ясно даже самим "первооткрывателям"… Ну и сколько звезд на небе для этого должны сойтись, история по видимому умалчивает...

sebres
–1

кстати, все бы изменилось, если бы первый выбор что-то менял, например вылет или выигрыш игрока, неравнозначность козлов А и Б, и т.д.

sebres
0
не может открыть ту дверь, которую выбрал игрок.

вы таки не поняли или я не понятно объяснил: что меняет выбранная дверь, или вернее какого козла ведущий откроет — первого или второго? т.е. первоначальный выбор не изменяет ничего, дверь с козлом будет открыта все равно, второй выбор (ткнуить снова в ту же дверь или в другую) ничего не меняет… убрав одного из козлов, это ведущий изменил условия задачи, сравняв вероятности машины для обеих оставшихся дверей, вне зависимости от "клейма" предыдущего выбора.


"ваша" математика понятна и в случае команды игроков и многократных повторов, без обмана — все так, что не отменяет всего выше описанного для каждого конкретного игрока...

sebres
+1
отказаться от подсказки...

а теперь представим, что первый раз вы не выбирали дверь… ведущий же все равно откроет дверь с козлом. Т.е. что изменилось — вы тыкаете в какую-то дверь (вероятность выбора правильной в этом случае один к двум), как на это влияет выбрана она была до этого или нет?


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


ПС Если, что вопрос не мой, задаёт профессор хановерского университета… я его втянул в дискуссию