Re: recursive formula.

[QM]

It seems you have some solutions, so I'm taking a different tack. Two points:

1) You'd probably benefit more from showing us a little code with your question, before seeing the solutions.

2) You may want to look at Memoize, like so:

use Memoize;
# make sure memoize happens before p is called
BEGIN { memoize('p'); }

Or, cache it yourself:

{ # closure for sub p

  my %seen;

  sub p
  {
    my $arg_string = join '^', @_;
    return $seen{$arg_string} if exists $seen{$arg_string};

    # compute $result here as usual
    # ...

    return $seen{$arg_string} = $result;
  } # end sub p

} # end closure for sub p

I leave it to you to work out how to handle the empty parameter list :)

Update: See BrowserUk's Re^2: recursive formula. below for reasons why this isn't a good idea.

[BioGeek]

I liked the following line from the Memoize perldoc:


"This module exports exactly one function, memoize. The rest of the functions in this package are None of Your Business."


I will look into the empty parameter list stuff.

[BrowserUk]

Memoize won't help for this as for any given set of data, the function will never be called twice with the same set of values. (Apart from the trivial case where the function is called with a single value. And in that case, the single value is return as a special case to end the recursion.)

For large datasets, Memoize would actually slow this function down by building a cache of values that would only ever be hit by chance. That chance, is if there exists two (or more) identical values in dataset.

Given the parameters are lists of floating point values with a continuous domain, "identical values" is an ethereal thing.

Also, the cache-key will be a function of both the number of values in the list, and their ordering. The size of the cache can quickly grow very large without ever providing payback.

[QM]

Memoize won't help for this as for any given set of data, the function will never be called twice with the same set of values.

Ah, yes, I missed that.

I initially thought that the function might be called multiple times with only slight changes to the data tables. [After all, why write a program if it's only going to be used once?] If it's only called once on 1 table of data, you are correct, there's little to gain. And if it's called with more than one data table, but they are largely independent, there's still little gain. It's only if the tables all have lots of overlap that it makes a difference. We could also debate whether recursion this shallow has much to gain, regardless of the undlerlying function or data. We'll have to let the OP comment on his intended use.

All of this reminds me of TheDamian's Tachyonic Variables talk. I won't divulge the secret, but in any case the actual module he developed isn't available yet.