ParaMonte Fortran 2.0.0
Parallel Monte Carlo and Machine Learning Library
See the latest version documentation. |

Todo List

- page Main Page
Critical Priority: The module

`pm_sampleConv`

for timer series convolution must be added to the library.

The implementation of such module is straightforward and follows that of the existing module pm_sampleCCF.

Critical Priority: The module

`pm_distanceManhattan`

for computing the Manhattan metric distance must be added to the library.

The module`pm_distanceMinkowski`

for computing the Minkowski metric distance must be added to the library.

Critical Priority: The ParaNest and ParaDISE samplers must be added to the module pm_sampling.

This is a task that only Amir Shahmoradi can complete.

- Type pm_arrayCenter::getCentered
- Normal Priority: Two new optional input scalar
`lbcold`

and`ubcold`

arguments can be added to procedures to specify a subset of the contents of the original array that has to be kept in the newly allocated centered array.

- Type pm_arrayCenter::setCentered
- Normal Priority: Two new optional input scalar
`lbcold`

and`ubcold`

arguments can be added to procedures to specify a subset of the contents of the original array that has to be kept in the newly allocated centered array. - Type pm_arrayChange::getChange
- The input argument
`step`

can be made`optional`

.

Currently, it is a required argument to avoid testing complexities in the case of input real-valued ranges.

- Module pm_arrayCompareLex
Normal Priority: A generic interface for supplying a user-defined arbitrary comparison operator should be added.

Normal Priority: Ideally, a procedure with unlimited polymorphic arguments could be also added for lexical comparison of all types of input arrays, albeit with a user-defined operator supplied to the procedure.

- (.lge.) Type pm_arrayCompareLex::operator(.lge.)
- Very Low Priority: The functionality of this generic interface should be extended to input container arguments, also to arrays of higher ranks.
- (.lgt.) Type pm_arrayCompareLex::operator(.lgt.)
- Very Low Priority: The functionality of this generic interface should be extended to input container arguments, also to arrays of higher ranks.
- (.lle.) Type pm_arrayCompareLex::operator(.lle.)
- Very Low Priority: The functionality of this generic interface should be extended to input container arguments, also to arrays of higher ranks.
- (.llt.) Type pm_arrayCompareLex::operator(.llt.)
- Module pm_arrayComplement
- High Priority: The two function interfaces of this module can be merged into a single generic interface.

- Type pm_arrayCopy::setCopyStrided
- Normal Priority: Benchmarks comparing this interface with LAPACK routines and conventional approach should be added to the documentation.

- Type pm_arrayFill::getFilled
- Low Priority: This generic interface can be extended to
`array`

arguments of higher ranks.

- Type pm_arrayFind::getCountLoc
Low Priority: This generic interface can be extended to higher-dimensional input arrays.

Critical Priority: Currently, the value of

`blindness`

is checked for being non-zero in the implementation.

However, the documentation of`blindness`

requires it to be positive.

This conflict between the implementation and documentation must be resolved.

Normal Priority: The functionality of this generic interface can be extended with an optional

`border`

argument as in getCountLoc.

- Type pm_arrayFind::getLoc
Low Priority: This generic interface can be extended to higher-dimensional input arrays.

Critical Priority: Currently, the value of

`blindness`

is checked for being non-zero in the implementation.

However, the documentation of`blindness`

requires it to be positive.

This conflict between the implementation and documentation must be resolved.

Normal Priority: The functionality of this generic interface can be extended with an optional

`border`

argument as in getCountLoc.

- Type pm_arrayFind::setLoc
Low Priority: This generic interface can be extended to higher-dimensional input arrays.

Critical Priority: Currently, the value of

`blindness`

is checked for being non-zero in the implementation.

However, the documentation of`blindness`

requires it to be positive.

This conflict between the implementation and documentation must be resolved.

- Module pm_arrayInit
- Normal Priority: A separate module
`pm_arrayInitHalo`

should be added in future to handle initialization of halos exclusively (without changing array cores). - Type pm_arrayInit::getCoreHalo
Low Priority: This generic interface can be extended to

`array`

arguments of higher ranks.

Normal Priority: Unlike setCoreHalo, this functional generic interface lacks the option for scalar input

`core`

.

This is because of ambiguity created by scalar`core`

for output`array`

of ranks two and higher.

This can be resolved once the Fortran standard allows deferred rank function output.

- Type pm_arrayInit::setCoreHalo
Normal Priority: The current interface requires the input

`core`

to be`contiguous`

when it is an array.

This restriction can be lifted by either removing the`contiguous`

attribute of the argument or adding additional`lbcore, ubcore`

subsetting arguments to the interface.

The former offers a simple yet powerful solution.

However, a benchmark must be done to investigate the performance penalty of switching the`contiguous`

attribute off.

Critical Priority: The examples of this generic interface incorrectly call the functional interface.

This must be fixed before release of the library.

Low Priority: This generic interface can be extended to

`array`

arguments of higher ranks.

- Type pm_arrayInsert::getInserted
Low Priority: This generic interface can be extended to 2D input objects.

Normal Priority: A benchmark comparing the performance of getInserted with and without

`positive, sorted`

should be added.- Type pm_arrayInsert::setInserted
Very Low Priority: This generic interface can be extended to 2D input objects.

Very Low Priority: This generic interface can be extended to accept an

`intent(inout), allocatable :: array`

instead of`ArraNew`

to simplify in-place insertion. However, the potential resulting code bloat outweigh the slightly improved calling syntax benefits.

Normal Priority: A benchmark comparing the performance of setInserted with and without

`positive, sorted`

should be added.

- Module pm_arrayMerge
- Low Priority: The examples of this module require an update.

- Type pm_arrayMinMax::getMinMaxVal
- Low Priority: This generic interface can be expanded to include the possibility of passing user-defined custom comparison.
- Type pm_arrayMinMax::setMinMaxVal
Critical Priority: The dynamic

`character`

allocation due to the bug described above must be eliminated within the implementation of this module as soon as the Intel compilers bugs are resolved.Low Priority: This generic interface can be expanded to include the possibility of passing user-defined custom comparison.

- Type pm_arrayPad::getPadded
- Normal Priority: Two new optional input scalar
`lbcold`

and`ubcold`

arguments can be added to procedures to specify a subset of the contents of the original array that has to be kept in the newly allocated padded array. - Type pm_arrayPad::getPaddedl
- Normal Priority: Two new optional input scalar
`lbcold`

and`ubcold`

arguments can be added to procedures to specify a subset of the contents of the original array that has to be kept in the newly allocated padded array. - Type pm_arrayPad::getPaddedr
- Normal Priority: Two new optional input scalar
`lbcold`

and`ubcold`

arguments can be added to procedures to specify a subset of the contents of the original array that has to be kept in the newly allocated padded array. - Type pm_arrayPad::setPadded
- Normal Priority: Two new optional input scalar
`lbcold`

and`ubcold`

arguments can be added to procedures to specify a subset of the contents of the original array that has to be kept in the newly allocated padded array. - Type pm_arrayPad::setPaddedl
- Normal Priority: Two new optional input scalar
`lbcold`

and`ubcold`

arguments can be added to procedures to specify a subset of the contents of the original array that has to be kept in the newly allocated padded array. - Type pm_arrayPad::setPaddedr
- Normal Priority: Two new optional input scalar
`lbcold`

and`ubcold`

arguments can be added to procedures to specify a subset of the contents of the original array that has to be kept in the newly allocated padded array. - Module pm_arrayRank
Low Priority: The relevant benchmarks comparing the functional and subroutine interfaces should be added here.

Critical Priority: Support for ranking of arrays of PDTs must be enabled again as soon as GNU Fortran Compiler

`gfortran`

supports PDTs.

High Priority: An optional argument

`sorted`

must be added to all interfaces within this module to allow fast computation of the rankings of previously sorted arrays without redundant resorting.

Normal Priority: The generic interfaces of this module must be extended to support rankings of matrices along a specified dimension.

Such a pattern occurs, for example, in computing the Spearman rank correlation matrix.

Normal Priority: The current implementation of the generic ranking interfaces of this module are separated from each other.

However, it may be preferrable to merge all generic interfaces into single interface bindings`getRank()`

and`setRank()`

.

Consequently, an extra argument of class rank_type must be added to all procedure interfaces to make them distinguishable.

For now, the procedures for different ranking methods were are under separate generic interface names, because of the complexity in the merging of the fractional ranking procedures (which output`real`

ranks of default kind RK) with the rest (which output`integer`

ranks of default kind IK).

- Type pm_arrayRank::getRankDense
Low Priority: The current bypass for the PDT name aliasing bug can be reverted back to PDT name aliasing once the ifort bug is resolved.

Low Priority: A test should be implemented for arrays of size that can be represented

*only*by an IKD integer.- Type pm_arrayRank::getRankFractional
Low Priority: The current bypass for the PDT name aliasing bug can be reverted back to PDT name aliasing once the ifort bug is resolved.

