@acer : how is this?

with(ImageTools):
BF8 := proc(ra, rb, xr, yr, n)
local data;
  data := ImageTools:-Create(yr, xr, 1);
  worker(data, HFloat(evalf(ra)), HFloat(evalf(rb)), xr, yr, n);
  return data;
end proc:
worker := proc(
  data :: Array(datatype=float[8], order=C_order),
  ra :: float[8],
  rb :: float[8],
  xr :: posint,
  yr :: posint,
  n :: posint)
local
  ix :: posint,
  iy :: posint,
  r :: float[8],
  rscale :: float[8],
  x :: float[8],
  y :: posint;

  rscale := (rb - ra) / (xr - 1);
  for ix to xr do
    r := ra + rscale * (ix - 1);
    x := HFloat(0.5);
    for iy to 3 do
      # Warmup.
      x := r * x * (1-x);
    end do;
    for iy to n do
      x := r * x * (1-x);
      y := trunc(x * yr) + 1;
      data[y, ix] := data[y, ix] + 1;
    end do;
  end do;
end proc:
worker := Compiler:-Compile(worker):
m := BF8(2.6, 4, 1000, 1000, 250):
map[inplace, evalhf](`/`, m, max(m)):
m3 := m ^~ (1/3):
ImageTools:-Write("abc.tiff", m3):

Leads to this image (converted to png). As you see it's upside down; easy to fix but I didn't bother. If your screen is too narrow (as mine is - I use my monitor in portrait mode), there's a scaled down version below.

Erik.

@Joe Riel : I think I like the idea of a 'let ... in ...' statement and I'd probably use it frequently. It would potentially lead to very high levels of nesting, I imagine, which would be an issue for aesthetical reasons - I would probably request to have your maplev-mode not indent the blocks inside these statements. I wonder whether the memory manager could be made to take advantage of the immutability of these guys. Maybe it would also be nice to have a way to close multiple let... in... scopes at once. (It's interesting to note the difference with the ?use statement, by the way, which creates only a temporary binding (not even a real name) for an expression - it doesn't evaluate the expression at the beginning of the statement, but does so every time it is referenced.)

On the whole I agree with Jacques' comments regarding option remember. I think we now have a slightly better approach with ?option/cache in that it can't grow arbitrarily out of control as easily in terms of memory usage overhead, but it can still be tricky in terms of memory access overhead (and other overhead, and considerations such as mutable data structures and side effects).

Erik.

Joe: I think the reason that unapply(f(x), x) doesn't return f is, that the result of unapply(f(x), x) should require a first argument and ignore the second and further arguments. f itself may not have that property. For example:

f := proc(a, b, c, $)
  if not type([_passed], 'list(numeric)') then
    return 'procname'(_passed);
  elif _npassed = 0 then
    return 1;
  elif _npassed = 1 then
    return a;
  else
    return `*`(_passed);
  end if;
 end proc;

Now f(x) evaluates to itself; and unapply(f(x), x) evaluates to, effectively, the identity function on a single argument. However, f itself is a more complicated beast, and maybe unapply was used specifically to 'tame' it.

Erik Postma
Maplesoft. 

Joe: I think the reason that unapply(f(x), x) doesn't return f is, that the result of unapply(f(x), x) should require a first argument and ignore the second and further arguments. f itself may not have that property. For example:

f := proc(a, b, c, $)
  if not type([_passed], 'list(numeric)') then
    return 'procname'(_passed);
  elif _npassed = 0 then
    return 1;
  elif _npassed = 1 then
    return a;
  else
    return `*`(_passed);
  end if;
 end proc;

Now f(x) evaluates to itself; and unapply(f(x), x) evaluates to, effectively, the identity function on a single argument. However, f itself is a more complicated beast, and maybe unapply was used specifically to 'tame' it.

Erik Postma
Maplesoft. 

What is the exact message you get? Is it "Error, recursive assignment"? If so, then you did not execute the statement c := 0, or you assigned something else to c after assigning 0 to c. Executing those two statements in order cannot give you that error message.

Hope this helps,

Erik Postma
Maplesoft.

