MathGroup Archive 2008

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Looking for Stop

  • To: mathgroup at
  • Subject: [mg93127] Re: Looking for Stop
  • From: Albert Retey <awnl at>
  • Date: Mon, 27 Oct 2008 03:14:29 -0500 (EST)
  • References: <gdugb5$jq8$>


> Mathematica has two termination commands:
>    Abort[]  interrupts a computation
>    Exit[] or Quit[]   returns control to OS
> I use Exit[] in some course-distributed application programs
> that detect an irrecoverable error requiring user intervention
> and program changes. This has an undesirable side effect:
> all cells containing support modules have to be reinitialized.
> Abort[] does not have that effect; however it doesnt stop
> execution of whatever follows.

I think you should understand that Quit or Exit do not only _stop_ the
kernel in what it does, they exit/quit the kernel process. When you
start the next evaluation, the frontend will start a new kernel and that
of course needs to be initialized.

> Is there a command "in between" that stops kernel
> execution but leaves cells initialized? Constraint:
> it has to work with versions >=4.1.  I looked for
> Stop[] but there isnt such a thing under versions 4 or 5.

Actually from the kernel point of view Abort[] is doing exactly that.
Your problem seems to be that once the kernel aborts the evaluation of
one cell, the frontend will send it the next cell in its evaluation
queue for evaluation. The kernel presumably doesn't know that this
already was in the frontend's queue before the Abort[], so it will just
treat it as any other evaluation that it will get from the frontend
after an Abort[]. I think this makes clear that it is not the kernel
that you need to manipulate, it is the frontend that needs to be
informed that it should abort the command _and_ clear its evaluation
queue. I just played around a little bit and think what you want can be
done with:


but note that the frontend token "EvaluatorAbort" is marked as "not
fully integrated yet", so it may change or go away. Also I have found
some oddities after using it: the very next evaluation sometimes
(always?) still returns $Aborted and only the second next will behave as
usual. So you need to check whether that is o.k. for you. If not, you
could go the hard way and do some FrontEnd-Programming to first remove
all cells from the evaluation queue (select all cells, call
"RemoveFromEvaluationQueue") before you call a Kernel-Abort.

That said, I share the opinion of Jens that to produce robust code you
really need to start early, and the decision to supply code in form of a
Notebook that has to be evaluated from top to bottom is probably where
you should start, because that approach has several problems when the
notebooks is given away to users not familiar with your code and/or
mathematica. You can do everything that can be done that way with one
function definition, that will produce the various output that otherwise
the cells in your notebook would create. When calling just one function
from one cell an Abort[] works as you want, and several other
possibilities like Catch/Throw give you even more control about how to
react to unexpected results. And when the desire arises, you can build a
gui for that function with Manipulate or the other Dynamic stuff...



  • Prev by Date: Re: Re: Function pure for Select
  • Next by Date: Hypergeometric2F1
  • Previous by thread: Re: Looking for Stop
  • Next by thread: Re: Looking for Stop