Читали предпоследнее предложение своей статьи? На всякий случай продублирую: «Так почему же студентов до сих пор мучают всякой хренью, придуманой в незапамятные времена?» И это после того, как вы предложили алгоритм, эффективность которого можете аргументировать только в «сфере обучения», и то лишь своим субъективным мнением.
Мнение я и не изменил. А вот фраза, о которой Вы почему-то не упомянули: «Таких интуитивно понятных алгоритмов, думаю, достаточно много.» И, знаете ли, я действительно думаю, что ни один я «такой умный». А П-П лишь повод подсветить проблему. Так что про «немедленно включить в программу» — это Вы уже сами придумали, ну или дайте ссылку, чтобы освежить мне память.
Никто никуда ОПН не вдавливает
Обсуждение говорит об обратном. Хорошее осуждение, даёт много материала для анализа.
Да нет, я пожалуй воздержусь от таких экспериментов.
Лучший критерий — результаты натурного испытания, но этим я сейчас тоже заниматься не буду.
будем считать историю завершённой.
М-да… Задачку Вы предложили не хилую.
Корректного решения кроме натурного эксперимента не существует (не вижу). Однако некоторые прикидки я сделал, как раз для ваших 100 строк. Возможны ошибки. Оценки по П-П взяты от фонаря.
А вот и неправильно. При преобразовании в ОПН каждый символ _ровно один раз_ попадает на вход алгоритма, _ровно один раз_ на стек попадает (если считать «удерживание» операции попаданием на стек, иначе она и раза не попадает) и _ровно один раз_ из стека достается.
Ладно, давайте разберёмся.
Несколько вводных замечаний (я уже осторожничаю)
1. Рассматриваем весь алгоритм от прихода инфиксной строки до получения конечного результата.
2. Операнды являются вещественными числами с длиной >=3
3. Алгоритм двухстековый (операнды отдельно, операции отдельно) как наиболее эффективный.
4. Попасть на вход алгоритма и быть задействованным в его работе — вещи разные, но мы их будем считать вместе.
5. Имеем 4 вида символов: 1. цифра 2. операция 3. "(" 4. ")" 5."." (разделитель) по видам логики обработки. Символы разделителей порядков игнорируем
6. Такие операции как нормализация по пробелам, валидация формулы и прочие сервисные игнорируем. Только чистый алгоритм.
7. s — общее количество использования
Поехали.
1. считывание символа в регистр АЛУ — 1
1.1 преобразовать в Сhar — (приведение типа) — 1
2. проверка на совпадение с одним из видов от 1 до 5 берём среднее — 3 (s — 4)
Здесь больше вообще-то, поскольку сравнение идёт с 17-ю символами
3. если цифра, то
3.1 записать в буфер числа (запись) — 1ц.
3.2 при приходе операции или ")" записать число в стек (чтение запись) 2ц
3.3 при расчёте операции вызов из стека запись в АЛУ 2ц
4. если операция, то
4.1 проверить приоритет по отношению к предыдущей операции (сравнение) — 2о (по одной на каждое положение проверяющий-проверяемый)
4.2 если приоритеты равны, то
4.2.1 предыдущий отправляется в АЛУ на расчёт (чтение) -1о
4.2.2 текущий записывается в стек операций (запись) — 1о
4.2.3 ИНАЧЕ текущий записывается в стек операций (запись) — 1о (1о-)
4.2.4. при расчёте операции вызов из стека запись в АЛУ 2о
5. если "(", то отправляется в стек операций (запись) — 1с
5.1 при завершении реверса удаление 1с
6. если ")", то
6.1 запустить реверс на расчёт фрагмента (удаление) — 1с
7. если ".", то записать в буфер числа (запись) — 1т.
7.1 при приходе операции или ")" записать число в стек (чтение запись) 2т
Может что еще забыл, ну да бог с ним. забудем пока перезапись вызов результатов, приведение чисел к формату dubl. Поведём итог
Обращение символам в процессе выполнения алгоритма
к любому — 5
дополнительно:
к цифре — 5
к операции — 6
к "(" — 2
к ")" — 1
к "." — 3
Таким образом общее число обращений к символу
к цифре — 10 (без учёта операций по результатам)
к операции — 11
к "(" — 7
к ")" — 6
к "." — 8
чтобы привести к сравнимому результату возьмём строку 100 символов. Из них при 8 закрытых скобками фрагментах получаем
"(" — 8 — 64 обращения
")" — 8 — 64 обращения
100-16 = 84 символа
84/4 = 21 групп операнд+операция
Операции — 20 — 220 обращений
цифры и точки — 64
"." — 21 — 168 обращений
цифры — 43 — 430 обращений
таким образом на строку в 100 символов общее количество обращений — 946
Сравните со своим алгоритмом теперь
Здесь сложнее считать, поскольку плохо понятно сколько обращений проходит в операциях со StringBuilder и с регулярными выражениями. Также как выше отбросим обращения при перезаписи результатов. Чтобы рассчитать количество проходов при выделении фрагментов по скобкам, \\ ?? поскольку выделенные фрагменты сразу удаляются возьмём коэффициент 1.5 к исходной длине строки.
Получаем
1. поиск первой ")" сильно зависит от месторасположения. С учётом исходных данных, 8 групп, максимальное расположение от начала первой ")" составит 92 символ. Из них
"(" — 8
операции — 20
цифры — 43
"." — 21
общее число обращений за проход — 92
2. Реверс. Поиск первой ")" при средней длине фрагмента 21 символ получим 21 обращение
3. Копирование фрагмента в строку «фрагмент» (чтение-запись) 42 обращения (копирование не по символам, ну да бог с ним). (допускаем: на фрагмент 6 операций, 2 *, 1/, 2+, 1-.) (суммарно по операциям — 119)
4. блок умножения (сумарно — 49 обращений)
4.1 Поиск первой операции * (допускаем: на фрагмент 7 операций, 2 *, 1/,2+,1-.
1-й * на 7 поз.) — 7обращений. (сум=23)
4.1.1.выделение левого фрагмента 3*2 (так же как в ОПН по видам и по среднему) 6 обращений.
4.1.2. выделение правого операнда 2*2 = 4 обращений
4.1.3. расчет результата, запись результата 6 обращений
4.2. Поиск второй операции * (Вх -18, с конца правого операнда(7), позиция* 15) — 8 обращений. (сум=26)
4.2.1.выделение левого фрагмента 3*2 (так же как в ОПН по видам и по среднему) 6 обращений.
4.2.2 выделение правого операнда 3*2 = 6 обращений
4.2.3. расчет результата, запись результата 6 обращений
5. Блок деления (Вх -15 симв, операция на 3) (сумарно — 17 обращений)
5.1 Поиск первой операции / 1-й / на 3 поз.) — 3 обращений.
5.1.1.выделение левого фрагмента 2*2 (так же как в ОПН по видам и по среднему) 4 обращений.
5.1.2. выделение правого операнда 2*2 = 4 обращений
5.1.3. расчет результата, запись результата 6 обращений
6. Блок сложения /вычитания (Вх -12 симв, ) (сумарно — 53 обращений)
5.1 Поиск первой операции (Вх12 с., на 3 поз.) — 3 обращений. (сумм=17)
5.1.1.выделение левого фрагмента 2*2 (так же как в ОПН по видам и по среднему) 4 обращений.
5.1.2. выделение правого операнда 2*2 = 4 обращений
5.1.3. расчет результата, запись результата 6 обращений
5.2 Поиск второй операции (Вх-9 на 4 поз.) — 3 обращений. (сум=17)
5.2.1.выделение левого фрагмента 2*2 (так же как в ОПН по видам и по среднему) 4 обращений.
5.2.2. выделение правого операнда 2*2 = 4 обращений
5.2.3. расчет результата, запись результата 6 обращений
5.3 Поиск третьей операции (Вх-6 на 3 поз.) — 3 обращений. (сум=19)
5.3.1.выделение левого фрагмента 2*2 (так же как в ОПН по видам и по среднему) 4 обращений.
5.3.2. выделение правого операнда 3*2 = 6 обращений
5.3.3. расчет результата, запись результата 6 обращений
Осталось 7 фрагментов. Примем что у них всё по столько же. итого 833
В указанной конфигурации исходной строки далее будет только реверс. Так что ещё 7*21= 147
Итого: 1254
Итак, вроде как всё понятно ОПН — 946, П-П -1254 обращений. Однако вспоминаем что здесь нигде не учтена логика, мои оценки количества обращений весьма сомнительны, ну и прочие, влияющие на производительность, вещи.
Методику расчёта оставил специально, чтобы не было вопросов.
Если честно, я ожидал худших результатов для П-П. А так… Даже почти близко.
А может сделаем так.
Вы апологет ОПН — отлично.
Берём одинаковую формулу на входе; определяем инструмент (с вас и общедоступный); запускаем и обмениваемся результатами.
Ещё раз я в курсе еффективности алгоритмов на ОПН, в курсе что разные алгоритмы ОПН дадут разную производительность, предполагаю (отсутствует точная информация) что под ОПН на современном железе есть аппаратные и программные ускорители, не может не быть, поскольку живёт долго и является доминантой в направлении. Однако готов провести такой эксперимент. Вот только писать для ОПН — увольте.
Конечно не сняли. Но, в целом, понятно, что слились.
Какие остались вопросы? В чём выразилось «слились»?
никакой пользы от этого велосипеда нет.
Время покажет.
«Непонимание», что смотреть, отнесём к упёртости и неспособности видеть дальше своего носа.
Некорректно. У вас там нет комментариев что есть что, а бегать по всем вашим опусам желания не возникает. Укажите конкретно про что говорили и я посмотрю.
А про нос вам стоило бы быть осторожнее.
-2.5*(0.03+0.02)*(-12.752+(-25.5656/-5.1249)-(2*4-5*2+10/5))+100+((25+(6*12/3*(-1)-((((9-7)*3.5+(-1)*(4+5+11-24/2-(5*3/5+42)+1287/5.4)-20)-20)+4.2)*47)-60+(((10.2+12.8)*2/4-5+[log10|100|]*[sqrt|9|]+[pow|2,3|])+10))+(10*0.02+12/0.02)+(60*20/30+10))+(-102.5478+52.1422) — держите. На ней тестировался алгоритм.
Ну и да, автор не препод. :)
Стоп!
Я нигде не предлагал перечеркнуть, нигде не предлагал «вместо». Я точно говорил о возникшем ощущении безальтернативности и мозголомности ОПН. То есть когда достаточно специализированная вещь является основой для курсовой у студентов, когда даже на Хабре я не увидел ничего кроме ОПН, не считая древовидных или рекурсивных решений, то меня как-то это несколько напрягло. Напрягло не просто так, а потому, что перед этим я поразбирался с ОПН. Так что это шло именно отсюда.
Нужно ли ОПН? — да. Надо ли его оставлять безальтернативным? — нет. Надо ли его вдавливать в молодые мозги? — нет. Вам же на вдалбливали в голову уравнения описывающие истечение газов из ракетного сопла и прочие специфические вещи. Хабр ресурс профессиональный, но не ограниченный. И на нём десятки статей С ОПН и ни одной реальной альтернативы (рекурсию и деревья не считаем).
Нет-нет, не подумайте что я себя с Циолковским сравниваю. И в мыслях не было. Циолковского я упомянул как известный пример отношений человека и общества. И исключительно в рамках предыдущего обсуждения.
Прошёл по ссылкам, но не понял что именно смотреть из каталога. В итоге не ясно что же Вы предлагаете посмотреть. Ну это во-первых.
Во-вторых, автор не старался ущемить алгоритмы на ОПН, мне не понравилось что в инфосфере присутствует доминанта ОПН. А особенно то, что эта доминанта присутствует в образовательном процессе в нашей системе образования. Считаю правильным, чтобы информация о реализациях на ОПН присутствовала в образовании, но так же считаю, что это не то, что надо безальтернативно вдалбливать в молодые мозги.
В процессе обсуждения выяснилось. что ОПН нужен в основном при написании компиляторов. Но компиляторами, насколько знаю, пишут не очень многие. А кто пишет, способен, при наличие базовой информации, сам при необходимости, разобраться с вопросом.
Время потраченное вами на реализацию с использованием ОПН не впечатлило.
Реализация у автора есть, на java.
Автор нигде не упоминает о большей эффективности его решения по отношению к ОПН, кроме сферы восприятия и обучения. Высказанные сомнения по поводу эффективности самого подхода посимвольного разбора присутствуют в силу перегруженности логики на этапе посимвольного разбора (подготовки к расчёту).
Пожалуй всё. надеюсь я снял ваши вопросы.
ЖЖ для трёпа и для вбросов.
Хочу напомнить Вам такую фамилию как Циолковский. Попробуйте посмотреть не только его космические расчёты. Кстати, история публикации его работ достаточно интересна. Обратите внимание что я не употребил слово «научных».
Я понимаю устоявшуюся позицию по разделению алгоритма вычисления математического выражения с помощью преобразования в ОПН на две части: подготовку и само вычисление. Однако, как мне кажется, это несколько искусственно. Расчёт не возможен без преобразования. Поэтому я говорю о комплексном алгоритме с использованием ОПН.
Ну и сравнения производятся, как правило при одинаковом входе и одинаковым требуемом результате.
Появление скобок в исходной формуле приводит к необходимости реверсивного движения с расчётами до закрытия фрагмента. т.е. до скобки открывающей, а затем возврат к последовательному перебору (двухстековый алгоритм) дальше по строке.
Появление вещественных чисел с длиной > 1 добавляет участника (буфер сборки чисел из цифр). логику, связанную с формированием чисел, дополнительные перемещения символов между участниками. При появлении в числе разделителя дробной части, появляется дополнительные логика и сравнения.
Предыдущий комментатор прав, я действительно рассматривал целостные алгоритмы, один из которых реализуется через использование ОПН. Это была моя ошибка, что я не подумал это как-то отдельно ярко выделить. да и просто не подумал, поскольку для меня это было очевидно. Вот такая проблема очевидности иногда вылезает.
Вы в итоге сравнили два алгоритма расчета значений обычного выражения в инфиксной нотации. Ни в одном из этих алгоритмов никаких ОПН и кусков ОПН не строится и вообще нету никакого ОПН.
Ну как же ОПН нет? А в какой нотации тогда строится постфиксная запись?
То есть это уже не скобки? Не встречал алгоритмов преобразования в ОПН, которые бы пропустили такую ситуацию.
Это не выражение ОПН,
в ОПН выражение характеризуется тем, что в нем символов операндов ровно на 1 больше, чем символов операций.
Я как-то и задал вопрос. поскольку мне показалось что по приведённому вами критерию конечная формула написанная вами не проходит, хотя инфиксная исходная форма корректна. Проверил ещё раз — не проходит: операндов 16 (без (-1), а операций только 13. Вопрос не в том, что Вы ошиблись — вопрос в том, что контроль постфиксной записи человеком очень затруднён, особенно на этапах начального изучения ОПН.
Вы говорите какую-то бессмыслицу. Никаких выражений в стеке при вычислении ОПН не лежит и ничего никуда не присоединяется.
Насколько я помню, сейчас лень искать, вы утверждали что для полного цикла обработки инфиксной записи до получения результата необходим только один стек и более ничего не надо. Выражение, преобразованное вами ранее, так понимаю, лежит в одном стеке. вопрос и был о том как работая с одним стеком (LIFO) произвести выемку двух операндов для операции, которая лежит на вершине стека. Если никаких выражений в стеке не лежит, то что там лежит, куда делось выражение, ведь у нас больше ничего нет кроме стека?
Вроде выяснили, что ОПН будет эффективнее во всех смыслах кроме понимания ( субъективно для Вас ).
Пока не выяснили, по прежнему считаю что посимвольный разбор строки с большим количеством логики на длинных сложных формулах не обладает очевидной эффективностью.
Несложно реализовать и в ОПН, и в деревьях.
Всё можно реализовать уже существующими способами. Развитие идёт тогда, когда начинают, по той или иной причине, искать альтернативные пути.
Не очень понимаю, о чем вы, но звучит как задача, которая решается деревьями
Это означает. что в скобки можно затолкнуть любой контекст. а не только математические знаки и цифры для формул. Как сказал выше, сейчас нет задач, которые бы нельзя было решить уже имеющимися средствами программирования. вопрос только соответствующих затрат.
Но если в будущем он неприменим, зачем тратить время школьника?
Это решит будущее. А для школьников это понятный элемент конструктора, который не ломает мозги и позволяет решать задачи связанные с разбором и вычислением формул. Чем они сейчас на уроках информатики занимаются — конструкторы собирают. Главное здесь — не ломать мозги.
Это неправильная стратегия разработки алгоритмов. Алгоритмы нужно придумывать не для того, что бы они были, а для решения реальных задач.
Он и решил задачу для которой был предназначен. Причём полностью и без тяжёлых последствий воздействия ОПН на голову и психику. А то, что я не рассматривал возможности применения в сфере промышленного программирования — это вопрос второй или дальше.
Мнение я и не изменил. А вот фраза, о которой Вы почему-то не упомянули: «Таких интуитивно понятных алгоритмов, думаю, достаточно много.» И, знаете ли, я действительно думаю, что ни один я «такой умный». А П-П лишь повод подсветить проблему. Так что про «немедленно включить в программу» — это Вы уже сами придумали, ну или дайте ссылку, чтобы освежить мне память.
Обсуждение говорит об обратном. Хорошее осуждение, даёт много материала для анализа.
Лучший критерий — результаты натурного испытания, но этим я сейчас тоже заниматься не буду.
будем считать историю завершённой.
Бывает.
Корректного решения кроме натурного эксперимента не существует (не вижу). Однако некоторые прикидки я сделал, как раз для ваших 100 строк. Возможны ошибки. Оценки по П-П взяты от фонаря.
Ладно, давайте разберёмся.
Несколько вводных замечаний (я уже осторожничаю)
1. Рассматриваем весь алгоритм от прихода инфиксной строки до получения конечного результата.
2. Операнды являются вещественными числами с длиной >=3
3. Алгоритм двухстековый (операнды отдельно, операции отдельно) как наиболее эффективный.
4. Попасть на вход алгоритма и быть задействованным в его работе — вещи разные, но мы их будем считать вместе.
5. Имеем 4 вида символов: 1. цифра 2. операция 3. "(" 4. ")" 5."." (разделитель) по видам логики обработки. Символы разделителей порядков игнорируем
6. Такие операции как нормализация по пробелам, валидация формулы и прочие сервисные игнорируем. Только чистый алгоритм.
7. s — общее количество использования
Поехали.
1. считывание символа в регистр АЛУ — 1
1.1 преобразовать в Сhar — (приведение типа) — 1
2. проверка на совпадение с одним из видов от 1 до 5 берём среднее — 3 (s — 4)
Здесь больше вообще-то, поскольку сравнение идёт с 17-ю символами
3. если цифра, то
3.1 записать в буфер числа (запись) — 1ц.
3.2 при приходе операции или ")" записать число в стек (чтение запись) 2ц
3.3 при расчёте операции вызов из стека запись в АЛУ 2ц
4. если операция, то
4.1 проверить приоритет по отношению к предыдущей операции (сравнение) — 2о (по одной на каждое положение проверяющий-проверяемый)
4.2 если приоритеты равны, то
4.2.1 предыдущий отправляется в АЛУ на расчёт (чтение) -1о
4.2.2 текущий записывается в стек операций (запись) — 1о
4.2.3 ИНАЧЕ текущий записывается в стек операций (запись) — 1о (1о-)
4.2.4. при расчёте операции вызов из стека запись в АЛУ 2о
5. если "(", то отправляется в стек операций (запись) — 1с
5.1 при завершении реверса удаление 1с
6. если ")", то
6.1 запустить реверс на расчёт фрагмента (удаление) — 1с
7. если ".", то записать в буфер числа (запись) — 1т.
7.1 при приходе операции или ")" записать число в стек (чтение запись) 2т
Может что еще забыл, ну да бог с ним. забудем пока перезапись вызов результатов, приведение чисел к формату dubl. Поведём итог
Обращение символам в процессе выполнения алгоритма
к любому — 5
дополнительно:
к цифре — 5
к операции — 6
к "(" — 2
к ")" — 1
к "." — 3
Таким образом общее число обращений к символу
к цифре — 10 (без учёта операций по результатам)
к операции — 11
к "(" — 7
к ")" — 6
к "." — 8
чтобы привести к сравнимому результату возьмём строку 100 символов. Из них при 8 закрытых скобками фрагментах получаем
"(" — 8 — 64 обращения
")" — 8 — 64 обращения
100-16 = 84 символа
84/4 = 21 групп операнд+операция
Операции — 20 — 220 обращений
цифры и точки — 64
"." — 21 — 168 обращений
цифры — 43 — 430 обращений
таким образом на строку в 100 символов общее количество обращений — 946
Здесь сложнее считать, поскольку плохо понятно сколько обращений проходит в операциях со StringBuilder и с регулярными выражениями. Также как выше отбросим обращения при перезаписи результатов. Чтобы рассчитать количество проходов при выделении фрагментов по скобкам, \\ ?? поскольку выделенные фрагменты сразу удаляются возьмём коэффициент 1.5 к исходной длине строки.
Получаем
1. поиск первой ")" сильно зависит от месторасположения. С учётом исходных данных, 8 групп, максимальное расположение от начала первой ")" составит 92 символ. Из них
"(" — 8
операции — 20
цифры — 43
"." — 21
общее число обращений за проход — 92
2. Реверс. Поиск первой ")" при средней длине фрагмента 21 символ получим 21 обращение
3. Копирование фрагмента в строку «фрагмент» (чтение-запись) 42 обращения (копирование не по символам, ну да бог с ним). (допускаем: на фрагмент 6 операций, 2 *, 1/, 2+, 1-.) (суммарно по операциям — 119)
4. блок умножения (сумарно — 49 обращений)
4.1 Поиск первой операции * (допускаем: на фрагмент 7 операций, 2 *, 1/,2+,1-.
1-й * на 7 поз.) — 7обращений. (сум=23)
4.1.1.выделение левого фрагмента 3*2 (так же как в ОПН по видам и по среднему) 6 обращений.
4.1.2. выделение правого операнда 2*2 = 4 обращений
4.1.3. расчет результата, запись результата 6 обращений
4.2. Поиск второй операции * (Вх -18, с конца правого операнда(7), позиция* 15) — 8 обращений. (сум=26)
4.2.1.выделение левого фрагмента 3*2 (так же как в ОПН по видам и по среднему) 6 обращений.
4.2.2 выделение правого операнда 3*2 = 6 обращений
4.2.3. расчет результата, запись результата 6 обращений
5. Блок деления (Вх -15 симв, операция на 3) (сумарно — 17 обращений)
5.1 Поиск первой операции / 1-й / на 3 поз.) — 3 обращений.
5.1.1.выделение левого фрагмента 2*2 (так же как в ОПН по видам и по среднему) 4 обращений.
5.1.2. выделение правого операнда 2*2 = 4 обращений
5.1.3. расчет результата, запись результата 6 обращений
6. Блок сложения /вычитания (Вх -12 симв, ) (сумарно — 53 обращений)
5.1 Поиск первой операции (Вх12 с., на 3 поз.) — 3 обращений. (сумм=17)
5.1.1.выделение левого фрагмента 2*2 (так же как в ОПН по видам и по среднему) 4 обращений.
5.1.2. выделение правого операнда 2*2 = 4 обращений
5.1.3. расчет результата, запись результата 6 обращений
5.2 Поиск второй операции (Вх-9 на 4 поз.) — 3 обращений. (сум=17)
5.2.1.выделение левого фрагмента 2*2 (так же как в ОПН по видам и по среднему) 4 обращений.
5.2.2. выделение правого операнда 2*2 = 4 обращений
5.2.3. расчет результата, запись результата 6 обращений
5.3 Поиск третьей операции (Вх-6 на 3 поз.) — 3 обращений. (сум=19)
5.3.1.выделение левого фрагмента 2*2 (так же как в ОПН по видам и по среднему) 4 обращений.
5.3.2. выделение правого операнда 3*2 = 6 обращений
5.3.3. расчет результата, запись результата 6 обращений
Осталось 7 фрагментов. Примем что у них всё по столько же. итого 833
В указанной конфигурации исходной строки далее будет только реверс. Так что ещё 7*21= 147
Итого: 1254
Итак, вроде как всё понятно ОПН — 946, П-П -1254 обращений. Однако вспоминаем что здесь нигде не учтена логика, мои оценки количества обращений весьма сомнительны, ну и прочие, влияющие на производительность, вещи.
Методику расчёта оставил специально, чтобы не было вопросов.
Если честно, я ожидал худших результатов для П-П. А так… Даже почти близко.
Вы апологет ОПН — отлично.
Берём одинаковую формулу на входе; определяем инструмент (с вас и общедоступный); запускаем и обмениваемся результатами.
Ещё раз я в курсе еффективности алгоритмов на ОПН, в курсе что разные алгоритмы ОПН дадут разную производительность, предполагаю (отсутствует точная информация) что под ОПН на современном железе есть аппаратные и программные ускорители, не может не быть, поскольку живёт долго и является доминантой в направлении. Однако готов провести такой эксперимент. Вот только писать для ОПН — увольте.
Какие остались вопросы? В чём выразилось «слились»?
Время покажет.
Некорректно. У вас там нет комментариев что есть что, а бегать по всем вашим опусам желания не возникает. Укажите конкретно про что говорили и я посмотрю.
А про нос вам стоило бы быть осторожнее.
Ну и да, автор не препод. :)
Я нигде не предлагал перечеркнуть, нигде не предлагал «вместо». Я точно говорил о возникшем ощущении безальтернативности и мозголомности ОПН. То есть когда достаточно специализированная вещь является основой для курсовой у студентов, когда даже на Хабре я не увидел ничего кроме ОПН, не считая древовидных или рекурсивных решений, то меня как-то это несколько напрягло. Напрягло не просто так, а потому, что перед этим я поразбирался с ОПН. Так что это шло именно отсюда.
Нужно ли ОПН? — да. Надо ли его оставлять безальтернативным? — нет. Надо ли его вдавливать в молодые мозги? — нет. Вам же на вдалбливали в голову уравнения описывающие истечение газов из ракетного сопла и прочие специфические вещи. Хабр ресурс профессиональный, но не ограниченный. И на нём десятки статей С ОПН и ни одной реальной альтернативы (рекурсию и деревья не считаем).
Во-вторых, автор не старался ущемить алгоритмы на ОПН, мне не понравилось что в инфосфере присутствует доминанта ОПН. А особенно то, что эта доминанта присутствует в образовательном процессе в нашей системе образования. Считаю правильным, чтобы информация о реализациях на ОПН присутствовала в образовании, но так же считаю, что это не то, что надо безальтернативно вдалбливать в молодые мозги.
В процессе обсуждения выяснилось. что ОПН нужен в основном при написании компиляторов. Но компиляторами, насколько знаю, пишут не очень многие. А кто пишет, способен, при наличие базовой информации, сам при необходимости, разобраться с вопросом.
Время потраченное вами на реализацию с использованием ОПН не впечатлило.
Реализация у автора есть, на java.
Автор нигде не упоминает о большей эффективности его решения по отношению к ОПН, кроме сферы восприятия и обучения. Высказанные сомнения по поводу эффективности самого подхода посимвольного разбора присутствуют в силу перегруженности логики на этапе посимвольного разбора (подготовки к расчёту).
Пожалуй всё. надеюсь я снял ваши вопросы.
Хочу напомнить Вам такую фамилию как Циолковский. Попробуйте посмотреть не только его космические расчёты. Кстати, история публикации его работ достаточно интересна. Обратите внимание что я не употребил слово «научных».
Ну и сравнения производятся, как правило при одинаковом входе и одинаковым требуемом результате.
Появление вещественных чисел с длиной > 1 добавляет участника (буфер сборки чисел из цифр). логику, связанную с формированием чисел, дополнительные перемещения символов между участниками. При появлении в числе разделителя дробной части, появляется дополнительные логика и сравнения.
Ну как же ОПН нет? А в какой нотации тогда строится постфиксная запись?
То есть это уже не скобки? Не встречал алгоритмов преобразования в ОПН, которые бы пропустили такую ситуацию.
Я как-то и задал вопрос. поскольку мне показалось что по приведённому вами критерию конечная формула написанная вами не проходит, хотя инфиксная исходная форма корректна. Проверил ещё раз — не проходит: операндов 16 (без (-1), а операций только 13. Вопрос не в том, что Вы ошиблись — вопрос в том, что контроль постфиксной записи человеком очень затруднён, особенно на этапах начального изучения ОПН.
Насколько я помню, сейчас лень искать, вы утверждали что для полного цикла обработки инфиксной записи до получения результата необходим только один стек и более ничего не надо. Выражение, преобразованное вами ранее, так понимаю, лежит в одном стеке. вопрос и был о том как работая с одним стеком (LIFO) произвести выемку двух операндов для операции, которая лежит на вершине стека. Если никаких выражений в стеке не лежит, то что там лежит, куда делось выражение, ведь у нас больше ничего нет кроме стека?
Пока не выяснили, по прежнему считаю что посимвольный разбор строки с большим количеством логики на длинных сложных формулах не обладает очевидной эффективностью.
Всё можно реализовать уже существующими способами. Развитие идёт тогда, когда начинают, по той или иной причине, искать альтернативные пути.
Это означает. что в скобки можно затолкнуть любой контекст. а не только математические знаки и цифры для формул. Как сказал выше, сейчас нет задач, которые бы нельзя было решить уже имеющимися средствами программирования. вопрос только соответствующих затрат.
Это решит будущее. А для школьников это понятный элемент конструктора, который не ломает мозги и позволяет решать задачи связанные с разбором и вычислением формул. Чем они сейчас на уроках информатики занимаются — конструкторы собирают. Главное здесь — не ломать мозги.
Он и решил задачу для которой был предназначен. Причём полностью и без тяжёлых последствий воздействия ОПН на голову и психику. А то, что я не рассматривал возможности применения в сфере промышленного программирования — это вопрос второй или дальше.