Туториал и правда вышел не очень. Будь в нём некоторое введение, чёткая постановка задачи и описание идеи, лежащей в основе предложенного способа, он был бы намного лучше. Отсутствие у читателя в голове того контекста, что есть у автора и который почему-то кажется ему само собой разумеющимся, не очень-то помогает понять уже готовое решение, запечённое в функцию, также лишённую контекста.
Насчёт самой решаемой проблемы тоже можно сказать пару вещей. Во-первых, неплохо бы дать оценку эффективности предложенного метода: сколько операций он позволяет сэкономить, как эта экономия соотносится с имеющимися затратами на вычисление проекции и как - со всеми затратами на отрисовку кадра. Во-вторых, трассировкой лучей занималось уже немало хороших грамотных специалистов и весьма возможно, что они уже придумали хорошие способы повысить эффективность и в этом вопросе. Может быть, стоило поискать эти решения. Возможно, они даже превосходят предлагаемое (а вопрос их сравнения тем временем возвращает нас к "во-первых").
Хочется. Очень хочется, чтобы был как раз такой учебник. Чтобы объяснялось именно по этим принципам: зачем что-то вводится, каким образом дошли до именно такой мысли. И в то же время не экскурс в отдельную область, а цельное систематическое изложение. Вот бы ещё и по другим наукам такие учебные пособия появлялись...
В то же время некоторое недоумение вызвали дата-сатанистские термины и аналогии во введении. Подозреваю, они окажутся близки не каждому читателю.
Но вообще, если серьёзно: вы видите на этой вечеринке хоть что-то, ради чего стоило бы не то что пронзать пространство-время, а просто встать и подойти из соседнего дома? Если у вас есть возможность отправиться во времени куда угодно, действительно ли эта вечеринка переплюнет все остальные возможности?
Или не будет, если её удастся заинлайнить. Что весьма вероятно, если учесть, что вся шаблонность там заключается в том, чтобы передать аргументы в соответствующий конструктор.
Его мощность находится на очень высоких ординалах.
Это высказывание вообще имеет какой-то смысл? Я не специалист, но насколько мне известно, мощность - характеристика множества и описывается кардинальными, а не ординальными числами. А даже удивительно большое, но конечное целое число само по себе является одним конкретным ординалом.
Со временем я пришёл к убеждению, что когда кажется, что нужны property, надо первым делом проверить, нет ли грязи в архитектуре. Просто потому что они тянут "кишочки" (т.е. детали реализации) наружу, в интерфейс. Хотя формально это оборачивается в "защитные" методы-прокладки, семантически происходит как раз это. А значит, нарушаются уровни абстракции и надо посмотреть, что перекособочено и поправить, пока не стало поздно и дорого.
Люди писали код для других людей, даже если не знали, кто эти люди.
Не могу с этим согласиться. Тогда люди писали код как раз для самих себя, причём чаще всего - для самих себя сегодняшних. Все эти практики хорошего кода, читаемости, самодокументируемости, управление версиями появились как следствие индустриализации программирования, перехода к командной работе и необходимости отчуждения кода.
Всё? Да ни в коем случае. Все существующие судебные системы - замшелые реликты, основанные на простых прямолинейных решениях. Они даже и близко не стоят к "идеалу", как бы его ни формулировать, а скорее являются огромной свалявшейся грудой костылей, кое-как фиксящих всплывавшие по ходу эксплуатации проблемы. Собственно говоря, вполне возможно, что по-настоящему идеальную систему невозможно не то что создать, а даже и непротиворечиво сформулировать (см. парадокс Кондорсе и теорему Эрроу).
Я тут намекал как раз на то, что мнимые числа - совсем не то же самое, что обычные скаляры. Это самостоятельный математический объект, прочно связанный и взаимодействующий с обычными числами, но другой, с иными свойствами. Это не что-то придуманное наобум потолочно-глядельным и пальце-сосательным способом, все эти свойства чётко выводятся. В то время как зачастую комплексные числа вводятся в неокрепшие умы учащихся под соусом в духе "вот это тоже число такое, но будет лежать отдельно в коробочке с буквой i". Хорошо ли это, правильно ли?
Взяв на вооружение популярную идею, что i - это тоже такая единица, только другая, трудно объяснить тот факт, что i^i будет где-то около 0.2 обычной единицы...
– Пусть сочинит стихотворение о кибэротике! – сказал он наконец, радостно усмехаясь. – Пусть там будет не больше шести строк, а в них о любви и измене, о музыке, о неграх, о высшем обществе, о несчастье, о кровосмесительстве – в рифму и чтобы все слова были только на букву "К"!
– А полного изложения общей теории бесконечных автоматов ты случайно не предложишь? – заорал оскорбленный до глубины души Трурль. – Нельзя же ставить таких кретинских усло... И не договорил, потому что сладкий баритон, заполнив собой весь зал, в этот момент отозвался:
Абсолютный шифр - это OTP (одноразовый блокнот). Автор почти переизобрёл его, но не до конца (что характерно, схема управления ключами вышла как раз такая, как надо). Учите основы криптографии, мальчики и девочки, не пытайтесь изобрести всё с нуля, не будьте такими же заносчивыми, как Эдгар Аллан По. И что важно - не пренебрегайте анализом стойкости ваших изобретений к дифференциальным атакам, атакам с известным текстом и известным ключом, а также другим достижениям криптоаналитической мысли.
Туториал и правда вышел не очень. Будь в нём некоторое введение, чёткая постановка задачи и описание идеи, лежащей в основе предложенного способа, он был бы намного лучше. Отсутствие у читателя в голове того контекста, что есть у автора и который почему-то кажется ему само собой разумеющимся, не очень-то помогает понять уже готовое решение, запечённое в функцию, также лишённую контекста.
Насчёт самой решаемой проблемы тоже можно сказать пару вещей.
Во-первых, неплохо бы дать оценку эффективности предложенного метода: сколько операций он позволяет сэкономить, как эта экономия соотносится с имеющимися затратами на вычисление проекции и как - со всеми затратами на отрисовку кадра.
Во-вторых, трассировкой лучей занималось уже немало хороших грамотных специалистов и весьма возможно, что они уже придумали хорошие способы повысить эффективность и в этом вопросе. Может быть, стоило поискать эти решения. Возможно, они даже превосходят предлагаемое (а вопрос их сравнения тем временем возвращает нас к "во-первых").
Хочется. Очень хочется, чтобы был как раз такой учебник. Чтобы объяснялось именно по этим принципам: зачем что-то вводится, каким образом дошли до именно такой мысли. И в то же время не экскурс в отдельную область, а цельное систематическое изложение. Вот бы ещё и по другим наукам такие учебные пособия появлялись...
В то же время некоторое недоумение вызвали дата-сатанистские термины и аналогии во введении. Подозреваю, они окажутся близки не каждому читателю.
В Rust теоретически UB может быть только внутри unsafe. На практике добиться UB в safe-code можно только очень странными эзотерическими способами.
Но вообще, если серьёзно: вы видите на этой вечеринке хоть что-то, ради чего стоило бы не то что пронзать пространство-время, а просто встать и подойти из соседнего дома? Если у вас есть возможность отправиться во времени куда угодно, действительно ли эта вечеринка переплюнет все остальные возможности?
Или не будет, если её удастся заинлайнить. Что весьма вероятно, если учесть, что вся шаблонность там заключается в том, чтобы передать аргументы в соответствующий конструктор.
Это высказывание вообще имеет какой-то смысл? Я не специалист, но насколько мне известно, мощность - характеристика множества и описывается кардинальными, а не ординальными числами. А даже удивительно большое, но конечное целое число само по себе является одним конкретным ординалом.
Со временем я пришёл к убеждению, что когда кажется, что нужны property, надо первым делом проверить, нет ли грязи в архитектуре. Просто потому что они тянут "кишочки" (т.е. детали реализации) наружу, в интерфейс. Хотя формально это оборачивается в "защитные" методы-прокладки, семантически происходит как раз это. А значит, нарушаются уровни абстракции и надо посмотреть, что перекособочено и поправить, пока не стало поздно и дорого.
Не могу с этим согласиться. Тогда люди писали код как раз для самих себя, причём чаще всего - для самих себя сегодняшних. Все эти практики хорошего кода, читаемости, самодокументируемости, управление версиями появились как следствие индустриализации программирования, перехода к командной работе и необходимости отчуждения кода.
... со слайдами!
Всё? Да ни в коем случае. Все существующие судебные системы - замшелые реликты, основанные на простых прямолинейных решениях. Они даже и близко не стоят к "идеалу", как бы его ни формулировать, а скорее являются огромной свалявшейся грудой костылей, кое-как фиксящих всплывавшие по ходу эксплуатации проблемы.
Собственно говоря, вполне возможно, что по-настоящему идеальную систему невозможно не то что создать, а даже и непротиворечиво сформулировать (см. парадокс Кондорсе и теорему Эрроу).
Если статью вообще и автора в частности читают и плюсуют - значит, нужны.
Главная заповедь, которую следует помнить функциональному программисту: "Программы делаются только и исключительно ради побочных эффектов".
И когда рынок захлестнёт цунами мемристорной памяти, а в их коллектив вольётся много опытных умелых разработчиков, тут-то Фантом взлетит!
Когда посещают такие мысли, очень важно не забывать изящную пелевинскую максиму о том, что миром правит не тайная ложа, а явная лажа.
Я тут намекал как раз на то, что мнимые числа - совсем не то же самое, что обычные скаляры. Это самостоятельный математический объект, прочно связанный и взаимодействующий с обычными числами, но другой, с иными свойствами. Это не что-то придуманное наобум потолочно-глядельным и пальце-сосательным способом, все эти свойства чётко выводятся. В то время как зачастую комплексные числа вводятся в неокрепшие умы учащихся под соусом в духе "вот это тоже число такое, но будет лежать отдельно в коробочке с буквой i". Хорошо ли это, правильно ли?
Взяв на вооружение популярную идею, что
i- это тоже такая единица, только другая, трудно объяснить тот факт, чтоi^iбудет где-то около0.2обычной единицы...Всё уже было у Лема, господа:
Потому что если в общей задаче сложность экспоненциальная, деление её на полином экспоненту никуда не денет.
Абсолютный шифр - это OTP (одноразовый блокнот). Автор почти переизобрёл его, но не до конца (что характерно, схема управления ключами вышла как раз такая, как надо). Учите основы криптографии, мальчики и девочки, не пытайтесь изобрести всё с нуля, не будьте такими же заносчивыми, как Эдгар Аллан По. И что важно - не пренебрегайте анализом стойкости ваших изобретений к дифференциальным атакам, атакам с известным текстом и известным ключом, а также другим достижениям криптоаналитической мысли.
Не сочтите занудством, но переход от O(N^2) даже к O(1) не станет экспоненциальным снижением сложности.