seki has asked for the wisdom of the Perl Monks concerning the following question:

Hello Monks

I am getting the following warning after a code refactoring where the optional divisor value passed via a parameter hashtable can be undef (because non-existent in the hashtable), even when trying to use a condition. For example

if ($divide_by){ $data_to_sum[0]->[$c] /= $divide_by; }

and

$data_to_sum[0]->[$c] /= $divide_by if $divide_by;

result in the same warning. What is the correct way to do? Use a default value of 0 to make the test work?

The best programs are the ones written when the programmer is supposed to be working on something else. - Melinda Varian

Replies are listed 'Best First'.
Re: Argument "" isn't numeric in division (/)
by LanX (Saint) on Jul 03, 2017 at 12:05 UTC
    both arguments should be numeric, check the numerator too.

    DB<2> use warnings; ""/3 Argument "" isn't numeric in division (/) at (eval 10)[C:/Perl_64/lib/ +perl5db.pl:646] line 2.

    Cheers Rolf
    (addicted to the Perl Programming Language and ☆☆☆☆ :)
    Je suis Charlie!

    update

    Laurent_R++ for correction: numerator <-> denominator

Re: Argument "" isn't numeric in division (updated)
by haukex (Archbishop) on Jul 03, 2017 at 12:13 UTC

    Since you're checking $divide_by for a true value (Truth and Falsehood), it's likely that $data_to_sum[0]->[$c] is empty, as LanX pointed out (Update before posting: and as you just discovered yourself). I just wanted to point out tip #4 from the Basic debugging checklist: Use Data::Dumper to see what the variables really contain (although personally I prefer Data::Dump):

    use Data::Dump; dd $data_to_sum[0]->[$c], $divide_by; $data_to_sum[0]->[$c] /= $divide_by if $divide_by; print $data_to_sum[0]->[$c], "\n"; __END__ ("", 123) 0

    Update: Actually, it turns out that using Data::Dump in this case might confuse the issue more, since it has an issue that causes it to silence the warning in question. So in this case, I recommend Data::Dumper, and I would recommend turning on its Useqq option (as it makes issues with control characters in the string easier to spot):

    use Data::Dumper; $Data::Dumper::Useqq=1; print Dumper($data_to_sum[0]->[$c], $divide_by); $data_to_sum[0]->[$c] /= $divide_by if $divide_by; print $data_to_sum[0]->[$c], "\n"; __END__ $VAR1 = ""; $VAR2 = 123; Argument "" isn't numeric in division (/) at ... 0

    Update 2019-08-17: Updated the link to "Truth and Falsehood".

Re: Argument "" isn't numeric in division (/)
by thanos1983 (Parson) on Jul 03, 2017 at 14:04 UTC

    Hello seki,

    I read that you found your answer already to your question, but I think it is interesting to read also perlnumber, integer or even casting the numbers with int.

    Related to your question, just a simple example:

    #!usr/bin/perl use say; use strict; use warnings; use Math::Roman qw(roman); use Scalar::Util qw(looks_like_number); my @array = ("8", "", 8, "132.8", 132.8, "III", roman('III')); foreach my $array_element (@array) { if (looks_like_number($array_element)) { say "Element: ".$array_element." is a number"; } else { say "Element ".$array_element." isn't a number"; } } __END__ $ perl test.pl Element: 8 is a number Element isn't a number Element: 8 is a number Element: 132.8 is a number Element: 132.8 is a number Element III isn't a number Element: III is a number

    I used Math::Roman and Scalar::Util. Also this is a frequently asked question perlfaq4/How do I determine whether a scalar is a number/whole/integer/float?.

    Similarly asked question A function to determine if a string is numeric.

    Hope this helps, BR.

    Seeking for Perl wisdom...on the process of learning...not there...yet!
Re: Argument "" isn't numeric in division (/)
by seki (Monk) on Jul 03, 2017 at 12:07 UTC

    Argl. My fault. As often like on StackO, I have discovered the answer just after posting the question.

    After using the debugger, the non-numeric value is on the left side of the expression (it is coming from a sql select and can also be null/empty in some circumstances).

    The best programs are the ones written when the programmer is supposed to be working on something else. - Melinda Varian
      I have discovered the answer just after posting the question.

      That's called Rubber Duck Debugging, and it happens to the most of us.

        I don't play with ducks, the colleague that teached me Perl rather shown me the teddy bear's method: brian's Guide to Solving Any Perl Problem.

        The best programs are the ones written when the programmer is supposed to be working on something else. - Melinda Varian
A reply falls below the community's threshold of quality. You may see it by logging in.