@acer : Yes, I meant to include that option. I wonder where I dropped it - I ran the code, so I must have done something wrong copying and pasting. I agree with your other remarks as well.

Erik.

@acer : Yes, I meant to include that option. I wonder where I dropped it - I ran the code, so I must have done something wrong copying and pasting. I agree with your other remarks as well.

Erik.

@pagan : If that's the case, then I think there is no finite optimal solution. If we take c fixed for the moment, we can get optimal values for a and b by running

Statistics:-ExponentialFit(ln~([3.05, 3.1, 3.75] -~ c), [.74e-4, .1806e-3, .584e-4]);

(at least, optimal in a slightly perturbed metric). We can find the minimal sum of squared residuals for a given value of c as follows:

minsumsq := c -> Statistics:-ExponentialFit(ln~([3.05, 3.1, 3.75] -~ c),
                                            [.74e-4, .1806e-3, .584e-4]);

It now appears that minsumsq keeps decreasing as c goes to minus infinity (and the corresponding a and b go to plus infinity and minus infinity, respectively). Thus, there's no optimal solution.

Hope this helps,

Erik Postma
Maplesoft.

@pagan : If that's the case, then I think there is no finite optimal solution. If we take c fixed for the moment, we can get optimal values for a and b by running

Statistics:-ExponentialFit(ln~([3.05, 3.1, 3.75] -~ c), [.74e-4, .1806e-3, .584e-4]);

(at least, optimal in a slightly perturbed metric). We can find the minimal sum of squared residuals for a given value of c as follows:

minsumsq := c -> Statistics:-ExponentialFit(ln~([3.05, 3.1, 3.75] -~ c),
                                            [.74e-4, .1806e-3, .584e-4]);

It now appears that minsumsq keeps decreasing as c goes to minus infinity (and the corresponding a and b go to plus infinity and minus infinity, respectively). Thus, there's no optimal solution.

Hope this helps,

Erik Postma
Maplesoft.

That's the first problem. The next is, the entries of S cannot be substituted into anything - what you need is equations of the form variablename = value. So you could define S as:

S := [seq(seq([h1 = h1vals[ii], h2 = h2vals[ii], h3 = h3vals[ii], h4 = h4vals[ii], h5 = h5vals[ii], h6 = h6vals[ii], 
                    w = wvals[jj]], jj = 1 .. 4), ii = 1 .. 4)];

assuming that sys is a system of (polynomial) equations in the variables h1, h2, ..., h6, and w.

If your system of equations is multivariate and not polynomial (and it does look like that from the rest of your worksheet), try using ?fsolve instead of ?RootFinding/Isolate.

Hope this helps,

Erik Postma.

That's the first problem. The next is, the entries of S cannot be substituted into anything - what you need is equations of the form variablename = value. So you could define S as:

S := [seq(seq([h1 = h1vals[ii], h2 = h2vals[ii], h3 = h3vals[ii], h4 = h4vals[ii], h5 = h5vals[ii], h6 = h6vals[ii], 
                    w = wvals[jj]], jj = 1 .. 4), ii = 1 .. 4)];

assuming that sys is a system of (polynomial) equations in the variables h1, h2, ..., h6, and w.

If your system of equations is multivariate and not polynomial (and it does look like that from the rest of your worksheet), try using ?fsolve instead of ?RootFinding/Isolate.

Hope this helps,

Erik Postma.

There are three editors that I know support editing Maple source code (more than an arbitrary programming editor): vi and emacs (of course), and a java-based editor called jEdit. Google will find them immediately. Any one of these will make you much happier than your current solution.

Erik Postma.

There are three editors that I know support editing Maple source code (more than an arbitrary programming editor): vi and emacs (of course), and a java-based editor called jEdit. Google will find them immediately. Any one of these will make you much happier than your current solution.

Erik Postma.

@Christopher2222 and @acer: Thanks for bringing these issues to my attention - I fixed the documentation and implementation; these changes should make it into a future version of Maple.

Erik.

@Christopher2222 and @acer: Thanks for bringing these issues to my attention - I fixed the documentation and implementation; these changes should make it into a future version of Maple.

Erik.