in reply to Infinite loop but no reason why

Looking at your code reveals several errors which could be caught with some error checking. For the specific section of code you point out, I note that you have this line:

my $mse = function( $i, $j );

But the function only uses one of those arguments:

sub function($_) #arbitary function...will be given in the partually w
+ritten program
{
    return ( $_[0] - 50.02 )**2 + 2;
}

[download]

There a several problems here. First, the ($_) isn't doing anything. You think you're using a prototype but you're not. I'd remove it. How you actually want to handle your errors is a different story. Here's one way:

use Carp qw/croak/; # put near the top of your program

sub function {
    if ( @_ != 2) {
        croak("function() requires two arguments");
    }
    my ( $x, $y ) = @_;
    # ... body of function
}

[download]

I also note that grid() is passed one more argument than you are using. You either need to test the number of arguments you are passing or test the value of each argument explicitly.

Also, as noted above, you're trying to compare floating point numbers with ==. That's bad and is likely to fail. Instead, you want to determine the what precision is acceptable and round the numbers to that and do a string compare (with eq). Or you could try the Math::Precision module (I haven't used it) or something similar.

To round the numbers and do a string compare, here's what perldoc perlop suggests (though it notes that this is expensive):

    sub fp_equal {
        my ($X, $Y, $POINTS) = @_;
        my ($tX, $tY);
        $tX = sprintf("%.${POINTS}g", $X);
        $tY = sprintf("%.${POINTS}g", $Y);
        return $tX eq $tY;
    }

[download]

Cheers,
Ovid

New address of my CGI Course.

Replies are listed 'Best First'.
Re^2: Infinite loop but no reason why
by ikegami (Patriarch) on Jul 19, 2006 at 15:10 UTC 
        sub fp_equal {
        my ($X, $Y, $POINTS) = @_;
        my ($tX, $tY);
        $tX = sprintf("%.${POINTS}g", $X);
        $tY = sprintf("%.${POINTS}g", $Y);
        return $tX eq $tY;
    }

    fp_equal($x, $y, 3);

    [download]

    could be replaced with 

        sub fp_equal {
        return abs($_[0] - $_[1]) < $_[2];
    }

    fp_equal($x, $y, 0.001);

    [download]

    Pros:

    • Faster because it doesn't convert the numbers to strings.
    • Supports arbitrary precisions (e.g. +-10, +-0.5), not just negative powers of 10.
[reply]
[d/l]
[select]

      I personally prefer relative precision, rather than absolute values, as you frequently don't know what the scale of the number is going to be for these sorts of calculations:

      sub fp_equal {
  my ($x,$y,$precision) = @_;
  $precision ||= 0.000001;

  return 1 if (! defined($x) and ! defined($y) );
  return 0 if (! defined($x) or  ! defined($y) );
  return 1 if ($x == $y);     # for 0 == 0
  ($x,$y) = ($y,$x) if (!$y); # for $y == 0
  return ( abs ( 1 - $x/$y ) <= $precision ) ? 1 : 0;
}

      [download]

      Update: I made an assumption based on the halving of the precision in the OP's problem that this was doing some sort of numerical analysis. ikegami is right in that sometimes you're looking at stepped measurements over a finite range, and so an absolute precision is necessary. (Most of my floating point comparisons are in scientific measurements, and I use relative precision so I don't have to have different definitions of precision for the units used and range of the measurements)

[reply]
[d/l]

        Relative presision removes the need to specify a precision (so it's easier to use), but it has limits.

        For example, most numbers in the real-time control system on which I work are have a range of 0 to 1 (inclusive). Some of the numbers with which I deal are measurements of valve positions. 0 means the valve is fully closed, 0.25 means it's one quarter open, and 1 means it's fully open. If we were to compare two valve positions, we'd consider 4/1000th open and 5/1000th open equal. Because relative precision has no idea these measurements are tiny compared to the range, it would consider them unequal.

        In my experience (in the real-time control systems world), relative presision should only be avoided whenever possible. Absolute precision should be used instead.

        Update:

        Oddly enough, we rarely use any kind of tolerance in our system except during automated testing. Equality checks are rarely if ever needed. Inequalities, on the other hand, are used throughout. We use deadbands to avoid jitter. 

        if ($x < 0.5) {
   # All is ok
   $ok = 1;
   ... normal operation mode ...
}
elsif ($x > 0.7) {
   # Things are definitely bad.
   $ok = 0;
   ... exceptional operation mode ...
}
elsif ($ok) {
   # In deadband. Was last ok.
   ... normal operation mode ...
}
else {
   # In deadband. Was last bad.
   ... exceptional operation mode ...
}

        [download]
[reply]
[d/l]

In Section Seekers of Perl Wisdom