Они имеют в виду, что у них в их алгоритме раса не учитывается, вот и все. Если вычислить риски по 2 людям разного цвета кожи, но в остальном одинаковых, то риск будет одинаковый. Корреляция между факторами риска и собственно риском есть и используется в их алгоритме. Корреляция между факторами риска и цветом кожи может быть, а может и не быть — это зависит от конкретной социоэкономической ситуации (и никоим образом не от алгоритма).
> только 20% подозреваемых, по которым программа определила высокий риск совершения преступлений, действительно совершили его в течение двух лет после выставления риска.
Косяк алгоритма. Вот об этом надо заострять внимание — на том, что судебная система руководствуется черт знает чем при выборе наказания. А не искать расизм там, где его нет. Было бы интересно еще посчитать обратный вариант — сколько из тех, кому был назначен малый риск, совершили повторные правонарушения. Если и там было бы большое число ошибок — то вообще замечательный сюжет «хороших наказываем, а плохих поощряем».
Здесь еще есть интересный вопрос в том, а не влияет ли сам факт того, что был выставлен высокий риск, на совершение повторного преступления? Скажем, если нарушителя с малым вычисленным риском отпустили, «погрозив пальчиком» — не будет ли это являться побудительным фактором для того снова нарушить? И наоборот, если за пьяное вождение посадить под домашний арест на пару лет — это будет неплохо защищать от повторного нарушения.
> Ошибочное предсказание рецидива для чернокожих вдвое выше, чем для белых.
И это тоже косяк алгоритма, и опять же не связанный с расой. Возможно, вес каких-то «отягощающих» факторов (которые в этой стат выборке коррелируют с расой) в итоговой оценке слишком задран.
Интересно, эти Northpointe для каждой конкретной местности подстраивают веса у алгоритма или он у них общий везде? Если общий везде — то это вообще явный косяк компании.
> не всегда по скомпилированному бинарнику можно этот самый stack trace получить, в релизной сборке читай никогда
При наличии в бинарнике async unwind tables вроде бы должно быть можно, не?
Статью — просим нижайше, очень интересная тема. И про breakpad, и про сбор стека в полете исключения.
У нас есть костыль, пишущий минидампы, на базе SEH-обработчика, но хотелось бы чего-то более C++ного и универсального. Если оно еще и под *nix сумеет асинхронные сигналы перехватывать и дампить (и давить потом, чтобы можно было как-то попытаться восстановиться) — вдвойне интересно
> Прошло всего 4 года, а стандарт уже подхватили некоторые основные игроки, новые проекты и open-source.
А хочется еще быстрее и еще больше ) Хочется async await, а приходится использовать gcc 4.7, в котором и C++11 не до конца допилен. Грустные реалии промышленного программирования.
> Насколько я помню, у них и C99 пока не поддерживается полностью.
В 2013 версии с C99 все стало гораздо лучше (хотя может быть все еще не полностью, утверждать не буду).
> Был сделан выбор в пользу современных тенденций и требований рынка…
Я имел в виду сделать некий набор официальных библиотек, которые бы стандартизировались по тем же принципам, что сейчас идет стандартизация в общий стандарт, и поддерживались производителями компиляторов. Соответственно — проблемы с безопасностью не больше, чем при использовании стандартной библиотеки компилятора (пишут те же люди); нет проблемы с выбором среди N библиотек — есть 1 официальная; документация на такие библиотеки тоже будет хорошей.
Из плюсов — меньше времени будет тратиться на добавление фич и их модификацию (я имею в виду спецификацию фичи — нет привязки к 3-годичному циклу общего стандарта); качество реализации каждой фичи будет выше (ибо не N реализаций от N команд, а 1 реализация от N команд; и пользователей кода соответственно X, а не X/N); баги в реализации будут фикситься быстрее (нет привязки к релизу следующей версии компилятора).
Из минусов — да, больше #ifdef/костылей под разные компиляторы (хотя буст в этом смысле не показатель — он пытается поддерживать старые компиляторы, а здесь производитель компилятора может просто не заявлять поддержку старых версий — как это и делается сейчас в стандартной библиотеке); меньше давление на производителя компилятора по поддержке новых стандартных библиотек (хотя и сейчас это их не останавливает — case in point MSVC и C99/expression SFINAE). На примере Boost.DLL — вроде бы самодостаточный модуль без каких-либо зависимостей (и он вполне может пройти все круги стандартизации за пару лет), но в лучшем случае это попадет в C++20; и даже после этого мы будем ждать, пока msvs/gcc/clang/icc реализуют эту часть стандарта у себя и выпустят очередные релизы, или использовать полифиллы из того же Boost. А можно было бы выпустить TS где-нибудь к 18 году и подождать, пока кто-то один/два из производителей накропает одну реализацию, которая скорее всего заработает со всеми остальными.
Я поддерживаю этот крик души (тот редкий случай, когда я был полностью согласен с Гитлером)), но направлен он явно не по адресу. Модули были представлены на рассмотрение комитету, и тот решил их не включать в C++17 (как, собственно, и остальное самое интересное, что было представлено). Национальные представители не могут «заставить» CoreWG принять другое решение. Лучшее, на что мы можем надеяться в ближайшей перспективе — это принятие модулей как TS.
Если рассмотреть вопрос модулей с более практической точки зрения, то
а) ничто не мешает их использовать уже сейчас, хоть они и не в стандарте — VS2015U1 уже умеет, clang вроде бы тоже что-то выкатывал.
б) если бы они даже вошли в стандарт, то это не значит, что их вдруг стало бы можно использовать — нужна поддержка компиляторами, и нужна поддержка библиотеками.
В общем, стандарт — это как красивая теория, а на практике мы сталкиваемся с жестокой реальностью того, что используется в основном C++11, и то не везде. C++14 еще не стало популярным (даже нет полной поддержки в MSVS), не говоря уж о C++17.
Что касается тех фич, про которые говорится в статье:
— Dynamic Library Load — не вижу большого смысла вносить это в стандарт. Фича, имхо, достаточно редкая, и она полностью закрывается замечательными библиотеками, скрывающими кишки от пользователя, типа того же Boost.DLL. Атрибут [[visible]] в стандарте при том полностью поддерживаю (я не очень понял, как там модули решат проблему с dllimport, но это отдельный разговор).
— стандартизация плоских контейнеров — это тоже решено библиотеками, но эта фича очень востребована, так что оно в стандарте вполне уместно
— класс для вывода stack trace — очень специфическая фича, и есть библиотеки в помощь. Если идти в сторону стандартизации, то было бы лучше стандартизировать ABI для описаний функций; это, к сожалению, утопично, а заставить разработчиков компиляторов поддерживать единого API над своими ABI — тоже выход.
— интерфейсы — интересно, но пока не очень ясно, чем это принципиально отличается от ABC. Меня бы больше порадовала возможность описывать в публичных заголовках классы частично (только публичные функции), если внешним потребителям не требуется знать структуру класса в памяти. Сейчас либо приходится вываливать на всеобщее обозрение кишки класса, либо делать ABC, либо колбасить Pimpl или что-то похожее.
— доступ к полям структур по индексу и базовая рефлексия — архинужно, хотя бы на уровне проитерироваться по полям структуры и узнать их имена. Но на это уже есть как минимум 2 документа, которые давно в работе. Какой-то из двух должен в конце концов дойти до стандарта.
У меня за последний год сложилось ощущение, что в стандартную библиотеку C++ хотят/пытаются внести слишком много функционала. Лучше, на мой взгляд, было бы доделать модули и сделать наконец какой-нибудь нормальный dependency manager, и выносить функционал в отдельные самодостаточные библиотечки. При этом можно сделать какой-нибудь особый namespace для «официальных» библиотек типа «isocpp/» и не менять процедуру стандартизации «официальных» модулей; пусть также они сначала пишутся и обсуждаются в рабочей группе, потом идут в LibraryWG и там монстры и корифеи их доводят до идеала. А вот потом, вместо того, чтобы увеличивать и без того огромный документ под названием C++ standard, каждый модуль может оставаться независимым мини-стандартом по типу TS, и у него будет одна реализация в одном месте вместо кучи независимых под каждый компилятор. 3 из 5 фич, упомянутых в статье, можно было бы вынести в такие вот библиотеки.
В статье описано все красиво, но мне, как пессимисту, представляется более реальным вариант, когда всякие учреждения будут собирать данные себе в тетрадочку, и, для галочки, еще и на портал.
Остроумное применение принципа, но я имел в виду, что люди, которые считают себя вправе нарушать закон, должны штрафоваться (даже если на самом деле нарушения и не было).
Те оштрафованные, кто знали про это изменение, наверняка также обжаловали. А те, кто не знали, этот штраф вполне заслужили, т.к. парковались неправильно.
Да, пожалуй, «средним» городам в этом смысле хуже всего. Расстояния и соответственно расценки уже достаточно большие, а удобные конкурирующие сервисы (еще?) не присутствуют. Хотя 180р выглядит вполне вменяемой ценой (моя последняя поездка на Я.Такси на расстояние около 5 км обошлась в 170 р). Может быть, с приходом uber цена уменьшится…
Принципиально разные условия. Для «мелких» городов характерна фиксированная цена на такси; если разница между минимальной поездкой и максимальной — пара километров и пять минут, то нет смысла в их дифференциации. К примеру, в моем городе официальные таксисты берут те же 80 р за поездку внутри города, а «леваки» с вокзала — 100р.
А вот в небольшом количестве крупных городов поездка с одного края на другой может вылиться в десятки километров и (при наличии пробок) в час, а то и больше. Плоский тариф на весь город там, понятное дело, невозможен; а вот «внутри микрорайона» (особенно если есть большой людской трафик на небольшой площади — станция метро, крупный супермаркет) условия оказываются близкими к тем, что в мелких городах, и плоский тариф — логичным.
Я не знаток уголовного права, но с точки зрения здравого смысла — обязанность предвидеть очевидные последствия есть. Я обязан убедиться, к примеру, при установке антенны, что используемые крепления (и то, к чему они крепятся) рассчитаны на соответствующую нагрузку. То же и с горшком. Иначе получается, что я могу взять любую область, в которой я профан, и делать все, что мне в голову взбредет без последствий. Про Америку и их систему права вопрос отдельный.
Про страхование — законодательству тут делать нечего, все договором между владельцем и страховой должно решаться. В России вопрос открытый (особенность менталитета, вообще мало кто добровольно страхуется). В Америке страховые начинают подтягиваться к новому куску пирога, к примеру http://www.aig.com/business/insurance/specialty/unmanned-aircraft-solutions
> возлагают ответственность на этого субъекта — пилота
Ответственность за любые действия по умолчанию несет тот, кто их совершает. Тут все логично и неважно, дрон там или не горшок с цветками.
> в отношении дронов не факт, что аварии будут признаны несчастным случаем.
Если пилот сделал все разумные действия по обеспечению безопасности — то с большой вероятностью будут. Если дрон упал на голову человека из толпы, над которой тот летал — то однозначно виноват пилот (нарушил правила FAA и как минимум проявил небрежность). Если (по всем признакам исправный) дрон летал над леском и вдруг упал и убил туриста, который внизу проходил — ситуация такая же, как если бы у меня с балкона оторвалась (по причине заводского дефекта) спутниковая тарелка и убила кого-то. Если доказать, что причиной послужил заводской дефект, а не небрежность при установке или эксплуатации (что может быть проблемно), то вины не будет. По УК.
> И вопрос со страховкой вовсе не прост
Либо идем и страхуемся, либо не страхуемся и рискуем потенциально очень большими деньгами. Все просто.
все нижеследующее — умозрительные размышления, а не твердые знания
Техконтроль за квадракоптерами не строже, чем за легкими летательными аппаратами типа глайдеров, парапланов и «кукурузников». Скорее всего, есть какая-нибудь норма типа предполетной проверки аппарата, которую должен делать сам пилот. План полета предоставляется (по крайней мере для некоторых категорий) уведомительным порядком. FAA может запрещать полеты над некоторыми местами, но не для конкретного пилота, а для всех.
Про страхование — похоже, что обязательного страхования нет, но можно застраховаться добровольно. Если будет несчастный случай, то все будет рассматриваться в рамках общего права (нет каких-то особенностей в том, что именно квадракоптер, а не кирпич упал на темечко)
А/м не стоит рассматривать — их законодатели рассматривают как очень особый случай. Вплоть до отдельной статьи за убийство с использованием авто.
Они вменяют. У FAA есть категория «беспилотные летательные аппараты» и, в частности, «модельные летательные аппараты»; FAA разрешает использовать такие аппараты без лицензии пилота, подачи полетного плана и прочего, но накладывает ограничения на высоту полета, требует визуального контроля аппарата пилотом, запрещает полеты над густонаселенными местами и т.д. А вот аппараты, используемые для коммерческих целей, под «модельные» не подпадают, и оператору потребуется получить лицензию пилота. Не получил лицензию — получил штраф.
А вот у федерального закона такого разделения нет и все летательные средства считаются одинаковыми. Dura lex, как говорится
Заголовок этой статьи несколько вводит в заблуждение. Сама эта статья упоминает о «новом законе», но не дает никаких деталей о нем. Если пройти по ссылкам, то там говорят про закон о наказании за сбитые летательные средства (18 U.S.C. § 32), который действует с 1984 года. Из нового — FAA подтвердила, что те, кто сбивают дроны, подпадают под действие того старого закона. Какого-то нового специального закона, устанавливающего ответственность за сбитые дроны, как я понимаю, нет.
Потому что в закон не делает различия между «легальными дронами» и другими летательными средствами (такими, как самолеты). Одна и та же норма закона применяется против тех, кто сбивает игрушечный дрон, и тех, кто роняет пассажирский авиалайнер.
Хотя пока не все так плохо. Новостные статьи, на которые ссылается автор, говорят, что этот федеральный закон еще не применялся против тех, кто сбивал дроны. В тех 2 случаях, что описаны в статье, их арестовывали за использование оружия, а не за сбитые дроны (и в одном случае дело дошло до суда, который его оправдал).
> только 20% подозреваемых, по которым программа определила высокий риск совершения преступлений, действительно совершили его в течение двух лет после выставления риска.
Косяк алгоритма. Вот об этом надо заострять внимание — на том, что судебная система руководствуется черт знает чем при выборе наказания. А не искать расизм там, где его нет. Было бы интересно еще посчитать обратный вариант — сколько из тех, кому был назначен малый риск, совершили повторные правонарушения. Если и там было бы большое число ошибок — то вообще замечательный сюжет «хороших наказываем, а плохих поощряем».
Здесь еще есть интересный вопрос в том, а не влияет ли сам факт того, что был выставлен высокий риск, на совершение повторного преступления? Скажем, если нарушителя с малым вычисленным риском отпустили, «погрозив пальчиком» — не будет ли это являться побудительным фактором для того снова нарушить? И наоборот, если за пьяное вождение посадить под домашний арест на пару лет — это будет неплохо защищать от повторного нарушения.
> Ошибочное предсказание рецидива для чернокожих вдвое выше, чем для белых.
И это тоже косяк алгоритма, и опять же не связанный с расой. Возможно, вес каких-то «отягощающих» факторов (которые в этой стат выборке коррелируют с расой) в итоговой оценке слишком задран.
Интересно, эти Northpointe для каждой конкретной местности подстраивают веса у алгоритма или он у них общий везде? Если общий везде — то это вообще явный косяк компании.
При наличии в бинарнике async unwind tables вроде бы должно быть можно, не?
Статью — просим нижайше, очень интересная тема. И про breakpad, и про сбор стека в полете исключения.
У нас есть костыль, пишущий минидампы, на базе SEH-обработчика, но хотелось бы чего-то более C++ного и универсального. Если оно еще и под *nix сумеет асинхронные сигналы перехватывать и дампить (и давить потом, чтобы можно было как-то попытаться восстановиться) — вдвойне интересно
А хочется еще быстрее и еще больше ) Хочется async await, а приходится использовать gcc 4.7, в котором и C++11 не до конца допилен. Грустные реалии промышленного программирования.
> Насколько я помню, у них и C99 пока не поддерживается полностью.
В 2013 версии с C99 все стало гораздо лучше (хотя может быть все еще не полностью, утверждать не буду).
> Был сделан выбор в пользу современных тенденций и требований рынка…
Я имел в виду сделать некий набор официальных библиотек, которые бы стандартизировались по тем же принципам, что сейчас идет стандартизация в общий стандарт, и поддерживались производителями компиляторов. Соответственно — проблемы с безопасностью не больше, чем при использовании стандартной библиотеки компилятора (пишут те же люди); нет проблемы с выбором среди N библиотек — есть 1 официальная; документация на такие библиотеки тоже будет хорошей.
Из плюсов — меньше времени будет тратиться на добавление фич и их модификацию (я имею в виду спецификацию фичи — нет привязки к 3-годичному циклу общего стандарта); качество реализации каждой фичи будет выше (ибо не N реализаций от N команд, а 1 реализация от N команд; и пользователей кода соответственно X, а не X/N); баги в реализации будут фикситься быстрее (нет привязки к релизу следующей версии компилятора).
Из минусов — да, больше #ifdef/костылей под разные компиляторы (хотя буст в этом смысле не показатель — он пытается поддерживать старые компиляторы, а здесь производитель компилятора может просто не заявлять поддержку старых версий — как это и делается сейчас в стандартной библиотеке); меньше давление на производителя компилятора по поддержке новых стандартных библиотек (хотя и сейчас это их не останавливает — case in point MSVC и C99/expression SFINAE). На примере Boost.DLL — вроде бы самодостаточный модуль без каких-либо зависимостей (и он вполне может пройти все круги стандартизации за пару лет), но в лучшем случае это попадет в C++20; и даже после этого мы будем ждать, пока msvs/gcc/clang/icc реализуют эту часть стандарта у себя и выпустят очередные релизы, или использовать полифиллы из того же Boost. А можно было бы выпустить TS где-нибудь к 18 году и подождать, пока кто-то один/два из производителей накропает одну реализацию, которая скорее всего заработает со всеми остальными.
Если рассмотреть вопрос модулей с более практической точки зрения, то
а) ничто не мешает их использовать уже сейчас, хоть они и не в стандарте — VS2015U1 уже умеет, clang вроде бы тоже что-то выкатывал.
б) если бы они даже вошли в стандарт, то это не значит, что их вдруг стало бы можно использовать — нужна поддержка компиляторами, и нужна поддержка библиотеками.
В общем, стандарт — это как красивая теория, а на практике мы сталкиваемся с жестокой реальностью того, что используется в основном C++11, и то не везде. C++14 еще не стало популярным (даже нет полной поддержки в MSVS), не говоря уж о C++17.
Что касается тех фич, про которые говорится в статье:
— Dynamic Library Load — не вижу большого смысла вносить это в стандарт. Фича, имхо, достаточно редкая, и она полностью закрывается замечательными библиотеками, скрывающими кишки от пользователя, типа того же Boost.DLL. Атрибут [[visible]] в стандарте при том полностью поддерживаю (я не очень понял, как там модули решат проблему с dllimport, но это отдельный разговор).
— стандартизация плоских контейнеров — это тоже решено библиотеками, но эта фича очень востребована, так что оно в стандарте вполне уместно
— класс для вывода stack trace — очень специфическая фича, и есть библиотеки в помощь. Если идти в сторону стандартизации, то было бы лучше стандартизировать ABI для описаний функций; это, к сожалению, утопично, а заставить разработчиков компиляторов поддерживать единого API над своими ABI — тоже выход.
— интерфейсы — интересно, но пока не очень ясно, чем это принципиально отличается от ABC. Меня бы больше порадовала возможность описывать в публичных заголовках классы частично (только публичные функции), если внешним потребителям не требуется знать структуру класса в памяти. Сейчас либо приходится вываливать на всеобщее обозрение кишки класса, либо делать ABC, либо колбасить Pimpl или что-то похожее.
— доступ к полям структур по индексу и базовая рефлексия — архинужно, хотя бы на уровне проитерироваться по полям структуры и узнать их имена. Но на это уже есть как минимум 2 документа, которые давно в работе. Какой-то из двух должен в конце концов дойти до стандарта.
У меня за последний год сложилось ощущение, что в стандартную библиотеку C++ хотят/пытаются внести слишком много функционала. Лучше, на мой взгляд, было бы доделать модули и сделать наконец какой-нибудь нормальный dependency manager, и выносить функционал в отдельные самодостаточные библиотечки. При этом можно сделать какой-нибудь особый namespace для «официальных» библиотек типа «isocpp/» и не менять процедуру стандартизации «официальных» модулей; пусть также они сначала пишутся и обсуждаются в рабочей группе, потом идут в LibraryWG и там монстры и корифеи их доводят до идеала. А вот потом, вместо того, чтобы увеличивать и без того огромный документ под названием C++ standard, каждый модуль может оставаться независимым мини-стандартом по типу TS, и у него будет одна реализация в одном месте вместо кучи независимых под каждый компилятор. 3 из 5 фич, упомянутых в статье, можно было бы вынести в такие вот библиотеки.
А вот в небольшом количестве крупных городов поездка с одного края на другой может вылиться в десятки километров и (при наличии пробок) в час, а то и больше. Плоский тариф на весь город там, понятное дело, невозможен; а вот «внутри микрорайона» (особенно если есть большой людской трафик на небольшой площади — станция метро, крупный супермаркет) условия оказываются близкими к тем, что в мелких городах, и плоский тариф — логичным.
Про страхование — законодательству тут делать нечего, все договором между владельцем и страховой должно решаться. В России вопрос открытый (особенность менталитета, вообще мало кто добровольно страхуется). В Америке страховые начинают подтягиваться к новому куску пирога, к примеру http://www.aig.com/business/insurance/specialty/unmanned-aircraft-solutions
Ответственность за любые действия по умолчанию несет тот, кто их совершает. Тут все логично и неважно, дрон там или не горшок с цветками.
> в отношении дронов не факт, что аварии будут признаны несчастным случаем.
Если пилот сделал все разумные действия по обеспечению безопасности — то с большой вероятностью будут. Если дрон упал на голову человека из толпы, над которой тот летал — то однозначно виноват пилот (нарушил правила FAA и как минимум проявил небрежность). Если (по всем признакам исправный) дрон летал над леском и вдруг упал и убил туриста, который внизу проходил — ситуация такая же, как если бы у меня с балкона оторвалась (по причине заводского дефекта) спутниковая тарелка и убила кого-то. Если доказать, что причиной послужил заводской дефект, а не небрежность при установке или эксплуатации (что может быть проблемно), то вины не будет. По УК.
> И вопрос со страховкой вовсе не прост
Либо идем и страхуемся, либо не страхуемся и рискуем потенциально очень большими деньгами. Все просто.
Мы куда-то от темы ушли, правда.
Техконтроль за квадракоптерами не строже, чем за легкими летательными аппаратами типа глайдеров, парапланов и «кукурузников». Скорее всего, есть какая-нибудь норма типа предполетной проверки аппарата, которую должен делать сам пилот. План полета предоставляется (по крайней мере для некоторых категорий) уведомительным порядком. FAA может запрещать полеты над некоторыми местами, но не для конкретного пилота, а для всех.
Про страхование — похоже, что обязательного страхования нет, но можно застраховаться добровольно. Если будет несчастный случай, то все будет рассматриваться в рамках общего права (нет каких-то особенностей в том, что именно квадракоптер, а не кирпич упал на темечко)
А/м не стоит рассматривать — их законодатели рассматривают как очень особый случай. Вплоть до отдельной статьи за убийство с использованием авто.
А вот у федерального закона такого разделения нет и все летательные средства считаются одинаковыми. Dura lex, как говорится
Хотя пока не все так плохо. Новостные статьи, на которые ссылается автор, говорят, что этот федеральный закон еще не применялся против тех, кто сбивал дроны. В тех 2 случаях, что описаны в статье, их арестовывали за использование оружия, а не за сбитые дроны (и в одном случае дело дошло до суда, который его оправдал).