Есть ли в реальном мире чего нибудь такое, чего бы нельзя было

← →
Кен (2003-06-20 06:23) [0]

описать языком программирования ? И как вообще правильно описывать окружающий нас мир на паскале ? Вот например описываем дом. "Дом.Кирпичи".
А может быть правильнее так :
"Дом.Стена.Кирпичи" ?

А бывает, что одно и тоже можно описать с двух точек зрения :
"Дом.Этаж" или "Дом.Подъезд"

А как правильно то тогда ? Возможно ли такой дуализм реализовать на Дельфи ? Чтобы одно и тоже описывалось поразному.

---------
Ещё у меня проблема с бабочкой.
Дело в том, что вначале она гусеница и у неё одни свойства, а потом, она превращается в бабочку и получает другие свойства.
Можно сделать свойство "Гусеничность" и выставить его в начале в True; , а потом когда гусеница превратится в бабочку свойство поменять на False;
Но дело в том, что от этого свойства зависит куча других свойств. Например "Летабельность". Надо, чтобы изменение одного свойства влекло за собой кучу изменений других свойств. Можно ли их как то жёстко связать между собой ?

← →
Дмитрий К.К. (2003-06-20 06:43) [1]

> Есть ли в реальном мире чего нибудь такое, чего бы нельзя
> было
>
> Кен © (20.06.03 06:23)
> описать языком программирования ?

В зеркало посмотри. Увидел? Вот это чудо пока еще не могут формализовать. Когда формализуют, получится искусственный интеллект, сравнимый с естественным.

← →
Snake2000 (2003-06-20 06:47) [2]

Чувак Матрицу пишет!!!!!!

← →
ZeroDivide (2003-06-20 08:35) [3]

>Есть ли в реальном мире чего нибудь такое, чего бы нельзя было
>описать языком программирования
Теоретически нет. Практически AI.

Кен © (20.06.03 06:23)

Ответ на первый вопрос:
На паскале сложно, на объектном паскале так:

TWall = class(TCustomWall)
protected
Blocks: TBlocks;
end

THouse = class(TCustomHouse)
private
Цемент: TЦемент;
protected
Wall: TWall;
Podezd: TPodezd;
Итд_итп: TИтд_итп;
public
Жильцы: TЖильцы;
end;

так правильно.

>Ещё у меня проблема с бабочкой.
>куча других свойств
Легче написать другой класс и создать его объект одновременно удалив объект соответствующей гусеницы.

← →
Danilka (2003-06-20 08:43) [4]

Кен © (20.06.03 06:23)
У гусеницы есть метод "куколка", который создает экземпляр класса "бабочка" и делает self.free.

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

Snake2000 © (20.06.03 06:47)
:))

← →
Danilka (2003-06-20 08:44) [5]

ZeroDivide © (20.06.03 08:35)
хех, писал свой пост невидя твоего.

← →
Жук (2003-06-20 08:56) [6]

> Кен © (20.06.03 06:23)
> Ещё у меня проблема с бабочкой.
> Дело в том, что вначале она гусеница и у неё одни свойства,
> а потом, она превращается в бабочку и получает другие свойства.

2 таблицы : "существо" и "тип существа", когда куколка прекращается в бабочку меняем значение поля, ссылающегося на таблицу типов.

> Легче написать другой класс и создать его объект одновременно
> удалив объект соответствующей гусеницы.

Идеалогически неверно. С жизненной точки зрения объект-то один :-)

← →
Danilka (2003-06-20 09:01) [7]

Жук © (20.06.03 08:56)
почему?
Был объект гусеница, потом он стал куколкой, единственное что делала куколка, это переделывала из гусеницы бабочку - на основании свойств класса гусеница, заполняла свойства объекта "бабочка". Классы бабочка и гусеница сами по себе очень различные, там общих свойств мизер по сравнению с специфичными. :))

да и с жизненой точки зрения, ни обьект один, а один набор химических элементов. :))

← →
Axel (2003-06-20 12:25) [8]

>Кен © (20.06.03 06:23)
>описать языком программирования

feelings

← →
euru (2003-06-20 14:30) [9]

>Кен ©

Я здесь, оказывается, примерно похожий вопрос задал:
http://delphimaster.net/view/14-1056096209/

Если хочешь, присоединяйся.

← →
Ru (2003-06-20 14:36) [10]

Глупость человеческая неописуема ... и непознаваема до конца ... и границ не имеет!

← →
Danilka (2003-06-20 14:52) [11]

Ru © (20.06.03 14:36)
ну, дык, есть-же в дельфях рандом.

