OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 15:30

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 127 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7  След.
Автор Сообщение
СообщениеДобавлено: Пятница, 18 Февраль, 2011 16:28 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
Согласен, что понятий в языке должно быть умеренное количество, однако к "записям" это никакого отношения не имеет. Это вообще не понятие языка. Кое где его удобно вводить в минимальной форме, как в Quick Basic, например. И то...Или например в ПЛ/I. Но "структура" там и "запись" тут - это две большие разницы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Февраль, 2011 16:36 

Зарегистрирован: Пятница, 20 Июль, 2007 17:26
Сообщения: 710
Откуда: Псков
Рыжий писал(а):
Оберон - не универсальный язык. Оберон язык основанный на концепции расширяемой записи и указателей. С соответствующим способом построения алгоритмов. С++ , да, относительно универсальная помойка. Возьмите любую простую задачу:
последовательность перекрывающихся прямоугольников с заполнением на экране: z-последовательность. И попытайтесь рассмотреть задачу с точки зрения массивов, и сточки зрения "объектов" , во втором случае еще и связный список из "объектов" организуют, не сомневаюсь.

Ну, на МАМПСе эту задачу доводилось решать.
А в чём трудность в Обероне? Ну, будет список в Z-порядке, и что?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Февраль, 2011 16:40 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
а то, что это массив. :mrgreen:
на мампсе - это правильно.


Последний раз редактировалось Рыжий Пятница, 18 Февраль, 2011 16:41, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Февраль, 2011 16:41 

Зарегистрирован: Пятница, 20 Июль, 2007 17:26
Сообщения: 710
Откуда: Псков
Рыжий писал(а):
Согласен, что понятий в языке должно быть умеренное количество, однако к "записям" это никакого отношения не имеет. Это вообще не понятие языка. Кое где его удобно вводить в минимальной форме, как в Quick Basic, например. И то...Или например в ПЛ/I. Но "структура" там и "запись" тут - это две большие разницы.

Я, конечно, не теоретик, но для графов Обероновская запись самое минимум то, узлы и связи- чего ещё надо. Просто, если конструируешь структуру да ещё и с петлями, то и работать с ней надо соответственно.
P.S.
Запись - для графов универсальней.


Последний раз редактировалось albobin Пятница, 18 Февраль, 2011 16:44, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Февраль, 2011 16:43 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
Если мне нужен граф, то мне нужна матрица смежности, а это - массив. По поводу трудностей , Касперски уже отмечал.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Февраль, 2011 16:49 

Зарегистрирован: Пятница, 20 Июль, 2007 17:26
Сообщения: 710
Откуда: Псков
Рыжий писал(а):
а то, что это массив. :mrgreen:
на мампсе - это правильно.

А это уже философия, вопрос интерпретации или выбора модели.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Февраль, 2011 16:56 

Зарегистрирован: Пятница, 20 Июль, 2007 17:26
Сообщения: 710
Откуда: Псков
Рыжий писал(а):
Если мне нужен граф, то мне нужна матрица смежности, а это - массив. По поводу трудностей , Касперски уже отмечал.

Можно и массивы, но выбор подходящей модели (списки vs массивы) зависит от задачи (для чего граф нужен).
Везде есть свои трудности.

P.S.
Тогда уж лучше не массив, а Relation :)


Последний раз редактировалось albobin Пятница, 18 Февраль, 2011 17:12, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Февраль, 2011 17:12 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Рыжий писал(а):
Если мне нужен граф, то мне нужна матрица смежности, а это - массив. По поводу трудностей , Касперски уже отмечал.

Фигня! Не всегда нужна матрица смежности. Точнее - не всегда имеется ФИЗИЧЕСКАЯ возможность использовать эту самую матрицу. Памяти не хватит. :mrgreen:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Февраль, 2011 17:15 

Зарегистрирован: Пятница, 20 Июль, 2007 17:26
Сообщения: 710
Откуда: Псков
Валерий Лаптев писал(а):
Рыжий писал(а):
Если мне нужен граф, то мне нужна матрица смежности, а это - массив. По поводу трудностей , Касперски уже отмечал.

Фигня! Не всегда нужна матрица смежности. Точнее - не всегда имеется ФИЗИЧЕСКАЯ возможность использовать эту самую матрицу. Памяти не хватит. :mrgreen:

Ну памяти может не хватить и на сам список :)
Проблема в динамике.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Февраль, 2011 17:58 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
Валерий Лаптев писал(а):
Рыжий писал(а):
Если мне нужен граф, то мне нужна матрица смежности, а это - массив. По поводу трудностей , Касперски уже отмечал.

Фигня! Не всегда нужна матрица смежности. Точнее - не всегда имеется ФИЗИЧЕСКАЯ возможность использовать эту самую матрицу. Памяти не хватит. :mrgreen:

Вы можете реализовывать разряженный массив как угодно. Но это должен быть массив. Вот.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Февраль, 2011 18:16 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Рыжий писал(а):
Валерий Лаптев писал(а):
Рыжий писал(а):
Если мне нужен граф, то мне нужна матрица смежности, а это - массив. По поводу трудностей , Касперски уже отмечал.

Фигня! Не всегда нужна матрица смежности. Точнее - не всегда имеется ФИЗИЧЕСКАЯ возможность использовать эту самую матрицу. Памяти не хватит. :mrgreen:

Вы можете реализовывать разряженный массив как угодно. Но это должен быть массив. Вот.

