util.normalize() is rounding?

[ghevcoul]

I'm working on writing some unit tests for some of the existing code and saw that the normalize() function in the util module is using round(). The documentation for the function says it returns the block containing the input position, so should this be using math.floor() instead?

[traverseda]

I don't know. Probably, test it out. It came from the original.

It sounds like math.floor() would be better, but I can't be sure.

[ghevcoul]

If we have a position like [10.6, 32.1, 47.3], using round() will return a block of [11, 32, 47], but my understanding is that we should be in block [10, 32, 47], which math.floor() would give us. Does this make sense?

[traverseda]

Makes sense to me.

[traverseda]

<koubio> Looks like d3b5cec broke the spawning and placing blocks
<@traverseda> Huh, I've re-opened the issue here. Well, the issue for the only major change I know about. https://github.com/traverseda/pycraft/issues/45
<koubio> Yeah math.floor is definitely the culprit here
<koubio> I went ahead and fixed the inventory issue too
<koubio> i'll create the PR in a few
<@traverseda> Ty

[ghevcoul]

That's my mistake, I changed the normalize function without fully testing the ramifications. I'll submit a PR to revert the change.

[nitori]

Just to clarify: cube_vertices is called with 0.5 as argument. So a block located at (11, 32, 47) goes from 11.5 - 10.5, 32.5 - 31.5 and 47.5 - 46.5.

Seems to be the reason at least (didn't look much further into it).

[ghevcoul]

That makes more sense. I was assuming that the corners of a block would align with whole numbers with the center point being [X.5, Y.5, Z.5], but in reality, the center point of the block is the whole number and the corners are at the .5s

This seems counter intuitive to me, but perhaps that just because I've played too much Minecraft.

[nitori]

Might be worth considering changing it.

Dirty test:

~ $ python3 -m timeit -s 'import math' 'math.floor(0.5)'
10000000 loops, best of 3: 0.131 usec per loop
~ $ python3 -m timeit 'int(0.5)'
10000000 loops, best of 3: 0.138 usec per loop
~ $ python3 -m timeit 'round(0.5)'
1000000 loops, best of 3: 0.209 usec per loop

Though the difference is probably not big enough to actually have an impact on the game.

[nitori]

In retrospect, I think the current behaviour, with using the blocks centre as the integer coordinates and adding +0.5/-0.5, seems to be much simpler behaviour.

The rounding might be a bit odd, but changing the structure just to get rid of the rounding isn't really worth it. I think an approach using numpy, like discussed in #56 (it hasn't been implemented yet aside from those tests in @TristanTrim's fork, right?), would be much better.