Я бы тоже не смешивал. И не смешиваю, а коллеги не соглашаются.
Коллеги, вероятно, не сталкивались с регрессионным анализом вне контекста машинного обучения.
Метод построения такой функции — это алгоритм машинного обучения, берущий на вход размеченную выборку и дающий ее на выходе.
Вот физики сейчас удивились, что их любимые МНК и градиентный спуск — это оказывается методы машинного обучения, а не методы оптимизации.
Аппроксимация в данном контексте — это просто математический жаргон, не имеющий строгого определния и означающий приближение одних объектов другими.
А меня вот учили, что аппроксимация — это научный метод для построения мат. моделей. И целый раздел мат. анализа. Про полиномы Лагранжа и Ньютона и вот это все.
А если так:
1. Задача классификации состоит в построении классификатора.
2. Классификатор может быть пострен на базе логистической регрессии.
3. Логистическая регрессия — это статистическая модель, которая может быть построена разными методами — регрессионным анализом, машинным обучением, etc.
Я вот в твоих определениях не понимаю, почему внезапно ты задачу решаешь моделью, а не методом.
Так и я в основном тексте говорю, что это «логистическая регрессия». А мой комментатор утверждает, что это не «логистическая регрессия» а «просто регрессия», а «логистическая регрессия» как постановка задачи — это «классификация». И кто прав?
Ну я бы не смешивал понятия «логистическая регрессия» и «классификатор». Несмотря на то, логистическую регрессию МОЖНО использовать для построения классификатора, это все же совсем разные вещи.
После этого построение модели, сопоставляющей любой точке в R^n значение в R — это и есть построение новой функции специального вида, приближающей исходную, т. е. аппроксимация.
Ну вот, если быть точным, то регрессия — это полученная модель, а аппроксимация — один из методов ее построения (но не единственный).
Поиск регрессии — это совершенно отдельная от машинного обучения задача, решаемая регрессионным анализом. То что вы с помощью регрессии можете построить классификатор, никак не относит регрессию к задачам машинного обучения.
Нам дают свершившиеся события (наличие или отсутствие перехода по рекламной ссылке, 0 или 1) и просят предсказать вероятность этого события (действительное число от 0 до 1)
Дорос до проектов и компаний в которых фундаменталка, кругозор и знание предметной области важнее знания конкретных языков и фреймворков. В конце очередного собеседования узнал, что писать надо будет под JVM. Согласился. Уже больше года полет нормальный :)
2. Как связаны Reactive Streams с серверами приложений? В .net Reactive Streams тоже есть (и, кажется, уже везде есть) и сам исходный паттерн Observable встроен в сам язык с самых первых версий.
3. После знакомства с maven и gradle я начал очень сильно ценить и любить msbuild.
4. Доминирования прикладных фреймворков не наблюдаю. Наблюдаю бардак в базовых АПИ (даты, коллекции, etc) и монстроидальные монолитные EE и Spring.
5. В java есть osgi и новый jigsaw. В .net есть MEF, но я ни разу не видел, чтобы кто-то им пользовался.
6. Наблюдаю использование большого количества бойлерплейтных паттернов типа Builder, вместо которых в C# удобный синтаксический сахар.
7. В java очень любят и активно используют annotation processors для генерации кода. После .net ощущается очень свежо и интересно. Dagger удивил, например (а что, так можно было?)
А еще я напомню, что множество — это не набор значений, а набор правил определяющих вхождение того или иного значения в данное множество. Опять же, из математики. Вхождение значения в интервал, как подсказывается кэп, определяется как a < value < b, где a, b — концы интервала.
Интервал — это множество. У которого по определению есть предикат «входит» для числа. Из него легко вывести предикат для подмножеств. Если предиката нету — это не интервал, а просто два числа на отрезке.
Открыл книжку Clean Architecture и полистал, соответственно, покритикую статью более предметно.
SRP:
Мартин пишет не о участниках проекта, а о стейкхолдерах (на картинках — CFO, COO, CTO и ответственности типа «рассчитать зарплату», «отчитаться о рабочих часах», etc). То есть речь совсем не о DBA, а пользователях и заказчиках системы и их бизнес-процессах. И с этой точки зрения определение имеет смысл, «генерировать отчет для CFO» — это вполне себе ответственность. А вот причем здесь DBA и почему он диктует компонентам ответственности — совершенно непонятно.
OCP:
В книжке Мартин оперирует классами и компонентами. Слово «артефакт» используется только в контексте исходной формулировки принципа от Бертрана Мейера от 1988 года, и, очевидно, что это не jar и не dll.
LSP:
Здесь больше нет старой формулировки от Мартина. Только исходная формулировка от Лисков.
Сразу за ней идет раздел под названием GUIDING THE USE OF INHERITANCE и старая добрая проблема square/rectangle. И дальше уже про интерфейсы и их реализации.
То есть определение Мартина более приближено к практическому программированию?
Не понимаю из чего сделан такой вывод. Мы не обсуждали применимость тех или иных определений к практическому программированию. Мы обсуждали их корректность и полноту, из чего и следует применимость. Если вы по Мартиновскому определению сами наследуете мутабельный класс от иммутабельного — это уже о нем говорит все что нужно знать.
А если программист написал в комментарии, что класс может быть изменяемым, но реализация таковой не является?
У вас контракт зависит от реализации?
Извините, но я, пожалуй, перестану тратить свое время.
Кстати, если разобраться — то как раз оригинальное определение Лисков несет неоднозначность, поскольку в нем не говорится какие именно свойства в нем рассматриваются: мгновенные (т.е. инварианты) или свойства поведения объекта.
Говорится и очень подробно, как и про инварианты, так и про свойства поведения (она называет это constraints и очень подробно и формально определяет).
Ах да, а еще оригинальный принцип подстановки Лисков не применим к интерфейсам, поскольку у интерфейса не может быть своих доказуемых свойств.
У Лисков как бы вообще нету ни классов, ни интерфейсов. У нее типы и подтипы (а интерфейс, это очевидно тип) с контрактами. Если конкретный язык не позволяет задавать предусловия и постусловия для интерфейса — это не означает, что их можно игнорировать.
В первом случае наследование мутабельного класса от иммутабельного не является нарушением LSP, ведь иммутабельность не является инвариантом типа!
Как бы из предыдущего следует, что если программист написал в комментарии, что класс иммутабельный — это уже constraint и его надо соблюдать. Даже если еще не существует кода, который бы мог этот constraint нарушить.
Открываем Мартина: «FUNCTIONS THAT USE POINTERS OR REFERENCES TO BASE
CLASSES MUST BE ABLE TO USE OBJECTS OF DERIVED CLASSES
WITHOUT KNOWING IT.»
Нету здесь речи ни о всех потенциальных функциях ни о функциях полагающихся на инвариант. Это вы уже дополняете, потому что знаете о чем правило. И прочитано это может быть как угодно (о чем и речь, собственно).
Ок, давайте такой пример:
1. Есть иммутабельный тип.
2. Есть функция его использующая.
3. Наследуем от иммутабельного типа новый — мутабельный (добавляем сеттеры, например).
По определению Мартина — это корректный код, функция может использовать мутабельный тип вместо базового иммутабельного.
По определению Лисков — нет, потому что нарушены инварианты.
Коллеги, вероятно, не сталкивались с регрессионным анализом вне контекста машинного обучения.
Вот физики сейчас удивились, что их любимые МНК и градиентный спуск — это оказывается методы машинного обучения, а не методы оптимизации.
А меня вот учили, что аппроксимация — это научный метод для построения мат. моделей. И целый раздел мат. анализа. Про полиномы Лагранжа и Ньютона и вот это все.
1. Задача классификации состоит в построении классификатора.
2. Классификатор может быть пострен на базе логистической регрессии.
3. Логистическая регрессия — это статистическая модель, которая может быть построена разными методами — регрессионным анализом, машинным обучением, etc.
Я вот в твоих определениях не понимаю, почему внезапно ты задачу решаешь моделью, а не методом.
Ну я бы не смешивал понятия «логистическая регрессия» и «классификатор». Несмотря на то, логистическую регрессию МОЖНО использовать для построения классификатора, это все же совсем разные вещи.
Ну вот, если быть точным, то регрессия — это полученная модель, а аппроксимация — один из методов ее построения (но не единственный).
Это каноничная логистическая регрессия. Прямо по определению — en.wikipedia.org/wiki/Logistic_regression
А это не регрессия, это аппроксимация.
1. Про дженерики выше много написано.
2. Как связаны Reactive Streams с серверами приложений? В .net Reactive Streams тоже есть (и, кажется, уже везде есть) и сам исходный паттерн Observable встроен в сам язык с самых первых версий.
3. После знакомства с maven и gradle я начал очень сильно ценить и любить msbuild.
4. Доминирования прикладных фреймворков не наблюдаю. Наблюдаю бардак в базовых АПИ (даты, коллекции, etc) и монстроидальные монолитные EE и Spring.
5. В java есть osgi и новый jigsaw. В .net есть MEF, но я ни разу не видел, чтобы кто-то им пользовался.
6. Наблюдаю использование большого количества бойлерплейтных паттернов типа Builder, вместо которых в C# удобный синтаксический сахар.
7. В java очень любят и активно используют annotation processors для генерации кода. После .net ощущается очень свежо и интересно. Dagger удивил, например (а что, так можно было?)
Исходный тезис автора — в ООП не моделируются предикаты второго порядка. Это, очевидно, неправда.
А вот «Спецификация» как по мне, вполне себе отвечает запросу автора.
SRP:
Мартин пишет не о участниках проекта, а о стейкхолдерах (на картинках — CFO, COO, CTO и ответственности типа «рассчитать зарплату», «отчитаться о рабочих часах», etc). То есть речь совсем не о DBA, а пользователях и заказчиках системы и их бизнес-процессах. И с этой точки зрения определение имеет смысл, «генерировать отчет для CFO» — это вполне себе ответственность. А вот причем здесь DBA и почему он диктует компонентам ответственности — совершенно непонятно.
OCP:
В книжке Мартин оперирует классами и компонентами. Слово «артефакт» используется только в контексте исходной формулировки принципа от Бертрана Мейера от 1988 года, и, очевидно, что это не jar и не dll.
LSP:
Здесь больше нет старой формулировки от Мартина. Только исходная формулировка от Лисков.
Сразу за ней идет раздел под названием GUIDING THE USE OF INHERITANCE и старая добрая проблема square/rectangle. И дальше уже про интерфейсы и их реализации.
Приведенном где и кем?
Не понимаю из чего сделан такой вывод. Мы не обсуждали применимость тех или иных определений к практическому программированию. Мы обсуждали их корректность и полноту, из чего и следует применимость. Если вы по Мартиновскому определению сами наследуете мутабельный класс от иммутабельного — это уже о нем говорит все что нужно знать.
У вас контракт зависит от реализации?
Извините, но я, пожалуй, перестану тратить свое время.
Говорится и очень подробно, как и про инварианты, так и про свойства поведения (она называет это constraints и очень подробно и формально определяет).
У Лисков как бы вообще нету ни классов, ни интерфейсов. У нее типы и подтипы (а интерфейс, это очевидно тип) с контрактами. Если конкретный язык не позволяет задавать предусловия и постусловия для интерфейса — это не означает, что их можно игнорировать.
Как бы из предыдущего следует, что если программист написал в комментарии, что класс иммутабельный — это уже constraint и его надо соблюдать. Даже если еще не существует кода, который бы мог этот constraint нарушить.
CLASSES MUST BE ABLE TO USE OBJECTS OF DERIVED CLASSES
WITHOUT KNOWING IT.»
Нету здесь речи ни о всех потенциальных функциях ни о функциях полагающихся на инвариант. Это вы уже дополняете, потому что знаете о чем правило. И прочитано это может быть как угодно (о чем и речь, собственно).
1. Есть иммутабельный тип.
2. Есть функция его использующая.
3. Наследуем от иммутабельного типа новый — мутабельный (добавляем сеттеры, например).
По определению Мартина — это корректный код, функция может использовать мутабельный тип вместо базового иммутабельного.
По определению Лисков — нет, потому что нарушены инварианты.
А о том, какие условия должны выполняться, чтобы оно соблюдалось?