Talk:IDL (programming language)

From Wikipedia, the free encyclopedia

(Full disclosure -- I (User:Mpiper) am an RSI employee.) The phrase "IDL's market share has been recently decreasing considerably" in the second sentence isn't true. I don't want to change it, though, because it could be seen as a conflict of interest. I think a less strongly worded statement, or a deletion, would be more appropriate.

(William M. Connolley 21:52, 10 Mar 2005 (UTC)) Fair enough... my own disclosure: I use and like IDL. I have no idea what its market share is. But perhaps some figures could be supplied if anyone wants to reinsert the text.

I modified the statement about loop speed: if I understand correctly, IDL loops are implemented in C and therefore can't be faster than a well-designed loop in C -- they can at most run as fast as such a thing. That is true of modern vectorized languages in general, including IDL, GDL, Matlab, Octave, Python, and Perl. zowie 19:10, 3 May 2005 (UTC)

(William M. Connolley 19:44, 3 May 2005 (UTC)) Fair enough. IDL is probably faster than a non-well-crafted-by-the-user loop, but as fast as a well crafted one...

I won't mess with it, but I'm not entirely sure what the appropriate way to write the "Problems" section is, and I'm not especially happy with the way it is now -- several "example problems" have been named, and solutions to them have been posted, but (in my experience anyway) the main problem is one that infects a great deal of late-model software: backward compatibility enshrines earlier mistakes. In the case of IDL, this adds up to a lot of "solutions" that the programmer must remember, and that tend to crowd out real design. I certainly don't want this to become a battleground page -- languages in particular are fodder for unproductive flame wars -- but I don't think that the Problems section does anything useful the way it stands now. It should either be augmented (by someone other than me -- I'm probably too partisan, as a quick google for "zowie IDL" will reveal) or deleted.

Hmmm... Came back to this some weeks later and noticed it was still the same. I added "...requiring individual work-arounds by the programmer", which I hope does not add too much POV but captures the flavor of what I was trying to get across... zowie 4 July 2005 17:43 (UTC)

(Niel Malan)I have a problem with the "Feature" "has all function arguments passed by reference ("IN-OUT")". Certainly IDL passes variables by reference, but indexed variables are passed by value. And what is "IN-OUT" supposed to mean?

I believe that this is a reference to the fact that you can pass values into and out of subroutines via the pass-by-reference mechanism, though as you point out it is broken (or at least violates the principle of least surprise) in IDL, because subregions of arrays act differently than complete arrays. But, hey, this is Wikipedia -- if you've got a problem with a page, fix it! :-) zowie 20:18, 23 August 2005 (UTC)

[edit] Problems

I'm not entirely comfortable with this section as it appears to amalgamate various things into ... well ... problems. Some things here are real problems -- like the fact that a language that counts from zero doesn't allow zero-length arrays. That's a real contradiction. On the other hand the number of bits in an integer is really more a matter of convention - unexpected convention, maybe, but not really a problem. Especially since you can change it if you don't like the default. That kind of thing might go better into a section called "gotchas" or such, that would accumulate ways in which IDL is different from the majority of other language in perhaps unexpected ways, but where the majority way of doing things is really just conventional and there's no particular reason to do it one way or another. IDL's "format" is probably a problem for a C programmer, but will seem natural to someone from the FORTRAN world. On the other hand the fact that IDL will produce a floating error upon almost every math operation leads to people ignoring its errors which seems like a real problem to me. Iron Condor 03:55, 26 October 2006 (UTC)

I agree that the section is rather incoherent. Part of that is the usual WP problem that many partisan editors tend to fight over contentious issues, editing back-and-forth until the article is no longer coherent enough to piss anyone off -- but doesn't carry much meaning either. The point I tried to make a long time ago (and backed off from since I have stopped using IDL altogether) is that, like many legacy languages, IDL has so many little niggling "gotchas" that it takes a huge amount of brain space, paranoia, and extra lines of code just to avoid the pitfalls of the language. That is itself a problem with the language -- more carefully designed environments have their own set of things to remember, but tend to require less brainspace merely to wrestle with the language (NumPy or, my favorite, PDL, are examples).

Anyhow, if you felt like reworking the section I'm sure it would be an improvement -- I agree that at the moment it is pretty poor writing. zowie 15:26, 26 October 2006 (UTC)

My limited experience with IDL at the Summer Science Program programing an orbit determination project were not pleasant. I tested out various for and while loops, and the performance was like snot.

(Well - isn't the whole point of vector languages not to use loops but do math on the vectors themselves? Iron Condor 20:04, 25 October 2006 (UTC))

Java, which runs on a virtual machine was alot faster, (like ten times). Anyway, our version of IDL had a bunch of problems, a really dumb one was the the constant pi, !dpi, was wrong in the seventh decimal place. I don't want to be flaming, but what are your thoughts on all of this? --BorisFromStockdale 07:15, 10 March 2006 (UTC)

The value for double precision pi is not incorrect. IDL by default only prints 8 significant figures and rounds the last digit. To see the full value, you need to use a FORMAT keyword in PRINT, e.g. print,!DPI,format='(F24.22)' .Leuliett 13:28, 10 March 2006 (UTC)

• I haven't put it in the Problems section but I consider IDL's formatting of double precision variables to be pretty bug-ridden -- at the very least, it frequently violates the principle of least surprise. For example, PRINTing a bunch of doubles to a file and then READing them back in (without specifying a FORMAT) gives incorrect results, because the default FORMAT doesn't use the double-precision context: the first variable to be read in gets the first part of the mantissa of the first variable written, and the second variable to be read in gets the rest of the mantissa and the exponent from the first variable, so (for example) writing 1.234567890000e13 and 3.141592653589793238e0, then attempting to read them back in gives you 1.234567 and 890000e13. (I may have the digits counts wrong). That problem goes back at least 15 years so it is clear that RSI has no intention of fixing it. zowie 15:34, 10 March 2006 (UTC)