← →
wnew (2003-06-20 14:58) [12]

Дмитрий К.К. © (20.06.03 06:43)
В зеркало посмотри. Увидел? Вот это чудо пока еще не могут формализовать. Когда формализуют, получится искусственный интеллект, сравнимый с естественным.

А ещё, если станет возможным описать приципы и алгоритмы контекстного, смыслового восприятия текста или речи, то - это и будет самый настоящий искуственный интеллект. Представляете перспективу? В любой стране мира, используя компактный, синхронный переводчик, можно будет вести непринуждёные беседы.

← →
Ru (2003-06-20 15:51) [13]

>Danilka © (20.06.03 14:52)

рандом завязан на заранее известной формуле, иногда вносят случайность через системный таймер.

ИИ

уже все давно описано и формализовано, правда, до сих пор, не реализовано.

← →
uw (2003-06-20 16:23) [14]

>wnew © (20.06.03 14:58)
>В любой стране мира, используя компактный, синхронный
>переводчик, можно будет вести непринуждёные беседы.

Слушай, а ведь так и будет. А то попадаешь в другую страну и таким себя уродом чувствуешь!

← →
AlexRush (2003-06-20 17:35) [15]

>> Кен © (20.06.03 06:23) Тебе Агенты Смиты нужны ?

← →
Soft (2003-06-20 17:42) [16]

>>Ru © (20.06.03 15:51)
>>ИИ
>>уже все давно описано и формализовано, правда, до сих пор, не реализовано.

Флаг, тху блин, клаву в руки...

← →
NailMan (2003-06-20 19:00) [17]

Главное - что еще пока не описали на любом языке программирования - поведение программиста при написании сложной программы. Этот процесс формулировке не подлежит.

← →
Fenik (2003-06-20 19:33) [18]

Кен!
Не трать время на ерунду.
Если не считаешь это ерундой, то хоть скажи: что за программу пишешь???

← →
MOA (2003-06-20 19:33) [19]

Думается, что в примере с личинка-гусеница-куколка-бабочка уважаемый Кен сформулировал нечто, к чему, наверное, нужно стремиться. Изменчивость сущности в современных языках программирования мы вынуждены моделировать через объекты классов и времена жизни этих объектов. И, действительно, не остаётся места для объектов, которые, с одной стороны, принадлежат к одному классу, а с другой стороны, свойства и поведение которых в разные моменты их времени жизни хочется отнести к другим классам, т.е., невозможно выразить эволюцию классов.
Что мы делаем с объектом класса при наступлении некоторого события - мы пишем некий обработчик, который модифицирует внутренние параметры объекта. Но невозможно выразить изменение класса объекта, изменение самого списка этих параметров.
Дело, как мне кажется, в том, что современные языки промышленного программирования - объектно-ориентированные (не истинно объектные). Т.е. невозможно в ран-тайм создать новый класс, в идеале - наследник от нескольких, и затем создать объект - экземпляр этого сгенерированного класса. Т.е. сам класс не относится ни к какому классу.
Вот если бы мы подумали, что класс - это ведь тоже некая сущность, и, если быть последовательными, тоже является объектом некоторого "метакласса", "класса классов" - тогда пример можно было бы выразить. Кстати, а "метакласс" - это ведь тоже объект, и не нужно ли вводить "класс всех метаклассов". Тогда где остановиться? - Интуиция подсказывает, что наверное, где-то можно, м.б. кто-то из коллег подскажет решение, если оно (уже) существует?
PS. Понятно, что такую, упомянутую Кен-ом эволюцию, можно выразить на любом полном языке программирования. Вопрос в том - существуют ли (или можно ли спроектировать) язык, в котором такие метаморфозы возможно выразить "непосредственно".

← →
Кен (2003-06-21 05:30) [20]

> Кен © (20.06.03 06:23)
>
> Ответ на первый вопрос:
> На паскале сложно, на объектном паскале так:
>
> TWall = class(TCustomWall)
> protected
> Blocks: TBlocks;
> end
>
> THouse = class(TCustomHouse)
> private
> Цемент: TЦемент;
> protected
> Wall: TWall;
> Podezd: TPodezd;
> Итд_итп: TИтд_итп;
> public
> Жильцы: TЖильцы;
> end;
>
> так правильно.
Нет. Вопрос то в том, как сделать, чтобы к одному и тому же объекту вели разные пути ? Дом.Квартира[50] и Дом.Подъезд[1].Этаж[9].КрайняяПравая и Дом.Верхний этаж.Справа[5 окно] Или просто Pos(x,y,z) Всё указывает на одно и тоже. Как это прописать ?
Ведь именно так мы мыслим. Ещё мы можем один и тот же объект называть поразному. Кошелёк.Деньги Кошелёк.Бабки Кошелёк.Лавэ и т. д. Как в паскале это будет ?

