Could you check for the nan in the conditional?
(err < -err) & ~np.isnan(err)

isnan doesn't work for dtype=object https://stackoverflow.com/questions/36198118/np-isnan-on-arrays-of-dtype-object and casting to float will break timedelta.

There may be a better way to write it, but that is the reason for the current approach.

Maybe & err != err?

Ah, there will be runtime warnings that will fail the tests.

err = np.array([np.nan, -0.1], dtype=object)
np.any(err < -err)

gives

/tmp/ipykernel_32424/1840248036.py:1: RuntimeWarning: invalid value encountered in less
  np.any(err < -err)

independent of what is added (unless something like err != err is added before, but then it will not test properly).

(It took me quite some time to get a solution that worked... Not that it may be a good indication, but at least I failed with quite a few alternatives...)

But it is numpy? Although with dtype=object. Or am I missing something?

Yeah, but dtype object isn't guaranteed to do anything under mathematical operations (of particular relevance < is not guaranteed to work). Its basically just a list.

The PR solves #22910 without introducing any new issues (as far as I can tell, all existing tests pass anyway). Although it may be that lots of other related things also should be fixed.

Fair, maybe this is a tangent of sorts, but I think we need to fix the underlying problems rather than add more bandaids on top.

It would really help to get some examples of things that doesn't work though.

I'm 99% sure that if you passed a unit-full pint object in as err this would probably fail. Maybe it failed before as well?

I'm not blocking on this, but just pointing out that we still have substantial work to do on cleaning up the engineering here.

I agree that it is bandaid for sure.

Thanks! Wasn't aware of pint (although I've seen it mentioned). This is what happens on both main and this when using errorbar:

/local/data1/matplotlib/lib/matplotlib/axes/_axes.py:3329: UnitStrippedWarning: The unit of the quantity is stripped when downcasting to ndarray.
  y = np.asarray(y, dtype=object)
/local/data1/matplotlib/lib/matplotlib/axes/_axes.py:3374: UnitStrippedWarning: The unit of the quantity is stripped when downcasting to ndarray.
  return np.asarray(err, dtype=object)

and when using bar:

/local/data1/miniconda3/lib/python3.8/site-packages/numpy/lib/stride_tricks.py:536: UnitStrippedWarning: The unit of the quantity is stripped when downcasting to ndarray.
  args = [np.array(_m, copy=False, subok=subok) for _m in args]
Traceback (most recent call last):

  File "/local/data1/miniconda3/lib/python3.8/site-packages/pint/quantity.py", line 901, in __float__
    raise DimensionalityError(self._units, "dimensionless")

DimensionalityError: Cannot convert from 'meter' to 'dimensionless'


The above exception was the direct cause of the following exception:

Traceback (most recent call last):

  File "/tmp/ipykernel_13475/2206117657.py", line 1, in <cell line: 1>
    plt.bar([1, 2], base, yerr=err)

  File "/local/data1/matplotlib/lib/matplotlib/pyplot.py", line 2392, in bar
    return gca().bar(

  File "/local/data1/matplotlib/lib/matplotlib/__init__.py", line 1412, in inner
    return func(ax, *map(sanitize_sequence, args), **kwargs)

  File "/local/data1/matplotlib/lib/matplotlib/axes/_axes.py", line 2369, in bar
    x, height, width, y, linewidth, hatch = np.broadcast_arrays(

  File "<__array_function__ internals>", line 5, in broadcast_arrays

  File "/local/data1/miniconda3/lib/python3.8/site-packages/numpy/lib/stride_tricks.py", line 536, in broadcast_arrays
    args = [np.array(_m, copy=False, subok=subok) for _m in args]

  File "/local/data1/miniconda3/lib/python3.8/site-packages/numpy/lib/stride_tricks.py", line 536, in <listcomp>
    args = [np.array(_m, copy=False, subok=subok) for _m in args]

ValueError: setting an array element with a sequence.

(empty plot).

Fair, so the point is you are definitelynot making it worse here, but the problem still remains.

I guess that a quick bandaid for bar and units is to use this approach there as well:

No, that is what I'm fundamentally objecting to - just making an object array doesn't make any sense!

Since these are already combining/using masks above, would it make sense to add a masked_invalid() call earlier?

I do not really know how masks actually works (which is a bit ironically, considering my comment on your PR about masks I did just before seeing this...), although I realize that it may be related. Just noted that this didn't work correctly when trying out the other fixes.

I may give it a do though, either here or as a follow-up.

👍 There is a cbook.safe_masked_invalid if that would help at all. Masking the invalid locations just ignores those in the computations (well the details are more involved, but that is the easy way of thinking about it).

I've played around with it and cannot get it to work. The reason seems to be that the array has dtype=object (although it is float when created) and therefore I get runtime warnings on min and max.

Using masked_invalid gives a masked array with a fill_value of ?, while cbook.safe_masked_invalid just returns an identical array.

If the array was float it would probably work though, but I have no idea where it is becoming dtype=object. Maybe related to datetime support?

(Not really clear to me why nanmin and nanmax is worse than adding masked conversions.)

I don't think there is necessarily anything wrong with it if we are expecting nan's for some reason. To me, this just seemed like it was potentially hiding something else, which as you've noted here this only happens for dtype=object. If you are passing in a float array, I really don't think we should be making it an object array 😟 Perhaps this is because these error bars are generally used for categoricals so something is converting to objects fast because of that?

We do this because we don't want to drop units.