Live data from Hacker News

Pycraft: Minecraft engine in Python

github.com

31–40 of 49 posts

Re: Pycraft: Minecraft engine in Python

#31
post #18

Earlier quoted context omitted.

To be pedantic (which I think is warranted here), range does not return a generator, it returns a sequence called a range object. This object can be indexed, sliced, and (relevant to this discussion) supports the 'in' operator. "x in range(10)" will operate in constant time and memory in Python 3. Whether it is actually more efficient than "0 $ python3 -m timeit -s 'x = 8' 'x in range(10)' 1000000 loops, best of 3: 0…

I'm certain that the call to range is significant there, but if you think of how this actually plays out, it may be doing a naive list compare. if a compare operation is your limiting operation, then the former has to do nine operations (Is x == 0? Is x == 1? ... Is x == 8?) vs precisely two in the latter (is x >= 0? Is x From a formal CS perspective, that's why this is wrong; It's because 'in' is an o(n) operation,…

To question your assessment I tested it on my own machine:

  python3 -m timeit -s 'x = 8' 'x in range(1000)'
  1000000 loops, best of 3: 0.405 usec per loop
  python3 -m timeit -s 'x = 8' '0 
While 0<=x<10 seems to be 5 times faster, both seem to be independent of the actual chosen values.

Re: Pycraft: Minecraft engine in Python

#32
post #24

I cringe when I see code like this: if len(vals) in range(1, 5): It seems like a harmless enough thing to do but that code is effectively creating a new array with values [1, 2, 3, 4, 5] and testing if the result of len() is in that array by iterating over it. This check is happening multiple times for each draw call every frame. Sadly I see this kind of stuff in Python all the time and it just adds weight to the arg…

The cost of abstraction. If it doesn't affect performance then who's thinking is "wrong" here?

What abstraction? Comparisons are ubiquitous, easy to read, and a one-liner as well. If the range were to change it could affect performance. I've never seen anything written like the original loop, it's not like it's a Python idiom or anything. I'd say it's the wrong way to do things.

Re: Pycraft: Minecraft engine in Python

#33
post #13
post #10

Earlier quoted context omitted.

Even though Notch was supposed to make it open source at some point. Another broken promise.

That point was when Minecraft was worthless. It's currently somewhere around the $2.5b mark in value. But that's just splitting hairs, it won't likely ever be open-sourced after MS acquired it. That said, they also promised a modding API too...

I dunno... Microsoft has been open sourcing some pretty awesome stuff lately.

Re: Pycraft: Minecraft engine in Python

#34
post #32
post #24

Earlier quoted context omitted.

The cost of abstraction. If it doesn't affect performance then who's thinking is "wrong" here?

What abstraction? Comparisons are ubiquitous, easy to read, and a one-liner as well. If the range were to change it could affect performance. I've never seen anything written like the original loop, it's not like it's a Python idiom or anything. I'd say it's the wrong way to do things.

The abstraction is in removing the cognitive overhead needed to understand this. The original programmer can now allocate the time saved to higher level concerns. That is what C did for assembly and what Python is doing for C. Is that not the theme of abstraction?

Re: Pycraft: Minecraft engine in Python

#35
post #14

I cringe when I see code like this: if len(vals) in range(1, 5): It seems like a harmless enough thing to do but that code is effectively creating a new array with values [1, 2, 3, 4, 5] and testing if the result of len() is in that array by iterating over it. This check is happening multiple times for each draw call every frame. Sadly I see this kind of stuff in Python all the time and it just adds weight to the arg…

Why do you suspect 1 You can actually get a very good idea for what Python is doing under the hood using the dis module: dis.dis(lambda: 1 > 27 ROT_TWO 28 POP_TOP 29 RETURN_VALUE Compare to: dis.dis(lambda: len(vals) in range(1, 5)) 1 0 LOAD_GLOBAL 0 (len) 3 LOAD_GLOBAL 1 (vals) 6 CALL_FUNCTION 1 9 LOAD_GLOBAL 2 (range) 12 LOAD_CONST 1 (1) 15 LOAD_CONST 2 (5) 18 CALL_FUNCTION 2 21 COMPARE_OP 6 (in) 24 RETURN_VALUE

That doesn't tell you about the speed of the code though.

    $> python -m timeit "1  python -m timeit "4 in range(1,5)"
    1000000 loops, best of 3: 0.413 usec per loop

    $> python -m timeit "4 in (1,2,3,4,5)"
    10000000 loops, best of 3: 0.0776 usec per loop
Tested in python 3.5.0, Even with the improvements to the range function, the comparison is almost 5x faster.

Re: Pycraft: Minecraft engine in Python

#37
post #10

Earlier quoted context omitted.

Even though Notch was supposed to make it open source at some point. Another broken promise.

What he actually said was "Once sales start dying and a minimum time has passed, I will release the game source code as some kind of open source." [0]. Sales haven't died down and he doesn't own it anymore anyway. [0] http://web.archive.org/web/20100301103851/http://www.minecra...

Seems like selling it is the broken promise. If sales die down, and a minimum time passes, he still can't OS it because he sold it.

Still, as long as the idea's out there... I heard the codebase isn't actually that great...

Re: Pycraft: Minecraft engine in Python

#38

I cringe when I see code like this: if len(vals) in range(1, 5): It seems like a harmless enough thing to do but that code is effectively creating a new array with values [1, 2, 3, 4, 5] and testing if the result of len() is in that array by iterating over it. This check is happening multiple times for each draw call every frame. Sadly I see this kind of stuff in Python all the time and it just adds weight to the arg…

Even without going into performance concerns, it's just harder to understand than the Example in this thread: half of the commenters consider that it means 1 <= len(vals) <= 5 and the other half consider that it means 1 <= len(vals) < 5...

Re: Pycraft: Minecraft engine in Python

#39
post #34
post #32

Earlier quoted context omitted.

What abstraction? Comparisons are ubiquitous, easy to read, and a one-liner as well. If the range were to change it could affect performance. I've never seen anything written like the original loop, it's not like it's a Python idiom or anything. I'd say it's the wrong way to do things.

The abstraction is in removing the cognitive overhead needed to understand this. The original programmer can now allocate the time saved to higher level concerns. That is what C did for assembly and what Python is doing for C. Is that not the theme of abstraction?

In this case I actually think the cognitive overhead is larger for the in range(5) call. You have to know how that will behave, is it 1 <= x < 5 or 1 <= x <= 5? The comparisons are more explicit and they are quite easy to read in this case.
Post reply on HN