comp.lang.idl-pvwave archive - RDF feed
type: channel
description: Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
items: Re: IDL as programming language?

Re: IDL as programming language?
type: item
description: These kinds of questions seem to recur quite often, so I'm posting instead of just replying by E-mail. In article <1994Aug28.122441.32497@waikato.ac.nz>, abz@waikato.ac.nz writes: |>[...] |> We have a number of questions, concerning |> comparisons between IDL and other programming languages (particularly FORTRAN). |> We are currently running an older version of IDL (2.2.2) on a Sun SPARC |> station. |> |> (i) Accuracy. Our current version of IDL seems to prefer doing calculations |> in single precision, while we prefer double. Has this been improved in the |> latest version? (e.g. in our current version, routines like LUDCMP work in |> s.p., despite being passed d.p. arguments.) |> I have little experience with this particular problem, but if you already have written routines in FORTRAN that does specific jobs in double precision (I guess you have),the use of the CALL_EXTERNAL routine makes it quite easy to use those routines whenever the built-ins are not sufficient. A note of advice on CALL_EXTERNAL: Don't let the hopeless bureaucratic style of the supplementary information in "call_external.doc" baffle you. Simply use your favourite editor to delete everything that has nothing to do with your machine, operating system, programming language etc, and then do the same with the examples. It's amazing how easy it is. |> (ii) Speed. Some of us Grads are running some really time consuming programs |> (large arrays, large loops). How does IDL compare with (say) FORTRAN in |> general, speedwise? (my impression is that it's pretty slow, but I could be |> wrong...) For exactly those scenarios (FORTRAN loops processing large arrays), IDL should be at worst a very few percent slower. If you're doing FFT's, the built-in routine in IDL outperforms the standard Coley-Tukey version in Numerical Recipes. I had a problem using FFT's for calculation of autocorrelation functions of real-valued data, so I could use the shortcuts in Num. Recipes twice (starting with real-valued data, a…
creator: steinhh
date: 1994-08-28T11:14:05-00:00

Re: IDL as programming language?
type: item
description: abz@waikato.ac.nz writes: > (ii) Speed. Some of us Grads are running some really time consuming programs > (large arrays, large loops). How does IDL compare with (say) FORTRAN in > general, speedwise? (my impression is that it's pretty slow, but I could be > wrong...) Loops are very slow. On the other hand, you usually can do it without loops in IDL. If you can't, there's always CALL_EXTERNAL or LINKIMAGE. > (iii) Memory. How does IDL's memory management compare? Again, some of our > programs (FORTRAN) have a tendency to gobblelarge chunks of memory (probably > bad programming, but still...) IDL does the same thing. I doubt if it would be any better than Fortran, but don't know if it's any worse. > (iv) What is a large IDL code like to debug? Certainly no worse than Fortran, and one can fiddle with things to see how they affect behavior much, much faster. According to the release notes for version 3.6, there is now a Motif-based interactive debugging tool for Unix platforms. I haven't used it, but it should help things out quite a bit. > (v) How 'robust' is IDL as a programming language? We have a variety of > different programming styles here -- some prefer 'quick and dirty' programming, > others a more structured approach. Forgive my possible ignorance, but I have > the impression that IDL as a language is more suited to the 'quick and dirty' > approach. Is this true? Does IDL as a programming language have many > glitches or inconveniences from a mathematical programmers point of view? I would agree with IDL as being oriented towards "quick and dirty" programming. That doesn't mean that one can't put together large software systems--we do. On the other hand, it doesn't enforce things like datatypes that other languages might. This can either be a blessing or a curse, depending on your point of view. As far as inconveniences go, from a mathematical point of view, one can point out the fact that IDL doesn't support a double-precision complex data type. > Any info/a…
creator: thompson
date: 1994-08-29T14:19:07-00:00

Re: IDL as programming language?
type: item
description: In article <1994Aug28.122441.32497@waikato.ac.nz>, abz@waikato.ac.nz wrote: > OK. One the lecturers in our department recently went to > Hawaii & America for a few weeks (lucky him) and came back > with the idea of using IDL as a complete programming > language rather than as just a plotter for FORTRAN generated data. > ... I don't want to use bandwidth, time, etc. repeating the comments previous posters have made to this thread (which I mostly agree with). I just wanted note that I use IDL for almost all of my programing, both scientific and otherwise. For example, I have a network monitoring program that polls our network-hub (via 'spawn'ed telnet) and keep track of network traffic. It may also be interesting to note that RSI wrote the GUI-builder that is part of 3.6.12 *in* IDL. -- Geoff Sobering (Geoff.Sobering@nih.gov) In Vivo NMR Research Center National Institutes of Health
creator: Geoff.Sobering
date: 1994-08-29T18:08:10-00:00

Re: IDL as programming language?
type: item
description: Geoff.Sobering@nih.gov (Geoff Sobering) writes: > In article <1994Aug28.122441.32497@waikato.ac.nz>, abz@waikato.ac.nz wrote: >> OK. One the lecturers in our department recently went to >> Hawaii & America for a few weeks (lucky him) and came back >> with the idea of using IDL as a complete programming >> language rather than as just a plotter for FORTRAN generated data. >> ... > I don't want to use bandwidth, time, etc. repeating the comments previous > posters have made to this thread (which I mostly agree with). > I just wanted note that I use IDL for almost all of my programing, both > scientific and otherwise. > For example, I have a network monitoring program that polls our network-hub > (via 'spawn'ed telnet) and keep track of network traffic. It may also be > interesting to note that RSI wrote the GUI-builder that is part of 3.6.12 > *in* IDL. RSI has a problem with quality control. I have been developing software in IDL for the past three years. IDL has been no better or worse than any other language. Initially IDL seems like a wonderfull language, it has all sorts of canned routines and a fairly easy GUI builder. However every time a new version of the language is released I spend at least a week patching up old software that the new version breaks. If you are only writing little programs with a limited lifespan then IDL is perfect. If you are working in a larger project (ours is 6000+ lines) the instability in the language can be a real pain. RSI seems to have little vision of where there product is headed. So features are added haphazardly and with little forthought. As a result IDL is ripe with kludge and nuance. They also have a problem with documenting changes when they happen. Once they included a whole paragraph in the release notes arguing that some bug was a feature due to backward compatability (to version 1.1) while the same release notes failed to mention that widget_info had changed from a procedure to a function. More recently RSI has added p…
creator: shapiro
date: 1994-08-29T20:50:01-00:00

Re: IDL as programming language?
type: item
description: In article <1994Aug28.122441.32497@waikato.ac.nz> abz@waikato.ac.nz writes: > > > OK. One the lecturers in our department recently went to Hawaii & America for a > few weeks (lucky him) and came back with the idea of using IDL as a complete > programming language rather than as just a plotter for FORTRAN generated data. IMHO, this is a very bad idea... Unfortunately, I have only a few things to back this up. Mostly it's a feeling, which doesn't hold much water, but, see below... > (i) Accuracy. Our current version of IDL seems to prefer doing calculations > in single precision, while we prefer double. Has this been improved in the > latest version? (e.g. in our current version, routines like LUDCMP work in > s.p., despite being passed d.p. arguments.) My first reason for not liking IDL is this. You have to very explicit about double precision variables. This has not been improved to my knowledge, but, I don't have the latest version, either. > (ii) Speed. Some of us Grads are running some really time consuming programs > (large arrays, large loops). How does IDL compare with (say) FORTRAN in > general, speedwise? (my impression is that it's pretty slow, but I could be > wrong...) This is my impression as well... it's slow, even though code-wise, it's really nice to do large array computations because you can often skip explicitly writing loops. > (iii) Memory. How does IDL's memory management compare? Again, some of our > programs (FORTRAN) have a tendency to gobblelarge chunks of memory (probably > bad programming, but still...) Really bad. IDL is always sucking up lots of memory, in my experience. > (iv) What is a large IDL code like to debug? UGH! Again, my opinion. Some people will probably like debugging idl code over FORTRAN code (or some other legitamate language). But, I would venture that they do not know how to use a real debugger like dbx... > (v) How 'robust' is IDL as a programming language? We have a variety of > different programming styles here -- so…
creator: n9140397
date: 1994-08-30T23:51:45-00:00

Re: IDL as programming language?
type: item
description: In article 15667@henson.cc.wwu.edu, n9140397@gonzo.cc.wwu.edu (Michael Hamilton) writes: > In article <1994Aug28.122441.32497@waikato.ac.nz> abz@waikato.ac.nz writes: > >> (v) How 'robust' is IDL as a programming language? > reply by Henson> >Other things you should consider: IDL does not, to my knowlege, create > executable code which you store on disk or which runs independently. > If you want to share something you wrote with a friend, they have to have > idl also, and maybe even the same version. Actualy languages like > C and FORTRAN are much more "portable". >> > portability is relative....... I can use IDL on all 4 of my main platforms (SUN,SGI, PC(portable), and MAC), with virtually no changes (set_plot, ....). fortran compilers and c compilers are not all that standard from platform to platform.... just try and compile the new ImageMagick.......... rc olsen
creator: olsen
date: 1994-08-31T15:23:59-00:00

Re: IDL as programming language?
type: item
description: I just have to give a little plug for IDL... In article <1994Aug30.235145.15667@henson.cc.wwu.edu> n9140397@gonzo.cc.wwu.edu (Michael Hamilton) writes: > In article <1994Aug28.122441.32497@waikato.ac.nz> abz@waikato.ac.nz writes: > >> (i) Accuracy. Our current version of IDL seems to prefer doing calculations >> in single precision, while we prefer double. Has this been improved in the >> latest version? (e.g. in our current version, routines like LUDCMP work in >> s.p., despite being passed d.p. arguments.) > IDL allows types to be Dynamic. Double precision is not a problem, you just must make sure that the variables you are dealing with at the time are all DOUBLES. One of the nicest features with IDL is that you can interact with variables of different types, and generally not worry about them, almost no other language allows you to do this (low level language at least) Therefore, if you initially define all your variables as DOUBLES, you should have NO problem. > >> (ii) Speed. Some of us Grads are running some really time consuming programs >> (large arrays, large loops). How does IDL compare with (say) FORTRAN in >> general, speedwise? (my impression is that it's pretty slow, but I could be >> wrong...) > The responses to this are extremely interesting. When programmed correctly (ie: a few loops as possible, accessing memory in the correct order, etc) IDL SCREAMS. ANd the speed is obtained with very little code. When dealing with matrix calculations, I have hardly heard anyone complain about its speed. GRANTED, if you do not use the built in operators, use lots of loops, and program as if you have to handle all the indexing,.. then its pretty slow.. > >> (iii) Memory. How does IDL's memory management compare? Again, some of our >> programs (FORTRAN) have a tendency to gobblelarge chunks of memory (probably >> bad programming, but still...) > No idea really. (probably not even close to C, maybe to Fortran but I really have no idea) But, hey, memory is cheap... (…
creator: stl
date: 1994-09-01T07:03:58-00:00

Re: IDL as programming language?
type: item
description: William Thompson (thompson@orpheus.gsfc.nasa.gov) wrote: : abz@waikato.ac.nz writes: : >Speed. Some of us Grads are running some really time consuming programs : >(large arrays, large loops). How does IDL compare with (say) FORTRAN in : >general, speedwise? (my impression is that it's pretty slow, but I could : >be wrong...) : Loops are very slow. On the other hand, you usually can do it without : loops in IDL. If you can't, there's always CALL_EXTERNAL or LINKIMAGE. Another alternative is the IDL and PV-Wave interface to the optimized and parallelized math library that our company sells. Dr. Thompson is certainly correct that A=B*C is a faster matrix multiple than the equivalent nested loops, but CALL GEMM(A,B,C) is about three times faster than that even on a single-CPU box. On the multi-processors, we're unbeatable. scisoft@well.sf.ca.us for more information, end of plug.
creator: scisoft
date: 1994-09-05T16:43:51-00:00