"Abort Evaluation" does not work
ben
I am running Mathematica 6.0 for Windows and experience continuous
trouble with
"Abort Evaluation".
When I evoke a statement with incorrect syntax, Mathematica does not
show any error message but rather keeps
computing forever. Choosing "Abort Evaluation" in such a case does not
work.
My only resort is to kill the whole kernel.
Has anybody any idea what is going wrong?
Thanks
Ben
Themis Matsoukas
i = 1;
While[i <= Infinity, ++i]
..but this loop does not:
i = 1;
While[i < 1000, Print[i]; ++i]
Themis
7.0 for Mac OS X x86 (64-bit) (November 11, 2008)
Sseziwa Mukasa
On Aug 18, 2010, at 7:07 AM, Themis Matsoukas wrote:
> I was hoping someone would answer your question because I too find 'Abort Evaluation' to work erratically. For example, the loop below responds to ' Abort Evaluation':
>
> i == 1;
> While[i <== Infinity, ++i]
>
> ..but this loop does not:
>
> i == 1;
> While[i < 1000, Print[i]; ++i]
As far as I can tell abort only works on kernel operations that are designed to be interruptible. In the first case, the expression is constantly evaluating in the kernel and when it receives the abort message it quits. In the second case, the kernel probably takes almost no time computing, but the front end has to format 1000 strings. So when you are submitting the abort command it is actually trying to abort a front end operation: formatting the strings, which cannot happen. It is also the case that Mathlink routines that don't check the abort messages while computing will not respond to the abort command, some built-in functions seem to have the same behavior.
Regards,
Sseziwa
Bill Rowe
>I was hoping someone would answer your question because I too find
>'Abort Evaluation' to work erratically. For example, the loop below
>responds to 'Abort Evaluation':
>i = 1; While[i <= Infinity, ++i]
>..but this loop does not:
>i = 1; While[i < 1000, Print[i]; ++i]
I would have expected things to be just the other way around but
wouldn't have thought to try either of these if there was a
difference. But deliberately creating a loop that doesn't
respond to Abort Evaluation isn't really something I want to do.
But you post does make me wonder why things behave this way.
Perhaps there is some level of error trapping present. It would
be easy for a syntax checker to see a test checking a loop
counter to be less than infinity will always be true. Suppose
the first test were changed to
i = 1; While[i < 1000, i--]
It would still be an infinite loop but not so obvious as
comparing i and infinity. Perhaps, this change makes a
difference in the response to Abort Evaluation. And do note, I
am speculating here rather than testing this.
Simon
I think the example you showed does respond to Abort Evaluation, the
only problem is that the frontend has already queued up a lot of
Prints that take time to perform... This becomes clear if you put a
Pause[1] in the loop.
Themis Matsoukas
> this way.
As Simon and Seeziwa explained, the loop
i = 1;
While[i < 1000, Print[i]; ++i]
does respond to 'Abort Evaluation' (but in a way that leaves the user wondering): it breaks the loop but it does not interrupt the printing of the i's that have been queued to the output. In this particular example, the loop is executed very fast (too fast to Abort during its evaluation) while printing, which takes much longer, does not respond to Abort and so it goes on till completion, leaving the impression that nothing was aborted.
The question then is, would it be too difficult for Mathematica to implement an abort that kills the Print? When I debug I make liberal use of Print statements and sometimes I do run into this problem of runaway printing that I cannot Abort.
Themis
AES
Themis Matsoukas <tmats...@me.com> wrote:
> As Simon and Seeziwa explained, the loop
> does respond to 'Abort Evaluation' (but in a way that leaves the user
> wondering): it breaks the loop but it does not interrupt the printing of the
> i's that have been queued to the output. In this particular example, the loop
> is executed very fast (too fast to Abort during its evaluation) while
> printing, which takes much longer, does not respond to Abort and so it goes
> on till completion, leaving the impression that nothing was aborted.
>
> The question then is, would it be too difficult for Mathematica to implement
> an abort that kills the Print? When I debug I make liberal use of Print
> statements and sometimes I do run into this problem of runaway printing that
> I cannot Abort.
Many, many of us have of course run into the same problem.
So, another question would be: if you look up "Abort" in Mathematica's
documentation, will it give you a little warning about this, so you'll
understand what's happening?
Wanna bet?
[Scroll down a screen or so to see what the "Additional Information"
section at the top of the Abort Help page says.]
You can call Abort anywhere within a computation. It has the same effect
as an interactive interrupt in which you select the abort option.
You can use Abort as an "emergency stop" in a computation.
Once Abort has been called, Mathematica functions currently being
evaluated return as quickly as possible.
In an interactive session, the final result from an aborted computation
is $Aborted.
You can use CheckAbort to "catch" returns from an abort.
Bill Rowe
>Many, many of us have of course run into the same problem.
>So, another question would be: if you look up "Abort" in
>Mathematica's documentation, will it give you a little warning about
>this, so you'll understand what's happening?
>Wanna bet?
Arguably, this characteristic of Abort is documented in the
documentation. At the bottom of the documentation page for Abort
under Tutorials is "Interrupts and Aborts" a clickable link that
brings up more information. Part of that tutorial reads:
The function Abort[] has the same effect as interrupting a
computation, and selecting the abort option in the interrupt menu.
What is not said is computations are done in the kernel not the
front end. That information is elsewhere. Armed with the
information computations are done by the kernel, it should be
apparent, Abort stops the kernel not the front end. And that
clearly implies anything already sent to the front end to
display will be unaffected by using Abort.
There are improvements that can be made to the documentation.
But, it is clearly impractical for the documentation for each
individual command to be stand alone documentation that covers
all aspect of that command without needing to look at any other
documentation for Mathematica. A direct consequence of this is
users unfamiliar with Mathematica will not have a complete
understanding of a command by reading just the documentation
page for that command.
David Bailey
>
> There are improvements that can be made to the documentation.
> But, it is clearly impractical for the documentation for each
> individual command to be stand alone documentation that covers
> all aspect of that command without needing to look at any other
> documentation for Mathematica.
>
A little while ago, someone suggested that WRI should implement a way
for users (maybe authorised) to add additional useful commentary to the
help system. I think this would be a really great way to feed back
discussions like this to every Mathematica user.
David Bailey
David Park
Information note on the Abort page (where new users might logically look):
"Abortion of an evaluation may be effectuated from the Evaluation Menu. This
aborts Kernel evaluation but does not stop any pending Front End
processing."
David Park
djm...@comcast.net
http://home.comcast.net/~djmpark/
From: Bill Rowe [mailto:read...@sbcglobal.net]
There are improvements that can be made to the documentation.
But, it is clearly impractical for the documentation for each
individual command to be stand alone documentation that covers
all aspect of that command without needing to look at any other
Uayeb
incarnation. Since a lot of my work involves large (several megabytes)
arrays of real numbers, usually astronomy images or 3D datacubes,
occasionally I make an error in typing a command in. Mathematica's
default response of simply printing the input form of what you gave it
when it doesnt understand means that the front end is suddenly asked
to format ten's or even hundreds of MB of numbers. I often realise my
mistake as soon as I see the pause, but of course "Abort..." is
useless. Unfortunately, as often as not, the front end simply crashes,
and I must hope that I've saved (since automatic saving/backups, also
discussed recently, doesn't exist).
I would really like to see a feature added which allows one to
interupt/cancell the work being done by the Front End, not just
Print[] statements.
Cheers,
Andy Green
Swinburne University
On Aug 20, 9:10 pm, Themis Matsoukas <tmatsou...@me.com> wrote:
> > But you post does make me wonder why things behave
> > this way.
>
> As Simon and Seeziwa explained, the loop
>
> i = 1;
> While[i < 1000, Print[i]; ++i]
>
> does respond to 'Abort Evaluation' (but in a way that leaves the user won=
dering): it breaks the loop but it does not interrupt the printing of the i=
's that have been queued to the output. In this particular example, the loo=
p is executed very fast (too fast to Abort during its evaluation) while =
printing, which takes much longer, does not respond to Abort and so it goes=
on till completion, leaving the impression that nothing was aborted.
>
> The question then is, would it be too difficult for Mathematica to implem=
ent an abort that kills the Print? When I debug I make liberal use of Print=
statements and sometimes I do run into this problem of runaway printing th=
at I cannot Abort.
>
> Themis
Sjoerd C. de Vries
the kernel can be aborted I can't see a reason why the Front End
couldn't be either. FE: Just drop everything you're doing, don't
display any new stuff, just give me the prompt line ASAP.
Cheers -- Sjoerd
On Aug 23, 8:40 am, "David Park" <djmp...@comcast.net> wrote:
> True, but still this is a common experience and WRI could easily add a More
> Information note on the Abort page (where new users might logically look):
>
> "Abortion of an evaluation may be effectuated from the Evaluation Menu. This
> aborts Kernel evaluation but does not stop any pending Front End
> processing."
>
> David Park
> djmp...@comcast.nethttp://home.comcast.net/~djmpark/