Hello Hrand, and welcome to the Monastery!

First: always begin your script with:

use strict;
use warnings;
[download]

as this will help you identify typos and other syntax errors.

Second, you cannot pass subroutine arguments in Perl as you do in C/C++. You need something like:

sub isPalindrome
{
    my $orig = shift;
    my $reversed = 0;
    my $n = $orig;
    ...
[download]

Third, there is a logic error in the second for loop: the first occurrence of the line:

$temp++;
[download]

should be deleted.

There are various other observations that could be made as to style, such as preferring for my $i (0 .. $testCases - 1) to the C-style loop used, but the points above are the main ones to start with.

Hope that helps,

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;
}
[download]

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

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

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.

Perl does its arithmetic with double-precision floating point, so you probably get 52-bit precision.

for (49..54) {
  $x=2**$_;
  $y = $x + 1.1;
  print $_, "\t", $y-$x;
}

49    1.125
50    1
51    1
52    1
53    2
54    0
[download]

In C++, the size of integer types isn't specified, but long long is probably 64 bits.

If you want to deal with really big numbers, you need to use a package like Math::BigInt.

If you only use ++ and reverse on your "numbers", perl's increment magic will make it Just Work (TM).

$x="100000000000000000000";
$x++;
print $x, "\n";
$x += 1;
print $x, "\n"';

100000000000000000001
1e+20
[download]

You missed line one of his code.

use bigint;
[download]

bigint - Transparent BigInteger support for Perl




Dave

So I did.