> No, I'm setting specific radii (in pixels) and testing against a 2D
> array using a brute-force method. In POV I was doing radius comparisons.
> At any rate, I'm only having to do the sqrt(x*x+y*y) calculation 128*128
> times when the program starts, to fill an array. It's like 1/4 of a
> cylindrical pigment, and is the maximum circle radius. It's a drop in
> the bucket, really.

Oh, OK. So you're creating an actual image and filling it with circles?

FWIW, you still probably don't need the sqrt. You probably have 
something like

if ( sqrt( x*x + y*y ) < radius )

which can just be

radiusSquared = radius * radius;
...
if ( x*x + y*y < radiusSquared )

>
> Of course, with today's computers I can afford to be so wasteful. Not
> that my program is running at record speeds or anything. Maybe if I knew
> assembly language... :(

Knowing assembly language isn't really the key to making faster 
programs. I mean, if you're an expert at assembly, then you can probably 
push your program's speed a little bit, but modern compilers do a pretty 
good job already. You're more likely to improve your program's speed in 
other ways. For instance, by learning how to avoid cache misses by 
keeping commonly accessed data close together or by changing your 
algorithm to avoid jumping around in memory. Also, if there's any chance 
that there's a better algorithm for what you're trying to do (and it 
seems there always is), then it would be better to spend your time 
finding it than rewriting the current algorithm in assembly.

  - Slime

Post a reply to this message