Low Priority: A test should be implemented for arrays of size that can be represented

*only*by an IKD integer.- Type pm_arrayRank::getRankModified
Low Priority: The current bypass for the PDT name aliasing bug can be reverted back to PDT name aliasing once the ifort bug is resolved.

Low Priority: A test should be implemented for arrays of size that can be represented

*only*by an IKD integer.- Type pm_arrayRank::getRankOrdinal
*only*by an IKD integer.- Type pm_arrayRank::getRankStandard
*only*by an IKD integer.- Type pm_arrayRank::setRankDense
*only*by an IKD integer.- Type pm_arrayRank::setRankFractional
*only*by an IKD integer.- Type pm_arrayRank::setRankModified
*only*by an IKD integer.- Type pm_arrayRank::setRankOrdinal
*only*by an IKD integer.- Type pm_arrayRank::setRankStandard
*only*by an IKD integer.- Type pm_arrayRebill::setRebilled
Very Low Priority: This generic interface can be extended to arrays of higher ranks.

Normal Priority: This generic interface should be extended to arrays of container type as done in pm_arrayResize.

- Type pm_arrayRebind::setRebound
Very Low Priority: This generic interface can be extended to arrays of higher ranks than currently supported.

Normal Priority: This generic interface should be extended to arrays of container type as done in pm_arrayResize.

- Type pm_arrayRefill::setRefilled
Very Low Priority: This generic interface can be extended to arrays of higher ranks than currently supported.

Normal Priority: This generic interface should be extended to arrays of container type as done in pm_arrayResize.

- Module pm_arrayRefine
- Normal Priority: Interfaces for
`real`

weights and without weights should be added in future.

- Type pm_arrayRemap::getRemapped
Critical Priority: The gfortran bugs in the implementations of this generic interface must be resolved in the future.

Low Priority: This generic interface can be extended to 1D input objects.

- Type pm_arrayRemap::setRemapped
Low Priority: This generic interface can be extended to 1D input objects.

Critical Priority: The gfortran bugs in the implementations of this generic interface must be resolved in the future.

- Type pm_arrayRemove::getRemoved
- Low Priority: This generic interface can be extended to 2D input objects.

- Type pm_arrayRemove::setRemoved
- Low Priority: This generic interface can be extended to 2D input objects.

- Type pm_arrayReplace::getReplaced
The internal compiler error with Intel Classic Fortran Compiler

`ifort`

and GNU Fortran Compiler`gfortran`

has to be fixed in the future versions.

Low Priority: This generic interface can be extended to 2D input objects.

High Priority: This generic interface can be extended to scalar input

`pattern`

and`replacement`

arguments.

Such an extension will likely lead to runtime performance gain for cases where`pattern`

and`replacement`

are arrays of length`1`

.

See pm_arraySplit for a relevant benchmark about this matter.

High Priority: A benchmark comparing the performance of setReplaced with and without

`sorted, unique`

optional input arguments should be added.

- Type pm_arrayReplace::setReplaced
Low Priority: This logic behind using

`intent(inout), allocatable :: array`

argument as opposed to returning the result in a new array is that the size of the output array is not known a priori, but is determined within the algorithm.

If the use of`allocatable`

dummy arguments is to be truly avoided, a new interface can be added where the output is returned in a`contiguous`

`ArrayReplaced`

while the input array remains intact.

Low Priority: This generic interface can be extended to 2D input objects.

High Priority: This generic interface can be extended to scalar non-string input

`pattern`

and`replacement`

arguments.

Such an extension will likely lead to runtime performance gain for cases where`pattern`

and`replacement`

are arrays of length`1`

. See pm_arraySplit for an example relevant benchmark about this matter.

High Priority: A benchmark comparing the performance of setReplaced with and without

`sorted, unique`

optional input arguments should be added.- Type pm_arrayResize::setResized
- Very Low Priority: This generic interface can be extended to arrays of higher ranks than currently supported.

- Type pm_arrayReverse::getReversed
- Low Priority: This generic interface can be extended to 2D input objects.

- Type pm_arrayReverse::setReversed
- Low Priority: This generic interface can be extended to 2D input objects.

- Type pm_arraySelect::getSelected
- Low Priority: This generic interface can be extended to higher-rank input objects.

- Type pm_arraySelect::setSelected
- Low Priority: This generic interface can be extended to higher-rank input objects.

- Type pm_arrayShuffle::getShuffled
- Low Priority: This generic interface can be extended to 2D input objects.

- Type pm_arrayShuffle::setShuffled
Low Priority: This generic interface can be extended to 2D input objects.

High Priority:

**Update 2021: This task is now resolved.**

The current random integer generator uses a simple double precision`real`

conversion to`integer`

values.

While this works fairly well for most use cases, it may biased for generating random`integer`

of kind IK4.

A future remedy should use Bitmask with Rejection as described here.

As of 2021, the use of double precision (64-bit) vs. single-precision for random number generation increases the computational cost of the algorithms by about three times.

- Module pm_arraySort
- Very Low Priority: An equivalent functional versions of setSorted and setSorted could be added along with the relevant benchmarks.

- Type pm_arraySort::isAscending
- This interface can be extended to scalar containers of strings.
- Type pm_arraySort::isAscendingAll
- This interface can be extended to scalar containers of strings.
- Type pm_arraySort::isDescendingAll
- This interface can be extended to scalar containers of strings.
- Type pm_arraySort::setSorted
- Normal Priority: Low Priority: The current bypass for the PDT name aliasing bug should be reverted back to PDT name aliasing once the ifort bug is resolved.
- Type pm_arraySpace::getLogSpace
- Normal Priority: This generic interface can be expanded to include procedures with real-valued input argument
`space`

instead of`count`

. - Type pm_arraySpace::setLogSpace
- Low Priority: This generic interface can be expanded to include procedures with real-valued input argument
`space`

instead of`count`

. - Module pm_arraySplit
- Normal Priority: A benchmark comparing the performance of output index array vs. output jagged array would be informative here.

- Type pm_arraySplit::setSplit
Normal Priority: A

`backward`

optional argument can be added in the future to search for the input`sep`

in the backward direction.Low Priority: For now, all PDT name aliases have been removed to bypass the Intel Classic Fortran Compiler

`ifort`

bug.

This can be reverted back to the original aliasing approach in the future once the Intel ifort bug is resolved.

However, the whole point of using aliases was to make the development of the code easier and nicer.

With the use of explicit names, there might really be no point in reviving the aliases other than code aesthetics.

Low Priority: This generic interface can be extended to 2D input objects.

- Module pm_arrayStrip
- Low Priority: A benchmark comparing the performance of indexing vs. allocating a modified array should be provided here.
- Type pm_arrayUnique::getUnique
Low Priority: This generic interface can be extended to 2D input objects.

Critical Priority: The internal compiler error with

`ifort`

and`gfortran`

has to be fixed in the future versions.

- Type pm_arrayUnique::setUnique
Low Priority: This generic interface can be extended to 2D input objects.

High Priority: To avoid extra data copy and improve performance, an extra optional

`lenUnique`

output argument could be added to the procedures such that when it is present, the output arrays`unique`

and`count`

will not be resized from`size(array)`

to the correct length`lenUnique`

.

In such a case, the onus would be on the user to ensure only the elements`(1:lenUnique)`

of the output arrays are used for any subsequent work as only these elements are meaningful. This would, however, come with the benefit of extra efficiency.

- Module pm_arrayVerbose
- Normal Priority: A generic subroutine interface corresponding to the generic function interface getVerbose might be added in future.

- Type pm_bench::benchMulti_typer
- Very Low Priority: The current construction of the
`name`

component of the output object relies on repeated allocation of`name`

.

This can be improved by removing the redundant allocation in future, although any performance benefits are questionable.

- Type pm_bench::getTiming
- High Priority: The computation of the median, skewness, and kurtosis of the timing vector in the
`stat`

component must be implemented. - Type pm_bench::setTiming
- High Priority: The computation of the median, skewness, and kurtosis of the timing vector in the
`stat`

component must be implemented.

- Type pm_complexMinMax::maxloc
- Normal Priority: This generic interface can be extended with optional
`mask`

and`back`

arguments to match those of the intrinsic`maxloc()`

.

- Type pm_complexMinMax::minloc
- Normal Priority: This generic interface can be extended with optional
`mask`

and`back`

arguments to match those of the intrinsic`minloc()`

.

- Module pm_container
- Normal Priority: Currently, only the following containers are exemplified:

- (=) Type pm_container::assignment(=)
- Very Low Priority: The functionality of this generic interface can be extended to input arrays of higher rank.
- (/=) Type pm_container::operator(/=)
- Very Low Priority: The functionality of this generic interface can be extended to input arrays of higher rank.
- (<) Type pm_container::operator(<)
- Very Low Priority: The functionality of this generic interface can be extended to input arrays of higher rank.
- (<=) Type pm_container::operator(<=)
- (==) Type pm_container::operator(==)
- (>) Type pm_container::operator(>)
- (>=) Type pm_container::operator(>=)
- Type pm_cosmicRate::getLogRateDensityB10
- This generic interface can be extended to higher-rank input arrays.

