Fri 29 Oct 2010 04:36:47 PM UTC, comment #3:
This is confirmed on a recent tip (2010-10-29). The bug seems to be the parsing of the comma, which can ordinarily be a break between statements. In this case, the comma is separating arguments in a function call but it appears that the parser for printing out the function has gotten confused.
Below is a slightly simpler example to show the problem.
|
Fri 29 Oct 2010 02:25:07 AM UTC, comment #2:
|
Fri 29 Oct 2010 01:25:38 AM UTC, original submission:
> c = @(f, T, n, t) (1/T)trapz(t, f(t).exp(-j.2.pi./T.n.t))
> four = @(f, T, n, t) sum(arrayfun(@(N) c(f, T, N, linspace(0, T, 100)).exp(j2pi/TN*t), [-n:n]))
> afour = @(f, T, N, t) arrayfun(@(x) four(f, T, N, x), t)
> save fourier
The printed representation of four/afour is incorrect, for instance:
afour =
@(f, T, N, t) arrayfun (@(x) four (f, T, N, x);
, t)
This of course prohibits loading the file; the file will only load after manual correction to the entries for four/afour.
octave:1> load fourier
parse error:
syntax error
>>> @(f, T, N, t) arrayfun (@(x) four (f, T, N, x);
Attached is the file "fourier" produced by the command "save fourier".
|