Joonas Liik wrote:
https://docs.python.org/2/library/sys.html#sys.setrecursionlimit
so as per the docs the programmer has no real control over how much
stack his program can have. all you can say is let me ignore the
safeguard a little longer, i hope i wont crash the program that is
not the same
On 07/14/2015 07:48 PM, Steven D'Aprano wrote:
On Wed, 15 Jul 2015 03:29 am, Marko Rauhamaa wrote:
Chris Angelico ros...@gmail.com:
On Tue, Jul 14, 2015 at 11:38 PM, Marko Rauhamaa ma...@pacujo.net
wrote:
No, tail call optimization doesn't change the behavior of the
program, for the worse
Gregory Ewing greg.ew...@canterbury.ac.nz:
A tail call *is* a goto. That's how you implement one in assembly
language -- you write a jump instruction instead of a call
instruction. The jump doesn't have to be to the same function.
In functional programming languages you might not even have a
On 07/15/2015 02:41 AM, Terry Reedy wrote:
On 7/14/2015 10:02 AM, Antoon Pardon wrote:
On 07/14/2015 03:43 PM, Chris Angelico wrote:
On Tue, Jul 14, 2015 at 11:38 PM, Marko Rauhamaa ma...@pacujo.net
wrote:
No, tail call optimization doesn't change the behavior of the program,
for the worse
Chris Angelico wrote:
I'm still interested in the explicit replace current stack frame with
this call operation. Calling it goto seems wrong, as most languages
with goto restrict it to _within_ a function,
This just suggests to me is that most language designers
are not very imaginative. :-)
Gregory Ewing greg.ew...@canterbury.ac.nz:
Marko Rauhamaa wrote:
It might even be tail-call optimized by Python. Only you can't count
on it because the language spec doesn't guarantee it.
The language spec might permit it, but the BDFL has explicitly
expressed a dislike for the idea of
On Wednesday, July 15, 2015 at 2:44:55 AM UTC-4, Marko Rauhamaa wrote:
Gregory Ewing greg.ew...@canterbury.ac.nz:
Marko Rauhamaa wrote:
It might even be tail-call optimized by Python. Only you can't count
on it because the language spec doesn't guarantee it.
The language spec might
On Wednesday, July 15, 2015 at 6:56:10 AM UTC-4, Marko Rauhamaa wrote:
Ned Batchelder n...@nedbatchelder.com:
On Wednesday, July 15, 2015 at 2:44:55 AM UTC-4, Marko Rauhamaa wrote:
The other problem for tail call elimination is the requirement that
functions return None by default. Smooth
On 07/15/2015 12:55 PM, Marko Rauhamaa wrote:
Ned Batchelder n...@nedbatchelder.com:
On Wednesday, July 15, 2015 at 2:44:55 AM UTC-4, Marko Rauhamaa wrote:
The other problem for tail call elimination is the requirement that
functions return None by default. Smooth tail call elimination would
On 15/07/2015 10:13, Gregory Ewing wrote:
Chris Angelico wrote:
I'm still interested in the explicit replace current stack frame with
this call operation. Calling it goto seems wrong, as most languages
with goto restrict it to _within_ a function,
This just suggests to me is that most
Ned Batchelder n...@nedbatchelder.com:
On Wednesday, July 15, 2015 at 6:56:10 AM UTC-4, Marko Rauhamaa wrote:
Ned Batchelder n...@nedbatchelder.com:
I don't understand this, can you explain more? Are you saying that the
Python specification shouldn't specify what x becomes?:
def
Ned Batchelder n...@nedbatchelder.com:
On Wednesday, July 15, 2015 at 2:44:55 AM UTC-4, Marko Rauhamaa wrote:
The other problem for tail call elimination is the requirement that
functions return None by default. Smooth tail call elimination would
require that Python leave the default return
On 2015-07-15 12:22, Mark Lawrence wrote:
On 15/07/2015 10:13, Gregory Ewing wrote:
Chris Angelico wrote:
I'm still interested in the explicit replace current stack frame with
this call operation. Calling it goto seems wrong, as most languages
with goto restrict it to _within_ a function,
Chris Angelico wrote:
Which really says that TCO is impossible if you have any sort of
clean-up or deallocation to be done after the call begins. The only
way to truly turn your tail call into a GOTO is to do all your cleanup
first.
Indeed. In compilers that implement TCO, there's quite
a lot
Mark Lawrence wrote:
IIRC the realms of the C setjmp and longjmp.
Not really the same thing. A longjmp chops the stack
back, whereas a tail call avoids putting something on
the stack to begin with.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Antoon Pardon wrote:
But it doesn't need to be all or nothing. How about the following possibility.
When the runtime detects a serie of tail calls, it will keep the bottom three
and the top three backtrace records of the serie.
Whatever value you choose for N, keeping only the
first/last N
On 15/07/2015 23:34, Gregory Ewing wrote:
Mark Lawrence wrote:
IIRC the realms of the C setjmp and longjmp.
Not really the same thing. A longjmp chops the stack
back, whereas a tail call avoids putting something on
the stack to begin with.
Thanks for that :)
--
My fellow Pythonistas, ask
On Wed, Jul 15, 2015 at 10:00 PM, MRAB pyt...@mrabarnett.plus.com wrote:
On 2015-07-15 12:22, Mark Lawrence wrote:
On 15/07/2015 10:13, Gregory Ewing wrote:
Chris Angelico wrote:
I'm still interested in the explicit replace current stack frame with
this call operation. Calling it goto
On Wed, Jul 15, 2015 at 7:13 PM, Gregory Ewing
greg.ew...@canterbury.ac.nz wrote:
Chris Angelico wrote:
I'm still interested in the explicit replace current stack frame with
this call operation. Calling it goto seems wrong, as most languages
with goto restrict it to _within_ a function,
On Tue, Jul 14, 2015 at 11:27 AM, Marko Rauhamaa ma...@pacujo.net wrote:
Ian Kelly ian.g.ke...@gmail.com:
On Tue, Jul 14, 2015 at 2:33 AM, Marko Rauhamaa ma...@pacujo.net wrote:
The programmer shouldn't be controlling tail call optimizations.
The programmer controls it regardless.
Ian Kelly ian.g.ke...@gmail.com:
On Tue, Jul 14, 2015 at 11:27 AM, Marko Rauhamaa ma...@pacujo.net wrote:
You'll see that the generated code is tail-call-optimized.
This can't be done generally, though. What if, instead of a local
variable, the assignment were to a dict item? Even if the
Gregory Ewing greg.ew...@canterbury.ac.nz:
Marko Rauhamaa wrote:
How about return?
How about goto? :-)
That's not entirely an unserious suggestion -- if you
really believe that a goto with arguments is a good
feature for a language to have, you shouldn't be
afraid to spell it as such.
Ian Kelly ian.g.ke...@gmail.com:
On Mon, Jul 13, 2015 at 11:25 PM, Chris Angelico ros...@gmail.com wrote:
(Also, side point: Python can't actually optimize the above function,
because it actually means call quicksort, then discard its return
value and return None. A true tail call has to
Marko Rauhamaa wrote:
Ian Kelly ian.g.ke...@gmail.com:
Another point in favor of an explicit tail-call keyword. Then one
couldn't make that mistake.
How about return?
How about goto? :-)
That's not entirely an unserious suggestion -- if you
really believe that a goto with arguments is a
On 07/14/2015 05:20 AM, Steven D'Aprano wrote:
On Tue, 14 Jul 2015 12:05 am, Chris Angelico wrote:
If you want to make an assertion that iterative
code requires equivalent warping to tail-recursive code, I want to see
an example of it. Is that difficult?
Of course it is. If it wasn't
On 14/07/2015 07:29, Gregory Ewing wrote:
Marko Rauhamaa wrote:
Ian Kelly ian.g.ke...@gmail.com:
Another point in favor of an explicit tail-call keyword. Then one
couldn't make that mistake.
How about return?
How about goto? :-)
Why not goto? It's use is scattered throughout the
On Tue, Jul 14, 2015 at 1:26 AM, Antoon Pardon
antoon.par...@rece.vub.ac.be wrote:
On 07/14/2015 05:20 AM, Steven D'Aprano wrote:
On Tue, 14 Jul 2015 12:05 am, Chris Angelico wrote:
If you want to make an assertion that iterative
code requires equivalent warping to tail-recursive code, I want
On 07/14/2015 10:34 AM, Ian Kelly wrote:
On Tue, Jul 14, 2015 at 1:26 AM, Antoon Pardon
antoon.par...@rece.vub.ac.be wrote:
I expect any example given, to be used as a contest by those reading,
for finding
the least warped alternative and then using that to dismiss the example.
So I really
On Mon, Jul 13, 2015 at 11:57 PM, Marko Rauhamaa ma...@pacujo.net wrote:
Ian Kelly ian.g.ke...@gmail.com:
On Mon, Jul 13, 2015 at 11:25 PM, Chris Angelico ros...@gmail.com wrote:
(Also, side point: Python can't actually optimize the above function,
because it actually means call quicksort,
Ian Kelly ian.g.ke...@gmail.com:
On Mon, Jul 13, 2015 at 11:57 PM, Marko Rauhamaa ma...@pacujo.net wrote:
How about return?
I think you miss my point entirely. return doesn't mean tail-call
optimize;
Why not?
it just means to return the result.
Same difference.
This is what led to the
Chris Angelico ros...@gmail.com:
Done explicitly like this, it avoids the problem of bad tracebacks,
because by definition you would use it only when you want the current
stack frame to be dropped. I wonder how hard it would be to hack this
into CPython... Anyone feel like tackling it?
I
On Tue, Jul 14, 2015 at 2:33 AM, Marko Rauhamaa ma...@pacujo.net wrote:
Ian Kelly ian.g.ke...@gmail.com:
On Mon, Jul 13, 2015 at 11:57 PM, Marko Rauhamaa ma...@pacujo.net wrote:
How about return?
I think you miss my point entirely. return doesn't mean tail-call
optimize;
Why not?
it
On Tue, Jul 14, 2015 at 3:41 PM, Paul Rubin no.email@nospam.invalid wrote:
Chris Angelico ros...@gmail.com writes:
That's a prime example of recursion... but not of recursion that can
be tail-call optimized into iteration. It's an example of forking
recursion, where one call can result in
Chris Angelico ros...@gmail.com:
On Tue, Jul 14, 2015 at 3:41 PM, Marko Rauhamaa ma...@pacujo.net wrote:
Tail-call optimization has nothing to do with converting algorithms into
iterations. It's a prosaic trick of dropping an unneeded stack frame
before making a function call.
The claim
On Tue, Jul 14, 2015 at 10:28 PM, Marko Rauhamaa ma...@pacujo.net wrote:
Chris Angelico ros...@gmail.com:
Done explicitly like this, it avoids the problem of bad tracebacks,
because by definition you would use it only when you want the current
stack frame to be dropped. I wonder how hard it
On Tue, Jul 14, 2015 at 3:41 PM, Marko Rauhamaa ma...@pacujo.net wrote:
Tail-call optimization has nothing to do with converting algorithms into
iterations. It's a prosaic trick of dropping an unneeded stack frame
before making a function call.
The claim that TCO means you don't need stack
On Tue, Jul 14, 2015 at 11:38 PM, Marko Rauhamaa ma...@pacujo.net wrote:
Chris Angelico ros...@gmail.com:
On Tue, Jul 14, 2015 at 10:28 PM, Marko Rauhamaa ma...@pacujo.net wrote:
I would rather optimize by default and disable optimizations with
--debug or equivalent.
That assumes that it's
On 2015-07-14, Ian Kelly ian.g.ke...@gmail.com wrote:
And yet, Python somehow manages to gain new features with each release.
The reason why most proposals get rejected is because most proposals
are bad. If every idea that came along just got accepted, we'd have a
disastrous hodge-podge of a
On 07/14/2015 03:43 PM, Chris Angelico wrote:
On Tue, Jul 14, 2015 at 11:38 PM, Marko Rauhamaa ma...@pacujo.net wrote:
Chris Angelico ros...@gmail.com:
On Tue, Jul 14, 2015 at 10:28 PM, Marko Rauhamaa ma...@pacujo.net wrote:
I would rather optimize by default and disable optimizations with
Chris Angelico ros...@gmail.com:
On Tue, Jul 14, 2015 at 10:28 PM, Marko Rauhamaa ma...@pacujo.net wrote:
I would rather optimize by default and disable optimizations with
--debug or equivalent.
That assumes that it's simply an optimization. This is a distinct
semantic change.
No, tail
On Wed, Jul 15, 2015 at 12:02 AM, Antoon Pardon
antoon.par...@rece.vub.ac.be wrote:
On 07/14/2015 03:43 PM, Chris Angelico wrote:
On Tue, Jul 14, 2015 at 11:38 PM, Marko Rauhamaa ma...@pacujo.net wrote:
Chris Angelico ros...@gmail.com:
On Tue, Jul 14, 2015 at 10:28 PM, Marko Rauhamaa
On Wed, 15 Jul 2015 03:43 am, Marko Rauhamaa wrote:
The problem there is in the C standard, not the compiler that complies
with the standard.
I don't like the way integer overflows are explicitly undefined in
modern C.
Similarly, I don't like the way tail call behavior is undefined in
Chris Angelico ros...@gmail.com:
Tail call elimination is necessary to cope with a system of
programming that has deliberately excluded certain other options (eg
mutables, in pure functional languages),
Tail call elimination is necessary for the functional programming style.
While Scheme
On 7/14/2015 10:02 AM, Antoon Pardon wrote:
On 07/14/2015 03:43 PM, Chris Angelico wrote:
On Tue, Jul 14, 2015 at 11:38 PM, Marko Rauhamaa ma...@pacujo.net wrote:
No, tail call optimization doesn't change the behavior of the program,
for the worse anyway.
It does, because you lose traceback
I think I'm beginning to understand. Tail call elimination is
necessary to cope with a system of programming that has deliberately
excluded certain other options (eg mutables, in pure functional
languages),
Tail recursion is the functional way to write a while loop. To put is
another way, a
On 15/07/2015 00:40, Mark Lawrence wrote:
On 13/07/2015 23:46, Terry Reedy wrote:
Optimizing specific tail calls is tricker. For one thing, calls to a
recursion-replacement function, such as recur, add a stack frame that
must also be popped. A CPython bytecode manimpuation solution was given
On 7/14/2015 1:52 PM, Chris Angelico wrote:
On Wed, Jul 15, 2015 at 3:43 AM, Marko Rauhamaa ma...@pacujo.net wrote:
I don't like the way integer overflows are explicitly undefined in
modern C.
Similarly, I don't like the way tail call behavior is undefined in
Python.
Where in the Python spec
On Wed, Jul 15, 2015 at 11:01 AM, Terry Reedy tjre...@udel.edu wrote:
On 7/14/2015 1:52 PM, Chris Angelico wrote:
On Wed, Jul 15, 2015 at 3:43 AM, Marko Rauhamaa ma...@pacujo.net wrote:
I don't like the way integer overflows are explicitly undefined in
modern C.
Similarly, I don't like the
On 13/07/2015 23:46, Terry Reedy wrote:
Optimizing specific tail calls is tricker. For one thing, calls to a
recursion-replacement function, such as recur, add a stack frame that
must also be popped. A CPython bytecode manimpuation solution was given
years ago as a recipe on the ActiveState
On 7/14/2015 1:15 AM, Paul Rubin wrote:
def quicksort(array, start, end):
midp = partition(array, start, end)
if midp = (start+end)//2:
quicksort(array, start, midp)
quicksort(array, midp+1, end)
else:
quicksort(array, midp+1, end)
Marko Rauhamaa wrote:
It might even be tail-call optimized by Python. Only you can't count on
it because the language spec doesn't guarantee it.
The language spec might permit it, but the BDFL has
explicitly expressed a dislike for the idea of implicit
tail call removal, so it's unlikely to
Steven D'Aprano st...@pearwood.info:
Tail call behaviour is not undefined in Python. There is a strong
convention (followed by all implementations I know of) to follow the
reference implementation's (CPython) behaviour, which is not to
optimize tail calls. But even if an implementation
On Wed, Jul 15, 2015 at 4:37 AM, Marko Rauhamaa ma...@pacujo.net wrote:
Steven D'Aprano st...@pearwood.info:
Tail call behaviour is not undefined in Python. There is a strong
convention (followed by all implementations I know of) to follow the
reference implementation's (CPython) behaviour,
Ian Kelly ian.g.ke...@gmail.com:
On Tue, Jul 14, 2015 at 2:33 AM, Marko Rauhamaa ma...@pacujo.net wrote:
The programmer shouldn't be controlling tail call optimizations.
The programmer controls it regardless.
return foo() # TCO
result = foo() # No TCO
return result # No
Chris Angelico ros...@gmail.com:
On Tue, Jul 14, 2015 at 11:38 PM, Marko Rauhamaa ma...@pacujo.net wrote:
No, tail call optimization doesn't change the behavior of the
program, for the worse anyway.
It does, because you lose traceback records. That's pretty significant
when you come to try
Steven D'Aprano st...@pearwood.info writes:
Here's an example where an overzealous but standards-conforming optimization
introduced a security bug:
http://code.google.com/p/nativeclient/issues/detail?id=245
In that particular example, the refactored code simply looks wrong.
--
Chris Angelico ros...@gmail.com:
You're proposing making _every_ instance of return func(...) into
this kind of thing.
Yes.
That's not always recursion,
Correct.
and it's certainly not always clear what called what to get you there.
Correct.
Marko
--
On Tue, 14 Jul 2015 06:33 pm, Marko Rauhamaa wrote:
Ian Kelly ian.g.ke...@gmail.com:
On Mon, Jul 13, 2015 at 11:57 PM, Marko Rauhamaa ma...@pacujo.net
wrote:
How about return?
I think you miss my point entirely. return doesn't mean tail-call
optimize;
Why not?
Because then you lose
Steven D'Aprano st...@pearwood.info:
C, in my opinion, is the poster child for how a programming language
should NOT be designed, and I don't want Python to go down the same
path. John Regehr writes:
... there are compilers (like GCC) where integer overflow behaved a
certain way for many
On Wed, 15 Jul 2015 03:29 am, Marko Rauhamaa wrote:
Chris Angelico ros...@gmail.com:
On Tue, Jul 14, 2015 at 11:38 PM, Marko Rauhamaa ma...@pacujo.net
wrote:
No, tail call optimization doesn't change the behavior of the
program, for the worse anyway.
It does, because you lose traceback
On Wed, Jul 15, 2015 at 3:43 AM, Marko Rauhamaa ma...@pacujo.net wrote:
I don't like the way integer overflows are explicitly undefined in
modern C.
Similarly, I don't like the way tail call behavior is undefined in
Python.
Where in the Python spec is it stated that tail call behaviour is
On Sun, Jul 12, 2015 at 8:20 AM, Ian Burnette ian.burne...@gmail.com wrote:
I've recently been playing around with Clojure, and I really like the way
they've overcome the JVM not supporting TRE. The way Clojure solves this
problem is to have a built in recur function that signals to the
On Mon, Jul 13, 2015 at 9:22 PM, Jussi Piitulainen
jpiit...@ling.helsinki.fi wrote:
That's oddly restricted to self-calls. To get the real thing, recur
should replace return - I'm tempted to spell it recurn - so the
definition would look like this:
def factorial(n, acc=1):
if n == 0:
On 07/13/2015 01:28 PM, Chris Angelico wrote:
On Sun, Jul 12, 2015 at 8:20 AM, Ian Burnette ian.burne...@gmail.com wrote:
[ About tail recursion ]
When a function is purely tail-recursive like this, it's trivial to
convert it at the source code level:
def factorial(n):
acc = 1
On Mon, Jul 13, 2015 at 10:00 PM, Antoon Pardon
antoon.par...@rece.vub.ac.be wrote:
On 07/13/2015 01:28 PM, Chris Angelico wrote:
On Sun, Jul 12, 2015 at 8:20 AM, Ian Burnette ian.burne...@gmail.com wrote:
[ About tail recursion ]
When a function is purely tail-recursive like this, it's
Ian Burnette writes:
I've recently been playing around with Clojure, and I really like the
way they've overcome the JVM not supporting TRE. The way Clojure
solves this problem is to have a built in recur function that
signals to the Clojure compiler to convert the code to a loop in the
JVM.
Hi there,
First, please forgive me if this is the wrong venue to be suggesting this
idea-- I'm just following the PEP workflow page
https://www.python.org/dev/peps/pep-0001/#pep-workflow.
I've recently been playing around with Clojure, and I really like the way
they've overcome the JVM not
On Tue, Jul 14, 2015 at 3:15 PM, Paul Rubin no.email@nospam.invalid wrote:
Chris Angelico ros...@gmail.com writes:
I'm not sure why the transition to another state has to be recursive.
It's not recursive: it's more like a goto with arguments, and a tail
call expresses it nicely.
Hmm, maybe,
On Mon, Jul 13, 2015 at 11:25 PM, Chris Angelico ros...@gmail.com wrote:
(Also, side point: Python can't actually optimize the above function,
because it actually means call quicksort, then discard its return
value and return None. A true tail call has to return the result of
the recursive
Chris Angelico ros...@gmail.com writes:
I'm not sure why the transition to another state has to be recursive.
It's not recursive: it's more like a goto with arguments, and a tail
call expresses it nicely.
Maybe this is something where previous experience makes you more
comfortable with a
On Tue, 14 Jul 2015 12:05 am, Chris Angelico wrote:
If you want to make an assertion that iterative
code requires equivalent warping to tail-recursive code, I want to see
an example of it. Is that difficult?
Of course it is. If it wasn't difficult, people would post examples instead
of
On 7/13/2015 3:07 PM, Marko Rauhamaa wrote:
Or, translated into (non-idiomatic) Python code:
def common_prefix_length(bytes_a, bytes_b):
def loop(list_a, list_b, common_length):
if not list_a:
Chris Angelico ros...@gmail.com:
def quicksort(array, start, end):
midp = partition(array, start, end)
if midp = (start+end)//2:
quicksort(array, start, midp)
quicksort(array, midp+1, end)
else:
quicksort(array, midp+1, end)
Chris Angelico ros...@gmail.com writes:
That's a prime example of recursion... but not of recursion that can
be tail-call optimized into iteration. It's an example of forking
recursion, where one call can result in multiple calls (same with tree
traversal); it calls itself to sort the first
On Tue, Jul 14, 2015 at 3:15 PM, Paul Rubin no.email@nospam.invalid wrote:
It's difficult given how subjective the concept of warping is. What's
straightforward to someone else sounds likely to look warped to you and
vice versa. But how does this look:
def quicksort(array, start, end):
On Mon, Jul 13, 2015 at 11:55 PM, Antoon Pardon
antoon.par...@rece.vub.ac.be wrote:
On 07/13/2015 02:34 PM, Chris Angelico wrote:
Warping your code around a recursive solution
to make it into a perfect tail call usually means making it look a lot
less impressive; for instance,
And sometimes
On Mon, Jul 13, 2015 at 6:34 AM, Chris Angelico ros...@gmail.com wrote:
On Mon, Jul 13, 2015 at 10:00 PM, Antoon Pardon
antoon.par...@rece.vub.ac.be wrote:
On 07/13/2015 01:28 PM, Chris Angelico wrote:
Why is it worth writing your code recursively, only to have it be
implemented iteratively?
On 07/13/2015 04:05 PM, Chris Angelico wrote:
On Mon, Jul 13, 2015 at 11:55 PM, Antoon Pardon
antoon.par...@rece.vub.ac.be wrote:
On 07/13/2015 02:34 PM, Chris Angelico wrote:
Warping your code around a recursive solution
to make it into a perfect tail call usually means making it look a lot
On 07/13/2015 02:34 PM, Chris Angelico wrote:
Warping your code around a recursive solution
to make it into a perfect tail call usually means making it look a lot
less impressive; for instance,
And sometimes your problem is very easily solved by a number of functions
that tail call each
On Mon, Jul 13, 2015 at 11:46 PM, Ian Kelly ian.g.ke...@gmail.com wrote:
On Mon, Jul 13, 2015 at 6:34 AM, Chris Angelico ros...@gmail.com wrote:
On Mon, Jul 13, 2015 at 10:00 PM, Antoon Pardon
antoon.par...@rece.vub.ac.be wrote:
On 07/13/2015 01:28 PM, Chris Angelico wrote:
Why is it worth
Ethan Furman et...@stoneleaf.us:
I would love to see good functional examples as it is definitely a
weak spot for me.
Oh, if you want to go functional, you should look at idiomatic Scheme
code:
(define
Antoon,
I think Chris is arguing in good faith; certainly asking for examples should be
a reasonable request.
Even if he is not, we would have better discussions and other participants
would learn more if you act like he is. I would love to see good functional
examples as it is definitely a
On 7/13/2015 7:22 AM, Jussi Piitulainen wrote:
Ian Burnette writes:
A post I did not receive, but want to comment on.
I've recently been playing around with Clojure, and I really like the
way they've overcome the JVM not supporting TRE. The way Clojure
solves this problem is to have a built
Hi,
The Python locale standard libraries has some oddities and (long-standing) bugs.
Example oddity: SETlocale *returns* a locale; getlocale output cannot always be
consumed by setlocale. Example bug: resetlocale fails in Windows. What is your
opinion about the work-around code below?
import
On 10/7/2014 1:01 PM, Ned Batchelder wrote:
On 10/7/14 2:10 AM, Gelonida N wrote:
Disadvantage of itertools.product() is, that it makes a copy in memory.
Reason ist, that itertools also makes products of generators (meaning of
objects, that one can't iterate several times through)
There are
On 8/6/2014 1:39 PM, Tim Chase wrote:
On 2014-08-06 11:04, Gayathri J wrote:
Below is the code I tried to check if itertools.product() was
faster than normal nested loops...
they arent! arent they supposed to be...or am i making a mistake?
I believe something like this was discussed a while
On 10/7/14 2:10 AM, Gelonida N wrote:
Disadvantage of itertools.product() is, that it makes a copy in memory.
Reason ist, that itertools also makes products of generators (meaning of
objects, that one can't iterate several times through)
There are two use cases, that I occasionaly stumble
://www.pokerstars.com/poker/games/rules/hand-rankings/.
Which of the following is better and more Pythonic ?
Your two code segments will do different things.
def poker(hands):
return max(hands, key=hand_rank)
In this case, the hand_rank function will take a single hand, and return
its rank value
hand_rank(hand):
Determine the rank of the poker hand.
rank = int(some_complex_computation(hand))
return rank
In other words, I'm assuming ‘hand_rank’ returns an integer.
Which of the following is better and more Pythonic ?
Only one of them does anything useful
Dear Peter
Below is the code I tried to check if itertools.product() was faster than
normal nested loops...
they arent! arent they supposed to be...or am i making a mistake? any idea?
**
*# -*- coding: utf-8 -*-*
*import numpy as np*
On Wed, Aug 6, 2014 at 3:34 PM, Gayathri J usethisid2...@gmail.com wrote:
Below is the code I tried to check if itertools.product() was faster than
normal nested loops...
they arent! arent they supposed to be...or am i making a mistake? any idea?
Don't worry about what's faster. That almost
On 06/08/2014 06:34, Gayathri J wrote:
Dear Peter
Below is the code I tried to check if itertools.product() was faster
than normal nested loops...
they arent! arent they supposed to be...or am i making a mistake? any idea?
*
*
*
*
*#
Gayathri J wrote:
Dear Peter
Below is the code I tried to check if itertools.product() was faster than
normal nested loops...
they arent! arent they supposed to be...
I wouldn't have expected product() to be significantly faster, but neither
did I expect it to be slower.
or am i
You might check numpy it is really powerful tool for working with multi
dimensional arrays:
ex.
a = arange(81).reshape(3,3,3,3)
a
array( 0, 1, 2],
[ 3, 4, 5],
[ 6, 7, 8]],
[[ 9, 10, 11],
[12, 13, 14],
[15, 16, 17]],
[[18, 19,
Dear Peter
Yes the f[t] or f[:,:,:] might give a marginal increase, but then i need
to do further operations using the indices, in which case this wouldnt help
Dear Wojciech
np.flat() works if u dont care about the indices and only the matrix/array
values matter.
but if the i,j,k matters,
Gayathri J wrote:
Dear Peter
Yes the f[t] or f[:,:,:] might give a marginal increase,
The speedup compared itertools.product() is significant:
$ python -m timeit -s 'from itertools import product; from numpy.random
import rand; N = 100; a = rand(N, N, N); r = range(N)' 'for x in
On 2014-08-06 11:04, Gayathri J wrote:
Below is the code I tried to check if itertools.product() was
faster than normal nested loops...
they arent! arent they supposed to be...or am i making a mistake?
I believe something like this was discussed a while ago and there was
a faster-but-uglier
Dear Peter
thanks . But thats what I was trying to say
just taking them to zero by f[:,:,:] = 0.0 or using np.zeros is surely
going to give me a time gain...
but my example of using the itertools.product() and doing f[x] =0.0 is just
to compare the looping timing with the traditional nested
I need to evaluate a complicated function over a multidimensional space
as part of an optimization problem. This is a somewhat general problem
in which the number of dimensions and the function being evaluated can
vary from problem to problem.
I've got a working version (with loads of
Frank Miles wrote:
I need to evaluate a complicated function over a multidimensional space
as part of an optimization problem. This is a somewhat general problem
in which the number of dimensions and the function being evaluated can
vary from problem to problem.
I've got a working version
301 - 400 of 1440 matches
Mail list logo
