Skip to content

Commit

Permalink
[docs] remove unavailable tree algorithm and fix tree depth behavior …
Browse files Browse the repository at this point in the history
…description in the tree guidelines
  • Loading branch information
Saulo Martiello Mastelini committed Jul 29, 2024
1 parent 192d1ca commit df257b8
Showing 1 changed file with 1 addition and 2 deletions.
3 changes: 1 addition & 2 deletions docs/recipes/on-hoeffding-trees.ipynb
Original file line number Diff line number Diff line change
Expand Up @@ -73,7 +73,6 @@
"| Hoeffding Tree Regressor | HTR | Regression | No | Basic HT for regression tasks. It is an adaptation of the [FIRT/FIMT](https://link.springer.com/article/10.1007/s10618-010-0201-y) algorithm that bears some semblance to HTC | [[4]](https://link.springer.com/article/10.1007/s10618-010-0201-y)\n",
"| Hoeffding Adaptive Tree Regressor | HATR | Regression | Yes | Modifies HTR by adding an instance of ADWIN to each node to detect and react to drift detection | -\n",
"| incremental Structured-Output Prediction Tree Regressor| iSOUPT | Multi-target regression | No | Multi-target version of HTR | [[5]](https://link.springer.com/article/10.1007/s10844-017-0462-7)\n",
"| Label Combination Hoeffding Tree Classifier | LCHTC | Multi-label classification | No | Creates a numerical code for each combination of the binary labels and uses HTC to learn from this encoded representation. At prediction time, decodes the modified representation to obtain the original label set | -\n",
"\n",
"\n",
"As we can see, although their application fields might overlap sometimes, the HT variations have specific situations in which they are better suited to work. Moreover, in River we provide a standardized API access to all the HT variants since they share many properties in common."
Expand Down Expand Up @@ -832,7 +831,7 @@
"\n",
"HTs monitor the incoming feature values to perform split attempts. To do so, they rely on a class of algorithms called *Attribute Observers* (AO) or *Splitters* (spoiler alert!). Each leaf node in an HT keeps one AO per incoming feature. After pre-determined intervals (`grace_period` parameter), leaves query their AOs for split candidates. Well, there are costs to monitor input features (mainly the numerical ones). In fact, AOs correspond to one of the most time and memory-consuming portions of the HTs. To manage memory usage, an HT firstly determines its least promising leaves, w.r.t. how likely they will be split. Then, these leaves' AOs are removed, and the tree nodes are said to be \"deactivated.\" That's it! The deactivated leaves do not perform split attempts anymore, but they continue to be updated to provide responses. They will be kept as leaves as long as there are not available resources to enable tree growth. These leaves can be activated again (meaning that new AOs will be created for them) if there is available memory, so don't worry!\n",
"\n",
"**Hint:** another indirect way to bound memory usage is to limit the tree depth. By default, the trees can grow indefinitely, but the `max_depth` parameter can control this behavior."
"**Hint:** another indirect way to bound memory usage is to limit the tree depth. By default, the trees can grow until they get close to the maximum recursion limit enabled in the system, but the `max_depth` parameter can control this behavior."
]
},
{
Expand Down

0 comments on commit df257b8

Please sign in to comment.