Этот топик читают: Гость
Гость
Ответов: 17029
Рейтинг: 0
|
|||
Редактировалось 1 раз(а), последний 2017-03-04 23:42:58 |
|||
карма: 0 |
|
Администрация
Ответов: 15295
Рейтинг: 1519
|
|||
Именно так. Однако в новом пакете все будет с точностью до наоборот...
|
|||
карма: 26 |
|
Гость
Ответов: 17029
Рейтинг: 0
|
|||
Редактировалось 1 раз(а), последний 2017-03-04 23:42:58 |
|||
карма: 0 |
|
Администрация
Ответов: 15295
Рейтинг: 1519
|
|||
Это в том, который будет основан на потоковой кодогенерации. Там MathParse будет такой как сейчас в пакете WEB.
|
|||
карма: 26 |
|
Ответов: 9906
Рейтинг: 351
|
|||
Dilma писал(а): Именно так. Однако в новом пакете все будет с точностью до наоборот...1) неправда в любом случае. 2) если используется doMathStr - это в любом случае парсинг |
|||
карма: 9 |
|
Администрация
Ответов: 15295
Рейтинг: 1519
|
|||
Galkov писал(а): если используется doMathStr - это в любом случае парсингНе будет такой точки у MathParse. Поскольку элементы функционально полностью эквивалентны, то смысла в их паралельном сосуществование нет. |
|||
карма: 26 |
|
Ответов: 9906
Рейтинг: 351
|
|||
Ну-ну.
Вот только сначала парсинг, а потом вычисления - тоже оптимальней, чем всегда парсинг |
|||
карма: 9 |
|
Администрация
Ответов: 15295
Рейтинг: 1519
|
|||
Мне думается, что количество программ, которым после компиляции нужно на лету вычислять формулы пренебрежительно мало по сравнению с теми, в которых просто требуется написать формулу в удобочитаемом виде. Я веду к тому, что генерация по шаблону в числе прочих своих достоинст еще ко всему прочему предоставляет совершенно простую возможность реализовать такие компоненты как MathParse и StringBuilder с нулевыми затратами производительности конечного приложения.
|
|||
карма: 26 |
|
Ответов: 9906
Рейтинг: 351
|
|||
Dilma писал(а): Я веду к тому, что генерация по шаблону в числе прочих своих достоинст А чего к этому вести - это и так понятно Dilma писал(а): Мне думается, что количество программ, которым после компиляции нужно на лету вычислять формулы пренебрежительно малоИ что теперь... А если надо У меня к примеру свой формульный калькулятор. Для чего еще надо - не знаю. Но причин ликвидации парсера как элемента - недостаточно как-то. |
|||
карма: 9 |
|
Гость
Ответов: 17029
Рейтинг: 0
|
|||
Редактировалось 1 раз(а), последний 2017-03-04 23:42:58 |
|||
карма: 0 |
|
Ответов: 16884
Рейтинг: 1239
|
|||
Dilma писал(а): предоставляет совершенно простую возможность реализовать такие компоненты как MathParse и StringBuilder с нулевыми затратами производительности конечного приложения.Реклама циркониевого браслета писал(а): После того, как я начал носить этот браслет, у меня совсем пропало давлениеПоподробнее можно? Насчет нулевых затрат производительности |
|||
карма: 25 |
|
Администрация
Ответов: 15295
Рейтинг: 1519
|
|||
имеется ввиду конечно же затраты производительности связанные с превращением схемы hiasm в код PHPjavascriptHTML. Реальная производительность конечного приложения зависит от компьютера, от корректности схемы и прочих не поддающихся никакому анализу и предсказанию факторов.
[size=-2]------ Добавлено в 18:18 Galkov писал(а): Но причин ликвидации парсера как элемента - недостаточно как-то.Парсера два. Причем один медленнее работает чем другой имея туже ф-ность. Чем не причина? v112.sh писал(а): а что такое StringBuilderЭлемент пакета WEB. Нечто вроде FormatString, но выполняемый на этапе кодогенерации |
|||
карма: 26 |
|
12