The first algorithm seems to be wrong. Assume A = [0, 100], B = [2, 1], x = 10. Then the correct answer is 1 (just nullify the second component). While your algorithm will return -1
Я не помню, нужно посмотреть на реализации, возможно, у вектора итераторы переопределены и специфицированны (хотя я и сомневаюсь). Вот чего точно нельзя делать - это превращать его в итератор явно.
Что нужно, например, для функций, берущих итератор интов на вход. Такая функция будет использовать уже общую реализацию итераторов, в которой Integer.
Для простоты синтаксиса. У них всегда Int, который в байтовом коде по возможности будет приводиться к int. Есть специальный механизм (Type Specialization), который позволяет даже с дженериками писать так, чтобы была отдельная реализация с примитивами, но работает всё не очень прозрачно и простой синтаксис приводит к тому, что аккуратно сделать так, чтобы нигде не было боксинга несколько затруднительно.
Можно посмотреть на Скалу, где невозможно отличить int от Integer (язык сам выбирает, где делать боксинг/анбоксинг). В итоге высокопроизводительный код сильно проще написать на джаве и импортировать, чем аккуратно разбираться "а почему компилятор в этом месте не догадался, что int достаточно".
Всё-таки меньше. Всего пусков 218, последний неуспешный был бы 29-м (но случилась авария перед запуском), итого примерно 190 успешных пусков подряд. А последняя неудачная посадка была на 108 пуске, т.е. 110 пусков назад.
Проблема с хранилищем отходов. Иметь электростанции и не иметь хранилище отходов - не очень хорошая схема, с отходами что-то нужно делать. Была гипотеза, что соляные шахты - это хорошее место (если там хранилась соль, то контакта с водой тоже не будет, звучит не безумно). К сожалению, за 50 лет выяснилось, что это не так. Не понятно, как может выглядеть новая надёжная схема, которая не окажется настолько же "надёжной" как прошлая (через 50 лет, а сроки хранения там от нескольких сотен, если я не ошибаюсь).
Собственно, это не одна конкретная утечка, а обнаружение, что этот способ, на длинной дистанции не работает.
Бром-содержащие фреоны тоже запретили примерно потому, что их не получалось хорошо хранить и утилизировать.
С хранилищами высокотоксичных отходов проблема как с "запасом прочности" у Шаттлов по мнению Феймана (см. https://habr.com/ru/articles/579218/).
Если инженерное хранилище ведёт себя не так, как ожидается (а в Ассе случилось именно это), то им нельзя пользоваться (даже если пока ещё никто не погиб).
Вроде, выплаты акционерам в себестоимость обычно не входят (хотя, если это оформлено как займ, то могут и входить, это вопрос того, как вести отчётность). У серийного производства себестоимость близка к предельным издержкам, насколько я понимаю. Но пока серии нет, можно обсуждать себестоимость всех доз вместе.
Предельные издержки на производство одной дозы действительно гораздо меньше стоимости продажи. Но это довольно частый эффект. Самый заметный, с которым многие встречались - это авиабилеты. Предельные издержки на ещё одного пассажира гораздо меньше, чем стоимость билета.
Кажется, скаловский sumScala и джавовский sumResultsFromDifferentMonads делают разное: первый приводит к Option, а второй - к Try. Если приводить к Option, то, вроде можно ещё проще:
def sumScala(i1: Option[Int], i2: Try[Int]) : Option[Int] = {
(i1, i2) match {
case (Some(x1), Success(x2)) => Some(x1 + x2)
case _ => None
}
}
Общая рекомендация "делайте проверку на err в коде один раз на переменную" (что дословно написано в тексте), или, даже, "парсите, а не валидируйте" - выглядит верной в общем случае (не смотря на то, что остальные тезисы в статье откровенно слабые).
The first algorithm seems to be wrong.
Assume A = [0, 100], B = [2, 1], x = 10.
Then the correct answer is 1 (just nullify the second component).
While your algorithm will return -1
Только в случае {∅} мы наклеили наш ярлычок.
А именно наклеили на единственный объект - на (единственный) ярлык, который никуда не наклеен.
Пустая коробка, и коробка, содержащая пустую коробку, - это разные сущности.
Я не помню, нужно посмотреть на реализации, возможно, у вектора итераторы переопределены и специфицированны (хотя я и сомневаюсь).
Вот чего точно нельзя делать - это превращать его в итератор явно.
Что нужно, например, для функций, берущих итератор интов на вход. Такая функция будет использовать уже общую реализацию итераторов, в которой Integer.
Сам сможет.
Но, например, итераторы из стандартной библиотеки специализированной версии для примитивов не имеют (а значит, если их используешь - будет боксинг).
Для простоты синтаксиса. У них всегда Int, который в байтовом коде по возможности будет приводиться к int. Есть специальный механизм (Type Specialization), который позволяет даже с дженериками писать так, чтобы была отдельная реализация с примитивами, но работает всё не очень прозрачно и простой синтаксис приводит к тому, что аккуратно сделать так, чтобы нигде не было боксинга несколько затруднительно.
Можно посмотреть на Скалу, где невозможно отличить int от Integer (язык сам выбирает, где делать боксинг/анбоксинг). В итоге высокопроизводительный код сильно проще написать на джаве и импортировать, чем аккуратно разбираться "а почему компилятор в этом месте не догадался, что int достаточно".
Последний неудачный пуск был бы 29-м, там авария случилась до взлёта: https://ru.wikipedia.org/wiki/Список_запусков_ракеты-носителя_Falcon_9
Всё-таки меньше. Всего пусков 218, последний неуспешный был бы 29-м (но случилась авария перед запуском), итого примерно 190 успешных пусков подряд.
А последняя неудачная посадка была на 108 пуске, т.е. 110 пусков назад.
Проблема с хранилищем отходов. Иметь электростанции и не иметь хранилище отходов - не очень хорошая схема, с отходами что-то нужно делать. Была гипотеза, что соляные шахты - это хорошее место (если там хранилась соль, то контакта с водой тоже не будет, звучит не безумно). К сожалению, за 50 лет выяснилось, что это не так. Не понятно, как может выглядеть новая надёжная схема, которая не окажется настолько же "надёжной" как прошлая (через 50 лет, а сроки хранения там от нескольких сотен, если я не ошибаюсь).
Собственно, это не одна конкретная утечка, а обнаружение, что этот способ, на длинной дистанции не работает.
Бром-содержащие фреоны тоже запретили примерно потому, что их не получалось хорошо хранить и утилизировать.
С хранилищами высокотоксичных отходов проблема как с "запасом прочности" у Шаттлов по мнению Феймана (см. https://habr.com/ru/articles/579218/).
Если инженерное хранилище ведёт себя не так, как ожидается (а в Ассе случилось именно это), то им нельзя пользоваться (даже если пока ещё никто не погиб).
del
Вроде, выплаты акционерам в себестоимость обычно не входят (хотя, если это оформлено как займ, то могут и входить, это вопрос того, как вести отчётность).
У серийного производства себестоимость близка к предельным издержкам, насколько я понимаю. Но пока серии нет, можно обсуждать себестоимость всех доз вместе.
Предельные издержки на производство одной дозы действительно гораздо меньше стоимости продажи. Но это довольно частый эффект. Самый заметный, с которым многие встречались - это авиабилеты. Предельные издержки на ещё одного пассажира гораздо меньше, чем стоимость билета.
Тут сложный вопрос в том, что считать себестоимостью. Например, как амортизировать изначальный РнД (и что в него включать).
Кажется, скаловский
sumScalaи джавовскийsumResultsFromDifferentMonadsделают разное: первый приводит к Option, а второй - к Try.Если приводить к Option, то, вроде можно ещё проще:
Как раз clone - это "дорогое копирование", а copy - это memcpy, как и перемещение.
В ожиданиях. Второй - это место с ожидаемым падением (если входные данные не корректны).
А unwrap предлагается использовать в каких-то таких случаях:
Конкретно у get есть версия, которая просто паникует (get_unchecked), но такой аналог есть не у всех функций возвращающих option.
Да, конечно.
Общая рекомендация "делайте проверку на err в коде один раз на переменную" (что дословно написано в тексте), или, даже, "парсите, а не валидируйте" - выглядит верной в общем случае (не смотря на то, что остальные тезисы в статье откровенно слабые).
В целом я согласен с комментарием, в тексте действительно много мусора.
Но в первом случае (про перформанс) автор всё-таки, вероятно, прав.
делает unwrap 1000 раз, а
всего один