Problems with Python 3.2 code vs Python 2.7

Question

I have code to build a mandlebrot set using pygame. Here is the code.

import pygame, sys, math from decimal import * window=pygame.display.set_mode((1000, 1000)) window.fill((255, 255, 255)) pygame.display.update() winrect=window.get_rect() hq=3 getcontext().prec=20 colors=((255, 0, 0), (255, 128, 0), (255, 255, 0), (128, 255, 0), (0, 255, 0), (0, 255, 128), (0, 255, 255), (0, 128, 255), (0, 0, 255), (128, 0, 255), (255, 0, 255), (255, 0, 128)) def graph(scale):#left, right, bottom, top window.fill((0, 0, 0)) minimum=-1 y=((scale[3]-scale[2]))/(winrect.height)+scale[2] for a in range(winrect.width): x=((scale[1]-scale[0])*(a))/(winrect.width)+scale[0] d, e=x**2-y**2+x, 2*x*y+y for i in range(int(1/(50*(scale[1]-scale[0]))+25)): d, e=d**2-e**2+x, 2*d*e+y if math.sqrt(d**2+e**2)>2: if i<minimum or minimum==-1: minimum=i break y=((scale[3]-scale[2])*winrect.height)/(winrect.height)+scale[2] for a in range(winrect.width): x=((scale[1]-scale[0])*a)/winrect.width+scale[0] d, e=x**2-y**2+x, 2*x*y+y for i in range(int(1/(50*(scale[1]-scale[0]))+25)): d, e=d**2-e**2+x, 2*d*e+y if math.sqrt(d**2+e**2)>2: if i<minimum or minimum==-1: minimum=i break x=((scale[1]-scale[0])*1)/winrect.width+scale[0] for b in range(winrect.height): y=((scale[3]-scale[2])*b)/winrect.height+scale[2] d, e=x**2-y**2+x, 2*x*y+y for i in range(int(1/(50*(scale[1]-scale[0]))+25)): d, e=d**2-e**2+x, 2*d*e+y if math.sqrt(d**2+e**2)>2: if i<minimum or minimum==-1: minimum=i break x=((scale[1]-scale[0])*winrect.width)/winrect.width+scale[0] for b in range(winrect.height): y=((scale[3]-scale[2])*b)/winrect.height+scale[2] d, e=x**2-y**2+x, 2*x*y+y for i in range(int(1/(50*(scale[1]-scale[0]))+25)): d, e=d**2-e**2+x, 2*d*e+y if math.sqrt(d**2+e**2)>2: if i<minimum or minimum==-1: minimum=i break for a in range(winrect.width): for b in range(winrect.height): x=((scale[1]-scale[0])*a)/winrect.width+scale[0] y=((scale[3]-scale[2])*b)/winrect.height+scale[2] d, e=x**2-y**2+x, 2*x*y+y for i in range(minimum): d, e=d**2-e**2+x, 2*d*e+y for i in range(20*hq): d, e=d**2-e**2+x, 2*d*e+y if math.sqrt(d**2+e**2)>2: window.set_at((a, b), colors[i-(int(i/len(colors))*len(colors))]) break for event in pygame.event.get(): if event.type==pygame.QUIT: pygame.quit() sys.exit() if event.type==pygame.KEYDOWN: if event.key==pygame.K_ESCAPE: pygame.quit() sys.exit() pygame.display.update() pygame.display.update() graph([-3, 2, -2.5, 2.5, 0])# scale=[-3, 2, -2.5, 2.5, 0] scalea=scale[:] while True: for event in pygame.event.get(): if event.type==pygame.QUIT: pygame.quit() sys.exit() if event.type==pygame.KEYDOWN: if event.key==pygame.K_ESCAPE: pygame.quit() sys.exit() if event.key==pygame.K_r: graph([-3, 2, -2.5, 2.5, 0]) scale=[-3, 2, -2.5, 2.5, 0] scalea=scale[:] if event.key==pygame.K_p: hq+=1 graph(scale) if event.key==pygame.K_o: if not hq==1: hq-=1 graph(scale) if event.key==pygame.K_SPACE: print(scale) print(scale[1]-scale[0]) if event.type==pygame.MOUSEBUTTONDOWN: if not scalea[4]: scalea[0]=(((scale[1]-scale[0])*event.pos[0])/winrect.width)+scale[0] scalea[2]=(((scale[3]-scale[2])*event.pos[1])/winrect.height)+scale[2] scalea[4]=1 else: scalea[1]=(((scale[1]-scale[0])*event.pos[0])/winrect.width)+scale[0] scalea[3]=(((scale[3]-scale[2])*event.pos[1])/winrect.height)+scale[2] scalea[4]=0 if scalea[1]<scalea[0]: scalea=[scalea[1], scalea[0], scalea[2], scalea[3], 0] if scalea[3]<scalea[2]: scalea=[scalea[0], scalea[1], scalea[3], scalea[2], 0] scale=scalea[:] if scale[1]-scale[0]<scale[3]-scale[2]: scale[1]+=((scalea[3]-scalea[2])-(scalea[1]-scalea[0]))/2 scale[0]-=((scalea[3]-scalea[2])-(scalea[1]-scalea[0]))/2 else: scale[2]-=((scalea[1]-scalea[0])-(scalea[3]-scalea[2]))/2 scale[3]+=((scalea[1]-scalea[0])-(scalea[3]-scalea[2]))/2 graph(scale) 

When I run it in python 3.2, it works fine. The image looks like this:

However, when I run it in python 2.7, I get a terrible image that looks like this:

Can this be fixed?

Answer 1

Yes, add this to the top of the file:

 from __future__ import division 

Python 2 uses integer division (gender separation) when using integer inputs by default; Python 3 switched to floating point division even when using integer inputs.

See PEP 238 , which documents the change:

The current division operator (/) has an ambiguous value for numeric arguments: it returns the gender of the mathematical division result if the arguments are ints or longs, but this returns a reasonable approximation of the division result if the arguments are float or complex. This means that expressions expecting a float or complex results are error prone when integers are not expected, but possible as input.

Answer 2

Add from __future__ import division at the top.