I seem to recall trying this many years ago, and, IIRC, I found that the more modern/straightforward implementation of dlamch caused issues somewhere down the line, probably in the LAPACK test suite.

But before we can even consider its effects on LAPACK, we should get the patch working with our own test suite. :)

Yeah, that should teach me not to author commits in the browser. I'll get it to compile and pass checks locally. Re LAPACK tests, is there an easy way to check compliance (e.g. putting this in libflame and running the LAPACK testsuite)? I can certainly print out the old and new values on a few archs and see where the differences lie. In particular, I think the "safe minimum" values may be slightly less than [FLT|DBL]_MIN when denormals are used.

BLAS tests pass now.

Yeah, that should teach me not to author commits in the browser. I'll get it to compile and pass checks locally.

It happens. At least it was just a branch.

Re LAPACK tests, is there an easy way to check compliance (e.g. putting this in libflame and running the LAPACK testsuite)?

I think the easiest way is to download netlib LAPACK and plug it in. (There should be a place to specify the BLAS library for testing purposes.) libflame's LAPACK code hasn't been refreshed in some time, so I don't think that's the best vehicle for testing anymore.

I can certainly print out the old and new values on a few archs and see where the differences lie. In particular, I think the "safe minimum" values may be slightly less than [FLT|DBL]_MIN when denormals are used.

Thanks, that would be very interesting to see.

No matter what your initial tests show, though, I'm nervous enough about this in the short term that I think you should add your new implementation as a preprocessor branch (guarded by something like BLIS_ENABLE_STD_LAMCH) so that it can be switched at compile time. (No need to create a configure switch yet; we'll consider this an expert option for now, similar to BLIS_DISABLE_BLAS_DEFS.) This will allow us to gain confidence in the newer implementation while preserving the option of quickly falling back to the older code.

@fgvanzee for IEE754 floating point all values match the "legacy" _lamch. What systems that BLIS supports could possibly do anything funny?

Looking at the LAPACK version, I'm actually convinced that, with the sfmin tweak I added, the "new" and "old" versions will always agree.

@fgvanzee for IEE754 floating point all values match the "legacy" _lamch. What systems that BLIS supports could possibly do anything funny?

No idea. I have a distant memory of looking at this maybe 5-6 years ago, so perhaps it was all due to a bug that got fixed. (I mean, I don't want them to be different. So I'm glad you're seeing consistent numbers now.)

Nevertheless, I don't see any harm in keeping the old code disabled via a preprocessor guard.

Preprocessor guard added. Define BLIS_ENABLE_LEGACY_SLAMCH to use the old code.

Thanks, much better.

Out of curiosity, why does the new bli_dlamch() sometimes use the FLT_ constants?

		case 'E': return DBL_EPSILON;
		case 'S': return safe_min;
		case 'B': return FLT_RADIX;
		case 'P': return FLT_RADIX*DBL_EPSILON;
		case 'N': return DBL_MANT_DIG;
		case 'R': return FLT_ROUNDS == FE_TONEAREST ? 1.0 : 0.0;
		case 'M': return DBL_MIN_EXP;
		case 'U': return DBL_MIN;
		case 'L': return DBL_MAX_EXP;
		case 'O': return DBL_MAX;

Out of curiosity, why does the new bli_dlamch() sometimes use the FLT_ constants?

@devinamatthews In case you missed my question from earlier.

I could have sworn I responded... oh well. This is because things like the radix and rounding behavior don't depend on the precision, so there is only one constant instead of three (float, double, long double).

Okay, thanks.