I once needed to know about whether a number is subnormal() so I would be happy to have it but... I think it's niche and numpy already proposes finfo for that so... I think users can live with this (big!) dependency if they already work with normal and subnormal numbers.

For isnormal(), if it's part of C99, I'd say why not because we're a "thin wrapper" but for issubnormal(), it'd be only available on platforms that compiled Python with C23 (unless you want to rewrite issubnormal()?)

I think users can live with this (big!) dependency if they already work with normal and subnormal numbers.

This is something more basic and is a part of libm.

For isnormal(), if it's part of C99, I'd say why not

Yes, it's essentially a free lunch.

but for issubnormal(), it'd be only available on platforms that compiled Python with C23

I think we can check compiler conformance and if C23 support is missing - provide a simple replacement in terms of isfinite() & isnormal().

PR is ready to review: #132935

I suggest leaving these out until there is a demonstrated user need.

Unless people actually need this (I never have), it becomes module clutter than gets in the way of finding "the good stuff". We shouldn't add cognitive loads (one more thing to learn and remember) unless we expect a payoff.

I suggest leaving these out until there is a demonstrated user need.

If bugreport is a demonstration of "used needs" - here it is.

SO example: https://stackoverflow.com/questions/59277521

it becomes module clutter than gets in the way of finding "the good stuff".

On the other hand, people can expect this from the libm wrapper. This time, rather than reinventing the wheel - I filled this bugreport.

I'm going to close this, on ground of Raymond's feedback.

@tim-one ?

Contrary to closing it, I'd like to see it expanded to include fpclassify() too :smile. The math module always intended to be a superset of the standard C libm functions, and C has grown, and math has generally kept up with it (albeit with a lag).

Alas, it looks like although "even Microsoft" supports isnormal() and fpclassify() now, 'issubnormal()` appears to be missing.

I don't find Raymond's objection persuasive in this case. It's not like we're making them up - they're very widely implemented already (comes with being part of standard C), the names are bizarre enough that if's dead easy to find detailed docs with a web search, and they're not at all hard to understand. Indeed, the names are darned near self-explanatory

Ironically, I would have used these things yesterday, while writing a saner ldexp() for Windows. Instead I mucked around with frexp() to pick out the exponent to compare it with magical constants.

Which I appreciate is more in the area of writing math libraries than end-user apps. I don't think they'll be widely used. But there's another kind of cognitive burden in trying to remember which near-universally supported math functions Python thinks are beneath its attention 😉.

I'd like to see it expanded to include fpclassify()

I was thinking about, but I don't see good arguments beyond "libm has it". After all, we don't have every math.h's functions exposed in the module (e.g. scalbn or logb).

"even Microsoft" supports isnormal() and fpclassify() now, 'issubnormal()` appears to be missing.

issubnormal() is a part of C23, which MSVC doesn't support yet.

I'd like to see it expanded to include fpclassify()

I was thinking about, but I don't see good arguments beyond "libm has it".

That "even Microsoft" has it means even they thought it was worth it 😉. Indeed, with fpclassify() there's no real need for isnormal() or issubnormal(). Note that the only argument you gave for isnormal() and issubnorm() was:

people can reasonably expect these classifiers as "The [math] https://docs.python.org/3.14/library/math.html#module-math) module consists mostly of thin wrappers around the platform C math library functions."

Why is that compelling to you for some minor libm functions, but poo-poo';ed for others?

After all, we don't have every math.h's functions exposed in the module (e.g. scalbn or logb)

And probably won't unless someone asks for them. Non-binary machines stil aren't really "a thing", so I don't expect anyone will.

Suit yourself, but I see no consistency in adding some minor libm functions but not others. "Why not fpclassify too, then?" was my first thought when seeing this report's title. They all make immediate sense for the fp format virtually everyone in the world uses. scalbn does too, of course, but its function is identical to the existing ldexp on virtually all platforms - it's gratuitous duplication for almost everyone.

Indeed, with fpclassify() there's no real need for isnormal() or issubnormal()

And vice versa. These interfaces looks non-orthogonal. Maybe it does make sense for C to speedup something somewhere... Though, my search over Github shows two major cases: 1) serialization of floats, 2) misuse of the fpcassify() API, where it could be replaced by one of isfoo(). And very rare cases of 2), when it's impossible.

On another hand, maybe we should prefer fpclassify() API to isnormal() & issubnormal() pair? 1) it's in libm since C99, 2) it fits all needs, which require isnormal()/issubnormal(), 3) it is one function, not two, 4) with a distinct and more generic API. This will require exposing FP_NORMAL, etc constants as some Enum type, I think. (BTW, I would rather buy access to FE_TONEAREST and friends from stdlib.)

