This is currently a proof of concept and works for views, models, and polygons with simple properties only, but expanding to more classes and properties should be straightforward. I have done similar things for various other new destination classes for outputs such as POV-Ray and anaglyphs.

This issue has been a problem for me before so I wrote a simple arithmetic parser (docs).

Evaluates a mathematical expression using the basic arithmetic operators +, -, *, /, and ^ along with parentheses for grouping and simple function calls of a single variable.

This routine is implemented with a recursive descent parser and does not use EXECUTE, so it is safe to use in the Virtual Machine.

For example, simple arithmetic expressions can be evaluated:

IDL> print, mg_evalexpr('1 + 2 + 3', error=error), error
                     6       0

Note that the ERROR keyword returns whether there was an error in evaluating the expression. Expressions can also take variables, if their values are provided via a structure or hash-like object:

IDL> print, mg_evalexpr('exp(i * pi)', { pi: !dpi, i: complex(0, 1) })
(      -1.0000000,   1.2246468e-16)

“Hash-like” here means that the object implements a hasKey method and subscripting via brackets like the IDL 8.0 Hash class.

1. Is it possible to dynamically resize a sparse matrix in the Petsc library?
2. Future of OpenCL?
3. Parallel I/O options, in particular parallel HDF5
4. Is it worthwhile to write unit tests for scientific research codes?

Currently, IDLdoc is built with IDL 6.4 to maximize who can use it, but this means any included IDL library routines could conflict with the routines provided by the user’s IDL distribution. IDLdoc is intended to be run from the command line, i.e., a full version of IDL, not a runtime or VM environment, so the IDL library routines should be provided by the user’s IDL distribution.

Get the new version here.

On-line documentation is now available for all 41 of the Coyote Graphics programs. (These are a subset of the programs in the Coyote Library.) This will make it much easier to use these Coyote Graphics programs.

Also, I have confirmation that IDLdoc will run on big libraries, i.e., over 4000 files, 7700 routines, and 850,000 lines of code!

Here’s our press release:

Tech-X Corporation invites you to visit our booth (Booth #1748) at the American Geophysical Union Fall Meeting 2011, December 5 – 9, at the Moscone Center in San Francisco.

We will be featuring GPU Computing, including GPULib, our library of mathematical kernels for GPU computing.

We will also be demonstrating the Remote Data Toolkit, which allows seamless access to remote data with IDL.

Personnel from Tech-X and/or their collaborators will be participating in the following activities:

Session A53C: Multisensor and Model Aerosol Data Inter-comparison and Synergy III Posters Friday, December 09 1:40PM – 6:00PM, Halls A – C

A53C-0382 Aerosol type estimations for the ERBE period (1985 – 1989) Jose R. Fernandez, SSAI, Hampton, VA; Seiji Kato, NASA Langley Research Center, Hampton, VA; Fred G. Rose, SSAI, Hampton, VA; David W. Fillmore, Tech-X Corporation, Boulder, CO

Exelis VIS will be at booth #1431; I haven’t heard about if there will be an IDL user group meeting.

UPDATE: Also, if you have an iPhone, I recommend the AGU app. It has been very useful already for me.

Full disclosure: I work for Tech-X Corporation.

;+
; Inverse hyperbolic cosine. Uses the formula:
;
; $$\text{acosh}(z) = \ln(z + \sqrt{z + 1} \sqrt{z - 1})$$
;
; :Returns:
;    float, double, complex, or double complex depending on the input
;
; :Params:
;    z : in, required, type=numeric
;       input
;-

The equation should be typeset like (results depend on browser):

$$\text{acosh}(z) = \ln(z + \sqrt{z + 1} \sqrt{z – 1})$$

Inline equations are also allowed. Both can appear in the main description and inside most tags (anywhere comments are just copied over to the output).

Here are the full release notes:

1. Allow LaTeX equation formatting.
2. Fix for bug where links to routines, files, etc. in directory overview comments on the overview page were not correct.
3. Adding links to parent items in index entries.
4. Changes to HTML output styling including larger type size.
5. Fixed bug where DLM contents could not be references using backtick notation in rst markup syntax.
6. Added private and hidden attributes to directory names in overview file.
7. Not showing warnings page when USER keyword is set.
8. Fixed bug where parsing rst Requires tag would cause IDLdoc to crash.
9. Fixed bug where Warnings page showed items from private or hidden items.
10. UPDATED 11/22: New color scheme.

[Download]

1. there is no easy way to turn the complete output on and off, much less on a more granular level
2. output goes to the output log, but sometimes it would be nicer to send the output to a log file
3. PRINT provides little help for things that I commonly need to print like the time/date, the routine that the message is originating from, etc.

I’ve created the MG_LOG routine to help with these problems.

At it’s most basic MG_LOG just prints out a message that you provide:

IDL> mg_log, 'Hello'
2011-11-17 11:41:44.000 DEBUG: $MAIN$: Hello

There are five priority levels of messages; in decreasing priority they are:

1. critical
2. error
3. warning
4. informational
5. debug

The default is a “debug”-level message, but we can set that when we provide a message:

IDL> mg_log, 'Hello', /informational
2011-11-17 11:45:28.000 INFORMATIONAL: $MAIN$: Hello

We can also configure the logger to only show messages of a certain level or higher:

IDL> mg_log, level=3
IDL> mg_log, 'Hello', /informational   ;note no output because 2 < 3
IDL> mg_log, 'Hello', /warning
2011-11-17 11:46:55.000 WARNING: $MAIN$: Hello

This solves problem #1 above, you only need to set the level in one location in your program, e.g., on startup. Setting the level to 0 turns off all messages, further granularity is provided by the other levels. Even more granularity is provided by named loggers which are organized into hierarchies and can be individually configured, but I’m not going to go into detail about those right now.

Output can also be redirected to files when the logger is configured:

IDL> mg_log, level=3, filename='myapp.log'
IDL> mg_log, 'Hello', /critical

Now look at the contents of myapp.log:

IDL> $cat myapp.log
2011-11-17 11:52:26.000 CRITICAL: $MAIN$: Hello

The file is opened and closed between each writing, so you don’t have to worry about the log file not being up-to-date. This solves problem #2.

For problem #3, MG_LOG also provides a FORMAT keyword that gives a few variables that can be inserted automatically into the log message. For example, let’s set the FILENAME to a null string so that output goes to the output log again and try a new log message format:

IDL> mg_log, format='%(levelname)s: %(message)s', filename=''
IDL> mg_log, 'Hello', /critical, filename=''
CRITICAL: Hello

The default log message format is:

%(time)s %(levelname)s: %(routine)s: %(message)s

The FORMAT keyword uses a special syntax to substitute a selection of predefined variables (“time”, “levelname”, “routine”, “message”, “stacktrace”, and “name”) into the log message.

In the course of writing the logging framework I had to write a routine, MG_SUBS, that performs substitution of variables into a string by name. I wanted to make this routine as usable for general use as possible, so we get a very flexible formatting syntax. It uses the C format codes with the addition of a name in parenthesis between the % and the rest of the format code indicating which variable should get substituted into that format code. For example, this can be used by itself like:

IDL> print, mg_subs('%(loc)s temp: %(temp)0.1f F', $
IDL>                {loc: 'Boulder', temp: 65.})
Boulder temp: 65.0 F

This allows the variables to be provided in any order, to be used twice in the format, and to even provide variables that are not used in the format.

There is also a TIME_FORMAT keyword to further specify the format of the “time” variable in the FORMAT property. It uses Fortran-style format codes since there are no C-style calendar format codes. The default time format is:

C(CYI4.4,"-",CMOI2.2,"-",CDI2.2," ",CHI2.2,":",CMI2.2,":",CSF06.3)

Together FORMAT and TIME_FORMAT provide a lot of control and flexibility in the log message format.

To get the code for the logging framework (and MG_SUBS), grab the dist_tools package with Subversion:

svn co http://svn.idldev.com/dist_tools/trunk dist_tools

Let me know if this is useful to you or you have problems/requests!

As always, see the Modern IDL website for purchasing, new code examples, table of contents, sample chapter (object graphics with the new function graphics updates!), and errata.

For example, suppose I have found the valid data in an image with:

IDL> valid_ind = where(band gt 0.)

And then I find indices of the clouds in the image using my special routine FIND_CLOUD_INDICES:

IDL> noncloud_ind = find_cloud_indices(band)

Now, if I want to find the indices of the pixels of the image that are valid and not cloud pixels, I can use my MG_SETINTERSECTION routine:

IDL> valid_ind = mg_setintersection(valid_ind, noncloud_ind)

Download the routines or look at the documentation.

More generally, inspections are a cheaper method of finding bugs than testing; according to Basili and Selby (1987), code reading detected 80 percent more faults per hour than testing, even when testing programmers on code that contained zero comments.

So grab mgunit and write some unit/regression/system tests; get a friend and have her look over your code; have a beta test period; etc.

Tech-X Corporation is pleased to announce our next three-day training course for GPU computing with CUDA will be held from September 19 – 21 at our offices in Boulder, Colorado, USA. If you are interested, please complete the form so we can contact you with further details.

The cost for this particular training will be US$1,200 for all three days. This price includes lunch each day. You can register and pay at our online store.

Full disclosure: I work for Tech-X Corporation.

My thoughts from using Lion for a few days on my home computer (I haven’t upgraded work computers yet):

1. IDL seems to work fine, though I haven’t done much on my home computer besides a few sanity tests.
2. Lion is the first Mac OS X update I have thought felt slower than its predecessor. I think it is mostly due to the new window creation animation. The extremely useful Secrets website says that the following should turn off the animation: “defaults write NSGlobalDomain NSAutomaticWindowAnimationsEnabled -bool NO“.
3. Spaces have been changed a bit to work with the new Mission Control feature. I had a 2 x 3 grid of spaces previously, but Lion only supports a 1-dimensional array of spaces, so now I have a single row of six spaces. This is what I’m missing the most so far, since my 2-dimensional mental model of the purposes of the spaces allowed quick switching between tasks.
4. Scrolling is, by default, backwards from the current direction, but there is a preference value to change it back to the Snow Leopard way. I suppose if I had a Magic Trackpad I would give the new way a try, but I use a regular mouse with a scroll wheel, so I stuck to the old way.
5. Most people are reporting an easy installation from the Mac App Store, but I had some difficulty. After Lion was downloaded, my Mac rebooted and the installer hung. It reported that it had 33 minutes to go for several hours. I tried again and it appeared to hang again, but I left it going all day as I was at work. When I come back, it had installed. Not sure how long it took, but it was definitely way longer than 33 minutes.
6. Rosetta support is gone, luckily all my applications are native now.
7. The UI is generally more muted and fading into the background, which I really like. On the other hand, iCal and Address Book got the skeuomorphic treatment, which I really don’t like.
8. For a few months, the new version of XCode cost $5. The new Lion version is free again.

Mike Galloy spent nearly five years writing this 462-page book covering modern topics in IDL, and it certainly shows. This virtual tome (available in both PDF and spiral-bound versions) contains a wealth of information on the IDL programming language, with sections for beginners and advanced users alike. It provides a wide range of topics spanning from IDL basics such as variables, file input/output, programming calls, and direct graphics to more advanced concepts such as widget/object graphics applications, IDL compound widgets and composite graphic classes, optimizing code performance, and external development using bridges, Python, etc.

One impressive aspect of Modern IDL is how well it illustrates some of the basic components of the IDL programming language from a fresh, unique perspective. Those with a chemistry or physics background will appreciate Galloy’s innovative way of viewing the IDL operator hierarchy via the “Periodic Table of IDL Operators.” Similarly, for those who are more literary in nature, there is an extensive section on strings and string manipulation, with an especially helpful segment on the often confusing, but very powerful, use of regular expressions. For visual learners, Modern IDL has an exemplary set of diagrams depicting the concept and use of pointer variables in IDL. The mathematically-minded will thoroughly enjoy the four-page section explaining the use of the IDLgrModel’s transformation matrix, as well as the seven-plus pages describing the simplistically beautiful, yet amazingly clever, HISTOGRAM function. Lastly, hard-core programmers will hone in on the chapter covering code performance in which Galloy addresses various ways to speed up and to make IDL code more computationally and memory efficient (e.g., taking advantage of IDL’s array operators, minimizing the number of interpreted statements, using IDL thread? aware operators/routines, etc.).

Accompanying the wide array of material in the Modern IDL text itself are over 50 pages of additional resources and information contained within the appendices. The book is also filled with numerous exercises and examples, which makes it a very practical, hands-on instructional guide. In my opinion, Galloy has written an outstanding and comprehensive book covering a vast range of topics relevant to the current world of IDL programming. This is a terrific resource — one that I will definitely revisit time and time again.

Thanks, I hope this is a great resource for IDL programmers! Check out Modern IDL‘s website for sample chapter, table of contents, and links to buy.

IDL> mg_make_dll, 'mg_analysis.c', /show_all_output

Don’t forget to put the directory with the DLM in your IDL_DLM_PATH.

I thought it would be interesting because of the discussion in the newsgroup and the fact that it was pretty simple to make it work for all the different numeric data types IDL offers (for an example of when it is not so simple, check out the implementation of MG_ARRAY_EQUAL in the source code).

The main algorithm is very simple, but complicated a bit by the fact that it is a C macro:

#define IDL_MG_TOTAL_TYPE(TYPE, IDL_TYPE, INIT)        \
IDL_VPTR IDL_mg_total_ ## IDL_TYPE (IDL_VPTR arg) {    \
  TYPE sum = INIT, c = INIT, y = INIT, t = INIT;       \
  int i;                                               \
                                                       \
  TYPE *arr = (TYPE *)arg->value.arr->data;            \
                                                       \
  for (i = 0; i < arg->value.arr->n_elts; i++) {       \
    y = arr[i] - c;                                    \
    t = sum + y;                                       \
    c = (t - sum) - y;                                 \
    sum = t;                                           \
  }                                                    \
  return(IDL_Gettmp ## IDL_TYPE (sum));                \
}

Ugly yes, but better than repeating the code nine times.

So this macro needs to be called for each of the supported data types to make the routines that handle each type:

IDL_MG_TOTAL_TYPE(UCHAR, Byte, 0)
IDL_MG_TOTAL_TYPE(short int, Int, 0)
IDL_MG_TOTAL_TYPE(int, Long, 0)
IDL_MG_TOTAL_TYPE(float, Float, 0.0)
IDL_MG_TOTAL_TYPE(double, Double, 0.0)
IDL_MG_TOTAL_TYPE(IDL_UINT, UInt, 0)
IDL_MG_TOTAL_TYPE(IDL_ULONG, ULong, 0)
IDL_MG_TOTAL_TYPE(IDL_LONG64, Long64, 0)
IDL_MG_TOTAL_TYPE(IDL_ULONG64, ULong64, 0)

And then the master routine needs to call the appropriate routine for the input type (it always computes a result that is the same type as the input):

IDL_VPTR IDL_mg_total(int argc, IDL_VPTR *argv, char *argk) {
  IDL_ENSURE_ARRAY(argv[0]);
  switch (argv[0]->type) {
    case IDL_TYP_BYTE:
      return(IDL_mg_total_Byte(argv[0]));
    case IDL_TYP_INT:
      return(IDL_mg_total_Int(argv[0]));
    case IDL_TYP_LONG:
      return(IDL_mg_total_Long(argv[0]));
    case IDL_TYP_FLOAT:
      return(IDL_mg_total_Float(argv[0]));
    case IDL_TYP_DOUBLE:
      return(IDL_mg_total_Double(argv[0]));
    case IDL_TYP_UINT:
      return(IDL_mg_total_UInt(argv[0]));
    case IDL_TYP_ULONG:
      return(IDL_mg_total_ULong(argv[0]));
    case IDL_TYP_LONG64:
      return(IDL_mg_total_Long64(argv[0]));
    case IDL_TYP_ULONG64:
      return(IDL_mg_total_ULong64(argv[0]));
    default:
      IDL_Message(IDL_M_NAMED_GENERIC, IDL_MSG_LONGJMP, "unknown type");    
  }
}