11 Responses to “IDL 8.0 wrap-up”

1. DMPalmer says:
   August 19th, 2010 at 4:13 pm

   IDL still needs better arrays.

   Length-zero arrays have been needed for a long time and I’m glad they are finally there. However we need some way to have arrays that are of any chosen dimensions including zero and including 1. A [3,3,1] array gets silently corrupted into a [3,3] array, and if you try to do a [3,0,3] array, IDL refuses.

   Also, there should be some way to concatenate arrays across any chosen dimension without the [[[x]],[[y]]] garbage. (And failing that, the garbage should be documented somewhere in IDL, instead of requiring people to stumble across Fanning’s page.)

2. Paulo Penteado says:
   August 19th, 2010 at 4:56 pm

   I have been for some time wondering when we will have Unicode strings and the associated functions. In fact, I have been wondering what exactly is the current state of Unicode support in IDL. The documentation seems to only mention the !Z format command, and a recent thread on the newsgroup showed that Unicode in file names is currently a bit confusing.

   I guess the best way to handle Unicode strings without messing up the existing string type would be to create a new type, or maybe just a class. And maybe in that type it would be possible to have a byte 0 in the middle of a string. To allow Unicode characters inside the source code, it might also be the time to move to a new file extension (where some compile options, like idl2, would be default).

   Also, more statistics in the standard library, or a bridge to R, would be nice, since the current statistics routines are very basic. For instance, there is not even a routine for kernel density functions, or the most common statistical tests and estimators.

3. Mike Charest says:
   August 19th, 2010 at 7:25 pm

   A couple of small things that I’ve encountered come to mind.

   Date/Time conversion:
   There currently isn’t a nice built-in function to take the epoch time stamps returned from the file_info() command and reformat them using string format codes. To do that the time stamp would have to be in Julian format. The command provided for converting date/time stamps is systime(), but it only produces Julian timestamps for the current time, not for a time passed as an input. You can pass systime() the epoch time stamp and get a pre-formatted date string as the output, but that doesn’t help if it’s not the format you want.

   Backslash character codes for regular expressions:
   It’s a lot neater to write result=stregex(string1, ‘[\w]‘, /extract)
   result=stregex(string1, ‘[a-zA-Z_0-9]‘, /extract)

   Finally, It would be nice to be able to append to the end of an array with empty square brackets.
   arr[]=4 instead of arr=[arr, 4]

4. Michael Galloy says:
   August 19th, 2010 at 9:24 pm

   @Mike Charest I would like an entirely new regular expression engine. I was converting some Python code to IDL recently and got much worse performance out of IDL’s regular expressions (using STRSPLIT). So I would like better performance and new features (like search and replace, greedy vs. non-greedy matching, etc.).

   Also, note that you can currently use ‘[[:alnum:]_]’ instead of ‘[a-zA-Z_0-9]’, although I agree that ‘\w’ would be easier.

5. Patrick says:
   August 23rd, 2010 at 5:19 pm

   1 I think they need some sort of map/reduce architecture. Especially since the language is only fast when vectorized, this sort of feature could really expand the set of feasible tasks that can be handled in IDL.

   2 They don’t have functions that perform set operations(intersection,union,relative complement) on unordered lists or arrays. Maybe they should just add this to their new list objects. The complement in particular is quite tricky to vectorize.

   3 Their error handling setup is not so good. You can’t nest catch blocks within a function. Catch isn’t really a reserved keyword, they fake it using a procedure call. And throwing errors with message blocks is extremely unwieldy. Considering their motion towards OO, maybe a true OO try/throw/catch system would be in order.

6. Patrick says:
   August 24th, 2010 at 1:42 pm

   On the issue of epoch time in IDL. There are three great functions used on a bunch of space physics missions(FAST,THEMIS, etc…) time_double(), time_string(), and time_struct()

   They convert back and forth between the Unix 1970 epoch in string and double precision and struct(each field split out) formats.

   That pretty much solve all the epoch issues that Mike Charest names.

   You can dig them out of the software package here:
   http://themis.ssl.berkeley.edu/socware/tdas_5_21/tdas_5_21.zip

7. Patrick says:
   August 25th, 2010 at 5:29 pm

   Thought of something else:

   IDL needs namespaces(like from C) or packages(like from python/perl). Routine name collisions can be a big problem with libraries of IDL software.

8. Jeff N. says:
   September 2nd, 2010 at 11:01 am

   I would also like to see a better regular expression engine.

   Also, here’s one thing I worried about with the new negative indexing: a[-1] refers to the last element of a, right? So that means that indexing front-to-back is 0-based, but indexing back-to-front is 1-based? I wonder if that will cause confusion in some cases

   (I haven’t really gotten to try IDL 8 much yet in more than a cursory way, b/c most of what i do is programming for ENVI)

9. Peraldo says:
   September 7th, 2010 at 7:27 am

   The new graphics system is nice, printing and saving the graphics works now more or less as it should have 20 year ago when I started using IDL:-)

   However, there seems to be some bugs/features:

   -erasing the contents of the (new style) graphics window works only partially – e.g. the old labels of the axes are overplotted with the new ones. The same with texts, unless a white background is used.

   -how do I delete the new style graphics window? I have not yet found a replacement for WDELETE. Might be my bad, but if someone knows how to do this I am interested.

   -programs like ELLIPSE should understand layout keyword!

   -IDL 8.0 is quite unstable in Fedora 13 (64-bit):-(

10. Michael Galloy says:
    September 7th, 2010 at 10:10 am

    @Peraldo To delete a window, use the close method:

    IDL> p = plot(findgen(10))
    IDL> p.close

    Could you post an example of labels being overplotted over the old ones?

11. Peraldo says:
    September 9th, 2010 at 2:32 am

    Michael: thanks, for some reason I did not find the close-method when I was checking the IDL-help for something like it. The label overplotting problem came when I tried to circumvent the (erroneous) lack of wdelete-like command. I am studying hundreds of orbits (overplotted on the density distribution as an image) and it was very inconvenient to every orbit to be plotted in its own window. The following example demonstrates the problem I encountered:

    x=findgen(300)
    y=findgen(300)
    xx=3x
    yy=3y
    kuva1=x#y
    kuva2=xx#yy
    ikkuna=window(window_title=’Akkuna’,dimensions=[600,600])
    kuvatus=image(kuva1,x,y,axis_style=1,/current)
    ikkuna.Erase
    kuvatus=image(kuva2,xx,yy,axis_style=1,/current)
    end

    If I write ikkuna.Erase from command line, it clears the window, but a new image “remembers” the old axes and titles.

    Now with the close-method I can forget this one:-)

    The ellipse-problem I solved by overplotting xcircle and ycircle -tables.