Stavros Macrakis wrote:
> On 5/25/07, Thomas Widlar < twidlar at yahoo.com
> <mailto:twidlar at yahoo.com>> wrote:
>
> Yes, about 2 hours, with numericalio.lisp modified 5/23/2007 4.14pm
>
>
> a) Are you sure that the revised version of the code is being loaded
> and executed properly? Try defining it as $read_list1 and calling
> that to be sure.... But even the old version shouldn't be this slow.
I cloned a read_list1 function. It executes. The revised version is loaded.
> b) I hope you're not trying to display the result (by having a ";" at
> the end of your command) -- that can easily take large amounts of time
> in any implementation. I don't know wxMaxima; does it *always*
> display the result? If so, try ( q: read_list(...), length(q) ),
> which will read in the list and then return just its length, not the
> whole list.
You're right, with '$' it takes wxmaxima about 20 secs to read 215626
float numbers.
with read_list. With ';' it takes about 2 hours to figure out it can't
display it or whatever
it is doing.
> I forget -- did you say that you didn't have this problem on other
> versions of Maxima besides wxMaxima? If so, that would be strange,
> since the computational core is the same.
maxima can read or read and display the huge list with no trouble.
Here are some speed comparisons on my machine (1Ghz, 500MB, Windows
2000, GCL) using an input file very similar to yours. It consists of
158,000 floating-point numbers which look like 1.000000001428572,
arranged five to a line, a total of 3 MB.
>
> 580 sec old read_list
> 30 new read_list
> 32 read as a Maxima list using load; file is q:[ ... ]$
> 0.7 read as a Lisp list using load; file is (setq q '(...))
> 0.5 just read file to EOF using Lisp read-line
>
> Clearly there is a large overhead for using the Maxima parser rather
> than the Lisp reader; that is not too surprising, since the Maxima
> parser is written in Lisp, while the Lisp reader is presumably written
> in C, and has access to low-level data structures. Still, a factor of
> almost 50 is a bit disappointing....
>
> But that still doesn't explain how your system takes 240 x as long for
> read_list. It does explain why your code is faster than read_list: it
> uses parsetoken, which uses the Lisp reader. read_list uses the
> Maxima reader, since it must handle bfloats as well as floats and
> integers. This could be improved in various ways if reading in large
> numeric files is a common requirement.
>
> -s
>
> PS parsetoken is actually buggy because it uses the Lisp parser, but I
> will fix that....
It handled integers and floats like 0.0000000E+00 OK.