in reply to Program Not Printing Help

Is that the actual code that is failing to produce output, or did you type it into the PerlMonks text box manually, introducing some typos in the process? This would be good to know before committing too much time to explaining what's wrong.

Also, when you run it, what error messages do you see? Have you tried fixing those so that it can compile, first? The code you posted does produce output if you're looking at STDERR.

You may also want to have a look at Math::Palindrome, although palindrome testing for numbers in Perl can be as simple as:

sub is_palindromic_number { my $n = 0 + shift; return $n == reverse $n; }

...which is mostly what Math::Palindrome uses internally as a test.


Dave

Replies are listed 'Best First'.
Re^2: Program Not Printing Help
by BillKSmith (Monsignor) on May 16, 2014 at 19:52 UTC
    Dave, Please explain the reason for the zero. It appears to force the scalar result to be a number rather than a string.
    Bill

      That's a good question. Reverse treats its scalar operand as a string, which works fine most of the time, with one notable exception.

      My understanding of numerical palindromes is that 01 should be treated as a number such that its palindrome is 1. If I don't force the value to be cast as a number, reverse will return 10 if given 01 to start with. This may be appropriate for strings, but for numeric values the leading zero should be disregarded, as it is not significant.

      It's possible I'm wrong in my interpretation of how numbers with leading zeros should be treated when considering whether they are palindromes, but my interpretation makes sense to me in my possible ignorance. ;)

      By casting our input as a number before handing it to reverse, we cause the leading zeros to vanish before reverse has a chance to see them and do the wrong thing with them.


      Dave

Re^2: Program Not Printing Help
by Hrand (Initiate) on May 16, 2014 at 17:00 UTC

    This is the actual code, I tried to keep it similar to the working c++ version.

      I can understand your reasons for doing that, but you should know that Perl can be much more efficient than C or C++ in terms of coding (time to write a program, time to debug it, number of code lines, etc.).

      Of course, the other aspect is that a C or C++ program will usually run faster (although not always), often slightly faster and more rarely much faster. But code speed is rarely that important. I am saying this although I am working daily with very large data sets (typically gigabytes or tens of GB, sometimes even more) and I need efficiency. But Perl is just efficient enough for my needs: if I have a program taking an hour to run in Perl, I don't really care if a program might take 50 minutes (this is the type of ratio we experience for our data- and IO-intensive processes, it would be different for computation-intensive processes). And quite often, a good use of Perl built-in efficient data structures will actually lead to Perl actually performing better.

      A typical example of coding efficiency in Perl: last week a colleague of mine rewrote a C program in Perl. The 4,000-line C program (including .h files, etc.) was replaced by a less than 400-line Program. And this colleague is a good developer but only started Perl less than 2 months ago (OK, he took advantage of a program I had written doing something relatively similar, and I helped him a bit on a few fine points, but really not that much).

      I am pretty sure that if I had done the porting (or should it be called translation? well, in this case, maybe it should really be called a rewrite) to Perl, the resulting program would have been even shorter (perhaps only about 300 lines), without sacrificing readability the slightest bit.

      On a much shorter program like here, you will probably not see such high code-volume reduction ratios, but it can be still very significant.

      All this to say that if you should start to use Perl, you might try to build on its much more powerful expressive capacities.