- Type pm_cosmicRate::getLogRateDensityF18
- Very Low Priority: This generic interface can be extended to higher-rank input arrays.

- Type pm_cosmicRate::getLogRateDensityH06
- Very Low Priority: This generic interface can be extended to higher-rank input arrays.

- Type pm_cosmicRate::getLogRateDensityL08
- Very Low Priority: This generic interface can be extended to higher-rank input arrays.

- Type pm_cosmicRate::getLogRateDensityM14
- Very Low Priority: This generic interface can be extended to higher-rank input arrays.

- Type pm_cosmicRate::getLogRateDensityM17
- Very Low Priority: This generic interface can be extended to higher-rank input arrays.

- Type pm_cosmicRate::getLogRateDensityP15
- This generic interface can be extended to higher-rank input arrays.

- Module pm_cosmology
- Normal Priority: A visualization comparison of all cosmological distances should be added here.
- Type pm_cosmology::getDisComTransNormedWU10
- High Priority: The origins of the glitch in the output of this algorithm at high redshifts (visible in the plots) must be investigated and corrected.

- Module pm_dateTime
A subroutine equivalent of the performance-critical functions with

`allocatable`

output (e.g., getDateTime) should be added in the future.High Priority: Most of the routines of this module are currently implemented for the default

`integer`

kind and the default`real64`

real kind.

The choice of kinds is primarily dictated by the output of the Fortran intrinsic`date_and_time()`

.

All routines should be extended to generic interfaces supporting multiple kinds in future.

- Type pm_dateTime::getDateTime
High Priority: The format specifiers \(\ms{%U}\) and \(\ms{%W}\) must be implemented.

Normal Priority: This interface can be extended to add

`format`

input argument to all possible calling interfaces.

Low Priority: Locale-dependent date and time formats can be added to this generic interface in the future, depending on the demand.

- Type pm_dateTime::getZoneAbbr
- High Priority: Currently, the zone abbreviation is derived from a predefined list.

The zone abbreviation must be inferred directly from the operating system.

On Windows, this could be also be done via the Powershell command`(Get-Date).IsDaylightSavingTime()`

to test whether the daylight savings is activated.

On Unix, The command`date +"\%Z"`

outputs the zone abbreviation.

- Type pm_distanceBhat::getDisBhat
- Critical Priority: The runtime checks for the complex input
`invCov`

must be implemented.

- Module pm_distanceEuclid
High Priority: The connection between the different packing schemes of the distance matrix and the packing methods in pm_matrixPack must be further clarified.

Normal Priority: A comparison and benchmark with faster less numerically-stable computational methods for pairwise distances might be informative here.

See also a relevant discussion in stackexchange.

- Type pm_distanceEuclid::getDisEuclid
- Normal Priority: A benchmark comparison with the equivalent compiler implementations would be informative.
- Type pm_distanceEuclid::getDisMatEuclid
- High Priority: This generic interface must be extended to allow other packing and subsets of the output distance matrix.
- Type pm_distanceEuclid::setDisEuclid
- Normal Priority: A benchmark comparison with the equivalent compiler implementations would be informative.
- Type pm_distanceEuclid::setDisMatEuclid
- High Priority: This generic interface must be extended to allow other packing and subsets of the output distance matrix.
- Type pm_distanceHellinger::getDisHellSq
- Critical Priority: The runtime checks for the complex input
`invCov`

must be implemented.

- Type pm_distanceMahal::getDisMahalSq
- Critical Priority: The runtime checks for the complex input
`invCov`

must be implemented.

- Type pm_distanceMahal::setDisMahalSq
Critical Priority: The runtime checks for the complex input

`invCov`

must be implemented.

High Priority: The performance of the implementation for

`complex`

input can be improved by using`do_product`

on columns of`invCov`

instead of the current implementation working with rows of`invCov`

in`matmul`

.

- Type pm_distBand::distBand_type
- Critical Priority: This derived type must be converted to PDT and the relevant components and methods must be added once PDTs are well supported.
- Type pm_distBern::distBern_type
- Critical Priority: This derived type must be converted to PDT and the relevant components and methods must be added once PDTs are well supported.
- Module pm_distBeta
- Critical Priority: The quantile function must be implemented here.
- Type pm_distBeta::distBeta_type
- Critical Priority: This derived type must be converted to PDT and the relevant components and methods must be added once PDTs are well supported.
- Type pm_distBeta::getBetaLogPDF
- Normal Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distBeta::getBetaPDF
- Normal Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distBeta::setBetaLogPDF
- Normal Priority: This generic interface can be extended to
`complex`

arguments.

- Module pm_distCosRaised
- Normal Priority: Two additional interfaces for computing the quantiles and random values of Raised Cosine Distribution must be added.

The methodology employed for the [Beta distribution](@ pm_distBeta) might be useful here.

- Type pm_distCosRaised::distCosRaised_type
- Type pm_distCosRaised::getCosRaisedCDF
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distCosRaised::getCosRaisedPDF
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distCosRaised::setCosRaisedCDF
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distCosRaised::setCosRaisedPDF
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Module pm_distCov
- Critical Priority: The output square matrices from the onion method are frequently non-positive-definite, particularly in higher dimensions.

A closer look into the root causes of this instability must be done.

- Type pm_distCov::setCovRand
High Priority: The current implementation of this generic interface uses a naive method of computing the Cholesky factorization with a default matrix packing for the Onion method.

The RFP packing format must be also implemented for this generic interface.

High Priority: The current implementation of the Gram method can be significantly improved, both computationally and functionally.

- Type pm_distExp::distExp_type
- Type pm_distExp::getExpCDF
- Normal Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distExp::getExpLogPDF
- Normal Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distExp::setExpCDF
- Normal Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distExp::setExpLogPDF
- Normal Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distExp::setExpRand
- Critical Priority: The Intel ifort bug (described below) appears to have been resolved in ifort 2021.4.

Therefore, once TACC and other relevant supercomputers have ifort >=2021.4 installed, the bug workaround must be resolved.

- Type pm_distExpGamma::distExpGamma_type
- Type pm_distExpGamma::getExpGammaCDF
- Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distExpGamma::getExpGammaLogPDF
- Normal Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distExpGamma::getExpGammaLogPDFNF
- Normal Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distExpGamma::setExpGammaCDF
- Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distExpGamma::setExpGammaLogPDF
- Normal Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distGamma::distGamma_type
- Type pm_distGamma::getGammaCDF
- Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distGamma::getGammaLogPDF
- Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distGamma::getGammaLogPDFNF
- Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distGamma::setGammaCDF
- Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distGamma::setGammaLogPDF
- Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distGenExpGamma::distGenExpGamma_type
- Type pm_distGenExpGamma::getGenExpGammaCDF
- Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distGenExpGamma::getGenExpGammaLogPDF
- Normal Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distGenExpGamma::getGenExpGammaLogPDFNF
- Normal Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distGenExpGamma::setGenExpGammaCDF
- Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distGenExpGamma::setGenExpGammaLogPDF
- Normal Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distGenGamma::distGenGamma_type
- Type pm_distGenGamma::getGenGammaCDF
- Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distGenGamma::getGenGammaLogPDF
- Normal Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distGenGamma::getGenGammaLogPDFNF
- Normal Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distGenGamma::setGenGammaCDF
- Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distGenGamma::setGenGammaLogPDF
- Normal Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distGeom::distGeom_type
- Type pm_distGeom::setGeomLogPMF
- Normal Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distGeomCyclic::distGeomCyclic_type
- Type pm_distGeomCyclic::setGeomCyclicLogCDF
- Normal Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distGeomCyclic::setGeomCyclicLogPMF
- Normal Priority: This generic interface can be extended to
`complex`

arguments.

- Module pm_distKolm
- Normal Priority: Two additional interfaces for computing the quantiles and random values of Kolmogorov Distribution must be added.

The methodology employed for the [Beta distribution](@ pm_distBeta) might be useful here.

- Type pm_distKolm::distKolm_type
- Type pm_distKolm::getKolmCDF
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distKolm::getKolmPDF
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distKolm::getKolmQuan
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distKolm::getKolmRand
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distKolm::setKolmCDF
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distKolm::setKolmPDF
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distKolm::setKolmRand
- Critical Priority: This interface can be extended to support vector-like
`rand`

arguments other than the`elemental`

approach.

Such an extension would be sensible only if the new interface improves the performance against the`elemental`

approach.

- Type pm_distLogNorm::distLogNorm_type
- Type pm_distLogNorm::setLogNormLogPDF
- Normal Priority: A performant vectorized
`logPDF(:)`

version of the subroutines under this generic interface could be added in the future. - Type pm_distLogUnif::distLogUnif_type
- Type pm_distLogUnif::getLogUnifCDF
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distLogUnif::getLogUnifLogQuan
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distLogUnif::getLogUnifPDF
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distLogUnif::getLogUnifPDFNF
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distLogUnif::getLogUnifRand
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distLogUnif::setLogUnifCDF
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distLogUnif::setLogUnifPDF
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distMultiNorm::distMultiNorm_type
- Type pm_distMultiNorm::getMultiNormLogPDF
- Normal Priority: When the input argument
`logPDFNF`