А вот - хрена!
Массив (хотя бы и разрЯженный :) ) - это только тогда, когда размерность массива известна. А если данные динамически растут, добавляются и удаляются (особенно в середину) -у вас будут БОЛЬШИЕ проблемы с производительностью ...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Февраль, 2011 18:25 

Зарегистрирован: Среда, 30 Сентябрь, 2009 14:45
Сообщения: 147
Рыжий писал(а):
Эти кирпичики жестко навязывают определенную манеру проектирования, которая, как и всякое столь жесткое ограничение, приведут и привели к очередному кризису ПО.

Жесткость тоже бывает востребована. Вот у себя в деревне подумал я, что фундамент под верандой несколько покосился, взял эти самые "жесткие" кирпичики, сложил, "ужесточил" с помощью бетона... По-моему, хорошо получилось.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Февраль, 2011 18:46 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Да чего там изворачиваться и каждый раз изобретать велосипеды вроде массивов записей, ассоциативных массивов? Даешь полноценные таблицы БД! Встроенная СУБД должна быть частью языка. 8)

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Февраль, 2011 20:00 

Зарегистрирован: Пятница, 20 Июль, 2007 17:26
Сообщения: 710
Откуда: Псков
Валерий Лаптев писал(а):
А вот - хрена!
Массив (хотя бы и разрЯженный :) ) - это только тогда, когда размерность массива известна. А если данные динамически растут, добавляются и удаляются (особенно в середину) -у вас будут БОЛЬШИЕ проблемы с производительностью ...

МАМПС - это разрЯженные массивы и обслуживающий персонал :)
Ни разу не сталкивался с БОЛЬШИМИ проблемами с производительностью ( в задачах для которых от предназначен) .
Ну это уже оффтоп.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Февраль, 2011 21:31 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Ну вот, например. Я сейчас занимаюсь одной задачкой из перколяции. Там надо заполнять прямоугольную таблицу узлов случайным образом мерами заданной длины (например, мера размером в 2 узла). Так вот при размере таблицы 20000*20000 наступают БОЛЬШИЕ проблемы с производительностью из-за виртуальной памяти.
Мне придется менять структуру данных, и соответственно, усложнять алгоритмы - чтобы уменьшить объемы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Февраль, 2011 23:32 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
albobin писал(а):
Валерий Лаптев писал(а):
А вот - хрена!
Массив (хотя бы и разрЯженный :) ) - это только тогда, когда размерность массива известна. А если данные динамически растут, добавляются и удаляются (особенно в середину) -у вас будут БОЛЬШИЕ проблемы с производительностью ...

МАМПС - это разрЯженные массивы и обслуживающий персонал :)
Ни разу не сталкивался с БОЛЬШИМИ проблемами с производительностью ( в задачах для которых от предназначен) .
Ну это уже оффтоп.

Это не оффтоп. :D


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Февраль, 2011 23:44 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
Маленькое отступление по синтаксису. В паскалях специально выдумано особое зарезервированное слово array , во многих языках, например, в ПЛ/I ничего подобного не используется, применятся т.н. описатель размерности. Что, вообщем, принято во всех языках первой линейки:
Бейсик:
dim st$
dim a(300)
ПЛ/I:
NAME CHAR (10)
J:
arr0=.3 4 $ 0

и.т.п
Паскаль-синтаксис отвлекает людей от использования массивов.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 19 Февраль, 2011 17:50 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
И правильно делает.
Массивовое мышление привычно математикам, но эффективно только на регулярных задачах.
На нерегулярных начинаются извраты по приведению к регулярному виду.

Вместо того, чтобы переходить к графовому.

Так же, как с реляционными базами. Регулярность, красивая алгебра, но в итоге - "ассемблер", на котором очень жёстко и долго моделировать реальные задачи. А уж модифицировать модель...

Представьте себе динамический полиморфизм на каком-нибудь APL. Динамическое появление в системе нового вида элементов матрицы и возможность смешивать в одной матрице элементы разных типов... Без записей и указателей попробуйте :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 19 Февраль, 2011 20:37 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
Никаких проблем, я добавлю новый элемент в герундий. :D
Как оказалось , это была самая крутая работа по теории программирования. Ну ее знают все:
http://compuhumour.narod.ru/science/no_pascal.html
Цитата:
В последнее время в прессе муссируются структуры данных. Абстрактные типы данных, структуры, указатели, списки и строки стали популярны в определенных кругах. Вирт, сосунок, написал даже целую книгу ("Алгоритмы + Структуры данных = Программы", Prentice Hall, 1976 [русский перевод - изд. "Мир", 198?]), в которой утверждает, что можно написать программу на базе структур данных, не используя другие способы. Как все настоящие программисты знают, единственной полезной структурой данных является массив. Строки, списки, структуры и наборы - это все разновидности массивов и их можно рассматривать как массивы без усложнения вашего языка приграммирования. Хуже всего с этими хитрыми типами данных то, что вы должны их описывать, а настоящие языки программирования, как мы все знаем, обладают возможностью неявного задания типа, основанного на первой букве 6-символьного имени переменной.

Илья, все что можно сделать на Обероне, на J можно сделать в сто раз короче. Тут нечего даже обсуждать.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 19 Февраль, 2011 21:07 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Я понимаю Вашу провокационную натуру и что Вы на 60% издеваетесь (а остальные 40% полезны для обдумывания). :lol:


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 127 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 5


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB