| Re: GDL - a little uppdate... [message #43768 is a reply to message #43729] |
Tue, 26 April 2005 10:04   |
George White
Messages: 10
Registered: November 1998
|
Junior Member |
|
|
On 22 Apr 2005, Y.T. wrote:
>
> m_schellens@hotmail.com wrote:
>> GDL - GNU Data Language, the free IDL clone
>>
>>
>> Now with z-buffer device, new subroutines, many improvements,
>> important bug fixes...
>>
>> GDL now understands main programs and the .RUN command :-)
>>
> [ etc etc ]
>
>
> So I had a look at that, and I am a lot less impressed than I was when
> I first heard that there is such a thing as a free IDL clone.
>
> As far as I can figure out, GDL uses the 'readline' library to receive
> input from the user, the 'gsl' library to perform the math and 'plplot'
> to output the result -- in other words, it is really just a parser that
> connects some other pieces.
>
> Now by itself that isn't a problem, but I do have to wonder about the
> choice -- why gsl? why plplot?
It is a problem if GDL can't readily substitute other libraries. Plotting
is a tricky area, but certainly for the numerical codes there are often
newer libraries that are significantly better for certain problems than
the "state of the art" a few years ago..
IDL uses Numerical Recipes, which tends to err on the side of simplicity
while GSL aims to stay closer to the "state of the art", but that doesn't
say you won't run into limitations on a particular problem.
> Isn't gnuplot much, much, much more popular? I'm not aware of any
> current linux distro that doesn't have it -- while the latest plplot
> rpm for redhat that I can find is for 7.3, and there don't seem to be
> any newer .debs or slack-tgzs either.
Popularity is the last metric an IDL fan should be using -- if you want
popular you'll have to stick with Excel. Gnuplot's underlying graphics
model is very limited. It does have its own language, but that is wasted
if you are writing your own interpreter. Based on my own experience,
plplot would have been high on the list of candidates for a reliable
plotting library with capabilities well matched to IDL's own plotting.
> And why gsl? That ain't exactly mainstream either (better than plplot,
> though).
>
> The more I think about it, the more obvious it appears to me to write
> an IDL clone in python, which is popular and widespread, has it's own
> array-math routines (which compete with IDL's in speed and versatility)
> and through things like python/Tk or python/gtk even has a native link
> into the OSes windowing environment.
>
> Maybe I'm naive about something here. Maybe I'm missing something.
>
> But after three days of failed attempts to get GSL and plplot to
> compile properly ("[error 1]", why thank you for that valuable
> information) on two otherwise perfectly vanilla machines (one RH9 and
> one Slack10) I'm just a little puzzled and maybe just a tad frustrated.
I've bult GDL on Irix 6.5, RH Fedora 2&3, and Mandrake 9&10. Irix was a
bit of a struggle, but the others either have RPMS or the libraries build
and install from sources without much trouble.
> Well, OK, maybe quite a bit frustrated. ;)
>
> Why would someone make a current, live, under-development-right-now
> project dependent on things that haven't been included in a distro in
> three years? That require five year old software tools to be built?
If you get things right the first time, you don't have to keep changing
them. I pretty sure it will be easier for you to get plplot and gsl
working than to rewrite GDL to use some other library, but if you prefer
the latter approach nobody will stop you, and if you end up with something
better, you might even become a hero.
If you need netcdf and the hdf's your troubles are just beginning -- I
found fedora src RPM's which I used to make and install the libraries.
GDL linked fine, but my last attempt to use them on Fedora core 3 resulted
in a fragile GDL. That may have been due to trying to run an XFS
filesystem on the vanilla Fedora kernel (4k stack), but when I try the
lastest hdf libraries GDL won't compile (it appears that some names have
been changed).
> Well, I haven't given up yet and I'm still trying -- but this obviously
> requires a pretty hefty pot of coffee before it'll run anywhere...
And a pretty hefty linux machine. I'm used to an SGI Octane with 512k
RAM. Linux seems to need 1G RAM perform reliably on the same size data
sets that worked with 512k on Irix.
> I'll let y'all know if/when I ever manage to get this working.
I find GDL very useful for simple tasks when real IDL tells me there
aren't any licenses available and on machines where we haven't installed
IDL.
There are also big advantages to having source -- some of our
IDL jobs have recently started giving errors writing large HDF files
and I would like to see if using O_SYNC with open() helps.
--
George White <aa056@chebucto.ns.ca> <gnw3@acm.org>
189 Parklea Dr., Head of St. Margarets Bay, Nova Scotia B3Z 2G6
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
