Planar 0.1 is out

[Casey Duncan]

I released the first version of the planar 2D geometry library. If
anyone has a chance to try building it on their platform of choice and
running the tests, that would be very helpful. Of course any other
feedback is appreciated.

Docs are here:
http://pygamesf.org/~casey/planar/doc/

Download here:
http://pypi.python.org/pypi/planar/

Or if you prefer, get it with Hg, here:
http://bitbucket.org/caseman/planar/

This initial version only implements a 2D vector class so far, but it
includes both a Python and C implementation and is fully documented
and unit tested. It is compatible with Python 2.6, 2.7 and 3.1. Next
I'm going to work on transforms and basic vector/point arrays that
will form the basis of more complex shape classes.

-Casey


--
Subscription settings: http://groups.google.com/group/grease-users/subscribe?hl=en

[Jonathan Hartley]

On 27/04/2010 05:05, Casey Duncan wrote:
> try building it on their platform of choice and
> running the tests,

Windows XP any use to you? I'll fire it up at lunchtime...

--
Jonathan Hartley Made of meat. http://tartley.com
tar...@tartley.com +44 7737 062 225 twitter/skype: tartley

[Casey Duncan]

Definitely, I've not done any testing on Windows, so let me know what
happens when it builds. I'm happy to help fix any compiler complaints.

-Casey

[Tartley]

Hey. Builds and installs OK, looks OK at the Python command line, but
one test failure (at the bottom of all this:)

I'm happy to do some diagnosis if it isn't immediately obvious to you
what this might be.

WinXP, Python 2.6.5, build using gcc from MinGW:

F:\Documents and Settings\jhartley\docs\scratch\planar-0.1
> python setup.py install
running install
running build
running build_py
running build_ext
building 'planar.cvector' extension
creating build\temp.win32-2.6
creating build\temp.win32-2.6\Release
creating build\temp.win32-2.6\Release\lib
creating build\temp.win32-2.6\Release\lib\planar
F:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Iinclude -IF:
\Python26\include
-IF:\Python26\PC -c lib/planar/cvectormodule.c -o build
\temp.win32-2.6\Release\lib\planar\cvectormodule.o
writing build\temp.win32-2.6\Release\lib\planar\cvector.def
F:\MinGW\bin\gcc.exe -mno-cygwin -shared -s build
\temp.win32-2.6\Release\lib\planar\cvectormodule.o build
\temp.win32-2.6\Release\lib\planar\cvector.def -LF:\Python26\libs -LF:
\Python26\PCbuild -lpython26 -lmsvcr90 -o build\lib.win32-2.6\planar
\cvector.pyd
running install_lib
creating F:\Python26\Lib\site-packages\planar
copying build\lib.win32-2.6\planar\cvector.pyd -> F:\Python26\Lib\site-
packages\planar
creating F:\Python26\Lib\site-packages\planar\test
copying build\lib.win32-2.6\planar\test\test_planar.py -> F:
\Python26\Lib\site-packages\planar\test
copying build\lib.win32-2.6\planar\test\test_util.py -> F:\Python26\Lib
\site-packages\planar\test
copying build\lib.win32-2.6\planar\test\test_vector.py -> F:
\Python26\Lib\site-packages\planar\test
copying build\lib.win32-2.6\planar\test\__init__.py -> F:\Python26\Lib
\site-packages\planar\test
copying build\lib.win32-2.6\planar\util.py -> F:\Python26\Lib\site-
packages\planar
copying build\lib.win32-2.6\planar\vector.py -> F:\Python26\Lib\site-
packages\planar
copying build\lib.win32-2.6\planar\__init__.py -> F:\Python26\Lib\site-
packages\planar
byte-compiling F:\Python26\Lib\site-packages\planar\test
\test_planar.py to test_planar.pyc
byte-compiling F:\Python26\Lib\site-packages\planar\test\test_util.py
to test_util.pyc
byte-compiling F:\Python26\Lib\site-packages\planar\test
\test_vector.py to test_vector.pyc
byte-compiling F:\Python26\Lib\site-packages\planar\test\__init__.py
to __init__.pyc
byte-compiling F:\Python26\Lib\site-packages\planar\util.py to
util.pyc
byte-compiling F:\Python26\Lib\site-packages\planar\vector.py to
vector.pyc
byte-compiling F:\Python26\Lib\site-packages\planar\__init__.py to
__init__.pyc
running install_egg_info
Writing F:\Python26\Lib\site-packages\planar-0.1-py2.6.egg-info

> yolk -l | grep planar
planar - 0.1 - active

> python setup.py build
running build
running build_py
running build_ext