is missing and`invCov`

is present, there is a possibility that the Cholesky Factorization in the computation of`logSqrtDetInvCov`

fails.

In such cases, the procedure will halt the program by calling`error stop`

.

An optional`info`

output argument must be added in the future to handle such runtime failures gracefully. - Type pm_distMultiNorm::setMultiNormRand
- Normal Priority: The access pattern for the upper-diagonal subset of
`chol`

is non`contiguous`

in the current implementation.

The access pattern can be likely made`contiguous`

by an appropriate implementation.

- Type pm_distNegExp::distNegExp_type
- Type pm_distNegExp::getNegExpCDF
- Normal Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distNegExp::getNegExpLogPDF
- Normal Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distNegExp::setNegExpCDF
- Normal Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distNegExp::setNegExpLogPDF
- Normal Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distNegExp::setNegExpRand
- Critical Priority: The Intel ifort bug (described below) appears to have been resolved in ifort 2021.4.

Therefore, once TACC and other relevant supercomputers have ifort >=2021.4 installed, the bug workaround must be resolved.

- Module pm_distNorm
- Very Low Priority: The performance of the current implementation of the Ziggurat RNG algorithm can be slightly improved for single-precision Normal RNG in the procedures that rely on xoshiro256ssw_type for uniform RNG.

This requires a customized implementation of the Ziggurat method for this`real`

kind.

- Type pm_distNorm::distNorm_type
- Type pm_distNorm::getNormKLD
- High Priority: The KLD implementation should be implemented with
`log1mexp`

for better accuracy. - Type pm_distNorm::setNormLogPDF
- Normal Priority: A performant vectorized
`logPDF(:)`

version of the subroutines under this generic interface could be added in the future. - Type pm_distPareto::distPareto_type
- Type pm_distPareto::getParetoLogCDF
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPareto::getParetoLogCDFNF
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPareto::getParetoLogPDF
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPareto::getParetoLogPDFNF
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPareto::getParetoLogQuan
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPareto::getParetoLogRand
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPareto::setParetoLogCDF
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPareto::setParetoLogPDF
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPareto::setParetoLogRand
- Critical Priority: This interface can be extended to support vector-like
`logRand`

arguments other than the`elemental`

approach.

Such an extension would be sensible only if the new interface improves the performance against the`elemental`

approach.

- Module pm_distPiwiPoweto
- Generic interfaces for computing the logarithm of CDF robustly (without numerical rounding) must be added in the future.
- Type pm_distPiwiPoweto::getPiwiPowetoCDF
- Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPiwiPoweto::getPiwiPowetoLogPDF
- Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPiwiPoweto::getPiwiPowetoLogPDFNF
- Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPiwiPoweto::setPiwiPowetoCDF
- Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPiwiPoweto::setPiwiPowetoLogPDF
- Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPois::distPois_type
- Type pm_distPois::setPoisLogPMF
- Normal Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPower::distPower_type
- Type pm_distPower::getPowerLogCDF
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPower::getPowerLogCDFNF
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPower::getPowerLogPDF
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPower::getPowerLogPDFNF
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPower::getPowerLogQuan
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPower::getPowerLogRand
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPower::setPowerLogCDF
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPower::setPowerLogPDF
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPower::setPowerLogRand
- Critical Priority: This interface can be extended to support vector-like
`logRand`

arguments other than the`elemental`

approach.

Such an extension would be sensible only if the new interface improves the performance against the`elemental`

approach.

- Module pm_distPoweto
- Generic interfaces for computing the logarithm of CDF robustly (without numerical rounding) must be added in the future.
- Type pm_distPoweto::distPoweto_type
- Type pm_distPoweto::getPowetoLogCDF
- Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPoweto::getPowetoLogCDFNF
- Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPoweto::getPowetoLogPDF
- Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPoweto::getPowetoLogPDFNF
- Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPoweto::getPowetoLogQuan
- Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPoweto::getPowetoLogRand
- Very Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPoweto::setPowetoLogCDF
- Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPoweto::setPowetoLogPDF
- Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPoweto::setPowetoLogQuan
- Low Priority: This generic interface can be extended to
`complex`

arguments.

- Type pm_distPoweto::setPowetoLogRand
- Low Priority: This interface can be extended to support vector-like
`logRand`

arguments other than the`elemental`

approach.

Such an extension would be sensible only if the new interface improves the performance against the`elemental`

approach.

- Type pm_distUnif::distUnif_type
- Type pm_distUnif::getUnifCDF
- Normal Priority: This generic interface can be extended to input string arguments to make it compatible with setUnifRand.
- Type pm_distUnif::getUnifRand
- The current random
`integer`

generator uses a simple double precision`real`

conversion to`integer`

values.

While this works fairly well for most use cases, it may biased for generating large random`integer`

of kind IK4.

A future remedy should use Bitmask with Rejection as described here.

As of 2021, the use of double precision (64-bit) vs. single-precision for random number generation increases the computational cost of the algorithms by about three times.

- Type pm_distUnif::setUnifCDF
Low Priority: This generic interface can be extended to input arguments with ranks higher than

`1`

.Normal Priority: This generic interface can be extended to input string arguments to make it compatible with setUnifRand.

- Type pm_distUnif::splitmix64_type
- High Priority: An illustration of the distribution of the probability of individual bits being
`0`

or`1`

in the mantissa of`real`

-valued random numbers and`integer`

random numbers must be added to the example.

- Type pm_distUnif::xoshiro256ssg_type
- High Priority: An illustration of the distribution of the probability of individual bits being
`0`

or`1`

in the mantissa of`real`

-valued random numbers and`integer`

random numbers must be added to the example.

- Type pm_distUnif::xoshiro256ssw_type
- High Priority: An illustration of the distribution of the probability of individual bits being
`0`

or`1`

in the mantissa of`real`

-valued random numbers and`integer`

random numbers must be added to the example.

- Type pm_distUnifEll::distUnifEll_type
- Type pm_distUnifPar::distUnifPar_type
- Type pm_distUnifPar::getUnifParLogPDF
- Critical Priority: The implementation of this generic interface with an input representative matrix
`repmat`

must be improved for better efficiency.

The current implementation computes the corresponding Gramian matrix which may be slower than directly computing the determinant of the representative matrix.

- Type pm_distUnifSphere::distUnifSphere_type
- Module pm_ellipsoid
- Critical Priority: The excluded procedure
`getLogVolUnion()`

in this module needs cleanup and merging with this module.

- Type pm_ellipsoid::getLogVolEll
- High Priority: A positive-definiteness runtime check for the
`gramian`

input argument of this generic interface must be added.

- Type pm_ellipsoid::isMemberEll
High Priority: A positive-definiteness runtime check for the

`invGram`

input argument of this generic interface must be added.

High Priority: The current implementation of this procedure hard-codes the computation of the Mahalanobis distance, whose current implementation relies on the Fortran intrinsic routines.

This hardcoding should be replaced with potential BLAS alternatives.

- Type pm_err::getFile
- Normal Priority: Adding an example usage to this interface can be helpful.

- Type pm_err::getFine
- Normal Priority: Adding an example usage to this interface can be helpful.

- Type pm_err::getLine
- Normal Priority: Adding an example usage to this interface can be helpful.

- Type pm_err::note_type
- Low Priority: A test should be implemented for arrays of size that can be represented
*only*by an IKD integer. - Type pm_err::setAsserted
- Normal Priority: Adding an example usage to this interface can be helpful.

- Type pm_err::show
- Low Priority: A test should be implemented for arrays of size that can be represented
*only*by an IKD integer. - Type pm_err::stop_type
- Low Priority: A test should be implemented for arrays of size that can be represented
*only*by an IKD integer. - Type pm_err::warn_type
- Low Priority: A test should be implemented for arrays of size that can be represented
*only*by an IKD integer. - Type pm_except::isNAN
- Critical Priority: The implementation of the test for
`NaN`

should be improved to a bitwise comparison that is also valid with non-IEEE-compliant processors. - Module pm_fftpack
- Critical Priority: The sine and cosine forward and reverse transforms must be added to this module.

- Type pm_fftpack::getFactorFFT
- Low Priority: Extension to higher order factors may be worthwhile in future.
- Type pm_io::display_type
- Critical Priority: The
`public`

attributes of all components of this derived type must be converted to`protected`

once the`protected`

attribute of Fortran 2023 is supported by the Fortran compilers supported by the ParaMonte library.

- Type pm_io::getCountRecord
- This procedure can be converted to a generic interface to add the optional
`iseq()`

external comparison procedures for custom exclusion or inclusion of lines in the count. - Type pm_io::getCountRecordLeft
- This procedure can be converted to a generic interface to add the optional
`iseq()`

