3.2 Scalars, Arrays, and Strings

IFEFFIT has three types of variables: numeric scalars, numeric arrays, and text strings. I'll call all of these ``Program Variables'' throughout this Reference Manual to mean all the named quantities that IFEFFIT knows about - you shouldn't confuse ``Program Variables'' with values that are adjusted in a fit which I'll call ``Fitting Variables'' (see section 3.4) when there's room for confusion. If you have some programming experience, IFEFFIT's data types should be familiar: numeric scalars are real numbers, numeric arrays are arrays of real numbers, and text strings are sequences of characters. If that you're not familiar with the ways computers store data, numeric scalars contain a single number, numeric arrays contain a set of numbers that is referred to as a whole, and text strings contain a single line of text. IFEFFIT uses double precision (64bit) floating point numbers for all it's numeric values, and does not have a separate integer type. Due to implementation limitations, the maximum number of elements in an array is 16384, and the maximum length of text strings is 128 characters. These limits are set when IFEFFIT is built. In principle, these limits could be changed, but I wouldn't guarantee it to be easy to do.

All Program Variables are named, and are global in the sense that every part of IFEFFIT sees the same variables using the same names. As you use IFEFFIT, you will define variables for your data, and tell the commands which data to use by name. In turn, IFEFFIT's commands will access variables by name, and may even create named variables or overwrite the values of variables already defined. That is, the variables you create and the ones that the IFEFFIT commands use will live in the same ``name-space''. This gives you and IFEFFIT's commands equal access to the variables. Thought this should definitely be seen as a strength, it also means that you should use some care in naming your variables. Normally, there's not much too worry about, as long as you avoid things like trying to store the value of E₀ in a variable named kmin. In general, IFEFFIT expects named variables to store quantities it expects. A glossary of the names and meanings IFEFFIT expects is listed at the end of Appendix A.

To create a variable, you would say something like phi = (1 + sqrt(5))/2. To set the value of k_min (used by several commands for Fourier transforms), you might say kmin = 1.00. You can also use any variable to assign to other variables. If you were so inclined, you could have said something like kmin = phi*(phi-1), or possibly something along the lines of x= exp(0), kmin = 4*atan(x)/pi is more of your idea of a good time. Actually, these aren't exactly equivalent ways to define variables, but we'll get to that shortly.

IFEFFIT uses a simple and strict naming convention for Program Variables, and distinguishes the 3 variable types by name. This means that everyone (and every command) can tell the variable type from its name alone. The convention may be a somewhat unusual, but shouldn't be very difficult to get used to. The rules are:

1. Text strings have names that begin with a dollar sign ($). Names for numeric scalars and arrays do not begin with a dollar sign.
2. Arrays have names that contain one dot (``.''), with at least one character before and after the dot. This gives arrays a prefix and suffix, which leads to a convention: the prefix is associated with the group of the array, and the suffix describes the contents of the array. Neither scalars nor text strings may have a dot in their name.
3. Scalars, the prefix and suffix of arrays, and the characters in the name of a text string after the dollar sign can contain only letters, numbers, '&', '?', ':', and `_' (underscore). They are limited to 64 characters.
4. Scalars and array prefixes names cannot begin with a numeral. Text strings and the suffixes of array names can begin with a numeral.
5. Variable names are not case-sensitive.

Some examples of the naming convention: `$file' and `$plot_color' are text strings. So is `$20', but `$19.95' is not allowed. `$1' is a valid name for a text string, but IFEFFIT uses `$1' ...`$9' as special variables for macro arguments (see chapter 10) and it will likely cause confusion if you actually try to use such variable names, especially in macros. `$test.1' is not allowed, nor is `dec$window' (it contains a `$' in the middle of it's name, and might inspire a wistful pining for VMS). Array names look like `my.energy' and `data.chi'. `X.11' is allowed, and as we saw in the previous chapter, the common convention for how to name data from column files, but `8.3' is not allowed as a variable (because it's a plain number). Typical scalar names are `E0' and `edge_step'. `10th_var' is not allowed, since it starts with a numeral. Neither `data-10' nor `the_end.' are allowed (the former contains a minus sign, the latter has a dangling dot `.').

`&' is allowed in variable names, and by convention, several built-in ``system'' scalar variables begin with `&', notably &print_level and &screen_echo. The characters '?', '_', and ':' are also allowed in variable names, and are not currently given any special meaning. Speaking of special characters, `@' is not allowed in any variable names, but is used with the show() command as a primitive wildcard or glob character. In addition, `*' is used in the write_data() command as a glob character, to match multiple string names, but isn't allowed in real string names. We'll come back to these glob characters later.

The naming convention gives a clear distinction between the three types, making life easier on all of us. Text strings will likely be used less than numbers, so the extra $ (with the mnemonics of ``string'' for English speakers) was chosen for text strings. The `.' in an array name suggests that they are associated with files (or data structures for the programmers out there). It also gives a prefix and a suffix to the array names, which gives a handy convention for grouping them together. Though this convention can be disregarded, it is generally a good idea to use the prefix to associate related arrays (say, from the same file, or along a single line of analysis), and to use the suffix to distinguish the contents of the array. This allows read_data() to assign decent array names based either on the column labels in the file or on the type and group keywords. It also means you can have arrays named Cu1.xmu and Cu2.xmu, containing $\mu$(E) data from two different files. A spline() command with Cu1.xmu would generate Cu1.bkg, etc, while a spline() on Cu2.xmu would generate Cu2.bkg, etc.

One more thing on naming conventions: though we haven't discussed macros much yet, macros are named sequences of IFEFFIT commands. They share the same naming rules as plain scalars. In fact, commands also share the same naming rules as plain scalars. To avoid confusion, you cannot assign a scalar a name of an existing macro or command. By the same token, you won't be able to create a macro with the name of a known scalar or command.

Before leaving this section I should admit that there actually is some data that you do not have direct access to through the Program Variables. The most notable example of data that is not available through Program Variables is the complete set of information for an EXAFS Path. The hiding of this data was a difficult design decision, but I felt it provided a simpler and cleaner interface ², and one that was more amenable to expanding. For the most part, you probably won't even notice that this path data is missing. Besides, almost all of the information about a Path can be converted into Program Variables.