Software products

Because the OxMetrics software installs the module information under HKEY_CURRENT_USER in the registry, it will not be visible when installing under an administrator account, and then trying to run it under another account.

No, administrator access is not required. Below is some more detailed installation information.

The relevant installation information for GiveWin to work with its client modules such as PcGive, STAMP and TSP is stored in the registry. The module and other persistent information (most recently used files, etc.) for GiveWin is stored under HKEY_CURRENT_USER. Even a restricted user has access to this. Note that HKEY_CURRENT_USER is user specific.

Other important information is under HKEY_CLASSES_ROOT, this regards ActiveX automation (allowing PcGive and TSP to communicate with GiveWin) and file types (such as the .gwg file type). A user with restricted privileges has no access to this, so the network administrator has to replicate this information across users.

If the installation is done on a server to which the users connect from other computers, then the network admninstrator has tools to roll out the install the the user's registry. Subsequently, GiveWin will read HKEY_CLASSES_ROOT, but does not need write access. Then the HKEY_CURRENT_USER\GiveWin.2 key can also be installed (this contains the module information).

Updating the registry can also be done `by hand'. Modules can be made to register themselves with (for x: substitute the correct path):

    x:\givewin2\bin\givewin.exe /regserver
    x:\givewin2\bin\pcgive.exe /regserver
etc.

GiveWin automatically updates the registry settings when it is run. Givewin /regserver will just update the registry without running GiveWin.

The entries in HKEY_CLASSES_ROOT are for file types:

All persistent data is stored in HKEY_CURRENT_USER under Software\GiveWin.2\GiveWin including the list of available modules.

GiveWin will update the registry everytime it is run, to ensure that it is run properly. The entries in HKEY_CLASSES_ROOT cannot be set by users with restricted privileges. In that case, the system administrator has to ensure the program is properly installed.

The above registry entries can be created with the following commands:

    givewin /regserver
    regserver oxmated.ocx

    regserver oxmated.ocx

There are two versions of Ox: Ox Professional and Ox Console. Ox Console cannot display graphics (but can save them to disk). Ox Professional, on the other hand, displays graphs in GiveWin. Whenever you see the `Cannot show draw window!' message in the output from Ox Console, there would have been a graph to see with Ox Professional.

Ox has many variable types, including integers, double precision real values (`doubles'), matrices, strings, arrays of any types, objects, etc. The presence of integers and scalar doubles distinguishes Ox from many other matrix languages.
There are several reasons why Ox has integers:

• addition, subtraction and multiplication are exact;
• matrix indexing involves integers;
• efficiency of single index operations.

In Ox, each expression has a type, e.g.:

• concatenating two strings yields a string;
• multiplying two matrices gives a matrix;
• adding two integers gives an integer;
• dividing two integers gives a double.

All arithmetic on a computer has limitations, and Ox does not escape these. Integers range from -2^31 to 2^31-1 (the corresponding constants, defined in oxfloat.h, are INT_MIN and INT_MAX). When integer computations overflow or underflow, the result just wraps around. So, adding 1 to the largest integer gives the largest negative value! It is rare to encounter this in practice. One case I have been contacted about several times is recursive evaluation of the factorial function, n! = n!*(n-1)*...*1; 0! = 1. Successive multiplication by integers keeps the result as an integer, and, when overflow occurs, negative numbers could result.

The following program illustrates.

    #include <oxstd.h>
    factint(const n)
    {
        if (n <= 1)
            return 1;
        return n * factint(n - 1);
    }
    main()
    {
        for (decl i = 2; i < 18; ++i)
        {
            println("%3d", i, "! = ",
                "%15.15g", factorial(i),
                " ", factint(i));
        }
    }

The function factint calls itself recursively, until the integer 1 is returned. All subsequent multiplications involve integers, with the computations going wrong from 13! onwards (the correct numbers on the left-hand side are computed with the built-in function factorial, which was new in Ox 3.2):

  2! =               2 2
  3! =               6 6
  4! =              24 24
  5! =             120 120
  6! =             720 720
  7! =            5040 5040
  8! =           40320 40320
  9! =          362880 362880
 10! =         3628800 3628800
 11! =        39916800 39916800
 12! =       479001600 479001600
 13! =      6227020800 1932053504
 14! =     87178291200 1278945280
 15! =   1307674368000 2004310016
 16! =  20922789888000 2004189184
 17! = 355687428096000 -288522240

Switching to real numbers requires changing one line in the program:

    factdouble(const n)
    {
        if (n <= 1)
            return 1.0;
        return n * factdouble(n - 1);
    }

This allows the function to go much further, until 170! The floating point computations using doubles are also subject to limitations:

• the largest value is approximately 1.79e+308;
• when overflow occurs, the result is infinity;
• about 15 of precision digits are available;
• as a consequence there is an ε such that 1.0+ε=1.0; this is the machine precision, DBL_EPSILON (about 2.2e-16).

Switching to doubles gave the factorial function a larger range. In most situations, the factorial is part of an expression which has an offsetting denominator. An example is the binomial coefficient. Computing 200!/(0!200!) using the factorial function results in .NaN, because it involves +.Inf/+.Inf. Using binomial(200,0) instead, gives the correct answer 1. A similar success could have been achieved with the loggamma function: log(n!) = logΓ(n+1), i.e. taking logs, and then the exponent: exp(loggamma(201) - loggamma(1) - loggamma(201))

DPD/Ox uses generalized inverses in the estimation procedure. The following expression is used in the DPD code (line 1496 in version 1.21):

  mzhzinv = invertgen(mzhzinv, 30);    /* replace zhz by inverse */

Strictly there is no problem with this, and if the two-step coefficients are similar to the one-step coefficients, and both look reasonable compared to results for the same model from other estimators (eg. OLS levels, Within) then there is probably nothing to worry about. However this computational problem can be a signal that too many instruments are used (specifically, in some of the cross-section equations, relative to the cross-section dimension of your panel). It is advisable to check that the results are robust to using a smaller instrument set. Note that an option is available to print out the full instrument set, this can be helpful to understand what is happening, especially regarding the GMM instruments.