Skip to content
This repository has been archived by the owner on Nov 23, 2024. It is now read-only.

Multi-part EnumType extraction #46

Closed
duklin opened this issue Feb 7, 2022 · 0 comments · Fixed by #78
Closed

Multi-part EnumType extraction #46

duklin opened this issue Feb 7, 2022 · 0 comments · Fixed by #78
Assignees
Labels
enhancement 💡 New feature or request @enum Related to the @enum annotation

Comments

@duklin
Copy link
Contributor

duklin commented Feb 7, 2022

Is your feature request related to a problem? Please describe

So far, only the simple enums have been covered such as:

algorithm : {'arpack', 'randomized'}, default='randomized'
gamma : {'scale', 'auto'} or float, default='scale'

There are multi-part enums whose values are inside the docstring description such as:

loss : str, default='hinge'
The possible options are 'hinge', 'log', 'modified_huber', 'squared_hinge', 'perceptron', or a regression loss: 'squared_error', 'huber', 'epsilon_insensitive', or 'squared_epsilon_insensitive'

learning_rate : str, default='optimal'
- 'constant': `eta = eta0`
- 'optimal': `eta = 1.0 / (alpha * (t + t0))` where t0 is chosen by a heuristic proposed by Leon Bottou
- 'invscaling': `eta = eta0 / pow(t, power_t)`
- 'adaptive': eta = eta0, as long as the training keeps decreasing

strategy : str, default='mean'
If "mean", then replace missing values using the mean along each column
If "median", then replace missing values using the median along each column
If "most_frequent", then replace missing using the most frequent value along each column
If "constant", then replace missing values with fill_value

Desired solution

Expand the current logic for EnumType extraction to include the multi-part enums.

Possible alternatives (optional)

Screenshots (optional)

Additional context (optional)

@duklin duklin added the enhancement 💡 New feature or request label Feb 7, 2022
@lars-reimann lars-reimann transferred this issue from lars-reimann/sem21 Feb 10, 2022
@lars-reimann lars-reimann added the @enum Related to the @enum annotation label Jun 25, 2022
@lars-reimann lars-reimann transferred this issue from Safe-DS/API-Editor Mar 19, 2023
@nvollroth nvollroth linked a pull request Mar 31, 2023 that will close this issue
nvollroth added a commit that referenced this issue Apr 3, 2023
Closes #46.

### Summary of Changes

Currently, valid values for the enum annotations were determined only
via the type string. In order to achieve a higher recognition rate of
the enum annotations, the recognition of the valid values was extended
to the description.


### Testing Instructions

1. Run `pytest` for `test_extract_valid_literals.py`.
2. Check the results of `pytest`.

---------

Co-authored-by: Lars Reimann <[email protected]>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: megalinter-bot <[email protected]>
@github-project-automation github-project-automation bot moved this from Backlog to ✔️ Done in Library Analysis Apr 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement 💡 New feature or request @enum Related to the @enum annotation
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

3 participants