> nosetests -d -w build\lib.win32-2.6\planar
...............................................................................E.........................
======================================================================
ERROR: test_is_null (planar.test.test_vector.PyVec2TestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "F:\Documents and Settings\jhartley\docs\scratch
\planar-0.1\build\lib.win32-2.6\planar\test\test_vector.py", line 108,
in test_is_null
assert not self.Vec2(float('nan'), 0).is_null
File "F:\Documents and Settings\jhartley\docs\scratch
\planar-0.1\build\lib.win32-2.6\planar\util.py", line 43, in getter
self.__dict__[name] = value = func(self)
File "F:\Documents and Settings\jhartley\docs\scratch
\planar-0.1\build\lib.win32-2.6\planar\vector.py", line 99, in is_null
return self.length2 < planar.EPSILON2
File "F:\Documents and Settings\jhartley\docs\scratch
\planar-0.1\build\lib.win32-2.6\planar\util.py", line 43, in getter
self.__dict__[name] = value = func(self)
File "F:\Documents and Settings\jhartley\docs\scratch
\planar-0.1\build\lib.win32-2.6\planar\vector.py", line 91, in length2
return self[0] ** 2 + self[1] ** 2
ValueError: (33, 'Domain error')

----------------------------------------------------------------------
Ran 105 tests in 0.046s

FAILED (errors=1)

On Apr 27, 5:05 pm, Casey Duncan <casey.dun...@gmail.com> wrote:
> Definitely, I've not done any testing on Windows, so let me know what
> happens when it builds. I'm happy to help fix any compiler complaints.
>
> -Casey
>

> On Tue, Apr 27, 2010 at 3:34 AM, Jonathan Hartley <tart...@tartley.com> wrote:
> > On 27/04/2010 05:05, Casey Duncan wrote:
>
> >> try building it on their platform of choice and
> >> running the tests,
>
> > Windows XP any use to you? I'll fire it up at lunchtime...
>
> > --
> > Jonathan Hartley      Made of meat.      http://tartley.com

> > tart...@tartley.com   +44 7737 062 225   twitter/skype: tartley

[Tartley]

BTW, 'Tartley' is Jonathan Hartley. I never realised Google groups
showed my name differently depending on whether I emailed or use the
web interface. No doubt left swathes of confusion in my wake over that
one.

[Casey Duncan]

Interesting, the assertion raising this exception is:

assert not self.Vec2(float('nan'), 0).is_null

What happens if you perform these statements on the python command line?

float("nan")**2

float("nan") + 0

on Mas OSX, I get:

>>> float("nan")**2
nan
>>> float("nan")+0
nan

Thanks.

-Casey

[Casey Duncan]

Ok, I'm still generally confused, but less so about this now ;^)

-Casey

[Tartley]

> python
Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> float('nan')
nan
>>> float('nan')**2

Traceback (most recent call last):

File "<stdin>", line 1, in <module>

ValueError: (33, 'Domain error')

>>> float('nan')+0
nan
>>> float('nan')*0
nan
>>>


I get the same results under Python 3.1.2.

I can try it out under a different WinXP machine tomorrow, just in
case it's a quirk of this trusty old Thinkpad.

On Apr 28, 10:25 pm, Casey Duncan <casey.dun...@gmail.com> wrote:
> Interesting, the assertion raising this exception is:
>
> assert not self.Vec2(float('nan'), 0).is_null
>
> What happens if you perform these statements on the python command line?
>
> float("nan")**2
>
> float("nan") + 0
>
> on Mas OSX, I get:
>
> >>> float("nan")**2
> nan
> >>> float("nan")+0
>
> nan
>
> Thanks.
>
> -Casey
>

[Tartley]

and, just in case it's helpful:

>>> float('nan') * float('nan')
nan

[Casey Duncan]

Ok, I'll be if I replace the **2 with explicit multiplication in the
Python code, it avoid NaN platforms quirks like this. The explicit
multiplication is faster anyway. The C code uses explicit
multiplication already, which I imagine is why it passes the same
test.

If you change the length2() method on line 88 of vector.py to this,
does it pass?

@cached_property
def length2(self):
"""The square of the length of the vector."""
x, y = self
return x*x + y*y

Thanks very much for testing.

-Casey

[Tartley]

> nosetests -d -w build\lib.win32-2.6\planar

.........................................................................................................
----------------------------------------------------------------------
Ran 105 tests in 0.110s

OK



Hooray!

On Apr 29, 12:56 am, Casey Duncan <casey.dun...@gmail.com> wrote:
> Ok, I'll be if I replace the **2 with explicit multiplication in the
> Python code, it avoid NaN platforms quirks like this. The explicit
> multiplication is faster anyway. The C code uses explicit
> multiplication already, which I imagine is why it passes the same
> test.
>
> If you change the length2() method on line 88 of vector.py to this,
> does it pass?
>
>     @cached_property
>     def length2(self):
>         """The square of the length of the vector."""
>         x, y = self
>         return x*x + y*y
>
> Thanks very much for testing.
>
> -Casey
>

[Casey Duncan]

Woot!, I checked in the change.

Thanks again!

-Casey

[Jussi Lepistö]

I tested on Windows 7 with Visual Studio 2008 Professional. Compiles
on both 32- and 64-bit versions of Python 2.6 and 3.1, but I only have
nose installed on 32-bit Python 2.6 so that's what I ran the tests
with.

Anyway, compiles ok on all platforms, the tests run fine except for
the error below.

[Casey Duncan]

Excellent, thanks! I suspect this will be a bear for dealing with
binaries. It'd need at least 4 I think, for each combination of
32/64-bit and Python 2.6/3.1. I imagine Python 2.7 will not be binary
compatible with 2.6 either. Is that right or is it possible to somehow
avoid separate 32/64 bit binaries?

Something to think about. For now I think there isn't enough
functionality to warrant a binary release.

-Casey

2010/4/28 Jussi Lepistö <jussi....@iki.fi>:

[Jussi Lepistö]

On 29.4.2010 8:34, Casey Duncan wrote:
> Excellent, thanks! I suspect this will be a bear for dealing with
> binaries. It'd need at least 4 I think, for each combination of
> 32/64-bit and Python 2.6/3.1. I imagine Python 2.7 will not be binary
> compatible with 2.6 either. Is that right or is it possible to somehow
> avoid separate 32/64 bit binaries?

Yes, all minor Python versions (2.6, 2.7, 3.1), along with 32- and
64-bit versions are binary incompatible. Also, as with Lepton, compiling
Python 2.5 extensions on Windows is a pain.

-Jussi

[Jonathan Hartley]

Two silly questions:

1) Can anyone help me understand *why* NaN**2 fails on Windows?

