ООП. Иерархия геометрических фигур.

Геометрические фигуры — не сферические кони в вакууме. Иерархией для них будет многомасштабное вейвлет-разложение и соответствующие кодировки, направленные на компактификацию описаний в пространстве вейвлет-коэффициентов через обычную композициональность. Эти кодировки — и будут классы. Обратное вейвлет-преобразование будет нам давать «объекты» — изображения геометрических фигур (поведения объектов).

Ты не умничай, ты пальцем покажи (с)

Дело тут не в виртуальной машине, как таковой, а в «делайте». Капиталистам это не нужно, а опенсорсники-хоббисты этим заниматься не будут. Слишком тяжелая работа. Нужно слишком много звезд, чтобы сошлись в одном месте, что такие вещи возникли из хобби.

Посмотри на «нейронные коды», на визуализацию состояния нейронных сетей. Это не совсем то же самое, но это тоже репрезентации.

Совместить все эти аспекты в рамках одной линейной иерархии нельзя. Тут нужно переходить к DoD и работе с репрезентациями объектов, а ООП (иерархии классов) уже будет возникать динамически над репрезентациями.

Ага, вот значит ты что имел в виду:

Поэтому мой любимый трюк с «DoD внизу, ООП вверху» там не прокатывает.

Иерархии stateless-поведений. Забавно. Такого варианта anemic вроде не видел ещё.

нужна ли человек-интерпретируемость моделей, выводимых методами машинного обучения

Есть мнение, что это вообще невозможно. Простой пример – шахматные программы. Правила известны и игра изучена за сотни лет вдоль и поперёк. AI делает ходы, которые не могут объяснить все топовые гроссмейстеры мира вместе взятые. И это хорошо, в этом собственно и смысл AI - находить такие модели, которые человеку недоступны. Любой школьник обыграет с компом гросса, точно также как и обгодит чемпиона мира по бегу сев на мопед. Желание иметь «понятные модели» всё равно что желание бегать быстрее мопеда, или рыть лопатой быстрее экскаватора: глупо и непродуктивно.

У меня вообще возникала идея специального языка для ИИ. В нём нативно поддерживается ассоциативность и идентичность объектов и нет концепции чисел на базовом уровне вообще, только в акселераторах (модулях расширения).

Желание иметь «понятные модели» всё равно что желание бегать быстрее мопеда, или рыть лопатой быстрее экскаватора: глупо и непродуктивно.

нет, это желание уметь прогнозировать с какой скоростью будет ехать мопед и сколько бензина потребуется

Я потом смогу продемонстрировать как это выглядит на практике. Грубо говоря, мы выделяем схемы (структуры) данных как отдельный уровень и работаем именно с ними. Это DoD и это хорошо для достижения высокого уровня утилизации железа. Но над схемами данных мы создаем легковесные объекты-обертки в момент, когда они непосредственно используются кодом.

Например, объект типа Decimal(10,4) может хранить параметры типа (10,4) вместе с, собственно, реперезентацией самого числа. И это то, что мы имеем в случае объектов класса BigDecimal в Java. А может хранить параметры отдельно и независимо от самого числа. А в DecimalView оно будет собираться в тот момент, когда нам нужно такое число обработать.

Такие обертки в С++ получаются достаточно легковесные, и в Java, в принципе, тоже. Presto так работает. Кстати, Presto — неплохой пример DoD, реализованный средствами «Java на максималках». Для Decimal Presto хранит параметры типа (10, 4) в метаданных колонки, а цифры числа — в ячейках таблицы. В момент обработки оно всё «собирается вместе» в рамках псевдо-объектного интерфейса Decimals.

Короче, в модели OOP over DoD мы решаем тут системную проблему дизайна ООЯП, что репрезентация объектов в памяти жестко впилена в компилятор и не поддается модицикациям.

Ты совершенно прав, есть даже мой любимый мем на тему explainable AI: «I can explain it to you but I can't understand it for you». Мало объяснить, нужно еще и понять)))

Тем не менее, есть промежуточная зона, и оно далеко не «всё или ничего». Вот мы с тобой сейчас тут общаемся и понимаем друг-друга. Т.е. для каких-то моделей есть удобоваримые интерпретации. И такие модели — это, по сути, «наше всё». Как Пушкин у филологов.

Если тебя интересуют числа, то их доля ничтожно, исчезающе мала во множестве всех возможных моделей. Но мы как-то живем))

Годная идея. Не расслабляйся. Я для такого языка скоро структурок данных продвинутых подкину)

Например, «сжатое квадратурное дерево». Это структура, выполняющая рекурсивное разбиение многомерного пространства с помощью сжатых деревьев с пространственной сложностью 2 бита на узел (без учета возможного сжатия). На таких деревьях можно делать ассоциативную память и решать задачи паттерн-матчинга. Единственное, что придется уходить от привычного нам понимания объекта и переходить к более низкоуровневым репрезентациям (уровень битов).

то можно её вынести в отдельные общие функции безо всякого ООП.

