From: Jan Simon on
Dear Paul,

> I couldn't quite find where the maximum length of a line in an .m file is specified... does anyone know?

Yes, now we *all* know, that you couldn't find this. ;-)

In Matlab 5.3 there was a limit of the line length in M-files -- even for lines continued by "...". In Matlab 6.0 this limit disappeared.
I'm not sure how long this limit was. One of my files ran fine with a line of 14400 characters.

Kind regards, Jan
From: Walter Roberson on
Jan Simon wrote:
>> I couldn't quite find where the maximum length of a line in an .m file
>> is specified... does anyone know?

> In Matlab 5.3 there was a limit of the line length in M-files -- even
> for lines continued by "...". In Matlab 6.0 this limit disappeared.
> I'm not sure how long this limit was. One of my files ran fine with a
> line of 14400 characters.

eval(repmat('+1',1,100000))

is still going on my 2008b system. It's taking a while...


eval() isn't absolute proof about what would be accepted in a .m file, but
limits such as 16Kb per line (POSIX BUFSIZ) are routinely surpassed in modern
computer languages so I don't _expect_ any significant difference between
eval() and .m files.

On the other hand, I never expected the eval() to take anywhere near as long
as it is.
From: Jan Simon on
Dear Walter,

> > In Matlab 5.3 there was a limit of the line length in M-files -- even
> > for lines continued by "...". In Matlab 6.0 this limit disappeared.
> > I'm not sure how long this limit was. One of my files ran fine with a
> > line of 14400 characters.

If it was not clear enough: An M-file containing a continued line with 14'400 characters runs fine in Matlab 5.3. But with 68'000 characters, Matlab 5.3 fails to start or P-code the M-file.
In Matlab 6.0 this limit was removed as claimed in the documentation.

> eval(repmat('+1',1,100000))
Wow.
Matlab 6.5.1 is less powerful:
eval(repmat('+1', 1, 47515)) % Ok
eval(repmat('+1.0', 1, 47515)) % Ok
But for
eval(repmat('+1', 1, 47516)) % Crash
Matlab terminates immediately without any message. The string length is obviously not the problem, as the '+1.0' example shows.

Look at the timings:
tic; eval(repmat('+1', 1, N)); toc
N = 1e4:
Matlab 6.5: 0.1 sec
Matlab 2009a: 1.2 sec
N = 2e4:
Matlab 6.5: 0.19 sec
Matlab 2009a: 10.97 sec

So the modern Matlab needs 10 times longer to process the double size of input. Similar effects appear if the large string is written in an M-file:
FID = fopen('DullSum.m', 'wb');
fprintf(FID, 'function s = DullSum\n s = ');
fprintf(FID, repmat('+1', 1, 20000));
fprintf(FID, ';\n');
fclose(FID);

Matlab 6.5:
tic; DullSum, toc % First call, 0.7 sec
tic; DullSum, toc % Subsequent calls, <0.01 sec
Matlab 2009a:
tic; DullSum, toc % First call, 11.27 sec
tic; DullSum, toc % Subsequent calls, 0.0002 sec

My conclusion: Do not use EVAL for large expressions.
Or more general: Do not use EVAL at all, because it performs the time-consuming parsing for each call again.

Kind regards, Jan
From: Walter Roberson on
Jan Simon wrote:

>> eval(repmat('+1',1,100000))
> Wow.
> Matlab 6.5.1 is less powerful:
> eval(repmat('+1', 1, 47515)) % Ok
> eval(repmat('+1.0', 1, 47515)) % Ok
> But for
> eval(repmat('+1', 1, 47516)) % Crash
> Matlab terminates immediately without any message.

2008b kept thinking about eval(repmat('+1',1,100000)) for a time, but
eventually segmentation faulted.

2008b spends about 2.87 seconds for 20000, about 13 seconds for 30000, about
30 seconds for 40000 (22 seconds on a second run, about 16 on further tests),
but faults for 40500 (Linux 64 bit with 10 Gb of memory)

Even eval(repmat('+0',1, 40500)) crashes for me in 2008b.


It is not pure string length; for example, using semi-colon instead of + can
take long strings very quickly -- e.g., 4.2 seconds for 400500 repetitions.
From: Jan Simon on
Dear Walter,

and it is no crash of the JIT:
feature('JIT', 'off');
feature('accel', 'off');
eval(repmat('+1', 1, 47516)) % Crash in Matlab 6.5

Obviously it is the revenge of EVAL.

Jan
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Matlab GUI code - zeros
Next: Optmisation problem