Вероятность, что хотя бы одна машина выйдет из строя растет при количестве машин, то есть если буквально читать, как написано в переводе, то мы чаще будем сталкиваться с недоступностью в части данных. В оригинале используются слова "not performing" - здесь это употреблено в контексте репликации, то есть когда данные на всех узлах одинаковы. Соответственно, вы теряете в скорости чтения, но доступность всех данных сохраняется.
P.S. Также по тексту "multiprocessing" переведено как "многопроцессорная", хотя здесь это "многопроцессная" в противопоставлении с многопоточной.
Даже если все пользователи будут знать о ремонте, у вас скорее всего есть лаг обработки данных порядка недели, поэтому весь этот период веса будут некорректно вести в ремонтирующуюся дорогу.
Мне правда интересно, почему это не считается проблемой. Обычно пользователи любят, когда им оперативно показывают дорожные события и как их обойти. Возможно, вероятности у вас сильно ограничены в разбросе и их влияние не так велико.
Повторюсь, что мне казалось бы естественным, снижать влияние вероятности, если ситуация несколько необычная, например, текущая скорость на эдже сильно отличается от исторической.
Что произойдет, если на высоковероятном ребре начнется ремонт? Как вы сможете это почувствовать?
То есть раньше у вас сработало бы переключение на другое ребро по трафику, а сейчас высокая вероятность ребра все равно погонит всех в пробку и вы здесь не получите фидбека, нужного для снижения вероятности. Как будто нужно отрубать вероятности, если скоростной профиль ребра существенно изменился.
Не защищая сбор статистики в МойОфис, стоит отметить что ИТ-компания это не РЖД и даже не Макдональдс, поэтому вовлеченность может сильно отличаться от средней. На графике в источнике тоже отражена зависимость от сфера деятельности.
Видели ли вы когда-нибудь концепт-кары на выставке? И сколько из них в таком виде поехало по улице? Я к тому, перспективы "дальнейшего коммерческого использования" - неизвестны, все может отмениться и поменяться, в том числе и голос. Автор обращался с вопросом: "нужно ли судиться сейчас?" - на сейчас как будто позиция слабовата да и торопиться некуда.
1. Для двунаправленного поиска есть довольно тонкий момент, что неизвестно время прихода на финиш, что важно для оценки пробок. Соответственно, обычно для финиша берется какое-то предсказание, которое может не совпасть с реальным и две волны встретятся в разное время. Для решения проблемы, наверное, нужно продолжать гнать прямую волну, а результаты обратной использовать как эвристику 2. В OSRM есть второй алгоритм - multi-level dijkstra (MLD). Он позволяет обновлять индекс на лету, но тут тоже сильно будет зависеть от скорости устройства и объема данных
final помимо оптимизации, еще и задает семантику "класс/метод не готов к перегрузкам". Естественно, что через некоторое время именно этот метод и хочется перезагрузить, но final говорит, что ни в коем случае нельзя, не объясняя почему - снизится скорость или нужно поправить другой метод или нужно на самом деле использовать другой подход? В общем, когда final стоит просто на всякий случай, он создает значительное напряжение при поддержке кода.
Можете какой срок на подачу иска к банку после пропажи денег? Не могу понять нужно ли это искать в ГК или в 161-ФЗ. Жалобу подавал в течение недели и счет блокировал, но банк отказал во всем.
В том, что вы нагуглили, есть ссылка на стандарт - вроде не так плохо.
В целом, лучше всего помогает представление как устроен соответствующий контейнер. Если вы представляете, что map - какое-то дерево, то легко представить, что модификация элементов не меняет итераторы. Это же относится и к сложности и к требованиям по памяти.
Но простор для реализации всегда остается. Самый классический пример: list::size vs list::splice - что из этого делать за константу. Тут надо и стандарт знать и версию компилятора.
На сервере должна мгновенно создаваться. На клиенте switch тоже быстро должен работать.
> Кто занимался резолвом конфликтов в свн - тот в цирке не смеется.
А в git что изменилось с этим?
Сделка не произошла, но случилось "неосновательное обогащение" - довольно противоречивая ситуация в гражданском праве.
GPL не требует, чтобы код был публично выложен
Вероятность, что хотя бы одна машина выйдет из строя растет при количестве машин, то есть если буквально читать, как написано в переводе, то мы чаще будем сталкиваться с недоступностью в части данных.
В оригинале используются слова "not performing" - здесь это употреблено в контексте репликации, то есть когда данные на всех узлах одинаковы. Соответственно, вы теряете в скорости чтения, но доступность всех данных сохраняется.
P.S.
Также по тексту "multiprocessing" переведено как "многопроцессорная", хотя здесь это "многопроцессная" в противопоставлении с многопоточной.
Даже если все пользователи будут знать о ремонте, у вас скорее всего есть лаг обработки данных порядка недели, поэтому весь этот период веса будут некорректно вести в ремонтирующуюся дорогу.
Мне правда интересно, почему это не считается проблемой. Обычно пользователи любят, когда им оперативно показывают дорожные события и как их обойти. Возможно, вероятности у вас сильно ограничены в разбросе и их влияние не так велико.
Повторюсь, что мне казалось бы естественным, снижать влияние вероятности, если ситуация несколько необычная, например, текущая скорость на эдже сильно отличается от исторической.
Что произойдет, если на высоковероятном ребре начнется ремонт? Как вы сможете это почувствовать?
То есть раньше у вас сработало бы переключение на другое ребро по трафику, а сейчас высокая вероятность ребра все равно погонит всех в пробку и вы здесь не получите фидбека, нужного для снижения вероятности. Как будто нужно отрубать вероятности, если скоростной профиль ребра существенно изменился.
Предлагаю распечатать инструкцию:
Если я что-то знаю, а кто-то - нет, скажи: "но это же обычный кругозор, неужели вам за всю вашу жизнь не было интересно что делают ..."
Если кто-то что-то знает, а я - нет, скажи: "разве я должен знать эти стопицот фреймвоков и все такое?"
Не защищая сбор статистики в МойОфис, стоит отметить что ИТ-компания это не РЖД и даже не Макдональдс, поэтому вовлеченность может сильно отличаться от средней. На графике в источнике тоже отражена зависимость от сфера деятельности.
Видели ли вы когда-нибудь концепт-кары на выставке? И сколько из них в таком виде поехало по улице?
Я к тому, перспективы "дальнейшего коммерческого использования" - неизвестны, все может отмениться и поменяться, в том числе и голос.
Автор обращался с вопросом: "нужно ли судиться сейчас?" - на сейчас как будто позиция слабовата да и торопиться некуда.
Пока не очень понятно, в чем нарушение лицензии:
1. использование некоммерческое
2. распространения пока не произошло - вроде не релиз был, а демо
Если работа приостановлена, то новая зарплата начисляться не будет. Можно пытаться на треть претендовать, но там уже немного спорно.
1. Для двунаправленного поиска есть довольно тонкий момент, что неизвестно время прихода на финиш, что важно для оценки пробок. Соответственно, обычно для финиша берется какое-то предсказание, которое может не совпасть с реальным и две волны встретятся в разное время. Для решения проблемы, наверное, нужно продолжать гнать прямую волну, а результаты обратной использовать как эвристику
2. В OSRM есть второй алгоритм - multi-level dijkstra (MLD). Он позволяет обновлять индекс на лету, но тут тоже сильно будет зависеть от скорости устройства и объема данных
Интересно посмотреть на то, какие коэффициенты нужно добавить в CTable и как будет выглядеть GetAreaUnion, если:
нужно рассчитать площадь фигуры, заданной точками (контур или внутренность)
другой случай: сами точки получаются, как значения функции
третий случай: пространство искривлено, а коэффициент искривления определяется внешней настройкой
Потому что когда методы виртуальные - это скучно и просто
Пункт 4 (про сделки) странный - отношения между работадателем и работником не регулируются ГК.
final помимо оптимизации, еще и задает семантику "класс/метод не готов к перегрузкам". Естественно, что через некоторое время именно этот метод и хочется перезагрузить, но final говорит, что ни в коем случае нельзя, не объясняя почему - снизится скорость или нужно поправить другой метод или нужно на самом деле использовать другой подход?
В общем, когда final стоит просто на всякий случай, он создает значительное напряжение при поддержке кода.
Неплохой способ решения проблемы глобального потепления.
Можете какой срок на подачу иска к банку после пропажи денег? Не могу понять нужно ли это искать в ГК или в 161-ФЗ. Жалобу подавал в течение недели и счет блокировал, но банк отказал во всем.
Есть ли у вас скриптах возможность настроить фильтрацию по городу?
В Азиатском кино будет альтернативное решение
В том, что вы нагуглили, есть ссылка на стандарт - вроде не так плохо.
В целом, лучше всего помогает представление как устроен соответствующий контейнер. Если вы представляете, что map - какое-то дерево, то легко представить, что модификация элементов не меняет итераторы. Это же относится и к сложности и к требованиям по памяти.
Но простор для реализации всегда остается. Самый классический пример: list::size vs list::splice - что из этого делать за константу. Тут надо и стандарт знать и версию компилятора.