fun programming site
http://projecteuler.net/index.php?section=problems
Having fun with the problems there. They are all math related problems, of a nature that is typically impractical to do by hand. I'm using Perl, though I have done one in C after doing it in Perl to see how much faster it was.
I like math for practicing programming. The problem you need to solve is precisely defined. Often you can directly compute the needed answer. Other times, where you need to use a brute force algorithm, you can easily define upper and lower bounds and easily recognize the answer once you find it.
While a good programmer should certainly be able to solve less clearly defined problems, math problems are good starting points.
This site likes to have their problems use techniques from earlier problems. I've taken this as an opportunity to practice creating Perl modules. Somehow, my is_prime() function, at least for inputs that Project Euler problems call for, runs faster than the Math::Primality modules is_prime() function. I suspect I'm doing something wrong with the latter. I've set up four modules so far(not on CPAN yet, but they will be at some point). Uatha::Base covers, well, baseline stuff the others use. Currently all it does is define TRUE=1 and FALSE=0 constants. This helps make some boolean code more self documenting. Uatha::Math::Tests covers tests on numbers, like the mentioned is_prime(). Uatha::Math::Arrays covers math operations on entire arrays, which has been needed in a few. Uatha::Data::Arrays covers stuff dealing with accessing arrays- the most useful bits I have there are slice generation functions for 2D arrays. I needed diagonal slices for one problem, and that gets hairy enough that having it inline even once gets confusing. It makes vertical and even horizontal slices(for 2D arrays, anyways) easier as well.
Uatha, by the way, is the Irish word for "singular". Some of these modules I'm creating do and will overlap in concept and even names with existing modules, so starting their names off with something that, at least at present, noone in CPAN is using, will help to reduce naming collisions and make them easier to manage when they do occur.
Most of the earlier ones run so fast that I haven't even thought of recoding in something faster than Perl, though a Collatz problem did take ~10 seconds in Perl. Just for the heck of it I decided to reimplement the exact same algorithm in C. The C version ran in less than a second.
Having fun with the problems there. They are all math related problems, of a nature that is typically impractical to do by hand. I'm using Perl, though I have done one in C after doing it in Perl to see how much faster it was.
I like math for practicing programming. The problem you need to solve is precisely defined. Often you can directly compute the needed answer. Other times, where you need to use a brute force algorithm, you can easily define upper and lower bounds and easily recognize the answer once you find it.
While a good programmer should certainly be able to solve less clearly defined problems, math problems are good starting points.
This site likes to have their problems use techniques from earlier problems. I've taken this as an opportunity to practice creating Perl modules. Somehow, my is_prime() function, at least for inputs that Project Euler problems call for, runs faster than the Math::Primality modules is_prime() function. I suspect I'm doing something wrong with the latter. I've set up four modules so far(not on CPAN yet, but they will be at some point). Uatha::Base covers, well, baseline stuff the others use. Currently all it does is define TRUE=1 and FALSE=0 constants. This helps make some boolean code more self documenting. Uatha::Math::Tests covers tests on numbers, like the mentioned is_prime(). Uatha::Math::Arrays covers math operations on entire arrays, which has been needed in a few. Uatha::Data::Arrays covers stuff dealing with accessing arrays- the most useful bits I have there are slice generation functions for 2D arrays. I needed diagonal slices for one problem, and that gets hairy enough that having it inline even once gets confusing. It makes vertical and even horizontal slices(for 2D arrays, anyways) easier as well.
Uatha, by the way, is the Irish word for "singular". Some of these modules I'm creating do and will overlap in concept and even names with existing modules, so starting their names off with something that, at least at present, noone in CPAN is using, will help to reduce naming collisions and make them easier to manage when they do occur.
Most of the earlier ones run so fast that I haven't even thought of recoding in something faster than Perl, though a Collatz problem did take ~10 seconds in Perl. Just for the heck of it I decided to reimplement the exact same algorithm in C. The C version ran in less than a second.