nesco, "Благородные Доны" уже жаловались, что смысл рассуждений других "Благородных Донов" ускользает, особенно в части классов, объектов, родителей и наследников...
Этот топик читают: Гость
Ответов: 8921
Рейтинг: 823
|
|||
карма: 19 |
|
Ответов: 9906
Рейтинг: 351
|
|||
Давайте так, формула для MathParse, как ни крути - есть запись на некотором формальном языке.
Не виноватый я, что так оно и есть на самом деле И, по большому счету, этот язык должен быть разжеван в справке на элемент. Максимально лаконичная форма описания языка - это и есть синтаксическая диаграмма, которую я привел для нашего конкретного случая. Как бы на языке РБНФ. Для которого тоже синтаксис точно так же можно описать на ем же. Альтернатива - смотри код. Ну ей-ей, посмотреть на выше приведенные 7 формул - проще, чем лопатить 1000 строк кода. Фишка в том, смысл этих 1000 строк - реализовать эти 7 формул. У меня есть предложения для их изменения. Как мне, спрашивается поступить: выложить новые формулы для обсуждения, или сказать - смотрите как славно я 1000 строк кода перелопатил ??? Особо сложного в РБНФ то и нету. Вертикальная палка - просто альтернатива (или). Квадратные скобки - повтор содержимого ноль, или один раз. Фигурные скобки - повтор содержимого ноль, или любое число раз. Обыкновенные скобки - просто обычная группировка, безо всяких скрытых смыслов. Ну и наконец, кто-то разве отказывался отвечать на вопросы, коль скоро таковые возникнут ??? |
|||
карма: 9 |
|
Разработчик
Ответов: 26113
Рейтинг: 2126
|
|||
Вот, я попробовал изменить CalcErrPos. Теперь строки будут считаться с 1 и будут отображаться первыми, те -- строка:позиция, как во всех редакторах сделано. Посмотрите. как там чего, все ли нормально, может подкорректируете, потом добавлю изменения на SVN, выкинув все ненужное.
himathparse.zip Galkov, большая ли разница в применении не
Да, хотел еще спросить -- а не возникнит ли ситуация, когда вместо #13#10, переводом строки будет только #13, стоит ли это учесть |
|||
карма: 22 |
| ||
файлы: 1 | himathparse.zip [5.7KB] [370] |
Разработчик
Ответов: 4698
Рейтинг: 426
|
|||
В первом посте обновлен компонент и тестовая схема. Изменения:
- Декомпиляция байткода теперь происходит только при подключении точки onDebugText и работает всегда (т.е. не зависит от режима работы компонента). - Код избавлен от применения классов, что дало прирост производительности чистых вычислений в 5 раз. (на старых тестах это не так заметно). - Исправлены баги, упоминавшиеся выше. |
|||
карма: 10 |
| ||
Голосовали: | sla8a |
Ответов: 9906
Рейтинг: 351
|
|||
nesco писал(а): Да, хотел еще спросить -- а не возникнет ли ситуация, когда вместо #13#10, переводом строки будет только #13, стоит ли это учесть Я думаю, что фигня все это... А вот Кладов думает по-другому -- и учитывает это. Можно посмотреть в TStrList.SetText Смотри сам, в общем nesco писал(а): большая ли разница в примененииДа никакой, как мне кажется. Компиляторы - тупы, конечно же. Но не до такой степени Но я не поленился, и посмотрел дизасм для обоих вариантов - действительно, абсолютно пофиг Вот он, для твоего фрагмента кода (комментарии мои):
По любому, один INC быстрее любого перехода (со сбросом конвейера)
|
|||
карма: 9 |
|
Разработчик
Ответов: 26113
Рейтинг: 2126
|
|||
Galkov писал(а): По любому, один INC быстрее любого перехода (со сбросом конвейера)У меня изначально вообще было так
------------ Дoбавленo в 15.09: Galkov писал(а): Смотри сам, в общемС твоим предложением это оказалось реализовать довольно просто. Окончательные исправления на SVN. |
|||
карма: 22 |
|
Ответов: 9906
Рейтинг: 351
|
|||
Это правда.
Ничем этот код не хуже: что раньше было два логических сравнения, что сейчас - те же два. ------------ Дoбавленo в 08.17: Assasin, для сведения: Дельфячья строка гарантирует нулик за своим "концом" (для совместимости со всякими другими системами, например WinApi). Следовательно, ты зря напрягался за этот код:
------------ Дoбавленo в 09.16: Ыще Чувствую недопонимание :
Исключения - есть объективная данность камня, и тебя никто не спрашивал, нравятся они тебе, или нет. Они все равно произойдут (ни о чем тебя не спрашивая). Просто - посчитай чего нибудь типа 200^200. И ощути разницу между Дельфи и FPC. Второй делал проверки, и все равно упал. А первый не делал - и все нормально (в смысле - сообщает об ошибке никуда не падая). Ибо настоящая проверка делается в камне. И фиг ты сделаешь ее "самостоятельно". В камне - чтобы пользователь мог заниматься делом, а не проверкой осуществимости своих делов. Собственно, и наша то задача - Калькулятор, а не Проверятель Возможности Калькуляции. А упасть можно и на умножении (как в вышеприведенной формуле, ибо там работает IntPower, который есть умножение), так и на сложении. ------------ Дoбавленo в 09.49: Ыще
Ыще
Ыще
Но не буду. Ибо от этого геморроя надо избавляться по любому. Он же, собака, оказывается -- более навороченный, чем в оригинальном MathParse... ------------ Дoбавленo в 10.58: Ыще
|
|||
карма: 9 |
|
Разработчик
Ответов: 4698
Рейтинг: 426
|
|||
Galkov писал(а): Дельфячья строка гарантирует нулик за своим "концом" (для совместимости со всякими другими системами, например WinApi).А фпцшная? Galkov писал(а): Под Дельфи эти супер проверки тупо НЕ НУЖНЫ (зачем ты их там оставил?). Спрашивается, зачем напрягать как компилятор, так и процессор.Я их с MathParse перенес и не трогал. Слышал, что так сделано потому, что в дельфи то как раз исключения нормально обрабатываются, а в FPC падает всегда. Вот поэтому эти проверки и ограждают от падений. Если бы не это, я бы всегда использовал только исключения, ибо удобнее в разы. Galkov писал(а): // Не правда !!! Сначала использование, а потом DECЦэ не баг, цэ фича! Это хитрые оптимизации Если ты заметил, выше идет такой код:
Galkov писал(а): inc(FPC, sizeof(FPC)); // чего-чего ???А это да. Поправил у себя. И ведь, собака, работает же верно, ибо на x86 sizeof(pointer) = sizeof(integer) Galkov писал(а): Очень хочется спросить, а где под условием FreeData(@Fd); Fd := Fitem;...Не заглядывая в код: по-моему там две переменных, которые в стеке, и одна линкуется к другой через .ldata, после чего уже идет динамически выделенная память в AddMTData. Поэтому можно очистить только остаточный хвост после второй переменной, а первый .ldata подчистится вместе со стеком. В любом случае заранее добавлю просчет количества элементов в цепочке и просто динамическим массивом буду выделять. Galkov писал(а): -- сей код несколько бессмысленен.Код, может, и бессмысленен, но лучше явно показать, что здесь идет расчет на то, что может использоваться при выполнении результат предыдущих вычислений. Если условия не будет, после правок кода сразу и не разберешься, почему %0 перестал обрабатываться корректно. ------------ Дoбавленo в 16.03: Кстати, начал работу над оптимизацией. Неужели все должно быть настолько сложно?
|
|||
карма: 10 |
|
Ответов: 9906
Рейтинг: 351
|
|||
Assasin писал(а): А фпцшнаяА куда бы они делись нафиг. В этом вообще нет никаких сомнений. Assasin писал(а): Я их с MathParse перенес и не трогалТрогал. Я тебе привел свой код для CmdDiv, с условной компиляцией. А ты ее убрал. Не надо было убирать. Assasin писал(а): Если бы не это, я бы всегда использовал только исключенияПросто я не умею портировать err.pas под FPC, чтобы поймать Exception. Ходят упорные слухи, что кто-то на форуме умеет. Но мне в лом разбираться во внутренних кишках этого безобразия... Assasin писал(а): Если ты заметил, выше идет такой кодВсе я заметил. Два раза. И сделал Вывод - Твой код ошибочный. Смотри внимательней. Assasin писал(а): по-моему там две переменных, которые в стеке, и одна линкуется к другой через .ldata, после чего уже...Чего это Вы, всегда, так сложно объясняете простые вещи.... При исполнении AddMTData - создается динамическая копия от второго аргумента, которая ставится в хвост первому аргументу. Хвостов получается ДВА. Кто второй убивать будет, Пушкин, что ли. Assasin писал(а): но лучше явно показать, что здесь идет... Это твои человеческие проблемы. Вот этими, человеческими средствами и разрешай эти проблемы. Все тебе спасибо скажут. А не исполняемыми байтами в коде пользователя. Ни один Инженер (вменяемый, разумеется) не будет ставить лишние детали, из-за того что так лучше смотрится (читается, понятнее). Уверяю тебя, проблем с понимаемостью в электронике - ничуть не меньше. |
|||
карма: 9 |
|
Ответов: 824
Рейтинг: 138
|
|||
[flood]
Galkov писал(а): Ни один Инженер (вменяемый, разумеется) не будет ставить лишние детали, из-за того что так лучше смотрится (читается, понятнее).Уверяю тебя, проблем с понимаемостью в электронике - ничуть не меньше. |
|||
карма: 1 |
|
Ответов: 9906
Рейтинг: 351
|
|||
[flood]Было-было.
Это "искусство" передавалось в курилках [/flood] |
|||
карма: 9 |
|
Ответов: 824
Рейтинг: 138
|
|||
[flood]И главное! - ВСЕ они были абсолютно вменяемы! [/flood]
|
|||
карма: 1 |
|
Ответов: 9906
Рейтинг: 351
|
|||
[flood]Но не Инженерами с большой буквы. А с маленькой
А домашнее все по чертежам тех конструкторов, что на низкой зарплате Которых и конструкторами нельзя назвать. Как и те деньги - зарплатой (с) Жванецкий [/flood] |
|||
карма: 9 |
|
Разработчик
Ответов: 4698
Рейтинг: 426
|
|||
Galkov писал(а): Трогал. Я тебе привел свой код для CmdDiv, с условной компиляцией.А ты ее убрал. Не надо было убирать. Хм, и правда, прошу прощения, почему-то в голове отложилось, что код писался методом копипасты, значит и правок условной компиляции не было. Galkov писал(а): Все я заметил. Два раза.И сделал Вывод - Твой код ошибочный. Смотри внимательней. Не понимаю, что не так. Тестовые формулы проходит верно (например -1 * func(1, 2, 3)). Сам уже в который раз провожу построчную отладку - все правильно работает. Для примера возьмем cnt = 3, stack (пусть растет вправо) = 3 2 1. 1. В начальный момент FSP указывает на 1. Поэтому когда мы загоняем значение FSP^ в TData, мы считываем единицу. 2. Уменьшаем cnt на 1, т.к. один аргумент мы уже считали. 3. Потом начинается цикл. FSP по-прежнему указывает на первый аргумент (единицу). 4. Чтобы считать следующий аргумент, уменьшаем FSP, переходя к числу 2 (второй аргумент). 5. Загоняем аргумент в TData. 6. Уменьшаем cnt на 1. cnt = 1. 7. cnt > 0 = True, продолжаем цикл, уменьшаем FSP, теперь FSP^ = 3 (третий аргумент). 8. Считываем его и загоняем в TData. 9. Уменьшаем cnt, cnt = 0 10. Цикл кончился, FSP остался на третьем аргументе (тройка). 11. Происходит считывание данных с внешней точки (не затрагивает стек). 12. Пишем FSP^ := <результат запроса>. 13. Имеем на стеке только одно число - результат запроса с внешней точки. Вопрос: что не так? |
|||
карма: 10 |
|
Ответов: 9906
Рейтинг: 351
|
|||
Кажется, мне надо принести извинения (надо было, все-таки, три раза замечать)
Был неправ. Готов искупить и загладить
Вариант cnt=0 у нас допустим Для CmdUNFunc, вроде бы - ДА И чего будет
------------ Дoбавленo в 22.55: Assasin писал(а): Кстати, начал работу над оптимизацией. Неужели все должно быть настолько сложно?Хмм......... Мне, пока, очень не хотелось бы в кодах использовать знание о структуре TResult. Мало ли чего еще в голову придет на этом Высоко-Интеллектуальном пути.... Пущай у нас будут методы основного класса, имеющие аргументом TResult. И они, методы (а не мы) знают про FProgram, и как из него чего добыть, или удалить. Ну твой-то вариант -- не такой уж смертельный
А хочется, ведь - большего:
Ну что тут можно сказать.... Пока, только одно в голову приходит: Який же ты Лыцарь, колы голой сракой ежа не вбьешь |
|||
карма: 9 |
|