WS
Дык это вроде как просто увеличение дискретности шкалы в два раза. Или я не прав?
Не совсем...
Size: a a a
2020 May 27
AS
да и в целом
NK
Не совсем...
Ну а бит, если он вообще тут нужен, переключает между использованием чётных/нечётных значений на шкале.
NK
Не совсем...
А в чём разница?
A🍊
Сложно объяснить. Но попробую. Фактически, алгоритм нахождения верхней и нижней оценок строится как сетка с шагом в несколько погрешностей. На каждом из подинтервалов выдаётся определённое значение. Но проблема в том, что значения t_a и t_b могут оказаться по разные стороны от точки сетки при любом разбиении. Решение - сделать две сетки (вторая сетка со сдвигом от первой так, что если значения оказались у границы первой сетки, то у второй они окажутся внутри интервала гарантированно), и бит как раз говорит, какую из двух сеток использовать.
Тогда передать нужно более одного бита: ведь чтобы принять решение о сдвиге сетки, некто (арбитр или сами участники) должны знать, что измерения вышли такими, что нужен этот самый сдвиг сетки.
WS
А в чём разница?
В нюансах наверно. Ну конкретно тут получается, что можно с 1 битом иметь интервал оценки в 8 \Delta t.
WS
Тогда передать нужно более одного бита: ведь чтобы принять решение о сдвиге сетки, некто (арбитр или сами участники) должны знать, что измерения вышли такими, что нужен этот самый сдвиг сетки.
Алиса сама это может определить.
A🍊
Алиса сама это может определить.
Не совсем вкурил. Допустим, границы — 10.0 и 11.0. Алиса получила 10.3. чтобы принять решение о сдвиге сетки на 10.5-11.5, она должна либо знать, что Боб получил меньше 10, либо сетка должна быть заведомо больше возможной разница между Алисой и Бобом.
WS
Не совсем вкурил. Допустим, границы — 10.0 и 11.0. Алиса получила 10.3. чтобы принять решение о сдвиге сетки на 10.5-11.5, она должна либо знать, что Боб получил меньше 10, либо сетка должна быть заведомо больше возможной разница между Алисой и Бобом.
Второе, конечно. Сетка с шагом 8 погрешностей (а разница между ними максимальная - две погрешности)
SZ
эээ- вообще не представляю как это делать в рамках нашего продукта
В какой-то момент бранчи неминуемо разойдутся так сильно что на поддержку обоих понадобятся разные команды. И вряд-ли кто-либо будет этим доволен. Может лучше сейчас подумать как обыграть две версии в одном бранче? Конфигами обложиться, абстракций навертеть, в любом случае поддержка сильно разошедшихся бранчей это, считай, поддержка двух проектов.
AS
какая разница в одном бранче находится код или в двух - елси сам код разный?
AS
* утрирую твой вариант когда бранчи разойдутся слишком сильно
AS
тут деваться некуда- разные комиты, если уж очень нужны фиксы и там и там
AS
трудозатраты на разный код в одном бранче и на разный код в разных бранчах разные
это как- с моей колокольни вес едино, только когда в одном бранче- надо еще как то реазделять сборку - а она тоже может отличаться- имхо в одном деражать- только гемороя больше
AS
в какой-то момент команда начнёт бунтовать. потому что львиная доля времени будет уходить на поддержку бранчей а не на разработку функционала
это елси в новом бранче сделали какой-то прям конкретный рефакторинг
RB
Мне интересно, есть ли обобщения этого дальше. Кажется, целая область научная может быть. Но никак не могу найти что-либо...
Мне кажется в такой ситуации и черри-пик вполне себе вариант.