Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change "FAILURE" message to something not so accusatory #250

Open
Vaguery opened this issue Feb 10, 2018 · 3 comments
Open

Change "FAILURE" message to something not so accusatory #250

Vaguery opened this issue Feb 10, 2018 · 3 comments

Comments

@Vaguery
Copy link
Contributor

Vaguery commented Feb 10, 2018

Sheesh. Show some empathy, Clojush.

I'M SORRY I WAS UNABLE TO DO THIS or maybe TRY AGAIN!

@Vaguery
Copy link
Contributor Author

Vaguery commented Feb 13, 2018

Let me temper this: The default behavior should be to pause and wait for keyboard input asking for continuation at the "end" of the assigned number of generations.

That is, if I do 200 generations and want to continue (because things are improving at the moment it stops) I would prefer to be able to continue right then, rather than re-launching with the same PRNG keys and a larger limit.

When Clojush launches now, what is being launched is clearly a process or long-running system. It seems terribly wasteful to kill it preemptively this way.

It should pause and ask something like (Carry on for another N generations? [y][n].

And of course you can have a configuration option that suppresses this behavior and provides the current (frustrating) behavior, for backwards-compatibility.

@lspector
Copy link
Owner

lspector commented Feb 13, 2018

Boy I miss Common Lisp. There, we could end with (break) and you'd get what you want and more for free (e.g. type (continue) to continue, but also execute anything else to inspect or change the state before continuing).

In Clojure I guess we'd have two options:

  • Put something like our own break loop at Clojush's top level, hanging waiting for input to continue or terminate once the generation limit has been reached.

  • Terminate but save enough information to restart later in the same state.

I believe that @thelmuth has done the second of these, but I don't know if the code for that is in the main repository or how to invoke it.

If we implement the first option then we'd want it to be conditional (as you suggest), because we often do large numbers of runs that we want to fully terminate without further intervention when they hit the generation limit. But if we set it up right then I can see it'd be nice to be able to run in a mode that allows for continuation.

FWIW when I conduct runs that I think I may want to let go on for many generations, I just launch them with something like :max-generations 100000, watch them as they run (by grepping the log), and kill them when I don't think they have any more to tell me. Of course, if I still want to run them longer after 100000 generations, then I'd be in trouble. But that hasn't happened yet, and if I thought it was likely then I might used a limit like 1000000000000000 or whatever.

@thelmuth
Copy link
Collaborator

I'm curious why @Vaguery doesn't just use @lspector's last suggestion of setting :max-generations to a Very Large Number? Why have a max generations if you might want to keep going?

Terminate but save enough information to restart later in the same state.

I have done this, once, for an experiment, in a very hacky way. It would not be a bad idea to implement this more generally, but I wouldn't necessarily recommend taking what I've done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants