Сириус - обероноподобный язык и компилятор

[alexus]

Код: [Выделить]

Result := NIL;
IF Start.value = Value THEN
    Result := Start;
ELSIF Start # End
    IF End.value = Value THEN
        Result := End;
    ELSE
        End := End.prev;
        WHILE ( Result = NIL ) & ( Start # End ) DO
            Start := Start.next;
            IF Start.value = Value THEN Result := Start END;
        END;
    END;
END;

Не слишком ли заумно для банального сканирования списка?.. Так не проще будет:

Код: [Выделить]

while ((start # end) and (start.value # value)) do
        start := start.next;
if (start = end) then
        result := nil
else    result := start;


[DIzer]

Не слишком ли заумно для банального сканирования списка?.. Так не проще будет:

Код: [Выделить]

while ((start # end) and (start.value # value)) do
        start := start.next;
if (start = end) then
        result := nil
else    result := start;


ИМХО и это заумь... я бы написал не думая нечто вроде

Код: [Выделить]

result:=start;
WHILE (result # NIL) & (result.value # avalue) DO
        result := result.next;
END;
IF result # NIL THEN
.....
END



[Kemet]

Код: [Выделить]

Result := NIL;
IF Start.value = Value THEN
    Result := Start;
ELSIF Start # End
    IF End.value = Value THEN
        Result := End;
    ELSE
        End := End.prev;
        WHILE ( Result = NIL ) & ( Start # End ) DO
            Start := Start.next;
            IF Start.value = Value THEN Result := Start END;
        END;
    END;
END;

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

А чего заумного? Проверяем первый элемент, сравнение дешевле присваивания, потому как сборщик мусора. Если не оно, смотрим, есть ли в списке еще элементы, если начальный и конечный элементы равны, значит был всего один элемент, искать больше нечего, иначе смотрим на последний элемент - вдруг по закону подлости искомое там и оказывается, итого, мы провели три сравнения, три дешевых операции, они дешевле одного присваивания,  и теперь начинаем крутить цикл, в котором уже тяжелая артиллерия и после выхода из которого ничего проверять не надо, всё уже проверено. Для наших специфических применений чем дешевле операция, тем лучше, с учетом, что это будет крутиться на PDP-11, вынужденного обрабатывать более 1000 сигналов в секунду.

Так не проще будет:

Код: [Выделить]

while ((start # end) and (start.value # value)) do
        start := start.next;
if (start = end) then
        result := nil
else    result := start;


Ы? А что случится, если искомое находится таки в end?

[alexus]

ИМХО и это заумь... я бы написал не думая нечто вроде

Код: [Выделить]

result:=start;
WHILE (result # NIL) & (result.value # avalue) DO
        result := result.next;
END;
IF result # NIL THEN
.....
END



Кто-то говорил, что список не закольцован?.. Нет, тогда откуда взялось условие (result # nil)? Исправляя заумь, недолжно впадать в... противоположность... даже, если противоположности смыкаются, как закольцованный список...

[alexus]

Так не проще будет:

Код: [Выделить]

while ((start # end) and (start.value # value)) do
        start := start.next;
if (start = end) then
        result := nil
else    result := start;


Ы? А что случится, если искомое находится таки в end?

Так end надо выбирать с умом... Ну, если всё же конец - это не конец, то перепишите первое условие так (start # end.next). Устроит? Хотя если предполагается, что надо проверять конечный элемент, то до начала цикла имело бы смысл написать end := end.next;. Или, если список не может быть кольцом, то так:

Код: [Выделить]

if (end # nil) then end := end.next;


[DIzer]

Кто-то говорил, что список не закольцован?.. Нет, тогда откуда взялось условие (result # nil)? Исправляя заумь, недолжно впадать в... противоположность... даже, если противоположности смыкаются, как закольцованный список...

  Подразумевалось, что если это специальный случай... то о нем нужно сказать ОТДЕЛЬНО...напоминаю  -изначально речь шла об уместности ветки  ELSE - я привел построение , где она  неуместна... да и даже если бы список был циклическим,.. я бы строил ДРУГОЕ решение (ему соответствующее) вместо общего - не умничал..

[Kemet]

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

[alexus]

Ну да, извиняюсь...

Принимается.

[DIzer]

ну тогда у вас СУЩЕСТВЕННО  кольцевой список -специальный случай..  не связанный с ЧАСТОТНОЙ задачей о которой говорил я.

[Kemet]

ну тогда у вас СУЩЕСТВЕННО  кольцевой список -специальный случай..  не связанный с ЧАСТОТНОЙ задачей о которой говорил я.

Да вроде ничего специального, это применяется, в том числе для оптимизации поиска в упорядоченном списке, т.к. в таком случае, кроме first и last есть ещё b middle, который делит его примерно пополам.

[DIzer]

  увы не совсем  так "подсписок может начинаться с любого элемента списка, в том числе и начального или конечного, и заканчиваться любым"

[DIzer]

то есть , то что привел я - не является решением  вашей задачи....

[Kemet]

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

[DIzer]

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

[Kemet]

Ну нет, секция ELSE в WHILE - это чисто "от Сириуса" ... Теряюсь в догадках - будем считать, что Kemet меня заинтриговал..

Ан нет никакой интриги.
Мы занимаемся специфическими задачами, часто на специфическом оборудовании, когда каждая лишняя команда - лишняя. Поэтому приходится заниматься ручной оптимизацией. Можно сказать, что ручная оптимизация отжила своё, но, кто-нибудь задавал себе вопрос почему оберонистые компиляторы не шибко умные  и зачем там DEC/INC, если их можно выразить через банальный +-1.
Что касается ручной оптимизации, то вспоминается процессор DEC Alpha. Он был самым производительным именно потому, что инженеры DEC, в отличии от других, применяли не автоматизированные средства проектирования. DEC Alpha это в буквальном смысле ручная работа. И именно такие подходы сейчас применяются при проектировании современных процессоров, т.е. после Alpha произошел откат от автоматизированного проектирования к ручному.
Что касается циклов, то у нас принят стандарт или паттерн, в соответствии с которым, если что-то связанное с циклом можно сделать вне цикла и до входа в него, должно быть сделано, никаких дополнительных проверок после выхода из цикла или блоков с ним связанных делать не нужно, все проверки и приведения уже выполнены. Это очень важно, ведь тот, кто потом будет оптимизировать цикл должен точно знать, где он заканчивается. Если у кого-то не получается соответствовать такому паттерну ( а у новичнов не получается и пишут как придётся ) и он не может оптимизировать цикл, он помещает свой "лишний" код, в котором проводит проверку правильности завершения цикла и т.п., в секцию ELSE цикла WHILE, тем самым логически его ограничивая. В дальнейшем ни у кого не возникает вопросов, что к чему относится.
Конечно, при оптимизации никто не может проста поменять а на б без всякого обоснования, но писать простанные описания и некогда и не каждый умеет такие кляузы сочинять. Поэтому был придуман специальные обозначения для таких целей. Но это уже ни к циклу WHILE, ни к Сириусу отношения не имеет.