external comparison procedures for custom exclusion or inclusion of lines in the count. - Type pm_io::getErrTableRead
High Priority: The

`optional`

input arguments`deliml`

`delimr`

must be added to allow parsing arbitrarily-delimited fields.

High Priority: When the user-specified

`sep`

contains a value other than`" "`

or`,`

, the current implementation cannot handle the presence of new line characters within string single or double quote delimited fields in output tables of type`character`

.

This limitation can be fixed by tracking the delimiters while reading the contents of`table`

.

Critical Priority: In the current implementation, the behavior under an empty

`sep`

with`trans`

option present is vague and untested.

This must be clarified via testing and further improvements.

Normal Priority: An

`optional`

input argument`del`

must be added to optionally delete the input`file`

or`unit`

upon**successful**reading of the`table`

.

Normal Priority: The behavior of this generic interface for empty tables is currently undefined, although the

`err`

code is non-zero.

This should be fixed.

Normal Priority: The non-intrinsic values for the output error code

`err`

must be standardized.

Currently, the`err`

is set to`-1`

if an error occurs other than what is diagnosed by the compiler.

- Type pm_io::getFieldSep
Normal Priority: An

`optional`

input argument`maxlenfield`

must be added to return the maximum inferred length of a field in all records of the table.

This option is potentially useful for parsing tables of string fields, where the proper field lengths is unknown a priori.

Without this option, the`read`

action may fail or otherwise, long fields would be truncated to fit the fixed length of`table`

fields.

Normal Priority: The

`optional`

input arguments`deliml`

and`delimr`

of rank`1`

of type css_type must be added to allow field recognition with arbitrary left/right delimiters within a record.

- Type pm_io::setContentsTo
- Normal Priority: This generic interface must be expanded to input
`unit`

in place of an input`file`

.

There are potential complexities associated with an input`unit`

that need`inquire`

statement such as`access`

,`form`

, etc.

- Type pm_io::show
- Critical Priority: The syntax of the procedure interfaces must be fixed and reverted to the original aliasing style, as soon as the Intel Classic Fortran Compiler
`ifort`

version 2021.5 bug is resolved. Note that GNU Fortran Compiler`gfortran`

version 10-11 has no problem compiling the code. - Type pm_knn::setKnnSorted
- High Priority: This generic interface should be extended to support discrete distance matrices.

- Type pm_mathCompare::isClose
- The implementations of the procedures of this generic interface can be improved to ensure robustness against possible rare cases of overflows and underflow as discussed in the documentation of pm_mathCompare.

- Module pm_mathConst
- Low Priority: Th contents of this module can be expanded to include more mathematical constants.

- Subprogram pm_mathConst::APERY_CONST
- Critical Priority: The current implementation of this constant hardcodes the first
`109`

significant digits.

This is more than sufficient for all existing use pm_sampleCov, only: getCovMerged kinds supported by compilers as of 2022.

However, the situation may change in the distant future, where the precision of some`use pm_sampleCov, only: getCovMerged`

kinds surpasses the number of decimal digits hardcoded here.

As such the implementation of this constant should be improved when better mechanisms of arbitrary precision implementation become available.

- Subprogram pm_mathConst::EULER_CONST
- Critical Priority: The current implementation of this constant hardcodes the first
`99`

significant digits.

This is more than sufficient for all existing use pm_sampleCov, only: getCovMerged kinds supported by compilers as of 2022.

However, the situation may change in the distant future, where the precision of some`use pm_sampleCov, only: getCovMerged`

kinds surpasses the number of decimal digits hardcoded here.

As such the implementation of this constant should be improved when better mechanisms of arbitrary precision implementation become available.

- Subprogram pm_mathConst::PRIME_CONST
- Critical Priority: The current implementation of this constant hardcodes the first
`105`

significant digits.

This is more than sufficient for all existing use pm_sampleCov, only: getCovMerged kinds supported by compilers as of 2022.

However, the situation may change in the distant future, where the precision of some`use pm_sampleCov, only: getCovMerged`

kinds surpasses the number of decimal digits hardcoded here.

As such the implementation of this constant should be improved when better mechanisms of arbitrary precision implementation become available.

- Type pm_mathCumPropExp::setCumPropExp
- Low Priority: This generic interface can be expanded to include input arrays with
`Weight`

s. - Type pm_mathCumSum::getCumSum
- Normal Priority: This generic interface can be expanded to include input arrays with
`Weight`

s. - Type pm_mathCumSum::setCumSum
- Normal Priority: This generic interface can be expanded to include input arrays with
`Weight`

s. - Type pm_mathFactoring::getFactoring
- High Priority: The performance of the procedures under this generic interface can be improved by using more efficient algorithms and lookup tables for various ranges of input values. The following schemes could be implemented,

- Type pm_mathLogSumExp::getLogSumExp
- Normal Priority: This generic interface can be expanded to include input arrays with
`Weight`

s. - Type pm_mathMinMax::getMinMax
- Low Priority: This generic interface can be expanded to include the possibility of passing user-defined custom comparison.
- Type pm_mathMinMax::setMinMax
- Type pm_mathNumSys::getCountDigit
- Normal Priority: The performance of this algorithm can be improved by invoking the proper approach to computing the number of digits.
- Type pm_mathNumSys::getNumeral
- Normal Priority: There is a dependency on the kind type parameter of the
`integer`

input arguments requiring`range(0_IKG) < 1024`

.

The algorithm must be modified to become kind-agnostic.

- Module pm_mathRoot
- Normal Priority: The Muller method of root-finding should be implemented.

- Type pm_mathRoot::setRoot
- High Priority: The current implementation of the Schroder method does not converge for
**certain problems**that the Halley method converges readily.

This may be due to the nature of the Schroder update.

Regardless, this should be further investigated.

For now, Schroder is diverted to Halley.

- Module pm_mathRootTest
- Critical Priority: Unfortunately, gfortran 12 and older versions do not properly support the parameterized derived types (PDTs).

As such, the example generic-real-kind PDT types could not be used here.

This creates significant complexities when using the examples of these modules,

because all`real`

kinds in this module are set to the highest precision available.

The onus is then on the end user to write wrappers that convert the relevant components and function-returns to the desired`real`

kinds.

In addition to being ugly, error-prone and verbose, this usage of the highest-precision`real`

kind is also highly inefficient computationally.

Fortunately, once PDTs are supported in gfortran, the conversion of the example types of this module to PDTs is straightforward and non-breaking.

The migration to PDTs must be done as soon as gfortran supports for PDTs is complete.

Note that other compilers have full support of PDTs.

- Type pm_mathSqrt::getSqrt
- Low Priority: A binary-representation calculation of the integer square root should be added in the future.

- Module pm_matrixChol
- High Priority: A benchmark comparing the performance of the two computational algorithms above should be implemented and gauge the impact of row vs. column major access pattern.

- Module pm_matrixClass
- High Priority: This module is a work in progress.

Various missing classifications of matrices should be added in the future and the existing classifications be refined.

- Type pm_matrixClass::isMatClass
High Priority: This generic interface must be extended to all matrix classes documented in this module.

High Priority: The implementation for rfpack can be improved once the corresponding improvements to the auxiliary routines used are implemented.

For example, the current implementation for positive-definiteness check makes a copy of the input array which can be avoided if the corresponding setMatChol interface is implemented.

- Type pm_matrixCopy::getMatCopy
Critical Priority: The testing and examples of this generic interface with respect to different RFP matrix packing formats are incomplete and must be done.

High Priority: This generic interface should be extended to also copy different RFP matrix packing formats directly to other RFP matrix packing formats.

High Priority: This generic interface should be extended to also copy the diagonals of matrices of different RFP formats and LFP formats.

High Priority: This generic interface can be extended to also accept

`operation`

argument for RFP matrix packing.

High Priority: The implementation for

`subset = dia`

must be extended to allow`operation`

argument.

- Type pm_matrixCopy::setMatCopy
Critical Priority: The testing and examples of this generic interface with respect to different RFP matrix packing formats are incomplete and must be done.

High Priority: This generic interface should be extended to also copy different RFP matrix packing formats directly to other RFP matrix packing formats.

High Priority: This generic interface should be extended to also copy the diagonals of matrices of different RFP formats and LFP formats.

High Priority: This generic interface can be extended to also accept

`operation`

argument for RFP matrix packing.

High Priority: The implementation for

`subset = dia`

must be extended to allow`operation`

argument.

- Type pm_matrixDet::getMatDet
Critical Priority: As soon as the Gfortran bug described above is resolved, the

`mat`

argument of the procedures under this generic interface can be changed to have the`value`

attribute instead of the`intent(in)`

.

This will obviate the need for creating an additional copy of the array inside the routine, which has to be also modified subsequently.

Low Priority: This generic interface could be extended to accept different classes of matrices , for example,

- Type pm_matrixIndex::getMatIndex
High Priority: This generic interface should be extended to convert indices of matrices from Rectangular Standard Packing to Rectangular Band Packing and vice versa.

