Aliaksandr Hryshyn #: Какой принцип предполагается? Как будет решаться вопрос очень быстро возрастающей вычислительной сложности? Как будет формулироваться задача для её программного решения?
1. Предлагается принцип следования "чертежам" общей объектной структуры (которую пытаюсь раскрыть в концепции) и построения программ в виде смоделированной "жизнедеятельности" соответствующих объектов.
2. Вопрос с вычислительной мощностью пока не обдумывал, хотя в голову он приходил. Пока не знаю как будет расти потребление ресурсов. Думаю, все будет зависить от сложности генерируемых программ и конечно, в какой момент мы упремся в потолок.
3. Вопрос " Как будет формулироваться задача для её программного решения " пока не имеет ответа. Еще рано. Практическое применение впереди. Сейчас я сосредоточен на воплощении идеи быстрого построения содержания объекта программой.
*Дополнено:
Немного некорректно ответил на вопрос касательно вычислительной сложности перепутав ее с "мощностью", хотя в принципе ответ можно оставить неизмененным, т.к. вычислительная сложность "покоряется" вычислительной мощности. Ну и подходу к задаче, разумеется.
"Набор свойств - список параметров, входящих в состав Объекта." — может лучше разделить понятия "свойство" и "параметр", или это не имеет значения? Свойства и параметры функции...
"Форма - Объединяет тип множеств принадлежащих Объекту, которые существующие в двух или трех измерениях." — это зачем? А если надо 4 измерения?
Почему бы не объединить "свойство" и "объект"? "Свойство" как частный случай "объекта".
Избыточно и размыты границы неотьемлимых свойств объекта и свойств, которые формируются внешними воздействиями, на мой взгляд. Потом упрется в проклятия и будет упрощать. Но Петр стойкий, может что и родится.)
Я бы начинал бы с градации объектов от простого к сложному. Свойство сложного эксперта, как объекта... ну не очень простой и понятный пример.
UML является языком широкого профиля, это — открытый стандарт, использующий графические обозначения для создания абстрактной моделисистемы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования, в основном, программных систем. UML не является языком программирования, но на основании UML-моделей возможна генерация кода."
\\-----конец цитаты.
Язык графического моделирования помогает визуализировать и проектировать человеку, но сам не генерирует системы для решения поставленных задач.
Для авторизации и пользования сайтом MQL5.com необходимо разрешить использование файлов Сookie.
Пожалуйста, включите в вашем браузере данную настройку, иначе вы не сможете авторизоваться.
Вы вошли в аккаунт. Двухфакторная аутентификация отключена. Настройте её заново и отсканируйте новый QR-код или продолжите с отключённой двухфакторной аутентификацией.
Какой принцип предполагается? Как будет решаться вопрос очень быстро возрастающей вычислительной сложности? Как будет формулироваться задача для её программного решения?
1. Предлагается принцип следования "чертежам" общей объектной структуры (которую пытаюсь раскрыть в концепции) и построения программ в виде смоделированной "жизнедеятельности" соответствующих объектов.
2. Вопрос с вычислительной мощностью пока не обдумывал, хотя в голову он приходил. Пока не знаю как будет расти потребление ресурсов. Думаю, все будет зависить от сложности генерируемых программ и конечно, в какой момент мы упремся в потолок.
3. Вопрос " Как будет формулироваться задача для её программного решения " пока не имеет ответа. Еще рано. Практическое применение впереди. Сейчас я сосредоточен на воплощении идеи быстрого построения содержания объекта программой.
*Дополнено:
Немного некорректно ответил на вопрос касательно вычислительной сложности перепутав ее с "мощностью", хотя в принципе ответ можно оставить неизмененным, т.к. вычислительная сложность "покоряется" вычислительной мощности. Ну и подходу к задаче, разумеется.
Ты и горячее с холодным путаешь
Ты то вообще не в теме объектов, к чему твой камент?
Имею право налево бро
Пётр, откройте для себя UML (https://ru.wikipedia.org/wiki/UML)
то что вы пытаетесь высказать "уже украдено до вас" :-)
Избыточно и размыты границы неотьемлимых свойств объекта и свойств, которые формируются внешними воздействиями, на мой взгляд. Потом упрется в проклятия и будет упрощать. Но Петр стойкий, может что и родится.)
Я бы начинал бы с градации объектов от простого к сложному. Свойство сложного эксперта, как объекта... ну не очень простой и понятный пример.
Пётр, откройте для себя UML (https://ru.wikipedia.org/wiki/UML)
то что вы пытаетесь высказать "уже украдено до вас" :-)
У Петра все более глобально)))
Пётр, откройте для себя UML (https://ru.wikipedia.org/wiki/UML)
то что вы пытаетесь высказать "уже украдено до вас" :-)
Это не совсем так. Из Википедии:
"UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения, для моделирования бизнес-процессов, системного проектирования и отображения организационных структур.
UML является языком широкого профиля, это — открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования, в основном, программных систем. UML не является языком программирования, но на основании UML-моделей возможна генерация кода."
\\-----конец цитаты.
Язык графического моделирования помогает визуализировать и проектировать человеку, но сам не генерирует системы для решения поставленных задач.
Готовлю третью часть концепции.