Adding np.nan to ultimates returns the same ultimates.

[genedan]

Are you on the latest chainladder version?

• Yes, this bug occurs on the latest version.

Describe the bug in words

Found during the investigation during of #692, I suspect due to the same root cause. When adding np.nan or a triangle that is marked as is_ultimate of np.nans to ultimate losses, the result is the original ultimate losses, rather than a column of NaNs .

How can the bug be reproduced?

This example is modified from the beginning of the file chainladder/workflow/tests/test_workflow.py:

import numpy as np
import chainladder as cl

raa = cl.load_sample("RAA")
cl_ult = cl.Chainladder().fit(raa).ultimate_  # Chainladder Ultimate
apriori = cl_ult * np.nan + cl_ult 
print(apriori)

cl_ult is:

              2261
1981  18834.000000
1982  16857.953917
1983  24083.370924
1984  28703.142163
1985  28926.736343
1986  19501.103184
1987  17749.302590
1988  24019.192510
1989  16044.984101
1990  18402.442529

cl_ult * np.nan is:

      2261
1981   NaN
1982   NaN
1983   NaN
1984   NaN
1985   NaN
1986   NaN
1987   NaN
1988   NaN
1989   NaN
1990   NaN

However, apriori, or cl_ult * np.nan + cl_ult is:

              2261
1981  18834.000000
1982  16857.953917
1983  24083.370924
1984  28703.142163
1985  28926.736343
1986  19501.103184
1987  17749.302590
1988  24019.192510
1989  16044.984101
1990  18402.442529

Because multiplication with np.nan results in a column of NaNs, but adding with np.nan returns the original column, we have an inconsistency in how arithmetic operations are treated when np.nan is involved.

What is the expected behavior?

We should get something like:

      2261
1981   NaN
1982   NaN
1983   NaN
1984   NaN
1985   NaN
1986   NaN
1987   NaN
1988   NaN
1989   NaN
1990   NaN

Which would be consistent with how numpy treats arithmetic operations between ndarrays and np.nan.

[genedan]

Looking further, this issue is subtly different from #692, as they involve different lines of code. They are still related since they both have to deal with the handling of NaNs.

If we generate an ultimate value Triangle object via multiplication with np.nan:

nan_ults = np.nan * cl_ult

We get an ultimate value Triangle full of NaNs, as expected:

      2261
1981   NaN
1982   NaN
1983   NaN
1984   NaN
1985   NaN
1986   NaN
1987   NaN
1988   NaN
1989   NaN
1990   NaN

However, looking under the hood, if we execute nan_ults.nan_triangle, we get:

array([[1.],
       [1.],
       [1.],
       [1.],
       [1.],
       [1.],
       [1.],
       [1.],
       [1.],
       [1.]], dtype=float16)

an ndarray full of 1s, when they should be all NaN. The difference between this example and #692 is that the problem with the latter example doesn't become apparent until we hit the _arithmetic_cleanup function, deep into the addition dunder, whereas with this example, the NaN problems are already apparent prior to the addition dunder.