Restructure the files under algorithms.gradients.

[a-matsuo]

What should we add?

Currently the files under under algorithms.gradients are messy. It's better to restructure the files. Grouping files by gradient type seems like a good idea. The files related to qgt and qfi are a bit tricky though.

gradients/
├──base/
│   ├── base_estimator_gradient.py
│   └── base_sampler_gradient.py
├── finite_diff/
│   ├── finite_diff_estimator_gradient.py
│   └── finite_diff_sampler_gradient.py
├── lin_comb/
│   ├── lin_comb_estimator_gradient.py
│   └── lin_comb_sampler_gradient.py
├── param_shift/
│   ├── param_shift_estimator_gradient.py
│   └── param_shift_sampler_gradient.py
├── qgt/
│   ├── base_qgt.py
│   ├── lin_comb_qgt.py
│   └── reverse_qgt.py
├── qfi/
│   └── qfi.py
└── reverse/
    └── reverse_gradient.py

[woodsp-ibm]

Is this just a code restructuring that will be transparent to end users? I.e. all the function will be imported into the gradient init file and an end user will still import from algorithms.gradients.

In the gradients in the docstring the organization/presentation to the user is not the same as the above structure (has Estimator grads, Sampler grads and QGT) - would you change that too, to reflect this organization or not. It would not affect the code in any way just how they are grouped in the docs.

[a-matsuo]

Is this just a code restructuring that will be transparent to end users? I.e. all the function will be imported into the gradient init file and an end user will still import from algorithms.gradients.

Yes! exactly.

In the gradients in the docstring the organization/presentation to the user is not the same as the above structure (has Estimator grads, Sampler grads and QGT) - would you change that too, to reflect this organization or not. It would not affect the code in any way just how they are grouped in the docs.

I hadn't thought of that. I think it's better to group by gradient type in the docs, too, if the file structures are so.