loadtxt CI failure: Dimension mismatch in example.dat during example tests

[JAi-SATHVIK]

Description

The loadtxt module tests are currently failing in CI (specifically Test #187 and #188) due to an input conversion error. The issue arises because there is a mismatch between the data provided in example/io/example.dat and the number of values the loadtxt routine is attempting to read.

The Error Log-

loadtxt: error <Bad value during floating point read> reading 6 values from line 1 of example.dat.

The Data File (example/io/example.dat):

 1.00000000E+00  4.00000000E+00
 2.00000000E+00  5.00000000E+00
 3.00000000E+00  6.00000000E+00

Expected Behaviour

The loadtxt routine should correctly detect the number of columns in example/io/example.dat (which is 2) and load the data into the allocatable array x without triggering a runtime error. The example test example_loadtxt provided in the repository should pass successfully during CI/CD workflows. Currently, it fails because it attempts to read 6 values from a 2-column line.

Version of stdlib

Latest main branch

Platform and Architecture

OS: Linux (Ubuntu 22.04 / GitHub Actions Runner) Architecture: x86_64 Compiler: gfortran (GCC)

Additional Information

I think we can either:

• Update example/io/example.dat to include the expected 6 columns of data.
• Update the example test program to expect a 2-column format.

[jalvesz]

Hi @JAi-SATHVIK. by any chance have you checked if your branches are well updated with respect to the recently added PR #1177 ?

[jalvesz]

Hi @JAi-SATHVIK afyer you merged the master branch the issues with loadtxt were gone but we come back to test_linalg_pseudoinverse failing in a random but frequently manner. I also saw a failures in one of the special matrices tests. Re-runing the jobs makes it pass but this is not robust.

@loiseaujc you mentioned to have an idea on how to fix the random failures in test_linalg_pseudoinverse ? My view is that the current tests using all to check accuracy for each individual value of randomly generated matrices and the inverse is not a robust test as it is extremely prone to machine tolerance errors. I would see solutions either on controlling the generation of the matrices themselves to be well conditioned or to change the error evaluation condition to be robust to individual values. Another idea is to fix the seed for the random number generator to make it reproducible.

[JAi-SATHVIK]

Hi @JAi-SATHVIK. by any chance have you checked if your branches are well updated with respect to the recently added PR #1177 ?

yes, after merging the master branch the issues were gone.