scalbn does too, of course, but its function is identical to the existing ldexp on virtually all platforms

This example was somewhat random. But there is a signbit(), for example. It's easy to grep out it's replacements with copysign() in Lib/test/.

Aren't we missing cmath.isnormal() and cmath.issubnormal()?

• isnormal(z): Check if ALL components of z are normal
• issubnormal(z): Check if ANY component of z is subnormal

The C99+ Annex G doesn't define anything like that.

Though, it also doesn't include isfinite (or isinf/isnan). But it says:

A complex or imaginary value with at least one infinite part is regarded as an infinity (even if its
other part is a NaN). A complex or imaginary value is a finite number if each of its parts is a finite
number (neither infinite nor NaN).

That's exactly - Python's isfinite/isinf. The isnan() in Python looks as an extension. But I doubt that isnormal() for complex numbers can be defined like that.

Great, different programming languages disagree on this:

• .NET:

public static bool IsNormal(Complex value)
{
    // much as IsFinite requires both part to be finite, we require both
    // part to be "normal" (finite, non-zero, and non-subnormal) to be true
    return double.IsNormal(value.m_real) && ((value.m_imaginary == 0.0) || double.IsNormal(value.m_imaginary));
}

public static bool IsSubnormal(Complex value)
{
    // much as IsInfinite allows either part to be infinite, we allow either
    // part to be "subnormal" (finite, non-zero, and non-normal) to be true
    return double.IsSubnormal(value.m_real) || double.IsSubnormal(value.m_imaginary);
}

• Swift:

  /// True if this value is normal.
  ///
  /// A complex number is normal if it is finite and *either* the real or
  /// imaginary component is normal. A floating-point number representing
  /// one of the components is normal if its exponent allows a full-precision
  /// representation.
  ///
  /// See also `.isFinite`, `.isSubnormal` and `.isZero`.
  @_transparent
  public var isNormal: Bool {
    isFinite && (x.isNormal || y.isNormal)
  }
  
  /// True if this value is subnormal.
  ///
  /// A complex number is subnormal if it is finite, not normal, and not zero.
  /// When the result of a computation is subnormal, underflow has occurred and
  /// the result generally does not have full precision.
  ///
  /// See also `.isFinite`, `.isNormal` and `.isZero`.
  @_transparent
  public var isSubnormal: Bool {
    isFinite && !isNormal && !isZero
  }

No doubts, you can define such notions. But note, that your definitions are different.

The C99 standard rationale shows arguments for isinf/isnan, e.g.:

Which arguments for using either definition of isnormal() for complex numbers? Is this useful? Why? M$ version is especially odd as asymmetrical wrt components.

isnormal(z) = isnormal(z.real) and isnormal(z.imag):

• performance:

$ python -m timeit -s "a = 2+0j; b = 5e-308+5e-308j" "a * b"
5000000 loops, best of 5: 49.1 nsec per loop
$ python -m timeit -s "a = 2+0j; b = 5e-308+5e-324j" "a * b"
5000000 loops, best of 5: 88.3 nsec per loop
$ python -m timeit -s "a = 2+0j; b = 5e-324+5e-324j" "a * b"
2000000 loops, best of 5: 124 nsec per loop

• accuracy:

>>> (5e-308+5e-308j) * 1e308
(5+5j)
>>> (5e-308+5e-324j) * 1e308
(5+4.9406564584124655e-16j)
>>> (5e-324+5e-324j) * 1e308
(4.9406564584124655e-16+4.9406564584124655e-16j)

• Neither component is denormalized

Do you see an argument for the other definition? Or should we give that a different name?
isnormal(z) = isfinite(z) and (isnormal(z.real) or isnormal(z.imag))

Sorry, could be elaborate your "performance" and "accuracy" arguments?

I'm mostly trying to compare it with the reasons for having std::isnormal(x).

• Most CPU's handle subnormal numbers much more slowly than normals. A simple multipliction by 2, can be up to 2.53x slower (compared to 1.15x slower for infinities). I expect a similar story for other operations.
• When you get a subnormal number after multiplication, you lose precision in later operations.

So, raising an error in these cases using isnormal() could make sense.

Yes, but I don't see yet arguments for a concrete isnormal() definition for complex.

Maybe we should discuss this on Discourse?

Feel free to do so .
I'm not sure if it worth, I am -0 on this.