`cutord` not working as advertised in the README.md file.

[DavidSagan]

Using the test test/spin1/a.jl which defines the DAMap a_fpp, cutord gives the error:

julia> include("test/spin1/a.jl");

julia> cutord(a_fpp, 2)
ERROR: MethodError: no method matching cutord(::DAMap{StaticArraysCore.MVector{…}, StaticArraysCore.MVector{…}, Quaternion{…}, Nothing}, ::Int64)
The function `cutord` exists, but no method is defined for this combination of argument types.

Closest candidates are:
  cutord(::TPS, ::Integer)
   @ GTPSA ~/.julia/packages/GTPSA/rjfML/src/methods.jl:359

Stacktrace:
 [1] top-level scope
   @ REPL[48]:1
Some type information was truncated. Use `show(err)` to see complete types.

[mattsignorelli]

The reason for this is that NonlinearNormalForm does not export cutord. GTPSA however exports cutord, and so there will be a symbol conflict unless NNF depends explicitly on GTPSA, which it does not - it depends on TPSAInterface.jl. Therefore the quick solution for this would be to use NonlinearNormalForm.cutord. In the long term, GTPSA should probably not export this function

[mattsignorelli]

A doc update however would be good to explain this

[DavidSagan]

Or how about a different function name like map_cutord (or cut_ord?) for the NNF version?

[mattsignorelli]

I think having different names for the similar functionalities may be more confusing than just requesting a qualified call e.g. using NonlinearNormalForm: NonlinearNormalForm as NNF; NNF.cutord

I should note that I've been seeing more and more packages require explicit imports, rather than just using __ to get all of the package's symbols (see DifferentiationInterface.jl which actually has a test making sure Explicitimports.jl is used, so I think that it is ok