Menu
▾
▴
1 Attachments
#94 redcls unresponsive in graphical mode for large output
I am using Reduce 4859. I tried to run Anthony Hearn's code from ACM SIGSAM 24, 14-15 (1972).
The only change I made was replacing "time" with showtime.
The phaseint(20) runs in redcsl in terminal (redcsl -w-) in 1920 ms + 330 ms GC (last step) (i7 3770, Linux), in redpsl in 2240 ms. However, in graphical mode (redcsl -w+), it becomes unresponsive, execution times grow rapidly. It completed finally in 239799 ms + 330 ms. Is this large difference normal?
A short update: with "off nat;" it is just slightly slower than in text mode (2230 ms + 340 ms GC).
Last edit: arpi 2019-02-19
Can you please email me a copy of your input test script so I do not need
to hunt for a copy of the paper that you cite? Thanks. Arthur
On Tue, 19 Feb 2019, Ari wrote:
Related
Bugs: #94
Thank you for this (and for the copy of the code you emailed). This is of
course horrid!
The simpler case of merely "(1-x)^1000;" is unsatisfactory too. Given that
the GUI version is multithreaded the obvious way for me to identify just
where it gums up does not work for me (and my first guess where to look
was in deed of improvement but was not the main blockage).
You can not readily read that many pages of displayed math fron the screen
- the coding there was sort of expecting that big calculations would be
done in a batch mode via a tarminal and small ones interactively via the
GUI. With compoters having got faster by a LARGE factor in the 20 years
since that code was mapped out the meaning of "big" has changed!
I will keep looking. It is liable to be some bif of the code that has
costs that grow quadratically with expression size where they could do a
lot better! And it is in the C++ code that unpicks the TeX-like stuff that
Reduce generates to send to the GUI.
With the latest release (4956), the execution of
phaseint 20;
is reasonably fast. However, scrolling the result up and down (in the csl graphical version) resulted in a crash.