2) I keep thinking that if one's package is for developers (eg. is a
library, or a developer-oriented application) then there's no need to
provide binaries - developers can easily compile their own. Binaries are
only really required for applications aimed at real people. Am I
minunderstanding?

--
Jonathan Hartley Made of meat. http://tartley.com

tar...@tartley.com +44 7737 062 225 twitter/skype: tartley

[Casey Duncan]

On Thu, Apr 29, 2010 at 2:26 AM, Jonathan Hartley <tar...@tartley.com> wrote:
> Two silly questions:
>
> 1) Can anyone help me understand *why* NaN**2 fails on Windows?

The floating point pow function in python, which handles the **
operator, is basically just a wrapper around the clib pow() function.
This function can return errors, one of which, on windows, is "Domain
error", which means that the function cannot operate on the values
passed it. This is an edge case where the glibc's pow() function does
not have the same behavior as the microsoft one. So basically:

pow(NaN, 2)

returns NaN in the glibc implementation (like NaN*NaN does), but
results in an error on Windows. The error is checked in the Python
code, and if set results in an exception. The "Domain error" message
actually comes from the Windows library code.

Welcome to the fun world of floating point portability! ;^)

NaN*NaN works on both because it does not involve the vagaries of the
c std lib. It's behavior is much more explicitly defined by the
floating point standard, which is implemented in hardware. It helps
here that we're all running on Intel chips too, other hardware may
take liberties with the floating point spec and all bets are off.

At least, Planar is not intended to fly the Space Shuttle or anything,
so for our purposes we can make some assumptions about these things
and not worry too much if it blows up on somebody's wonky hardware ;^)

> 2) I keep thinking that if one's package is for developers (eg. is a
> library, or a developer-oriented application) then there's no need to
> provide binaries - developers can easily compile their own. Binaries are
> only really required for applications aimed at real people. Am I
> minunderstanding?

Where "real people" means "people who can compile their way out of a
paper bag" correct? ;^) I think to a degree, this is true, but
particularly on Windows many folks have no compiler, and don't even
know how to spell C, yet still want to have some fun hacking up a game
in Python. Game development tends to be an entry point for folks
learning programming, so it'd be nice to make Planar more accessible
to that crowd, once it matures a bit.

I'd say for now, catering to more "seasoned" developers is fine until
folks starting wanting binaries.

-Casey

[Casey Duncan]

2010/4/29 Jussi Lepistö <jussi....@iki.fi>:

Luckily Planar does not support Python 2.5, which has a nice side
effect of avoiding that whole mess 8^)

-Casey

[Tartley]

On Apr 29, 4:18 pm, Casey Duncan <casey.dun...@gmail.com> wrote:

Thanks for all that - makes perfect sense all round. (although, for
the record, by 'real people' I meant 'everyone except programmers.' No
matter, your answer is perfect.)