Normal Priority: The implementation of the procedures for converting indices from LFP to RDP could be likely improved for better performance.

- Type pm_matrixInit::getMatInit
- Critical Priority: This generic interface should be extended to matrices of different packing formats besides the default.
- Type pm_matrixInit::setMatInit
- Critical Priority: This generic interface should be extended to matrices of different packing formats besides the default.
- Type pm_matrixInv::setMatInv
- High Priority: The functionality of this generic interface must be extended to fully dispatch to LAPACK inverse matrix routines where appropriate.

- Module pm_matrixMulAdd
- Critical Priority: The following BLAS Band-matrix routines must be added to this module:
- Module pm_matrixMulTri
High Priority: The BLAS routines

`?TPMV`

,`?TPSV`

,`?TBMV`

and`?TBSV`

for Linear Full and Band packing format of the triangular input matrix must be implemented.

Normal Priority: A benchmark comparison of the procedures of setMatMulTri with the optimized BLAS routine calls would be informative.

- Type pm_matrixTrans::setMatTrans
- Normal Priority: The performance of this algorithm could be possibly improved by converting the recursive procedure calls within the implementation to do-loops.

- Module pm_matrixUpdate
Normal Priority: A benchmark comparison of the procedures of this module with the default BLAS/LAPACK implementation would be informative.

Normal Priority: A benchmark comparison of the procedures of this module with the default BLAS/LAPACK implementation would be informative.

- Type pm_matrixUpdate::setMatUpdate
- Normal Priority: The input shape and offset arguments can be made optional by adding new interfaces to the module.

This should be done only after performing relevant benchmarks with the current interface to gauge whether the extension of this module is worth the effort.

- Type pm_matrixUpdate::setMatUpdateR1
- Normal Priority: Benchmarks comparing this interface with LAPACK routines and conventional approach should be added to the documentation.
- Type pm_matrixUpdate::setMatUpdateTriang
- Normal Priority: The input shape and offset arguments can be made optional by adding new interfaces to the module.

This should be done only after performing relevant benchmarks with the current interface to gauge whether the extension of this module is worth the effort.

- Module pm_optimization
- High Priority: The Nedler-Mead algorithm must be implemented.

- Module pm_physUnit
- Normal Priority: Th contents of this module should be substantially expanded.

Conversion procedures for converting physical quantities in various units must be added.

- Module pm_polation
- High Priority: Routines for spline and higher-dimensional interpolation methods must be implemented.

- Module pm_polynomial
- High Priority: A generic interface
`setPolyCoef(coef, root)`

must be added that computes polynomial coefficients from its roots using recursive FFT-based polynomial multiplications.

See the commented-out generic interface`setPolyCoef`

within this module as the starting point.

- Type pm_polynomial::getPolyStr
Normal Priority: This generic interface can be expanded to include an option for the name of the polynomial variable and operator symbols.

Low Priority: The runtime performance of this algorithm can be improved by calling setStr() in the implementation and adding fixed symbols (variable name, ...) progressively.

In particular, the implied do-loop in the current implementation likely significantly stresses the compiler for high-degree polynomials.

The significance of the improvements should be weighed in the light of the relevance of such improvements.

Is this procedure going to be called frequently in numerically intensive applications? Unlikely.

- Type pm_polynomial::setPolyRoot
Critical Priority: The current implementation relies on several local allocations, the most important of which are called

`workspace`

in the current implementation.

Although this generic interface used to accept a`workspace`

argument, it was subsequently removed in favor of simplicity.

A new set of interfaces can be added in the future to allow specification of scratch space arguments to avoid repeated local allocations.

This could boost performance when this generic interface is called many times repeatedly.

Critical Priority: The generic interface for the Eigenvalue method internally uses the eigenvalue computing routine of EISPACK for upper Hessenberg matrices to compute the roots of the polynomial.

This internal implementation should be substituted with the corresponding external routine once it is implemented in the ParaMonte library.

Low Priority: The existing implementations of the algorithms for the Jenkins-Traub method contain relics of F77 coding style in the form of a few

`goto`

statements.

These remaining goto statements should be carefully removed in the future.

Normal Priority: A benchmark comparing the runtime performances of the different polynomial root-finding algorithms of the ParaMonte library should be added here.

Normal Priority: A benchmark comparing the runtime performances of the

`complex`

vs.`real`

coefficient routines of this module should be added here.

- Type pm_polynomial::setPolyRootPolished
- Normal Priority: An optional
`reltol`

may be added in the future to allow control over the error in the refined`root`

.

- Module pm_quadTest
- Critical Priority: Unfortunately, gfortran 12 and older versions do not properly support the parameterized derived types (PDTs).

As such, the example generic-real-kind PDT types could not be used here.

This creates significant complexities when using the examples of these modules,

because all`real`

kinds in this module are set to the highest precision available.

The onus is then on the end user to write wrappers that convert the relevant components and function-returns to the desired`real`

kinds.

In addition to being ugly, error-prone and verbose, this usage of the highest-precision`real`

kind is also highly inefficient computationally.

Fortunately, once PDTs are supported in gfortran, the conversion of the example types of this module to PDTs is straightforward and non-breaking.

The migration to PDTs must be done as soon as gfortran supports for PDTs is complete.

Note that other compilers have full support of PDTs.

- Type pm_sampleACT::getACT
- High Priority: The performance of the implementations of this generic interface can be improved by minimizing allocations and converting function calls to subroutine calls.

- Type pm_sampleAffinity::setAffinity
- High Priority: The performance of the algorithm for the case
`dim = 1`

can be further improved by looping over the sample in the innermost layer.

- Module pm_sampleCor
- High Priority: The procedures of this module should be extended to support samples of type
`complex`

of arbitrary kind type parameter, similar to procedures of pm_sampleVar.

- Type pm_sampleCor::setCordance
- Normal Priority: This generic interface should be extended to allow custom user-specified cordance criteria.

- Module pm_sampleCov
- Normal Priority: The inclusion of bias correction in the calculation of covariance is a frequentist abomination and shenanigan that must be eliminated in the future.

The correction factor should be computed separately from the actual covariance calculation.

- Type pm_sampleCov::setCov
- Normal Priority: The examples of this generic interface should be extended to corrected weighted covariance matrices.

- Type pm_sampleCov::setCovMean
- Normal Priority: The examples of this generic interface should be extended to corrected weighted covariance matrices.

- Type pm_sampleNorm::getNormed
- Very Low Priority: The functionality of this interface can be expanded to include normalizing of higher dimensional input
`sample`

and whole`sample`

input arrays of arbitrary shape, although the latter is trivial using the Fortran array syntax.

- Type pm_sampleNorm::setNormed
- Normal Priority: The functionality of this interface can be expanded to include normalizing of higher dimensional input
`sample`

and whole`sample`

input arrays of arbitrary shape, although the latter is trivial using the Fortran array syntax.

- Type pm_sampleScale::getScaled
- Very Low Priority: The functionality of this interface can be expanded to include scaling of higher dimensional input
`sample`

and whole`sample`

input arrays of arbitrary shape, although the latter is trivial using the Fortran array syntax.

- Type pm_sampleScale::setScaled
- Normal Priority: The functionality of this interface can be expanded to include scaling of higher dimensional input
`sample`

and whole`sample`

input arrays of arbitrary shape, although the latter is trivial using the Fortran array syntax.

- Type pm_sampleShift::getShifted
- Very Low Priority: The functionality of this interface can be expanded to include shifting of higher dimensional input
`sample`

and whole`sample`

input arrays of arbitrary shape, although the latter is trivial using the Fortran array syntax.

- Type pm_sampleShift::setShifted
- Normal Priority: The functionality of this interface can be expanded to include shifting of higher dimensional input
`sample`

and whole`sample`

input arrays of arbitrary shape, although the latter is trivial using the Fortran array syntax.

- Module pm_sampleVar
- Normal Priority: The inclusion of bias correction in the calculation of variance is a frequentist abomination and shenanigan that must be eliminated in the future.

The correction factor should be computed separately from the actual variance calculation.

- Type pm_sampleVar::getVar
- Very Low Priority: The functionality of this interface can be expanded in the future to include the computation of the variance of higher dimensional input
`sample`

and whole`sample`

input arrays of arbitrary shape.

- Type pm_sampleVar::setVar
Normal Priority: The examples of this generic interface need to be extended to weighted samples.

Very Low Priority: The functionality of this interface can be expanded in the future to include the computation of the variance of higher dimensional input

`sample`

and whole`sample`

input arrays of arbitrary shape.

- Type pm_str::getMaxVal
- High Priority: The restriction on the non-zero length of the input string can be lifted to make the behavior compatible with the corresponding intrinsic routine.

- Type pm_str::getMinVal
- High Priority: The restriction on the non-zero length of the input string can be lifted to make the behavior compatible with the corresponding intrinsic routine.

- Module pm_strANSI
- Critical Priority: The gfortran bug must be resolved as soon as possible.
- Type pm_strASCII::getStrQuoted
- Normal Priority: This generic interface can be extended to include an optional argument
`delim`

