Comments on: Project Euler Problem 4 http://basildoncoder.com/blog/2008/04/21/project-euler-problem-4/ Incoherent and disjointed opinionated drivel from somewhere near London Sat, 22 Nov 2008 16:49:45 +0000 http://wordpress.org/?v=2.3.1 By: russ http://basildoncoder.com/blog/2008/04/21/project-euler-problem-4/#comment-985 russ Wed, 23 Apr 2008 17:34:16 +0000 http://basildoncoder.com/blog/2008/04/21/project-euler-problem-4/#comment-985 You can do some fancy functional stuff without leaving Perl, if you've got the stomach for it ;-) Try the <a href="http://search.cpan.org/~lbrocard/Language-Functional-0.03/Functional.pm" rel="nofollow">Language::Functional</a> module from CPAN, which gives you map, foldl, filter, take, and lots of other fundamental functions, though it doesn't really approach something like Haskell or F# (so you might find it tricky to emulate the pipeline of the F# solution above). You can do some fancy functional stuff without leaving Perl, if you’ve got the stomach for it ;-) Try the Language::Functional module from CPAN, which gives you map, foldl, filter, take, and lots of other fundamental functions, though it doesn’t really approach something like Haskell or F# (so you might find it tricky to emulate the pipeline of the F# solution above).

]]> By: Sol http://basildoncoder.com/blog/2008/04/21/project-euler-problem-4/#comment-983 Sol Wed, 23 Apr 2008 16:26:12 +0000 http://basildoncoder.com/blog/2008/04/21/project-euler-problem-4/#comment-983 Oh sure, my last comment wasn't meant to contradict, just explain my "lens" a little bit better. I forgot to say that I do, in fact, do lots of work in "higher" languages, most often Perl, and look forward to the day I have enough spare to to explore one of these fancy new functional languages in depth. Oh sure, my last comment wasn’t meant to contradict, just explain my “lens” a little bit better. I forgot to say that I do, in fact, do lots of work in “higher” languages, most often Perl, and look forward to the day I have enough spare to to explore one of these fancy new functional languages in depth.

]]> By: russ http://basildoncoder.com/blog/2008/04/21/project-euler-problem-4/#comment-980 russ Wed, 23 Apr 2008 14:19:26 +0000 http://basildoncoder.com/blog/2008/04/21/project-euler-problem-4/#comment-980 Again, you're right in all details, I just think we're looking at it through slightly different lenses. I worked on embedded software for a few years so I do have some exposure to areas where efficiency is paramount, and it still does crop up in desktop and web development (which is where I earn a crust these days), so I'd never claim it's completely irrelevant. In fact, maybe part of the reason I'm not pandering to it here is because I'm indulging myself by ignoring it ;-) Regarding the choice of C in this post, if you look at some of the other posts in the series you'll see that I often do a straightforward imperative solution first, as to most developers that is still the most recognisable form. I chose C here partly in line with that, and partly on a whim - but not because I had performance (or lack of it) in mind. I haven't written any C code in anger for a couple of years, and this seemed like a good chance to review some of the basics. The string reversal/comparison stuff was simply the first straightforward solution that popped into my head. It was also convenient in that it was an approach that would work in most other languages, whereas mutating the string with pointers is a bit less universal :-) Again, you’re right in all details, I just think we’re looking at it through slightly different lenses. I worked on embedded software for a few years so I do have some exposure to areas where efficiency is paramount, and it still does crop up in desktop and web development (which is where I earn a crust these days), so I’d never claim it’s completely irrelevant. In fact, maybe part of the reason I’m not pandering to it here is because I’m indulging myself by ignoring it ;-)

Regarding the choice of C in this post, if you look at some of the other posts in the series you’ll see that I often do a straightforward imperative solution first, as to most developers that is still the most recognisable form. I chose C here partly in line with that, and partly on a whim - but not because I had performance (or lack of it) in mind. I haven’t written any C code in anger for a couple of years, and this seemed like a good chance to review some of the basics.

