'<' not supported between instances of 'complex' and 'int'

[carterg33]

Hey all, thank you so much for upkeeping an incredible package!

I just wondered if anything is known about the following error: '<' not supported between instances of 'complex' and 'int'

This seems to occur mostly irrespective of the model I am using - whether its an ensemble of Logistic Regression or A single Extremely Fast Decision Tree Classifier, the traceback changes a little but the overarching problem seems the same. I have included an example below.

Happy to share more information but a lot of my steps are quite specific to my dataset so wondering if this is a known issue or just a problem with my methodology before I do so!

Below is an example:

TypeError                                 Traceback (most recent call last)
~\AppData\Local\Temp/ipykernel_19644/2731090305.py in <module>
      1 from river import evaluate
----> 2 evaluate.progressive_val_score(
      3     model=pipe,
      4     dataset= stream.iter_pandas(X_additional, y_additional) ,
      5     metric=metric,

c:\users\carter\miniconda3\lib\site-packages\river\evaluate\progressive_validation.py in progressive_val_score(dataset, model, metric, moment, delay, print_every, show_time, show_memory, **print_kwargs)
    230     )
    231 
--> 232     for checkpoint in checkpoints:
    233 
    234         msg = f"[{checkpoint['Step']:,d}] {metric}"

c:\users\carter\miniconda3\lib\site-packages\river\evaluate\progressive_validation.py in _progressive_validation(dataset, model, metric, checkpoints, moment, delay, measure_time, measure_memory)
     42         # Question
     43         if y is None:
---> 44             preds[i] = pred_func(x=x)
     45             continue
     46 

c:\users\carter\miniconda3\lib\site-packages\river\compose\pipeline.py in predict_one(self, x, learn_unsupervised)
    400     @property
    401     def _supervised(self):
--> 402         return any(step._supervised for step in self.steps.values())
    403 
    404     @property

c:\users\carter\miniconda3\lib\site-packages\river\imblearn\random.py in predict_one(self, x)
     20 
     21     def predict_one(self, x):
---> 22         return self.classifier.predict_one(x)
     23 
     24 

c:\users\carter\miniconda3\lib\site-packages\river\base\classifier.py in predict_one(self, x)
     67         # The following code acts as a default for each classifier, and may be overridden on an
     68         # individual basis.
---> 69         y_pred = self.predict_proba_one(x)
     70         if y_pred:
     71             return max(y_pred, key=y_pred.get)

c:\users\carter\miniconda3\lib\site-packages\river\multiclass\ovr.py in predict_proba_one(self, x)
     97 
     98         for label, model in self.classifiers.items():
---> 99             yp = model.predict_proba_one(x)[True]
    100             y_pred[label] = yp
    101             total += yp

c:\users\carter\miniconda3\lib\site-packages\river\ensemble\bagging.py in predict_proba_one(self, x)
    106 
    107     For each incoming observation, each model's `learn_one` method is called `k` times where
--> 108     `k` is sampled from a Poisson distribution of parameter 1. `k` thus has a 36% chance of
    109     being equal to 0, a 36% chance of being equal to 1, an 18% chance of being equal to 2, a 6%
    110     chance of being equal to 3, a 1% chance of being equal to 4, etc. You can do

c:\users\carter\miniconda3\lib\site-packages\river\linear_model\glm.py in predict_proba_one(self, x)

c:\users\carter\miniconda3\lib\site-packages\river\optim\losses.py in mean_func(self, y_pred)
    105     def mean_func(self, y_pred):
    106         if isinstance(y_pred, np.ndarray):
--> 107             return 1.0 / (1.0 + np.exp(-y_pred))
    108         return utils.math.sigmoid(y_pred)
    109 

c:\users\carter\miniconda3\lib\site-packages\river\utils\math.py in sigmoid(x)
    292 
    293     """
--> 294     if x < -30:
    295         return 0
    296     if x > 30:

[MaxHalford]

Hey @carterg33, thanks for the kind words and for reporting this issue. If I remember correctly, I saw this happen once because the square root of a very small number was producing a complex number. It's most likely a numerical instability issue.

The traceback is useful, but not sufficient for us to debug properly. Could you provide the code you used to produce this traceback?

[carterg33]

Hey Max - thank you for looking into this so quickly!

Here is a repo I am working in with the data included: https://github.com/carterg33/domain-detection/blob/main/program/online_pipeline.ipynb

Let me know if there is something that will make this easier to debug for you as I am new to this! If you have any initial ideas of how this could be avoided please do let me know as willing to give anything a go.