of type`character(1,SKG)`

that contains the user-specified quotation mark (other than double-quote).

- Type pm_strASCII::setAsciiFromEscaped
- High Priority: A performance benchmarking of the different interfaces of this generic interface should be added in the future.

- Type pm_strASCII::setStrQuoted
- Normal Priority: This generic interface can be extended to include an optional argument
`delim`

of type`character(1,SKG)`

that contains the user-specified quotation mark (other than double-quote).

- Type pm_swap::setSwapped
- This generic interface can be extended to take an optional
`mask`

input argument that leads to selective swapping of array elements: - Module pm_sysPath
- Normal Priority: The following functionalities need to be added to this module,
- Type pm_sysPath::getBaseName
- High Priority: The current Fortran standard 202x does not allow passing characters of non-default kind to the intrinsic Fortran statements and procedures.

As such, the implementation of this procedure for non-default`character`

kinds leads to compile-time kind mismatch errors.

This procedure should be converted back to a generic interface in the future when non-default character kinds are also fully supported by the intrinsic functions.

- Type pm_sysPath::getDirCurrent
- Low Priority: A subroutine version of this functional interface could be implemented in future to avoid allocations and allow for non-default character kinds.

- Type pm_sysPath::getDirHome
- Low Priority: A subroutine version of this functional interface could be implemented in future to avoid allocations and allow for non-default character kinds.

- Type pm_sysPath::getDirName
- High Priority: The current Fortran standard 202x does not allow passing characters of non-default kind to the intrinsic Fortran statements and procedures.

As such, the implementation of this procedure for non-default`character`

kinds leads to compile-time kind mismatch errors.

This procedure should be converted back to a generic interface in the future when non-default character kinds are also fully supported by the intrinsic functions.

- Type pm_sysPath::getDirSep
- High Priority: The current Fortran standard 202x does not allow passing characters of non-default kind to the intrinsic Fortran statements and procedures.

As such, the implementation of this procedure for non-default`character`

kinds leads to compile-time kind mismatch errors.

This procedure should be converted back to a generic interface in the future when non-default character kinds are also fully supported by the intrinsic functions.

- Type pm_sysPath::getDirSeps
- High Priority: The current Fortran standard 202x does not allow passing characters of non-default kind to the intrinsic Fortran statements and procedures.

As such, the implementation of this procedure for non-default`character`

kinds leads to compile-time kind mismatch errors.

This procedure should be converted back to a generic interface in the future when non-default character kinds are also fully supported by the intrinsic functions.

- Type pm_sysPath::getExtName
- High Priority: The current Fortran standard 202x does not allow passing characters of non-default kind to the intrinsic Fortran statements and procedures.

As such, the implementation of this procedure for non-default`character`

kinds leads to compile-time kind mismatch errors.

This procedure should be converted back to a generic interface in the future when non-default character kinds are also fully supported by the intrinsic functions.

- Type pm_sysPath::getFileName
- High Priority: The current Fortran standard 202x does not allow passing characters of non-default kind to the intrinsic Fortran statements and procedures.

As such, the implementation of this procedure for non-default`character`

kinds leads to compile-time kind mismatch errors.

This procedure should be converted back to a generic interface in the future when non-default character kinds are also fully supported by the intrinsic functions.

- Type pm_sysPath::getIndexBaseName
Normal Priority: The examples should be extended to cover the optional argument

`style`

.

High Priority: This procedure should be extended to support non-default character kinds.

- Type pm_sysPath::getIndexDirName
Normal Priority: The examples should be extended to cover the optional argument

`style`

.

High Priority: This procedure should be extended to support non-default character kinds.

- Type pm_sysPath::getIndexExtName
- High Priority: This procedure should be extended to support non-default character kinds.

- Type pm_sysPath::getPathAbs
- Very Low Priority: A subroutine version of this functional interface could be implemented in the future to avoid allocations.

- Type pm_sysPath::getPathExpandedUser
- Low Priority: A subroutine version of this functional interface could be implemented in future to avoid allocations and allow for non-default character kinds.

- Type pm_sysPath::getPathJoined
- High Priority: The current Fortran standard 202x does not allow passing characters of non-default kind to the intrinsic Fortran statements and procedures.

As such, the implementation of this procedure for non-default`character`

kinds leads to compile-time kind mismatch errors.

This procedure should be converted back to a generic interface in the future when non-default character kinds are also fully supported by the intrinsic functions.

- Type pm_sysPath::getPathMatch
- High Priority: The current Fortran standard 202x does not allow passing characters of non-default kind to the intrinsic Fortran statements and procedures.

As such, the implementation of this procedure for non-default`character`

kinds leads to compile-time kind mismatch errors.

This procedure should be converted back to a generic interface in the future when non-default character kinds are also fully supported by the intrinsic functions.

- Type pm_sysPath::getPathNew
High Priority: An optional

`suffix`

argument can be added in the future. Currently, the path suffix is hard-coded in the procedure, unlike`prefix`

.

High Priority: The current Fortran standard 202x does not allow passing characters of non-default kind to the intrinsic Fortran statements and procedures.

As such, the implementation of this procedure for non-default`character`

kinds leads to compile-time kind mismatch errors.

This procedure should be converted back to a generic interface in the future when non-default character kinds are also fully supported by the intrinsic functions.

- Type pm_sysPath::getPathPosix
- Low Priority: The performance of this algorithm could be likely improved by reimplementing the function to remove the unnecessary copy
`pathPosix = path`

.

- Type pm_sysPath::getPathPosixEscaped
- Normal Priority: The implementation of this procedure can be improved by replacing the call to the subroutine version with the actual code.

- Type pm_sysPath::getPathTemp
High Priority: An optional

`suffix`

argument can be added in the future. Currently, the path suffix is hard-coded in the procedure, unlike`prefix`

.

High Priority: The current Fortran standard 202x does not allow passing characters of non-default kind to the intrinsic Fortran statements and procedures.

As such, the implementation of this procedure for non-default`character`

kinds leads to compile-time kind mismatch errors.

This procedure should be converted back to a generic interface in the future when non-default character kinds are also fully supported by the intrinsic functions.

- Type pm_sysPath::getPathVerbatim
- High Priority: The current Fortran standard 202x does not allow passing characters of non-default kind to the intrinsic Fortran statements and procedures.

As such, the implementation of this procedure for non-default`character`

kinds leads to compile-time kind mismatch errors.

This procedure should be converted back to a generic interface in the future when non-default character kinds are also fully supported by the intrinsic functions.

- Type pm_sysPath::glob
- High Priority: The current Fortran standard 202x does not allow passing characters of non-default kind to the intrinsic Fortran statements and procedures.

As such, the implementation of the procedures of this generic interface for non-default`character`

kinds leads to compile-time kind mismatch errors.

This procedure should be converted back to a generic interface in the future when non-default character kinds are also fully supported by the intrinsic functions.

- Type pm_sysPath::isDir
Critical Priority: This generic interface should be extended in the future to gracefully handle intrinsic

`inquire()`

exceptions.

High Priority: The current Fortran standard 202x does not allow passing characters of non-default kind to the intrinsic Fortran statements and procedures.

As such, the implementation of this procedure for non-default`character`

kinds leads to compile-time kind mismatch errors.

This procedure should be converted back to a generic interface in the future when non-default character kinds are also fully supported by the intrinsic functions.

- Type pm_sysPath::isFailedChangeDir
- Low Priority: A subroutine version of this functional interface could be implemented in future to avoid allocations and allow for non-default character kinds.

- Type pm_sysPath::isFailedCopy
- Normal Priority: The current Fortran standard 202x does not allow passing characters of non-default kind to the intrinsic Fortran statements and procedures.

This generic interface should be extended to in the future to support non-default character kinds when they fully supported by the Fortran intrinsic procedures.

- Type pm_sysPath::isFailedGlob
High Priority: The current Fortran standard 202x does not allow passing characters of non-default kind to the intrinsic Fortran statements and procedures.

As such, the implementation of the procedures of this generic interface for non-default`character`

kinds leads to compile-time kind mismatch errors.

This procedure should be converted back to a generic interface in the future when non-default character kinds are also fully supported by the intrinsic functions.

High Priority: The current implementation of this generic interface recognizes only the two most popular wildcards

`?`

and`*`

for globing.

This must be expanded to other widely accepted wildcards (e.g., linux wildcards) or at least the wildcards supported on the respective platforms.

High Priority: The current implementation of this generic interface relies on access to supported runtime shells.

If the runtime shell is unrecognized, the algorithm falls back to`bash`

if the shell is detected on the system, otherwise, the procedure fails.

This should be fixed by changing the approach to rely instead on`scandir()`

and`fnmatch()`

popular interfaces for cross-platform globing.

- Type pm_sysPath::isFailedList
High Priority: The current Fortran standard 202x does not allow passing characters of non-default kind to the intrinsic Fortran statements and procedures.