На костёр его!

Зачем в гуе иерархия фигур? Например?

Формочек, конечно, а не фигур.

не обязательно. если задача только в том, чтобы распознавать, в классе Фигура создай метод-распознаватор.

Ну и там будет реализация проверки валидности для всего. Такая же, как в конструкторе каждой фигуры.

Это не надо знать.

Не можем == не нужно?
Есть некое x надо выяснить является ли оно y. Что сложного?

Только после того, как ты положишь фигуру на поверхность можно посчитать её площадь.

Так, псевдокод этого куска в студию.

«как правильно сделать иерархию фигур Евклидовой геометрии» - это некорректная постановка

Дивный мир программирования просто состоит из некорректных постановок и смены требований походу.

Напрограммировать для геометрических кругов общий класс отображать всё полигонами из треугольников тоже можно.

Даже окружности и кривые?

Я вам по секрету скажу, что нет единого метода решения всех задач.

В смысле нет? ООП это лучшая парадигма. Что угодно можно решить в ООП. Лет 10 жабаадепты про это трубили.

Я думаю тред нужно было начать с кода без ООП

Но зачем? ООП - это же лучшая парадигма.

На костёр его!

Падажжи, не так быстро. Так дела не делаются, сначала надо подобрать подходящий паттерн для реализации костра.

Ну и там будет реализация проверки валидности для всего.

если тебе нужно только распознавать фигуры, то да. зачем городить огород?

если нужна только самопроверка набора точек на соответствие заявленному классу - напишешь тогда, когда реализуешь соответствующий класс.

если нужно и то и другое - распознавалка фигур останется в классе Фигура, там же Квадрат сможет самопровериться на квадратность.

тебе чо надо-то, барин?

ООП - это же лучшая парадигма.

это инструмент. один из способов локализовать проблему, связанный с ней набор данных, и работать только с ней, не отвлекаясь на все остальное. чтобы все участники концессии могли делать свою часть работы, не ожидая пока ты там родишь гениальное, согласовываешь интерфейс. или берешь стандартный.

на любом языке можно группировать данные и создавать интерфейсы. то, что в каких-то языках сделали такой подход дефолтным, повлияло на индустрию в целом положительно, апатамушта наличие стандартов выкашивает затратный и ненужный индустрии велосипединг. пластичности ООП достаточно, чтобы вместить асинхронное, реактивное программирование, массовую миграцию на микросервисы и что там еще. а если где-то (где?) ООП скорее мешает, чем помогает - пользуйся тем, что помогает.

Ты с ума сошёл? Даже в псевдокоде рисовать граф через угловое разрешение для коммента? По-моему очевидно, что это возможно.

Формочек, конечно, а не фигур

Так там композиция прекрасно работает, не нужно же создавать 100500 формочек, так что можно делать жирные классы компонентов. Хотя я GUI прям на низком уровне не делал, тут сугубо теоретические предположения.

не нужно

Не нужно потому что ненужно. А зачем это нужно? Площадь и пересечения считаются без знания типов фигур. Собственно в этом смысл ООП, чтобы не делать свитч по типу.

в этом смысл ООП, чтобы не делать свитч по типу

То есть полиморфизм — это единственная стоящая вещь во всем ООП?

Всё разобьётся, когда появятся круги, сферы, кривые и прочие штуки которые встречаются в реальной геометрии, которая внезапно так же бесконечно сложна как и алгебра.

Как бы полиморфизм без наследования хотя бы интерфейсов будет костыльным. А наследование без инкапсуляции будет костыльным. Ну и вот.

Всё разобьётся, когда появятся круги, сферы, кривые и прочие штуки которые встречаются в реальной геометрии

в реальной геометрии (тм) уже отменили квадраты, ромбы и вообще многоугольники? нет? значит этот код останется и будет работать.

бесконечно сложна

бесконечно сложные задачи требуют бесконечных бюджетов и бесконечного времени на их выполнение. остальные проблемы решаемы.

остальные проблемы решаемы

<зануда> Проблемы остановки не решаемы на бесконечных бюджетах :) </зануда>

Проблема программирования в том, что физические бюджеты, которые у нас есть, чрезвычайно малы по сравнению с теми, которые требуют задачи алгоритмической индукции (так называется то, что мы называем программированием)

Мы способны программировать только то, что для чего существуют хорошие аппроксимации алгоритмической индукции в рамках наших крошечных вычислительных бюджетов. Поэтому и думаем, «что от чего наследовать». Потому что, как ни наследуй, аппроксимация получается плохая. А выбраться из этого локального минимума уже не хватает ресурсов. Случайный скачек «из» с очень высокой вероятностью будет скачком в полный хаос.

Я, кстати, не просто так всем мозги мучаю на тему Algorithmic Information Theory. Мегаполезная штука для нашего брата, потому что она, вместе с прочим, рассматривает задачи алгоритмической индукции (которую мы решаем у себя в голове) и, между делом, закрывает много спорных вопросов прикладного программирования. Но это не всё. Она формулирует критерии, которым должен удовлетворять «идеальный язык программирования», понимаемый тут не как конкретный синтаксис с операционной семантикой, а как интегрированная платформа для задач алгоритмической индукции.

