Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 1866 17-01-2007 15:54 | |
Ответ на »сообщение 1865« (AVC)
___________________________
При копипасте получилась ошибка.
В коде вместо "?" надо читать "*".
№ 1865 17-01-2007 15:51 | |
Ответ на »сообщение 1861« (Geniepro)
___________________________
О, а поподробнее нельзя об этом? Что там за ошибка была?
Ошибка была "глупая" (но была, а это все же презентация!).
К сожалению, ссылка, которую дает info21 на своем сайте "Информатика-21":
http://cern.ch/oberon.day
почему-то сейчас не работает.
Так что, наверное, код вышлю завтра (возьму у себя на работе).
Насколько помню, там у Вирта в числе прочих были два численных примера: вычисление обратной величны (функция Reci) и еще какая-то (не исключено, что Sqrt).
Кажется, в обеих были ошибки (по недосмотру).
Любопытно, что если заменить цикл WHILE на REPEAT, функции были бы корректны (кажется, сейчас перед глазами их нет).
Стоп! Нашел на старой флешке.
Вот эти функции:
PROCEDURE Reci(x: REAL): REAL;
VAR y, c: REAL;
BEGIN y := 1.0; c := 1.0 – x;
WHILE c > e DO
y := y ? (1.0+c); c := c?c
END
RETURN y
END Reci
и
PROCEDURE Sqrt(x: REAL): REAL;
VAR y, c: REAL;
BEGIN y := x; c := 1.0 – x;
WHILE c > e DO
y := y ? (1.0 + 0.5?c);
c := c ? c ? (0.75 + 0.25?c)
END ;
RETURN y
END Sqrt
Очевидно, что в обоих случаях
c := 1.0 - x
при предусловии (* 0 < x < 2 *)
может получить отрицательное значение.
Но тогда мы просто не войдем в цикл WHILE.
А вот если бы цикл был REPEAT...UNTIL, то все бы работало (кажется :) ), т.к. в теле цикла c (т.е. correction) получает положительное значение.
В первом случае c := c * c
а во втором c := c ? c ? (0.75 + 0.25?c)
№ 1864 17-01-2007 15:49 | |
Ответ на »сообщение 1856« (Сергей Перовский)
___________________________
Мы ведем отсчет от разных точек, потому, что по разному воспринимаем ООП :)
Если бы кто посоветовал работу, которая бы четко сформулировала принципы ООП так, чтобы не было разночтений и разных толкований. Smalltalk видится подходящей основой для эталона ООП, но о каком Smalltalk речь? Наверно не о Smalltalk-72, Smalltalk-76 и даже не Smaltalk-80 (хотя, почему нет?). В гибридных языках типа C++, Java, C# как-то это все выглядит разными подзаконными актами при отсутствии собственно закона.
№ 1863 17-01-2007 15:37 | |
Ответ на »сообщение 1771« (AVC)
___________________________
Насчет модуля, кажется, понятно.
В действительности, есть немаловажный нюанс при "разрезании" класса на модуль и расширяемые типы. Для класса можно порождать сколь угодно много экземпляров - объектов. В случае модуля - сам модуль может быть только один.
А в чем принципиальное различие между расширением типа и наследованием?
Вопрос непростой. Помимо чисто "идейно-психологического" различия (математическое понятие против социально-антропологического) есть и кое-что еще. Наследование (inheritance) устанавливает отношение наследования (нерефлективное, несимметричное, но транзитивное) между двумя сущностями - классами. Строго говоря, из наследования не вытекает, что "наследник" должен в точности сохранять структуру "наследодателя", лишь дополняя ее, и безболезненно подменять "наследодателя" везде, где тот ранее использовался.
У Вирта расширение типа (type extension) строится на понятии подтипизации (subtyping). Есть тип (расширяющий тип), есть его подтип (расширяемый тип). Принцип подстановки (Liskov substitution principle), выдвинутый Барбарой Лисков в 1993 г., говорит о том, что S является подтипом типа T, если для любого истинного q(t) следует, что истинно и q(s).
Если не ошибаюсь, в Eiffel при наследовании можно не только модифицировать, но и даже удалять свойства, унаследованные от базового класса. В C++, например, есть приватное наследование (private inheritance), нарушающее принцип подстановки и подтипизацию.
Вообще говоря, имеет смысл воспринимать type extension в Обероне с позиции record class Хоара, а не process class Нигаарда-Дала. Здесь больший уклон в данные, а не в операции. Хотя при наличии в Обероне процедурных типов, через которые и реализуются методы, никто не запрещает все перевернуть с ног на голову.
№ 1862 17-01-2007 15:36 | |
Пользуясь случаем, пока концентрация экспертов столь высока, простой вопрос: есть ли какие-нибудь наработки на Блэкбоксе по использованию SIMD инструкций типа SSE в виде модулей, библиотек и т.п.?
Или подобная низкоуровневая оптимизация должна реализовываться на уровне среды, как в .NET и C#?
№ 1861 17-01-2007 14:41 | |
Ответ на »сообщение 1860« (AVC)
___________________________
Например, есть стандартная схема прохода по списку:
p := list;
WHILE p # NIL DO
S(p);
p := p.next
END;
Эх, ажно плакать хочется...
Насколько короче так:
do map s list
или
CONST eps = 1.0E-5;
...
y := approximation;
REPEAT
y0 := y;
y := F(x, y0)
UNTIL (y = y0) OR (ABS(y - y0) < eps*ABS(y));
approximate f x approximation eps = appr (f x approximation) approximation
where
appr y y0 = if (y == y0) || (abs(y - y0) < eps * abs(y)) then y
else appr (f x y) y
our'sqrt x y0 = (y0 + x / y0) * 0.5
main = print y
where
y = approximate our'sqrt x first'approximation epsilon
x = 2.0
epsilon = 1.0e-5
first'approximation = 1.0 Хотя тут уже не так однозначно... 8-о
Но с учётом того, что у Вас процедура не полностью оформлена (что поправимо), всё ж таки выигрыш есть... ;о)
TYPE Func = PROCEDURE (x, y : REAL) : REAL;
PROCEDURE Approximate (F : Func; x, approximation, eps : REAL) : REAL;
VAR y, y0 : REAL;
BEGIN
y := approximation;
REPEAT
y0 := y;
y := F(x, y0)
UNTIL (y = y0) OR (ABS(y - y0) < eps*ABS(y));
RETURN y
END Approximate;
PROCEDURE Our_Sqrt (x, y0 : REAL) : REAL;
BEGIN
RETURN (y0 + x / y0) * 0.5
END Our_Sqrt;
PROCEDURE Do*;
CONST epsilon = 1.0E-5;
VAR x, y, first_approximation : REAL;
BEGIN
first_approximation := 1.0;
x := 2.0;
y := Approximate (Our_Sqrt, x, first_approximation, epsilon);
StdLog.Real (y);
END Do;
Тем более, что ошибки в кодировании численных итераций допускают не только новички.
Достаточно вспомнить презентацию Вирта на дне Оберона в ЦЕРН.
О, а поподробнее нельзя об этом? Что там за ошибка была?
№ 1860 17-01-2007 12:41 | |
Ответ на »сообщение 1822« (Trurl)
___________________________
Ответ на »сообщение 1815« (AVC)
___________________________
>>>Вот вопрос: в каком учебнике современный программист найдет сoвет, как ему выбрать "эпсилон"?
В любом учебнике по численным методам. ;-)
Если бы... :(
Сколько не тужусь, могу вспомнить только примеры вида: вычислите значение функции f(x) с точностью eps=0.001 (т.е. эпсилон уже задан в условиях задачи).
Правда, может быть, память подводит?
О чем я?
Хотя бы вот о чем.
Например, есть стандартная схема прохода по списку:
p := list;
WHILE p # NIL DO
S(p);
p := p.next
END;
И еще много стандартных схем.
Почему в учебниках обычно нет стандартной схемы итеративного решения?
Возможно, она должна выглядеть как-то так:
CONST eps = 1.0E-5;
...
y := approximation;
REPEAT
y0 := y;
y := F(x, y0)
UNTIL (y = y0) OR (ABS(y - y0) < eps*ABS(y));
Мне кажется, такая схема была бы полезна в учебниках.
Тем более, что ошибки в кодировании численных итераций допускают не только новички.
Достаточно вспомнить презентацию Вирта на дне Оберона в ЦЕРН.
№ 1859 17-01-2007 11:18 | |
Ответ на »сообщение 1857« (Сергей Перовский)
___________________________
Что-то в этот раз сумбурно получилось. Но, надеюсь, понятно.
Не, ну "нерв момента" уловить возможно! :о)
Сергей, вам с такими пожеланиями и устремлениями, прямая дорга не сюда, а тему на два номера меньше... ;о) Чесслово! Потом не пожалете да ещё и спасибо скажете!
№ 1858 17-01-2007 11:17 | |
2 Сергей Перовский
>>>Но, надеюсь, понятно.
Конечно, понятно! Но и здесь не все однозначно.
Есть "программист Ivanov". А есть, к примеру, Дейкстра. Который, будучи по основной профессии физиком, гордо написал о своем роде занятий "программист" (кажется, еще в 1957 году). Я не знаю Дейкстру-физика, хотя допускаю, что здесь у него есть достижения. Но я хорошо знаю Дейкстру-программиста. И именно в этой области он сделал много полезного. И у меня просто не "повернется язык" назвать Дейкстру простым "писарем-переводчиком" с человеческого языка на компьютерный.
№ 1857 17-01-2007 10:52 | |
Ответ на »сообщение 1851« (pepper)
___________________________
>>>Чем достали? Откуда такое неприятие?
По десятому разу.
Когда человек говорит, что он программист, это все равно, что сказать "я умею писать". Это может означать 2 класса церковно приходской школы или десяток романов. Чаще первое :)
Профессиональными программистами обычно называют себя люди, ничего, кроме некоторого инструментария не знающие.
Спросите ребенка, только что научившегося писать, что он может написать.
И он совершенно справедливо ответит - ВСЕ!
Вот только ему придется диктовать...
Постоянная история: давайте сделаем программную реализацию этого метода, наймем десяток программистов, Вы им только спецификации напишите.
Да мне проще описать алгоритм на языке программирования. Компилятор меня поймет однозначно. На спецификации потребуется больше времени и программисты все равно поймут их неправильно.
Программист - перводчик с человеческого языка на компьютерный. Какова его роль в мире с всеобщей компьютерной граматностью?
Когда то существовала уважаемая профессия - писарь. Переводчик с устного языка на письменный и обратно. Кому сейчас придет в голову воспользоваться подобными услугами?
Что-то в этот раз сумбурно получилось.
Но, надеюсь, понятно.
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|