Про телефонные номера — весьма сомнительно. Уже сейчас всякие юзернеймы и ID постепенно приобретают вид вроде «VasyaXYZ1980abrxkdhg», а что будет через пару десятков лет — представить страшно. По осмысленности это не сильно выигрывает у простого набора цифр, запоминать такое никто, разумеется, не будет. Поэтому вполне логично иметь один цифровой ID, зато на все сразу. Уже сейчас телефонные номера движутся в эту сторону благодаря приложениям вроде Whatsapp и Viber. Ну и в другом лагере дела обстоят похожим образом: на роль универсального ID претендует СНИЛС.
Как известно, драконов не существует. Эта примитивная констатация может удовлетворить лишь ум простака, но отнюдь не ученого. Банальность бытия установлена слишком давно и не заслуживает более ни единого словечка… Имеется три типа драконов: нулевые, мнимые и отрицательные. Все они, как было сказано, не существуют, однако каждый тип — на свой особый манер. Мнимые и нулевые драконы… не существуют значительно менее интересным способом, чем отрицательные.
Только одна маленькая придирка. Я с хаскелем знаком поверхностно, но насколько знаю ML, «f (x, y, z)» и «f x y z» — все же не одно и то же. Первое — передача в функцию одного параметра, кортежа из трех элементов. Второе — последовательная передача трех параметров через карринг, тут по сути вызов трех разных функций происходит. Ну и с вытекающими из этого фишками каждого из подходов.
"->" — это еще ничего. В Racket, который тесно связан со своей IDE — есть даже греческая буква λ для лямбда-выражений. Хорошо хоть ключевое слово lambda оставить додумались.
Функция getCustEmail была унаследована от функции getCustName, когда в приложении появилась поддержка email-адресов. Наследование кода подобным образом позволяет избежать случайного введения в программу новых багов.
Вы обзываете наследованием простое копирование кода с внесением правок, чем извращаете саму эту идею. Ваш пример — максимум рефакторинг, и то какой-то бессмысленный и беспощадный.
Наследование же как раз наоборот позволяет избавиться от дублирования кода и избежать потенциальных ошибок.
Если бы вам предоставили, скажем, готовый класс CustInfo с полем custRec и методом getCustName(custRec), а вы унаследовали от него свой класс MyCustInfo и расширили его методом getCustEmail(custRec) — вот это примерно то, что обычно подразумевается под наследованием.
Как раз недавно читал про метод повышения размерности для сведения нелинейной задачи к линейной.
Если кому интересно, тут про это немного написано: nlp.stanford.edu/IR-book/html/htmledition/nonlinear-svms-1.html
Ищется по «kernel mapping» или «kernel trick».
Автор читает лекции на ВМК, поэтому имел удовольствие наблюдать его в деле. Весьма эксцентричный товарищ, с налетом фанатизма, любовью ко всему низкоуровневому и показной ненавистью к майкрософту. Но с другой стороны — ценнейший источник знаний, может рассказать массу нюансов и неочевидных вещей, реально глубоко разбирается в теме. Его книжки(а их достаточно много, доступны на его сайте, в основном C/C++/UNIX/NASM) определенно стоит почитать, но все же при этом нужно критически относиться к некоторым излишне категоричным заявлениям.
Это ни в коем случае не критика и не придирка :) Просто штука эта достаточно известная, а именно она и раскрывается в статье.
Если для вас это новое, то советую почитать теорию про замыкания, функции высшего порядка и плюшки Lexical Scope — это в ряде случаев мощнейшие инструменты, позволяющие получать простые и красивые решения сложных задач. Думаю, это может помочь в вашей области деятельности.
Ну тут действительно не совсем понятно, что именно подразумевается под запретом косинуса и насколько далеко эти запреты распространяются. В решении с экспонентами мы получаем, как верно заметил автор, тот же косинус, но записанный в виде формулы. Если так, то можно не городить огород, а просто в самом очевидном решении в первообразной использовать не -cos, а -sqrt(1-sin^2). По смыслу это то же самое, что косинус, замаскированный под экспоненты. А если и такой вариант запрещен, то можно довести задачу до абсурда, сказав, что тогда и синус оказывается автоматически запрещенным, так как выводится из этой формулы через косинус.
Ну собственно, если скормить эти примеры gcc c ключом -S, то на выходе увидим совершенно идентичные ассемблерные листинги. Удивительно было бы ожидать тут какие-то различия.
Да нет, обилие уже только навскидку приходящих в голову отвлекающих факторов никак от конкретного озера не зависит. Причем, в отличие от домашних, эти факторы весьма сложно назвать устранимыми.
Если 4 часа работы в таких кошмарных условиях оказались продуктивнее работы в «обычной» обстановке, то это очень веский повод кардинально пересмотреть свой подход к организации домашнего рабочего места.
Станислав Лем. Вероятностные драконы. youtu.be/sVkB8Jsi1_8
Тут как раз несколько камер используется.
Только одна маленькая придирка. Я с хаскелем знаком поверхностно, но насколько знаю ML, «f (x, y, z)» и «f x y z» — все же не одно и то же. Первое — передача в функцию одного параметра, кортежа из трех элементов. Второе — последовательная передача трех параметров через карринг, тут по сути вызов трех разных функций происходит. Ну и с вытекающими из этого фишками каждого из подходов.
Вы обзываете наследованием простое копирование кода с внесением правок, чем извращаете саму эту идею. Ваш пример — максимум рефакторинг, и то какой-то бессмысленный и беспощадный.
Наследование же как раз наоборот позволяет избавиться от дублирования кода и избежать потенциальных ошибок.
Если бы вам предоставили, скажем, готовый класс CustInfo с полем custRec и методом getCustName(custRec), а вы унаследовали от него свой класс MyCustInfo и расширили его методом getCustEmail(custRec) — вот это примерно то, что обычно подразумевается под наследованием.
Если кому интересно, тут про это немного написано: nlp.stanford.edu/IR-book/html/htmledition/nonlinear-svms-1.html
Ищется по «kernel mapping» или «kernel trick».
И всё же, если не секрет, что ожидают услышать в ответ на эти вопросы? Что нужно отвечать? И, самое главное, как отвечать не нужно?
Если для вас это новое, то советую почитать теорию про замыкания, функции высшего порядка и плюшки Lexical Scope — это в ряде случаев мощнейшие инструменты, позволяющие получать простые и красивые решения сложных задач. Думаю, это может помочь в вашей области деятельности.
Web-Engineering I: Grundlagen der Web-Entwicklung
Web-Engineering II: Entwicklung mobiler HTML5-Apps
Первый стартует 15 октября, второй — в январе.