Ведь часто слово зависит от контекста. Кошёлёк.Бабки или Лавочка.Бабки . Тут ведь речь идёт о совершенно разных объектах.

> Жук © (20.06.03 08:56)
> > Кен © (20.06.03 06:23)
> > Ещё у меня проблема с бабочкой.
> > Дело в том, что вначале она гусеница и у неё одни свойства,
> > а потом, она превращается в бабочку и получает другие
> свойства.
>
> 2 таблицы : "существо" и "тип существа", когда куколка прекращается
> в бабочку меняем значение поля, ссылающегося на таблицу
> типов.
А нельзя без отдельных таблиц ?
Так, чтобы изменение одного параметра меняло сразу массу других параметров ? Причём действовало бы в обе стороны.

Например.
Свойства бабочки-гусеницы:
1 Бабочность : Boolean
2 Крылатость : Boolean
3 Летабельность : Boolean
4 Длинноусость : Boolean
Если ставим свойство 1 в true, то автоматически ставятся в true и свойства 2 3 4. Но в тоже время, если по каким то причинам свойства 2 3 4 стали true, то в true должно встать и свойство 1, потому, что если у гусеницы появились крылья, длинные усы и она умеет летать, это уже готовая бабочка.
Можно конечно писать обработчики на все парамтры. Но почему так сложно ? А если их 200 будет ? Можно их просто связать друг с другом в структуре ?
Ведь параметр Бабочность - всего лишь обобщение массы других параметров. Руководящий и направляющий так сказать, но зависимый от тех кем руководит.

← →
Кен (2003-06-21 06:04) [21]

> MOA © (20.06.03 19:33)
> Думается, что в примере с личинка-гусеница-куколка-бабочка
> уважаемый Кен сформулировал нечто, к чему, наверное, нужно
> стремиться. Изменчивость сущности в современных языках программирования
> мы вынуждены моделировать через объекты классов и времена
> жизни этих объектов. И, действительно, не остаётся места
> для объектов, которые, с одной стороны, принадлежат к одному
> классу, а с другой стороны, свойства и поведение которых
> в разные моменты их времени жизни хочется отнести к другим
> классам, т.е., невозможно выразить эволюцию классов.
Да. Про эволюцию как раз хотелось бы поговорить. Но не знаю как к этой сложной теме подступиться.

← →
Мазут Береговой (2003-06-21 09:43) [22]

Надо начинать надо хотя бы с атома:
атом.электрон(i).молекула.коллекция(i).живаяприрода(вид).клетка.орган(i).... и т.д.
атом.электрон(i).молекула.коллекция(i).неживаяприрода(вид).структура..... и т.д.

← →
euru (2003-06-21 10:52) [23]

>MOA © (20.06.03 19:33)

Я примерно то же самое в этой ветке пытаюсь узнать:
http://delphimaster.net/view/14-1056096209/

Во-первых, личинка-гусеница-куколка-бабочка в реальном мире являются одним объектом, меняющим свое состояние с течением времени. Поэтому моделировать эти преобразования удалением одного объекта и созданием другого, наверно, не совсем корректно.

Во-вторых, возьмем переменную, напр. Boolean. Это тоже своего рода объект, у которого два состояния - True и False. Но ведь мы же не уничтожаем его, чтобы поменять True на False или наоборот. Мы просто меняем его состояние.

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

← →
Mike B. (2003-06-21 11:07) [24]

> euru © (21.06.03 10:52)
Ну и пусть у тебя будет свойство, принимающее два значения - Гусеница и Бабочка, и объект в зависимости от его значения меняет свое поведение, в чем проблема то?

← →
NailMan (2003-06-21 11:14) [25]

Когда-то я делал в паскале6 игрушку(RPG в ASCII графике) и для описания предметов я использовал следующую конструкцию:

TGameObject = record
gType : Integer;
personP : PPersonParameters;
objP : PObjectParameters;
SpecP : PSpecialSystemParameters;
.....
end;

PPersonParameters = ^TPersonParameters;
где в немаленькой структуре TPersonParameters были описаны поля свойств персонажа.

аналогично
TObjectParameters - структура свойств предмета.

TSpecialSystemParameters - структура свойств системного объекта(точка входа, маркер и т.д.)

