Кстати это был действительно хайтек, если своего Феликса я успешно ремонтировал, то чинить круговую логарифмическую линейку КЛ-1 не решился бы. К счастью их можно ещё найти в исправном состоянии, даже те, что больше полувековой давности.
Тут проблема не столько в транслитерации. Лично знаю одну коренную немку, которая неофициально (например в e-mail) пишет своё имя как ilona, с маленькой буквы. Потому как об «Ilona» глаз спотыкается даже у привычных к латинскому алфавиту.
Есть же какие-то устройства для дальней и сверхдальней связи для субмарин в подводном положении.
Есть конечно, только вот передатчик в два с лишним мегаватта мощности и 60-километровой антенной не столько излучает привычные нам радиоволны, а скорее модулированно раскачивает магнитное поле Земли. И CPS у него три буквы за 15 минут, для сигналов точного времени подходит слабо.
Все методы основанные на эхо/радиолокации разбиваются о то, что нам необходимо точно знать скорость звука/света в воде, а та зависит от температуры, солёности и даже давления (потому как на тех глубинах воду уже нельзя считать несжимаемой жидкостью). Плюс-минус лапоть посчитать конечно можно, что и было сделано полвека назад, но вот с точностью до пяти знаков пока не выходит.
PS: Методам основанным на триангуляции добовляет сложности то, что неоднородности воды залегают слоями, и звук/свет пущенный не строго вертикально ещё и слегка преломляется в сторону и идёт не по прямой линии.
PPS: Опускать гирлянды датчиков/камер и по ним высчитывать поправки к скорости очень хорошая идея, потому как кроме собственно определения глубины можно получить много интересных данных об океане, но вспоминается выставленный в музее батискаф с толщиной стенки сантиметров 15. Каждый датчик придётся паковать в стальную сферу размером с мультиварку, плюс как-то герметизировать шину питания и данных. Сколько это будет весить и стоить — думать страшно. Впрочем, при массе «колбасы» датчиков в десятки тонн можно даже не включать питание — при таком весе её почти не будет изгибать течениями и достаточно просто измерить длину высокотехнологичной «верёвки».
У вас там usb принципиально не рассматривается чтоли?
Думаю что там осознанно выбран экзотический разъём:
Дети будут втыкать любой механически совместимый кабель с непредсказуемым результатом.
Судя по фотографиям разъёмы весьма компактные, а на моторах сделано углубление для прокладки плоского кабеля со стандарным для Lego радиусом изгиба в 4 мм. Такие USB кабели если и существуют, то тоже экзотика.
USB-контроллер в каждом моторе или датчике нажатия это уж перебор и повышение и так весьма высокой цены.
Не известно как в новых SPIKE, а в кабелях NXT была земля, питание и старый добрый I2C, так что рулить им можно было с любой «Ардуины». Надеюсь и в новых моторах не перемудрили с протоколом обмена.
В EV3 как раз можно использовать старые NXT моторы и сенсоры (FAQ)
В 2013 г. Лего ещё дорожила своей репутацией.
When developing LEGO® MINDSTORMS® Education EV3 there has been a strong focus on ensuring backwards compatibility to NXT, making it possible to use many NXT elements with EV3.
Some of the main features:
EV3 uses the same connector cables as the NXT, so all NXT sensors and motors will work with the new EV3 platform.
EV3 uses the same LEGO Technic building system as NXT so you can reuse all of your bricks and other elements.
EV3 uses the same DC transformer as NXT.
EV3 software can be used to program the NXT, however not all software features support NXT.
Непонятно как дела с совместимостью Spike и Boost (17101), никаких официальных данных пока не нашёл.
SPIKE Prime is entirely new so the sensors, hardware and cables will only work with SPIKE Prime. EV3 and NXT components won’t work with the SPIKE Prime hub because they use different types of connections.
WeDo 2.0 motors and sensors share the same connection type but are not designed to be compatible with SPIKE Prime components.
Скоро будет возможен такой лайфхак — возить с собой пяток телефонов с детскими тарифами. Чтоб в случае неотвратимой аварии другие автономные машины предпочитали самоубиваться (вместе с заплатившими за это авто пассажирами) о что-то другое, спасая (как думает ИИ) много человеческих жизней. Дивный новый мир!
В идеальном мире все ошибки должны отлавливаться на этапе тестирования, но у нас однажды баг утёк в продакшн и некоторые сообщения в топике стали рушить десериализатор. В «обычной» системе, когда проекты обмениваются информацией через базу данных, можно пойти к DBA, и те, грязно ругаясь, в виде абсолютного исключения, могут стереть дефектные данные прямо в PROD базе. Весьма опасный сценарий, но плохой план починки лучше чем ничего.
В кафке же, «что написано пером, то не вырубишь топором», поэтому пришлось срочно патчить консумеры, причём другой команде разработчиков, не виновных в этом косяке. На 2 повреждённых записи приходилось 8 нормальных, поэтому просто «перемотать» руками оффсеты в consumer group и перепрыгнуть весь плохой кусок означало потерю нужных даных.
Это проблема не только кафки, а всех append-only event log, но интересно кто как это решает?
С одной стороны, Avro активно пропагандируется изобретателями Кафки как компактный, а главное документирующий формат.
С другой — по отзывам из разных фирм многие всё же используют JSON, потому как так «проще и гибче»
При этом закрадывается подозрение, что JSON решает проблемы на стороне продюсера (нет схемы — нет проблем), но при этом перекладывает ответсвенность за правильную интерпретацию на консумера. Получатель должен знать особенности структуры данных отправителя, а это противоречит идее независимых команд разработчиков, обменивающихся данными через небольшое количество хорошо определённых интерфейсов.
В первом докладе Avito часто упоминается Avro, вы выбрали его?
Вопрос по второму докладу, о Booking.com: Если вы скрываете настоящее имя топиков за абстракцией в самописной библиотеке, то как конечные пользователи могут определить, что нужные им данные уже есть в Кафке?
Например: Команда А получила от бизнеса заказ на новую фичу и ей нужны исходные данные из другой области. Возможно в фирме уже есть какая-то другая команда Б, в другом проекте, а может даже федерации, которая уже публикует нужные записи. Как команды находят друг друга? Смотрят в Кафку и пытаются по имени топиков определить что там внутри? Пишут email во внутреннюю рассылку? Идут на SchemaRegistry сервер (при условии что сериализация в Avro) и ищут там? Одиним словом как вы поддерживатете знание о содержимом топиков, если их 3k+ штук?
Но с такой информацией к директору идти нельзя, ведь от нас хотели получить вероятность возврата кредита каждым заемщиком. Что делать? Ответ простой — нам нужно как-то преобразовать функцию f(w,x)=..., значения которой лежат в диапазоне (-Inf; +Inf) на функцию, значения которой будут лежать в диапазоне [0; 1]. И такая функция существует, ее называют функцией логистического отклика или обратного-логит преобразования.
Я это интерпретировал как «нам нужна функция, отображающая всю числовую прямую на отрезок [0;1]». Таких функций можно придумать много и разных, например 0,5+1/2*sin(x). Даже если дополнительно потребовать непрерывности, монотонности и как следствие существования обратной функции, то кандидатов тоже можно измыслить предостаточно, например 0,5+arctg(x)/Pi.
Вопрос был почему из всего многообразия вариантов было решено использовать именно логит.
Upd: выше уже назвали аргументы в пользу logloss. Спасибо!
Переместить интервал (-Pi/2; +Pi/2) в (0;1) можно простым умножением и прибавлением константы, это не проблема. Вопрос без подвоха, действительно интересно почему выбрана именно функция с экспонентой, а не какая-либо другая.
Вспоминается история четырёхлетней давности, когда IBM по заказу безопасников из TSA разработала «Randomizer App» для iPad, единственной функцией которого является случайным образом показывать стрелку влево или вправо. За 336413 долларов, плюс ещё больше миллиона на необозначенные расходы.
А таблицы Брадиса?
Есть конечно, только вот передатчик в два с лишним мегаватта мощности и 60-километровой антенной не столько излучает привычные нам радиоволны, а скорее модулированно раскачивает магнитное поле Земли. И CPS у него три буквы за 15 минут, для сигналов точного времени подходит слабо.
PS: Методам основанным на триангуляции добовляет сложности то, что неоднородности воды залегают слоями, и звук/свет пущенный не строго вертикально ещё и слегка преломляется в сторону и идёт не по прямой линии.
PPS: Опускать гирлянды датчиков/камер и по ним высчитывать поправки к скорости очень хорошая идея, потому как кроме собственно определения глубины можно получить много интересных данных об океане, но вспоминается выставленный в музее батискаф с толщиной стенки сантиметров 15. Каждый датчик придётся паковать в стальную сферу размером с мультиварку, плюс как-то герметизировать шину питания и данных. Сколько это будет весить и стоить — думать страшно. Впрочем, при массе «колбасы» датчиков в десятки тонн можно даже не включать питание — при таком весе её почти не будет изгибать течениями и достаточно просто измерить длину высокотехнологичной «верёвки».
Думаю что там осознанно выбран экзотический разъём:
Some of the main features:
Непонятно как дела с совместимостью Spike и Boost (17101), никаких официальных данных пока не нашёл.
Редиски!
Сам элемент в серединке бутерброда между холодным и горячим радиатором.
Родной 12-вольтовый мотор на вентиляторе заменил на вибромотор из пульта от X-Box, ему хватает пары вольт.
В кафке же, «что написано пером, то не вырубишь топором», поэтому пришлось срочно патчить консумеры, причём другой команде разработчиков, не виновных в этом косяке. На 2 повреждённых записи приходилось 8 нормальных, поэтому просто «перемотать» руками оффсеты в consumer group и перепрыгнуть весь плохой кусок означало потерю нужных даных.
Это проблема не только кафки, а всех append-only event log, но интересно кто как это решает?
В первом докладе Avito часто упоминается Avro, вы выбрали его?
Например: Команда А получила от бизнеса заказ на новую фичу и ей нужны исходные данные из другой области. Возможно в фирме уже есть какая-то другая команда Б, в другом проекте, а может даже федерации, которая уже публикует нужные записи. Как команды находят друг друга? Смотрят в Кафку и пытаются по имени топиков определить что там внутри? Пишут email во внутреннюю рассылку? Идут на SchemaRegistry сервер (при условии что сериализация в Avro) и ищут там? Одиним словом как вы поддерживатете знание о содержимом топиков, если их 3k+ штук?
Я это интерпретировал как «нам нужна функция, отображающая всю числовую прямую на отрезок [0;1]». Таких функций можно придумать много и разных, например 0,5+1/2*sin(x). Даже если дополнительно потребовать непрерывности, монотонности и как следствие существования обратной функции, то кандидатов тоже можно измыслить предостаточно, например 0,5+arctg(x)/Pi.
Вопрос был почему из всего многообразия вариантов было решено использовать именно логит.
Upd: выше уже назвали аргументы в пользу logloss. Спасибо!
Государственные заказы они такие, по всему миру.