The string reversal/comparison stuff was simply the first straightforward solution that popped into my head. It was also convenient in that it was an approach that would work in most other languages, whereas mutating the string with pointers is a bit less universal :-)

]]> By: Sol http://basildoncoder.com/blog/2008/04/21/project-euler-problem-4/#comment-974 Sol Wed, 23 Apr 2008 10:53:25 +0000 http://basildoncoder.com/blog/2008/04/21/project-euler-problem-4/#comment-974 Yeah, my thoughts on this seem to be muddled. I think I have two issues. It seems to me that the solution of converting the string to an array, reversing the array, then converting the array back to a string is both grotesquely inefficient and somewhat inelegant. But on the flip side, it's dead easy to program quickly and be certain that you've got it right. My corresponding instinct is that you should probably only be dropping into C if program efficiency is important. So even though I'd agree that your second C solution (in the next post) is probably the most elegant solution, my programming instincts look at it and go "Ack! Why is he doing the simple greater than check only after doing all the string manipulation?!" I guess my overall instinct is that if programmer efficiency is of paramount importance, you shouldn't be working in C at all. Combined with a slight layer of bitterness at all the very high level language advocates who are always trying to tell me that program efficiency isn't that important anymore, when in my work it is still crucial (and likely will remain so for at least another decade). :) Yeah, my thoughts on this seem to be muddled. I think I have two issues.

It seems to me that the solution of converting the string to an array, reversing the array, then converting the array back to a string is both grotesquely inefficient and somewhat inelegant. But on the flip side, it’s dead easy to program quickly and be certain that you’ve got it right.

My corresponding instinct is that you should probably only be dropping into C if program efficiency is important. So even though I’d agree that your second C solution (in the next post) is probably the most elegant solution, my programming instincts look at it and go “Ack! Why is he doing the simple greater than check only after doing all the string manipulation?!”

I guess my overall instinct is that if programmer efficiency is of paramount importance, you shouldn’t be working in C at all. Combined with a slight layer of bitterness at all the very high level language advocates who are always trying to tell me that program efficiency isn’t that important anymore, when in my work it is still crucial (and likely will remain so for at least another decade). :)

]]> By: russ http://basildoncoder.com/blog/2008/04/21/project-euler-problem-4/#comment-951 russ Tue, 22 Apr 2008 08:58:33 +0000 http://basildoncoder.com/blog/2008/04/21/project-euler-problem-4/#comment-951 You're right, but I should point out that programmer efficiency - or more specifically expressiveness - is indeed what I am interested in here. The goal of this series is to complete a solution to each problem in multiple languages, and evaluate the solutions subjectively. Of course, the language choice is fairly arbitrary for each post (bar C#, which I'm currently coding for a living and therefore tends to pop up a lot) so I don't claim this will be anything definitive. It's more an exploration. Actually, I've missed a fairly obvious final step here to increase expressiveness further, which I'll do a separate post on later. You’re right, but I should point out that programmer efficiency - or more specifically expressiveness - is indeed what I am interested in here. The goal of this series is to complete a solution to each problem in multiple languages, and evaluate the solutions subjectively.

Of course, the language choice is fairly arbitrary for each post (bar C#, which I’m currently coding for a living and therefore tends to pop up a lot) so I don’t claim this will be anything definitive. It’s more an exploration.

Actually, I’ve missed a fairly obvious final step here to increase expressiveness further, which I’ll do a separate post on later.

]]> By: Sol http://basildoncoder.com/blog/2008/04/21/project-euler-problem-4/#comment-945 Sol Tue, 22 Apr 2008 03:01:47 +0000 http://basildoncoder.com/blog/2008/04/21/project-euler-problem-4/#comment-945 I don't see why you just don't check the string directly to see if it is a palindrome. Unless I'm missing something, it's exactly the same complexity as your C string reverse function up there, conceptually cleaner, and more efficient. Obviously the reverse thing makes more sense when you've got the fancy language and you care more about the programmer's efficiency than you do about the program's efficiency.... I don’t see why you just don’t check the string directly to see if it is a palindrome. Unless I’m missing something, it’s exactly the same complexity as your C string reverse function up there, conceptually cleaner, and more efficient. Obviously the reverse thing makes more sense when you’ve got the fancy language and you care more about the programmer’s efficiency than you do about the program’s efficiency….

]]>