Am 23.10.2014 um 22:06 schrieb James Crist:
What's "composable" in this context?
Easy to write without intruding too much into the actual function.
OK
That would not affect SymPy itself, as it is not multithreaded.
No, but it would affect anything that tried to run sympy functions that use
this in a separate thread.
Yep, I'm aware of that.
Given Python's generally weak support for multithreading, I don't see
that as a real shortcoming of SymPy though.
(I am aware that some Python implementations address that specifically.)
It should work without a problem under Windows - there's no mention that
signal.alarm() does not work on any platform.
From the python documentation: "On Windows, signal()
<https://docs.python.org/2/library/signal.html#module-signal> can only be
called with SIGABRT, SIGFPE, SIGILL, SIGINT, SIGSEGV, or SIGTERM. A
ValueError
<https://docs.python.org/2/library/exceptions.html#exceptions.ValueError>
will be raised in any other case." To use `signal.alarm`, you need to call
signal with `SIGALRM`, which is not supported. The test suite is run on
travis, which uses ubuntu, so it works there fine.
Okay, I overlooked that.
Funny that nobody has complained that --timeout doesn't work on Windows.
(Or maybe I overlooked those complaints.)
It's quite intrusive.
It's also going to be broken with every new algorithm, because people
will (rightly) concentrate on getting it right first.
I don't think it's that intrusive (especially with precomposed checking
functions).
Those add overhead - the function call count doubles.
I don't have numbers, but I suspect it's going to be measurable unless
very carefully tuned.
AND it needs to be very carefully retuned whenever the algorithm changes.
Sorry, but I'm seeing a lot of unaddressed mid-term risks here.
> It wouldn't have to be available for every function,
No, only those that are called very often.
I.e. exactly those where overhead can hurt.
Unless I see some benchmarks that discount that as utterly irrelevant,
I'm strictly -1 on this proposal.
> and
requires very little modification. In the last half hour I've almost
finished applying an example of it to `fu`. Didn't take long at all, and
requires only a few lines of code changed.
I can believe that, it's not hard to do.
I'm worried about the performance impact.
I wish there was a way to go about doing this without modifying any of the
logic code (simply decorating functions/using a context manager would be
ideal). But this doesn't seem to be possible in a crossplatorm/robust way.
I suspect it's entirely doable, and entirely within Python.
However, decorators aren't that easy to do. Plus they incur the same
kind of overhead.
I'm still wondering whether the problem you're solving is worth solving
at all. Sure it's annoying having to Ctrl-C the application
occasionally, but a mere annoyance isn't worth it IMNSHO.
I did write up a second option that used a decorator and a contextmanager,
but it assumes single-thread application (uses a global TIMEOUT variable :(
).
Yeah, it can be difficult and intrusive to thread state to subfunctions.
OTOH I doubt that this particular problem is tied to the decorator
approach; I'd be surprised if you don't have it in your normal code as
well. (It might be hidden because you're doing a simple case in your
testing, and the context manager solution would force you to full
generality.)
So... double-check whether your assumption about the decorator solution
is right.
(I see you tried it anyway.)
Note that SymPy should not depend on any globals.
There are a few cached values around, but these are either
not-initialized-yet or never-to-change-anymore - that's the harmless
variant of globals.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/544A972F.9010501%40durchholz.org.
For more options, visit https://groups.google.com/d/optout.
