To modernize Powell's Fortran 77 code, do the following.
Do things by small steps, and use verify.m to verify that the code
behaves in the same way before and after the changes, e.g.,

options=[]; options.maxdi=20; options.nr=20; verify({'newuoa', 'newuoa_norma'}, options)

verifies newuoa against newuoa_norma on problems of at most 20 variables, 20 random runs for each
problem.
NOTE that newuoa_norma is the version of NEWUOA in .development/norma/.

0. Refactoring.

0.1. Refactor the code into the free form. Change the file name to .f90.
0.2. End all blocks with END BLOCK BLOCKNAME.
0.3. Put a space before and after all =, +, -, comma; for * and /, do
the same if it improves the readability. For =, be careful with ==, =>,
<=, and /=; for -, be careful with -DX (e.g., 1.0-D1).

1. Remove the implicitness.

1.1. Always use IMPLICIT NONE.
1.2. Declare all reals as REAL(RP) and all integers as INTEGER(IK).
Change all 1.0D0 to 1.0_RP, etc.
1.3. Declare the variables in the following order:
Inputs (integer, real)
In-outputs (integer, real)
Outputs (integer, real)
Intermediate variables (integer, real, logical, character)
Within each category, follow the alphabetical order.
1.4. Declare only one variable in each line.
1.5. Specify the intent of dummy variables.
1.6. In the signature of subroutines, arrange the dummy variables in the same
order as they are declared. This does not apply to the main subroutine
(e.g., newuoa.f90) or the common subroutines (e.g., r1update), where the
dummy variables are arranged according to the logic of the subroutine.
1.7. All dummy arrays should be assumed-shape. Use VERISIZE to verify
their sizes if DEBUGGING is true.

2. Use matrix/vector operations.

If appropriate, replace loops with matrix/vector operations (inprod, matprod,
r1update, etc.; see linalg.F90). This will reduce the complexity of the code.

Note that floating-point arithmetic is NOT ASSOCIATIVE! For example,

a = t
do i = 1, n
    a = a + b(i)
end do

is NOT equivalent to a = t + sum(b) unless t = 0.

3. Transpose XPT and BMAT (and other arrays if appropriate).

See Notes_On_Transposing_XPT_BMAT for how to do it.

4. Modularize the code.

Recognize blocks of the code that can be modularized into subroutines.

4.1. Note that WCHECK, XOPTSQ should be calculated internally rather
than passed as a dummy argument. This may change a bit the result. To
keep the results identical, do the same in the original code.

4.2. Note that DSTEP is renamed to DELBAR in NEWUOA.

5. Remove the GOTOs.

This is the most complex and important step. It needs a lot of care.

6. Correct the bugs.

Two bugs have been spotted in NEWUOA:
-- DNORM was not updated after a model step;
-- the update of IDZ in update.f was incorrect.

Similar bugs may exist in other solvers.

7. Others.

7.1. Temporary variables
Use temporary variables at little as possible.
Do not share temporary variables.
Even for temporary variables, their names should be informative; do not
use temp, tempa, tempb ...

7.2. Integer kind and real precision
It is a good idea to keep integer kind IK = 16 during the development.
This will remind us to explicitly convert integer types when necessary.
In addition, changing IK does not affect the result unless for large
problems, when MAXFUN may be changed due to the upper limit of
INTEGER(IK).

It is also useful to try RP = 32. The reason is the same as above. But
changing RP will obviously affect the result.

7.3. We should also try different combinations of DEBUGGING,
USE_INTRINSIC_ALGEBRA, USE_POWELL_ALGEBRA to make sure that all
variations of the code works correctly.

7.4 Do not use ZERO, ONE,TWO, TEN, TENTH, etc in Powell's original code, as they may not be defined.

7.5 Do not mix MATMUL with MATPROD or DOT_PRODUCT with INPROD. They are not guaranteed to produce
  the same results given the same data!!!!
