Thanks a few small comments. It seems like at least one run fails around querying the subnormal information from the macros. Not sure what to do about that, I suppose either hard-code or maybe use nextafter for them. (if we do that, it might be nice to see if we can find out whether subnormals work in that step, no idea what nextafter does. OTOH, the typical thing is FTZ mode, which I suspect still allows manual creation with nextafter... so it's really a user problem and we would need an ftz attribute on finfo rather than changing what smallest_subnormal gives.)

I tried modifying the template to use nextafter when macro is not defined, only hardocded the16 bit (it was going 0)

edit: wait, maybe I can do better, let me fix all the other error cases first

Any reason why for double-double format tiny was set to NAN instead of DBL_MIN?

float_dd_ma = MachArLike(ld,
                         machep=-105,
                         negep=-106,
                         minexp=-1022,
                         maxexp=1024,
                         it=105,
                         ...
                         eps=exp2(ld(-105)),  # This is 2^-105!
                         epsneg=exp2(ld(-106)),
                         huge=nextafter(ld(inf), ld(0)),
                         tiny=nan,  # Set to NaN for double-double!
                         smallest_subnormal=nextafter(0., 1.))

Any reason why for double-double format tiny was set to NAN

IIRC it was some weird/wrong value, then things were changed and nobody wanted to figure out the right value, so it was set to NaN because that seemed still better than being nonsense.
I think there is a difficulty that the tiny definition is a bit trickier, because the precision of double-double changes over the full range.
Anyway, have a brief look at gh-19511 and then set it to something reasonable if you find a value (I would love to use the one from the headers, but dunno if even those are unreliable...).

I would love to use the one from the headers, but dunno if even those are unreliable

I think tiny might be taken from headers (as the underflow checks are passed) but the huge value will need to be what is set in machar above nextafter(ld(inf), ld(0))

Let me confirm this and post here whatever suits the best

Only override the EPSILON-2^-105 to and MAX_FINITE=npy_nextafterl(NPY_INFINITY, 0.0L) seems to worked for native ppc64le

For this particular issue of testing array_repr

platforms where long double == double (float64) earlier it is only getting passed because of the difference in data type namings and default precision value of 8 for printing

Windows Old behaviour (before refactoring)

Resulting in 2 arrays as following

In [1]: import numpy as np

In [2]: np.__version__
Out[2]: '2.3.3'

In [3]: LD_INFO = np.finfo(np.longdouble)

In [4]: o = 1 + LD_INFO.eps

In [5]: a = np.array([o])

In [6]: b = np.array([1], dtype=np.longdouble)

In [7]: a, b
Out[7]: (array([1.]), array([1.], dtype=float64))

As you can see the only difference is in dtype leading to that test's assert to fail leading to passing the test

In this new behaviour

In [1]: import numpy as np

In [2]: np.__version__
Out[2]: '2.4.0.dev0+git20250930.d8508a2'

In [3]: LD_INFO = np.finfo(np.longdouble)

In [4]: o = 1 + LD_INFO.eps

In [5]: a = np.array([o])

In [6]: b = np.array([1], dtype=np.longdouble)

In [7]: a, b
Out[7]: (array([1.], dtype=float64), array([1.], dtype=float64))

So since both get dispatched from the same dtype, results in failing the test, I am not sure whether testing this was the intention behind this test. Anyways the hack to retain the original behaviour is as follows

inside getlimits.py

# On platforms where longdouble is the same size as double (e.g., Windows),
# use double descriptor to populate constants for backward compatibility.
# The old MachArLike code would match the float64 signature on such platforms
# and return float64 scalars.
if (self.dtype.type == ntypes.longdouble and
    self.dtype.itemsize == numeric.dtype(ntypes.double).itemsize):
     self.dtype = populate_dtype
     populate_dtype = numeric.dtype(ntypes.double)
else:
     populate_dtype = self.dtype
# Fills in all constants defined directly on the dtype (in C)
_populate_finfo_constants(self, populate_dtype)

This override to use float64 which is as per here the implied dtype and might not need to explicitly put in array representations

@seberg what you suggest? keeping the current way (which retain the past behaviour) or need to change the array print behaviour by increasing the precision to respectively used dtype and ignorning the name of dtype (Not sure how useful, maybe can do in a different PR)?

The Qemu/loongarch64 docker image is not even building so considering that out for now. This PR is ready for the review

@seberg I need an opinion here

From macros FLT_MANT_DIG=24 includes the implicit leading bit for precision (IEEE specifies 23 explicit fraction bits but effective 24-bit significand);
FLT_MIN_EXP=-125 reflects C's radix-agnostic definition where the exponent is offset by +1 compared to IEEE's unbiased min of -126 for normalized numbers; similarly, FLT_MAX_EXP=128 offsets IEEE's max unbiased exponent of +127, marking the overflow threshold.
With MAChar these values were hardcoded so somewhere the values are as per IEEE (nmant, minexp) and somewhere as per C macro (maxexp)

So do you prefer the complete original behaviour or we should take the whatever value comes from the header as finfo and adjust the derived values correct with proper documentations around this?

Also orignally machar used values make more sense atleast for nmant and sticking to that won't break any user's code, in case if they were doing some nmant or minexp dependent calculations and suddenly after refactor upgrade they are seeing float32 showing 24 instead of 23 mantissa bits

So do you prefer the complete original behaviour or we should take the whatever value comes from the header as finfo and adjust the derived values correct with proper documentations around this?

Ufff, that is annoying that these definitions are so subtly different! For the Python side, we clearly can't change the values.

For nmant, I could see calling it mant_dig instead and using the C definition on the C-side. However for min_exp/max_exp that sleigh of hands doesn't work that well, unless we name it _c_max_exp, but...
So think I lean towards using the identical finfo_... naming and documenting that these do not match the C definition unfortunately (at least for the new C docs).

(I would like to still tag the integer constants, but if you like I can push that also.)

@seberg if this look good enough then I can proceed with the documentation

Hmm... test failures aren't looking to be coming from finfo refactor

@SwayamInSync decided to just put it in. I feel this should be reasonable both from a general API perspective and from the changes to the finfo.

(Although, I will expect that there may be some follow-ups with finfo, it's always trickier than you expect.)

I think it's just as well to include release notes that you think are helpful in a seperate PR to add docs (and at that point -- or earlier -- others will also get another chance to review the API choices here).

Thanks @seberg , will do the doc PR asap