При создании карты(динамическая, связанно-бесконечная) я создавал объект, и задавал ему тип - personage, Gobject, SObject и соотвественно выделялась память под нужную структуру и она заполнялась. Вся дальнейшая работа была только с соответствующей структурой. Таким образом мой игровой объект(точнее запись, так как я про объекты не знал) мог быть как предметом(меч, щит, дерево, косяк травки), так и персонажем и системным объектом карты.

Может так можно организовать меняющиеся состояния объекта?

Типа был eType="Гусеница" для описания свойств юзалась структура TБабочкаПараметры. Гусеница стала куколкой(eType="Куколка") когда ее возраст стал скажем 2 недели; выделила память под структуру TКуколкаПараметры, и старые базовые свойства(положение возраст и т.д.) мигрировали из старой структуры в новую, старая структура высвободила память. Теперь все действия будут проводиться с параметрами TКуколкаПараметры.

Ну и так далее.

???

← →
euru (2003-06-21 11:26) [26]

>Mike B. © (21.06.03 11:07)

Нужно не свойство в объекте, говорящее какого типа объект, а свойство самого объекта быть в любой момент момент времени каким-либо типом. Т.е. если объект в данный момент Гусеница, то у него не должно быть методов и свойств, несвойственных Гусенице (напр., Летать(), ПлощадьКрыла и т.д.), а если объект стал Бабочкой, то у него должны пропасть свойства Гусеницы (типа, Окукливаться() или ПредпочитаемыеТипыЛистьев) и появиться свойства Бабочки.

А если делать по-старому (вводить свойство, возвращающее тип объекта, в сам объект), то тогда в этом объекте нужно будет предусмотреть все методы и свойства, соответствующие любому возможному типу объекту. Но ведь Гусеница не может быть в тот же момент и Бабочкой.

← →
Mike B. (2003-06-21 11:32) [27]

> свойство самого объекта быть в любой момент момент времени каким-либо типом
А смысл какой??? Ты ведь не создаешь гусеницу и бабочку, ты создаешь модель, которая внутри может быть устроена как угодно.

← →
wnew (2003-06-21 11:59) [28]

И всё-таки гусеница - это гусеница, а не бабочка и соответственно, наоборот. А если сильно нужно, то применить множественное наследие, т.е. от обоих классов, и от баочки, и от гусеницы, а если надо, то и от куколки.

← →
euru (2003-06-21 12:01) [29]

Я разделю два понятия.

Описание модели как внутри, так и снаружи может быть устроено как угодно (а, возможно, я ошибаюсь).

А вот объект, созданный на основе этого описания и моделирующий реальный объект, должен адекватно отражать этот реальный объект, чтобы не было возможности выполнить действие Окукливаться(), когда объект не Гусеница.

← →
euru (2003-06-21 12:05) [30]

>wnew © (21.06.03 11:59)

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

← →
Mike B. (2003-06-21 12:05) [31]

> euru © (21.06.03 12:01)
Ну о чем и речь. Пиши объект так, чтобы при значении этого свойства равном Бабочка, метод Окукливаться() не выполнялся, выдавал исключение, ругался матом, что мешает то?

← →
wnew (2003-06-21 12:28) [32]

Ну в реальной жизни-то сначала гусеница потом куколка, а затем бабочка и каждый раз при появлении нового объекта, старый объект исчезает. По этому можно создать класс отвечающий всем трём состояниям, но с тремя конструкторами и при создании объекта или его изменении старый объект уничтожать и потом создавать снова с вызовом актуального конструктора.

← →
Mike B. (2003-06-21 12:32) [33]

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

← →
euru (2003-06-21 12:35) [34]

>Mike B. © (21.06.03 12:05)
Если объект - Бабочка, то метода Окукливаться() у него не должно быть в принципе. Ты где-нибудь встречал реальных бабочек, которых какие-то внешние условия пытались заставить окукливаться (типа вызвать Бабочка.Окуклиться()), а она в ответ ругалась матом или отбрасывала крылья? До она просто никак не отреагирует на такое предложение, потому что не знает, что это такое.

Еще пример. Стандартная иерархия: объект Фигура, от него порождены объекты Квадрат и Круг. У них есть виртуальный метод Рисовать(). Разве при реализации этого метода для объекта Квадрат мы где-нибудь проверяем , квадрат он или нет? То же самое и для Круга. Нигде. Система сама знает, если объект типа Квадрат, то нужно вызвать метод Рисовать() для квадрата.

Классический полиморфизм позволяет абстрагироваться при описании методов объекта от их реализации. Так почему же нельзя перенести полиморфизм на сами объекты?

