[Python Wpg] Fwd: Cannot figure out this ZeroDivisionError exception

[Stuart Williams]

Good catch Mike.

Stuart.

On Fri, Mar 11, 2011 at 6:38 PM, Mike pfaiffer <high.res.mike at gmail.com>wrote:

> On 11-03-11 2:22 PM, Kevin Veroneau wrote:
>
>> ---------- Forwarded message ----------
>> From: Kevin Veroneau<kveroneau at gmail.com>
>> Date: Fri, Mar 11, 2011 at 2:22 PM
>> Subject: Re: [Python Wpg] Cannot figure out this ZeroDivisionError
>> exception
>> To: Stuart Williams<stuart at swilliams.ca>
>>
>>
>> Thank you the help.
>>
>> I updated the code with the added brackets.  The exception is still
>> firing.
>>
>> camz is set on line 17:  camx, camy, camz = 0, 0, 300
>>
>> scale is set to 1, and when the mode is changed to from 0 to 1, the
>> following is executed:
>> scale = scale/camz
>>
>> I suspect that I have the scale set too low, it is current 1.  In the end,
>> it would be doing:
>> scale = 1/300 which then equals a zero-based float point number:  0.003333
>>
>> If I set the scale to 1, the objects in 3D space are too far to see and
>> defeats the purpose of the demo.  Although I do suspect it is more related
>> to the math in dividing the scale than it is in the math for the drawing
>> routine.
>>
>> This helps a lot as now the problem is more pinpointed and I know where to
>> look.
>>
>> Thanks!
>>
>
>        Just a thought. Would scale = 1/300 not produce 0 instead of the
> floating point 0.00333? It looks like you may have a data type conversion
> issue. If the numerator is an integer then the result of the division will
> be an integer. I was caught by this a couple of times (and will no doubt be
> caught by it again in the future).
>
>                                Later
>                                Mike
>
>
>
>
>  On Fri, Mar 11, 2011 at 1:58 PM, Stuart Williams<stuart at swilliams.ca
>> >wrote:
>>
>>  I briefly looked through your code, and the print of scale + movex makes
>>> me
>>> wonder if you're assuming different operator precedence than Python gives
>>> you:
>>>
>>>   nx = (x[n]+xrotoffset+camx)/nz/scale+movex
>>>
>>> is interpreted as (formatted to match PEP8):
>>>
>>>   nx = (((x[n] + xrotoffset + camx) / nz) / scale) + movex
>>>
>>> I suspect scale is zero, even if scale+movex is not.
>>>
>>> camz starts at zero, and if line 68 execute then scale becomes zero.
>>>
>>> The other thing I noticed is your code has the loop over 8 values later
>>> in
>>> the loop than the code that you're following.
>>>
>>> Perhaps that will help.
>>>
>>> Stuart.
>>>
>>> On Thu, Mar 10, 2011 at 4:33 PM, Kevin Veroneau<kveroneau at gmail.com
>>> >wrote:
>>>
>>>  Hello,
>>>>
>>>>   I am in the process of learning the basics of 3D math and programming,
>>>> and thought using Python and Pygame would be a good choice to prototype
>>>> in.
>>>> The 2D example works great, the isometric 3D example also works.  But in
>>>> the
>>>> 3rd example, when I press Space to enter into full 3D, it uses a flow
>>>> control statement to change a calculation.  Even though the calculation
>>>> is
>>>> very similar in both isometric and full 3D, it just does not work and I
>>>> am
>>>> very confused why.
>>>>
>>>>   You can view the source code online in my public Subversion
>>>> Repository:
>>>> http://django.kveroneau.info/svn/node1/python/pygame/3danim2.py/cat
>>>>
>>>>   I am following the tutorial step-by-step on this website:
>>>> http://skytopia.com/project/cube/cube.html
>>>>
>>>>   That website explains 3D using pseudo-code, the author made it
>>>> resemble
>>>> BASIC-like syntax for clarity.  As I read through the tutorial, I coded
>>>> it
>>>> in Python, and thus is why there is three python files, one for each
>>>> phase
>>>> of the example.
>>>>
>>>>   I thought I would ask here, as I noticed many of you on this mailing
>>>> list using Python for mathematical purposes, and this exception is
>>>> related
>>>> to a math operation in a calculation.  This is my first time going in
>>>> depth
>>>> with 3D programming and how the math behind it works.  I would of course
>>>> move to OpenGL once I understand the fundamentals.
>>>>
>>>>   On the topic of OpenGL, which OpenGL Python library would you
>>>> recommend
>>>> someone who is just diving into GL.  I feel my Python skills are pretty
>>>> strong at this point.  I understand that Blender can be scripted using
>>>> Python, would this be a good place to start or should I use a
>>>> stand-alone
>>>> python module?
>>>>
>>>> Thanks,
>>>>   Kevin Veroneau
>>>>
>>>>
>>>> _______________________________________________
>>>> Winnipeg Python Users Group mailing list
>>>> http://WinniPUG.ca
>>>> Winnipeg at python.org
>>>> http://mail.python.org/mailman/listinfo/winnipeg
>>>>
>>>>
>>>>
>>>
>>
>>
>> _______________________________________________
>> Winnipeg Python Users Group mailing list
>> http://WinniPUG.ca
>> Winnipeg at python.org
>> http://mail.python.org/mailman/listinfo/winnipeg
>>
>
> _______________________________________________
> Winnipeg Python Users Group mailing list
> http://WinniPUG.ca
> Winnipeg at python.org
> http://mail.python.org/mailman/listinfo/winnipeg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/winnipeg/attachments/20110311/61c38c0b/attachment.html>