тебе чо надо-то, барин?

Для начала я хочу взять произвольный shape и получить ответ на простой вопрос: «это шо за покемон». И сделать это просто имея набор классов без перебирания их где-то руками и выращивания метода-анализатора на 100500 строк.

это инструмент. один из способов локализовать проблему, связанный с ней набор данных, и работать только с ней, не отвлекаясь на все остальное.

Так не получается. В процессе создается множество накладных проблем с иерархиями, паттернами и прочей оопотой.

Падажжи, не так быстро. Так дела не делаются, сначала надо подобрать подходящий паттерн для реализации костра.

Вот, проклятие.

значит этот код останется и будет работать.

Пока первый залётный дятел с обновленным тз всё не поломает.

Даже в псевдокоде рисовать граф через угловое разрешение для коммента?

Нет конечно. Мы же про ооп. Надо тут класс, там класс, а тут херак-херак и что-то считается.

Собственно в этом смысл ООП, чтобы не делать свитч по типу.

Но если в конечном итоге нужен конечный тип, чтобы как-то с ним работать, а не абстрактное нечто.

Жаль, но на создание такого яп всё равно не хватит бюджета:)
Хотя было бы интересно, если бы языки двинулись хоть куда-то от оопошно-императивного дефолта.

Ну, их делают. Я знаю несколько человек, которые втихаря грызут гранит проблемы. Кроме того, Explainable ML — это все именно об этом, просто там мы уже уходим от привычных нам символьных кодировок и переходим к тому же геометрическому представлению информации. Следи за обновлениями, как говорится. Корпорации плотно подсели на ИИ и уже не слезут. Даже если очередной кризис грянет.

Вот мне, например, интересны вероятностные языки программирования. В них много чего полезного можно делать, что на обычных — забодаешься. Но ВЯП строятся на сложных сэмплерах, которые требуют спец-акселераторов (перебор делать). Поэтому оно пока или игрушка, или очень узкий инструмент.

В общем, алгоритмическая индукция — вещь очень жручая. И по этой причине непрактичная. Как появятся доступные акселераторы (а они появятся), появятся и соответствующие инструменты программирования.

если в конечном итоге нужен конечный тип, чтобы как-то с ним работать

В иерархии типов интерфейс один, конкретный тип не имеет значения.

В иерархии типов интерфейс один, конкретный тип не имеет значения.

Ну охренеть теперь. То есть вместо того, чтобы решать непосредственно задачу, мне надо как-то изъеживаться, чтобы менять радиус круга и сторону квадрата одним интерфейсом.

мне надо как-то изъеживаться, чтобы менять радиус круга и сторону квадрата одним интерфейсом

А как ты хотел, чтобы они были в одной иерархии, т.е. одним типом с разными реализациями и при этом с разными интерфейсами? Да и вроде бы это не рокетсаенс сделать метод resize().

Да и вроде бы это не рокетсаенс сделать метод resize().

И гадать потом, чего он там ресизит.

А как ты хотел, чтобы они были в одной иерархии, т.е. одним типом с разными реализациями и при этом с разными интерфейсами?

Мне надо, чтобы общее было в общем интерфейсе, а частное в частном классе. Что в этом сложного, лул.

Мне надо, чтобы общее было в общем интерфейсе, а частное в частном классе

Тогда тебе не надо классы вообще. Что в этом сложного, лул.

гадать потом, чего он там ресизит

Ну как бы это свойство императивного программирования в принципе.

Ну как бы это свойство императивного программирования в принципе.

Мы начали с того, что у нас ооп, понятные классы, что если я хочу сделать setSideSize, то поменяется размер стороны, а если сделаю setRadius, то поменяется радиус, а закончилось всё тем, что надо делать один метод setFukkenSize для всего.

Тогда тебе не надо классы вообще. Что в этом сложного, лул.

Тогда получается, что ООП не нужно, чисто из-за собственных противоречий, лул.

Мы начали с того

Ты начал с того. Тебе показали что твои предпосылки неверные.

один метод setFukkenSize для всего

Нет не один а много, но с одним названием и параметрами. Твои претензии что сложно объять необъятное никак не относятся к ООП.

Нет не один а много, но с одним названием и параметрами.

Я понял, что он у тебя будет перегруженный - но это тоже дерьмо.

Твои претензии что сложно объять необъятное никак не относятся к ООП.

Мне нужна одна элементарная операция - есть x, надо понять чем оно является. 5 комментов и оказывается, что я уже пытаюсь объять необъятное.

Я расшифрую: это просто поток сознания с отдельными осмысленными предложениями, не более того.

Как внесу тебе кривых фигур сложной топологии в m-мерном пространстве, да ещё и не совсем евклидовом, а каком-нибудь аналоге пространства Минковского для более высоких размерностей, так и накроется всё медным тазиком.