← →
Mike B. (2003-06-21 12:48) [35]

>euru © (21.06.03 12:35)
А чем с точки зрения конечной системы мешает наличеие метода Окукливаться() есл ив целом объект ведет себя правильно?

← →
euru (2003-06-21 14:40) [36]

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

← →
Кен (2003-06-22 06:12) [37]

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

Про дом.
Я так подумал, что записи Дом.Кирпич и Дом.Стена.Кирпич отличаются только индексами. При Дом.Кирпич[i] индексируются все кирпичи дома, а при Дом.Стена[i].Кирпич[j] индексируются стены и кирпичи в рамках стены.
То есть Дом.Кирпич[1000] и Дом.Стена[10].Кирпич[100] - указывают на один и тот же кирпич.
Как это грамотно записать на Дельфи ?

← →
kaif (2003-06-22 14:58) [38]

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

TButterflyState = class;

TButterfly = class
FButterflyState: TButterflyState;
public
property State: TButterflyState read FButterflyState;
procedure NextState;
end;

TButterflyState - абстрактный класс. Его потомки это классы яйца, гусеницы, куколки и бабочки. Метод NextState удаляет объект предыдущего состояния в свойстве State и заменяет его на экземпляр нового класса. В любой момент времени для того, чтобы узнать, какое состояние сейчас у бабочки, можно проверить State на класс с помощью оператора is. А потом приведя State явно к какому-то типу вызывать его свойства и методы.
Эта структура хороша тем, что если появится у бабочки новое состояние, например, состояние "линяющей гусеницы", то достаточно будет описать новый класс, потомок TButterflyState или его потомков с какими угодно новыми методами.

← →
kaif (2003-06-22 15:02) [39]

А вообще мы описываем не внешний мир, а лишь реализуем свои собственные абстракции. И ООП похоже на наш способ мыслить о мире и описывать, а не на сам этот мир.

← →
Всеволод Соловьёв (2003-06-22 18:33) [40]

>Как это грамотно записать на Дельфи ?
В делфи объекты - это указатели.

procedure NewKirpich; var kirpich: TKirpich; i, j: integer; begin for i := 0 to 9 do for j := 0 to 99 do begin kirpich:= TKirpich.create; house.kirpichi[i*100+j] := kirpich; house.stena[i].kirpichi[j] := kirpich; end; end;
вот и вся проблема :)

← →
Marser (2003-06-22 22:40) [41]

> kaif © (22.06.03 15:02)
> А вообще мы описываем не внешний мир, а лишь реализуем свои
> собственные абстракции. И ООП похоже на наш способ мыслить
> о мире и описывать, а не на сам этот мир.

100%

← →
Кен (2003-06-23 05:27) [42]

> Всеволод Соловьёв © (22.06.03 18:33)
> >Как это грамотно записать на Дельфи ?
> В делфи объекты - это указатели.
>
> procedure NewKirpich;
> var kirpich: TKirpich;
> i, j: integer;
> begin
> for i := 0 to 9 do
> for j := 0 to 99 do begin
> kirpich:= TKirpich.create;
> house.kirpichi[i*100+j] := kirpich;
> house.stena[i].kirpichi[j] := kirpich;
> end;
> end;
>
> вот и вся проблема :)
А какой кирпич в доме считаем самым первым ? Самый старый ? Тот который первым положили ? Но мы же ни того ни другого не знаем.

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

← →
Всеволод Соловьёв (2003-06-23 09:05) [43]

А какой кирпич в доме считаем самым первым ? Самый старый ? Тот который первым положили ? Но мы же ни того ни другого не знаем.
самый первый считается самым первым. как тебе хочется таким он и будет. может я сверху их строить начал, а? подвесил, потом под них, итд. какая тебе разница, каким мы его положили, или какой он древности. нам не надо это знать. мы это придумаем. ты что-то тупишь. впрочем, это твое обычное состояние :)
Ведь, чтобы добавить новую процедуру нужен компилятор Дельфи.
Гениальная мысль!
А оформить это всё в виде отдельной программы вроде бы нельзя.
Наверно лучше использовать отдельную базу данных какую-то.
скомпилируй и будет тебе отдельная программа :) а если тебе нужны другие счетчики, так поменяй их на переменные, которые будешь считывать откуда-нибудь.

← →
Mike B. (2003-06-23 10:32) [44]

← →
euru (2003-06-23 13:27) [45]

>Mike B. © (23.06.03 10:32)
> kaif © (22.06.03 15:02)
>Совершенно верно. К чему я веду.

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

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