jax-ml/jax · error · TypeError

z.dtype={} is not supported, see docstring for supported typ

Error message

z.dtype={} is not supported, see docstring for supported types.

What it means

jax.scipy.special.lpmn only accepts z arrays of dtype float32 or float64. Integer, complex, or half-precision z raises TypeError immediately, before the 1D and m/n checks.

Source

Thrown at jax/_src/scipy/special.py:2208

    n: The maximum degree of the associated Legendre function, often called
      `l` in describing ALFs. Both the degrees and orders are
      `[0, 1, 2, ..., l_max]`, where `l_max` denotes the maximum degree.
    z: A vector of type `float32` or `float64` containing the sampling
      points at which the ALFs are computed.

  Returns:
    A 2-tuple of 3D arrays of shape `(l_max + 1, l_max + 1, len(z))` containing
    the values and derivatives of the associated Legendre functions of the
    first kind. The return type matches the type of `z`.

  Raises:
    TypeError if elements of array `z` are not in (float32, float64).
    ValueError if array `z` is not 1D.
    NotImplementedError if `m!=n`.
  """
  dtype = lax.dtype(z)
  if dtype not in (np.float32, np.float64):
    raise TypeError(
        'z.dtype={} is not supported, see docstring for supported types.'
        .format(dtype))

  if z.ndim != 1:
    raise ValueError('z must be a 1D array.')

  m = core.concrete_or_error(int, m, 'Argument m of lpmn.')
  n = core.concrete_or_error(int, n, 'Argument n of lpmn.')

  if m != n:
    raise NotImplementedError('Computations for m!=n are not yet supported.')

  l_max = n
  is_normalized = False
  p_vals = _gen_associated_legendre(l_max, z, is_normalized)
  p_derivatives = _gen_derivatives(p_vals, z, is_normalized)

  return (p_vals, p_derivatives)

View on GitHub (pinned to 1e1c6a8fc0)

Solutions

  1. Cast z: lpmn(m, n, z.astype(jnp.float32))
  2. Generate evaluation points with float dtypes from the start (jnp.linspace, jnp.arange(..., dtype=jnp.float32))
  3. For complex z, note lpmn is real-only — restructure the computation or use scipy outside JAX

Example fix

// before
jax.scipy.special.lpmn(3, 3, jnp.array([0, 1, 2]))  # int32
// after
jax.scipy.special.lpmn(3, 3, jnp.array([0, 1, 2], dtype=jnp.float32))
Defensive patterns

Strategy: validation

Validate before calling

z = jnp.asarray(z, jnp.float32) if jnp.dtype(z) not in (np.float32, np.float64) else z
lpmn(m, n, z)

Type guard

def float32_64(z):
    return jnp.dtype(z) in (np.float32, np.float64)

Prevention

When it happens

Trigger: Calling lpmn(m, n, jnp.linspace(...)) is fine, but lpmn(m, n, jnp.array([0, 1])) (int), bfloat16 z, or complex z raises; also reached via scipy_fun wrappers in tests.

Common situations: Passing integer grids (e.g., indices) as evaluation points; bf16 TPU tensors; complex cosine arguments from orbital-mechanics code; forgetting that lpmn does not auto-cast unlike SciPy's more permissive handling.

Related errors


AI-assisted analysis of jax-ml/jax@1e1c6a8fc0 (2026-08-27). Data as JSON: /api/errors/4a629ee84d0abccb. Report an issue: GitHub.