As such, the implementation of the procedures of this generic interface for non-default`character`

kinds leads to compile-time kind mismatch errors.

This procedure should be converted back to a generic interface in the future when non-default character kinds are also fully supported by the intrinsic functions.

Critical Priority: Support for Windows powershell must be added.

Critical Priority: Support for input wildcard patterns must be added with the help of isFailedGlob.

- Type pm_sysPath::isFailedMakeDir
- Normal Priority: The current Fortran standard 202x does not allow passing characters of non-default kind to the intrinsic Fortran statements and procedures.

This generic interface should be extended to in the future to support non-default character kinds when they fully supported by the Fortran intrinsic procedures.

- Type pm_sysPath::isFailedMakeDirTemp
- Normal Priority: The current Fortran standard 202x does not allow passing characters of non-default kind to the intrinsic Fortran statements and procedures.

This generic interface should be extended to in the future to support non-default character kinds when they fully supported by the Fortran intrinsic procedures.

- Type pm_sysPath::isFailedMove
- High Priority: The current Fortran standard 202x does not allow passing characters of non-default kind to the intrinsic Fortran statements and procedures.

As such, the implementation of this procedure for non-default`character`

kinds leads to compile-time kind mismatch errors.

This procedure should be converted back to a generic interface in the future when non-default character kinds are also fully supported by the intrinsic functions.

- Type pm_sysPath::isFailedRemove
- High Priority: The current Fortran standard 202x does not allow passing characters of non-default kind to the intrinsic Fortran statements and procedures.

As such, the implementation of this procedure for non-default`character`

kinds leads to compile-time kind mismatch errors.

This procedure should be converted back to a generic interface in the future when non-default character kinds are also fully supported by the intrinsic functions.

- Type pm_sysPath::isFile
Critical Priority: This generic interface should be extended in the future to gracefully handle intrinsic

`inquire()`

exceptions.

As such, the implementation of this procedure for non-default`character`

kinds leads to compile-time kind mismatch errors.

This procedure should be converted back to a generic interface in the future when non-default character kinds are also fully supported by the intrinsic functions.

- Type pm_sysPath::ls
- Normal Priority: The current Fortran standard 202x does not allow passing characters of non-default kind to the intrinsic Fortran statements and procedures.

As such, the implementation of the procedures of this generic interface for non-default`character`

kinds leads to compile-time kind mismatch errors.

This procedure should be converted back to a generic interface in the future when non-default character kinds are also fully supported by the intrinsic functions.

- Type pm_sysPath::setPathMatch
- High Priority: The current Fortran standard 202x does not allow passing characters of non-default kind to the intrinsic Fortran statements and procedures.

As such, the implementation of this procedure for non-default`character`

kinds leads to compile-time kind mismatch errors.

This procedure should be converted back to a generic interface in the future when non-default character kinds are also fully supported by the intrinsic functions.

- Type pm_sysPath::setPathPosix
- High Priority: An optional argument external procedure
`iseq()`

should be added to the procedures of this generic interface to bring flexibility to searching for`ignore`

patterns.

- Type pm_sysPath::setPathPosixEscaped
- Low Priority: This procedure can be converted to a generic interface with an input
`intent(inout), allocatable :: path`

interface for further convenience.

- Type pm_sysPath::setPathWindows
- High Priority: An optional argument external procedure
`iseq()`

should be added to the procedures of this generic interface to bring flexibility to searching for`ignore`

patterns.

- Type pm_sysShell::isFailedExec
- Low Priority: The current Fortran standard 202x does not allow passing characters of non-default kind to Fortran intrinsic procedures.

This generic interface should be extended to in the future to support non-default character kinds when they fully supported by the Fortran intrinsic procedures.

- Type pm_sysShell::isFailedGetDirTemp
- Low Priority: A subroutine version of this functional interface could be implemented in the future to avoid allocations and allow for non-default character kinds (once the Fortran compilers fully support non-default characters).
- Type pm_sysShell::isFailedGetOutput
- Low Priority: This generic interface should be extended to support character
`output`

of non-default kind once non-default characters is support by all relevant Fortran compilers. - Type pm_sysShell::isFailedGetShellHeight
- Low Priority: The current Fortran standard 202x does not allow passing characters of non-default kind to Fortran intrinsic procedures.

This generic interface should be extended to in the future to support non-default character kinds when they fully supported by the Fortran intrinsic procedures.

- Type pm_sysShell::isFailedGetShellShape
- Low Priority: The current Fortran standard 202x does not allow passing characters of non-default kind to Fortran intrinsic procedures.

This generic interface should be extended to in the future to support non-default character kinds when they fully supported by the Fortran intrinsic procedures.

- Type pm_sysShell::isFailedGetShellWidth
- Low Priority: The current Fortran standard 202x does not allow passing characters of non-default kind to Fortran intrinsic procedures.

This generic interface should be extended to in the future to support non-default character kinds when they fully supported by the Fortran intrinsic procedures.

- Type pm_sysShell::isFailedPutEnvVar
- Low Priority: A subroutine version of this functional interface could be implemented in future to avoid allocations and allow for non-default character kinds.

- Subprogram pm_timer::getTimeSYS (since)
- Normal Priority: The performance of this procedure could be improved by avoiding the unnecessary retrieval of the count rate and computing its inverse to get the period (which is fixed in the entire runtime).

This requires redefining this procedure as a type-bound procedure of a parent timer type.

However, preliminary benchmarks indicate that the division (instead of multiplication) slows down the computation by at most 25 percent. On modern architecture, the extra cost is likely on the of 25 CPU cycles, approximately 25 nanoseconds. This is likely negligible in most practical scenarios. Here is a benchmark script for the cost of division vs. multiplication, - Type pm_timer::timer_type
- Critical Priority: The
`start`

component of this derived type must become`protected`

as soon as Fortran 2023 is supported by the compilers.

- Type pm_val2complex::getComplex
- Low Priority: This generic interface can be extended to support conversion to
`complex`

of arbitrary kind via an optional input`mold`

argument whose type and kind dictates that of the output.

- Type pm_val2str::getStr
- Low Priority: This generic interface can be expanded to arrays of higher dimensions than two.
- Type pm_val2str::setStr
Low Priority: This generic interface can be expanded to arrays of higher dimensions than two.

Critical Priority: The default length of fields must be generically defined.

Currently, the maximum length of the fields is set to`127`

.

While this number is more than enough precisions of much higher orders available by compilers, it is bound to fail in the distant future.

Therefore, it must be generically set based on the`precision`

of the fields.

- Type pm_ziggurat::getZig
- Normal Priority: Examples should be added to the documentation of this generic interface in future.

- Module runParaDRAM
- Critical Priority: The current tests for
`long double`

interface fail with Intel LLVM Fortran Compiler`ifx`

and Intel LLVM C/C++ Compiler`icx`

compilers.

Apparently, there is a mismatch between`long double`

and`c_long_double`

storage.

This issue does not exist with GNU compilers, although the GNU definition of`long double`

appears to yield incorrect values in some calculations, e.g., in`isFailedGeomCyclicFit()`

of the ParaMonte library.

- Module test_pm_arrayRemap
- High Priority: The following tests should be extended to include allocatable arrays of arbitrary bounds.
- Module test_pm_arrayRemove
- High Priority: The following tests should be extended to include allocatable arrays of arbitrary bounds.
- Module test_pm_arrayReplace
- High Priority: The following tests should be extended to include allocatable arrays of arbitrary bounds.
- Module test_pm_bench
- Module test_pm_matrixChol
- Critical Priority: This test collection must be expanded to cover all interfaces.

- Subprogram test_pm_sys::test_CmdArg_type_1 ()
- This test needs further improvements in the future. See comments in the body of the test.
- Subprogram test_pm_sys::test_EnvVar_type_1 ()
- This test needs further improvements in the future. See comments in the body of the test.
- Subprogram test_pm_sys::test_EnvVar_type_2 ()
- This test needs further improvements in the future. See comments in the body of the test.
- Subprogram test_pm_sys::test_EnvVar_type_3 ()
- This test needs further improvements in the future. See comments in the body of the test.
- Subprogram test_pm_sys::test_getSysInfo_1 ()
- This test needs further improvements in the future. See comments in the body of the test.
- Subprogram test_pm_sys::test_isFailedExec_1 ()
- This test needs further improvements in the future. See comments in the body of the test.
- Subprogram test_pm_sys::test_isFailedExec_2 ()
- This test needs further improvements in the future. See comments in the body of the test.
- Subprogram test_pm_sys::test_OS_type_1 ()
- This test needs further improvements in the future. See comments in the body of the test.
- Subprogram test_pm_sys::test_OS_type_2 ()
- This test needs further improvements in the future. See comments in the body of the test.
- Subprogram test_pm_sys::test_OS_type_3 ()
- This test needs further improvements in the future. See comments in the body of the test.
- Subprogram test_pm_sys::test_SysCmd_type_1 ()
- This test needs further improvements in the future. See comments in the body of the test.