Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

documentation building, readthedocs config #203

Merged
merged 30 commits into from
May 15, 2024
Merged

Conversation

newville
Copy link
Member

this is a work-in-progress to start on getting docs to build and push to readthedocs.

so far, it has not touched the doc contents, but some of that will need changing as well.

Copy link

codecov bot commented Mar 15, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.74%. Comparing base (ea1d664) to head (b1ae532).
Report is 1 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #203      +/-   ##
==========================================
+ Coverage   95.59%   95.74%   +0.15%     
==========================================
  Files          12       12              
  Lines        1905     1905              
==========================================
+ Hits         1821     1824       +3     
+ Misses         84       81       -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@newville
Copy link
Member Author

This PR to update the docs is now at the state of being incomplete but reviewable.

By way of documentation for what has changed in this PR:

  1. This adds config files for codecov and readthedocs. These might need more tweaking or have been updated already in earlier PRs.
  2. some sphinx changes were needed to the layout.
  3. I made "index" a lot shorter. It is now mostly an intro and Table of Contents. I added a custom "sidebar" giving the version, quick install instructions, and a link to GitHub.
  4. moved most of what was in index.rst to install.rst, but heavily edited this to more modern install instructions, and updated Credits to describe the recent transition to the lmfit github org.
  5. made some edits to "user_guide", but more could be done. No substantial changes to "numpy" or "tech guide".
  6. I updated the docstrings for ufloat and ufloat_fromstr, so that "autodoc" can be (and is) used with sphinx.
  7. for linking to PDF and static zipped HTML, the current approach is fragile, so I sort of set these up differently:

I am fine with using readthedocs. But, I am also willing to use GitHub pages. I use this for almost all my other projects, and it has the distinct advantage of allowing us to put any files we want in the gh-pages branch, including static PDFs.

By way of proof-of-concept and viewing the development here, I added a gh-pages branch to the main lmfit/uncertainties and pushed the rendered results of the current state of this PR there. This is viewable at https://lmfit.github.io/uncertainties/

We could use both, and/or make the links to the PDF and zipped HTML point to the fully-qualified URLs https://lmfit.github.io/uncertainties/uncertainties.pdf and https://lmfit.github.io/uncertainties/uncertainties_doc.zip.

I think there is always more to do. And I would say that all the changes here could be undone or modified: suggestions most welcome.


.. The "import uncertainties" is put here because some examples requires
uncertainties to have been imported (and not only ufloat).
>>> import uncertainties as un
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this conflict with any other packages?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it does not but have no idea how to tell!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dunno. One could probably ask that about any abbreviation.

@andrewgsavage
Copy link
Contributor

the table of contents has switched position with 'get uncertainties' on index.html

@andrewgsavage
Copy link
Contributor

I'd remove the autofuncton then this looks good to merge

@newville
Copy link
Member Author

@andrewgsavage

the table of contents has switched position with 'get uncertainties' on index.html

Yes. The intention is that the information on how to get uncertainties is prominent on the index page.
Is this a problem?

I'd remove the autofuncton then this looks good to merge

Do you mean you want to not have the docstrings for ufloat and ufloat_fromstr? One of the (okay, many) things I find odd about the current doc is that these are not provided. And the docstrings are kind of a mess.

I think these autofunctions could be moved, but I think they should be given somewhere.

@andrewgsavage
Copy link
Contributor

andrewgsavage commented Apr 23, 2024 via email


Each number created this way is an **independent (random) variable**
(for details, see the :ref:`Technical Guide <math_def_num_uncert>`).
.. autofunction:: ufloat
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The section created from the docstring is quite long, making this page more difficult to read for a new user.

I'd prefer if it linked to the function in an API reference section

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That seems OK. The current docs don't describe Variable, UFloat, or AffineScalarFunc. They sort of talk about "value with an uncertainty". I think that an API section really should mention this. Opinions?


.. The "import uncertainties" is put here because some examples requires
uncertainties to have been imported (and not only ufloat).
>>> import uncertainties as un
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it does not but have no idea how to tell!

used. Running the test suite requires `pytest` and `pytest_cov`, and building
these docs requires `sphinx`. To install these optional packages, use one of:

.. code-block:: sh
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is very helpful, thanks for adding

>>> print('Result = {:10.2f}'.format(x))
Result = 0.20+/- 0.01

(Python 2.6 requires ``'{0:10.2f}'`` instead, with the usual explicit
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

python2 reference can be deleted

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hah! thanks - I missed that one.


>>> print('Automatic number of digits on the uncertainty: {}'.format(x))
Automatic number of digits on the uncertainty: 0.200+/-0.010
>>> print(x0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

close bracket

might be worth setting these up as doc tests in the future

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1


.. The "import uncertainties" is put here because some examples requires
uncertainties to have been imported (and not only ufloat).
>>> import uncertainties
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

single space before >>>

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On second read, I think this (lines 19-23) can be removed. Especially if this is to become 'getting started'

It doesn't add anything; new users need to read through this page and will get to adv math functions. Numpy users can find that easily.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, I agree...

Basic math with uncertain Variables
=========================================

:class:`Variable`s can be used in basic mathematical calculations
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:class:[](https://lmfit.github.io/uncertainties/user_guide.html#id6)Variables

hasn't rendered correctly

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will investigate (when moved to an api.rst, probably)

the functions from the standard** :mod:`math` **module**. These
mathematical functions are found in the :mod:`uncertainties.umath`
module:
Besides being able to apply basic mathematical operations to uncertaintties
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

uncertaintties > uncertainties

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1


>>> print(x*y)
240.0+/-76.83749084919418
>>> (x*y).std_dev == (x*y).nominal_value * sqrt((x.std_dev/x.nominal_value)**2 + (y.std_dev/y.nominal_value)**2 )
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd introduce the .n and .s abbreviations early on (maybe at line 50?) and use them here to make this shorter.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I was thinking maybe avoid .n and .s as they might be something to deprecate. I'm OK with fully embracing them as part of the API.

Objects are meant to represent variables that are independent from
each other (correlations are handled through the AffineScalarFunc
class).
Variablees are independent from each other, but correlations between them
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Variablees >Variables

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

@andrewgsavage
Copy link
Contributor

Looks good, how much more are you planning to do on this before merging? this + changelog are the last things to do before a new release.

@newville
Copy link
Member Author

newville commented May 1, 2024

Yeah, how much more to do is a great question ;).

I might ask opinions all around (@wshanks, @jagerber48) on how complete this needs to be, and if the version at https://lmfit.github.io/uncertainties is approaching "acceptable".

@andrewgsavage
Copy link
Contributor

I think the main thing is to remove anything python2 related + typos/formatting misses. Anything more is nice to have and can be done in a later PR.

It looks like you're roughly halfway through editing each of the files, with numpy and tech guide to go? Might as well continue through those.

I'd leave converting user guide -> getting started out of this PR to make it easier to review what's moved where and ensure nothings getting removed. There's enough moving in this PR already to keep track of!

@newville
Copy link
Member Author

OK, sorry for the delay on this. I believe I have addressed most of the issues and this might be good enough, at least for a while. Suggestions? Again, rendered results are at https://lmfit.github.io/uncertainties

doc/install.rst Outdated
The :mod:`uncertainties` package was written and developed by `Eric O. LEBIGOT
(EOL)`_. EOL also maintained the package until 2024, when the GitHub project
was moved to the `lmfit GitHub organization`_ to allow more sustainable
development and maintenance. Currentt members of the devlopment and
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Current


>>> import uncertainties
To create a number with uncertainties or *Variable*, use the :func:`ufloat`
function, which takes a *nominal value* ( (which can be interpreted as the most
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Double open bracket

To create a number with uncertainties or *Variable*, use the :func:`ufloat`
function, which takes a *nominal value* ( (which can be interpreted as the most
likely value, or the mean or central value of the distribution of values), a
*standard error* ( (the standard deviation or :math:`1-\sigma` uncertainty), and
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Double open bracket

complicated. That is, a Variable with a value of 25 +/- 10 might be greater
than a Variable with a value of 24 +/- 8 most of the time, but *sometimes* it
might be less than it. The :mod:`uncertainties` package takes the simple
approach of comparing. That is
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Of comparing nominal values.

@andrewgsavage
Copy link
Contributor

There's some python 2 print statements in the tech guide

@andrewgsavage
Copy link
Contributor

Also some python 2 print statements on the bumpy guide

@andrewgsavage
Copy link
Contributor

Also some python 2 print statements on the numpy guide

@andrewgsavage
Copy link
Contributor

Numpy*
There's also a ref to python2 on the numpy page.

For Python 2:

converters = dict.fromkeys(range(num_cols), uncertainties.ufloat_fromstr)

Other than that this looks and reads well. Id fix those then merge.

@newville
Copy link
Member Author

@andrewgsavage Thanks!! OK, I think I have addressed hose spelling/print errors.

I am still investigating the "loadtxt" thing: "The code does what???"

@newville
Copy link
Member Author

@andrewgsavage OK, I think the loadtxt/savetxt doc is correct now.


.. Formatting method:

More **control over the format** can be obtained (in Python 2.6+)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Python2 reference

@andrewgsavage andrewgsavage merged commit 3255816 into lmfit:master May 15, 2024
18 checks passed
@newville
Copy link
Member Author

@andrewgsavage Thanks! Should we re-kindle the conversation about tagging and releasing 3.2.0?

@andrewgsavage
Copy link
Contributor

Looks good, merged since there's been no indication anyone else will read through since you asked 2 weeks ago.

@andrewgsavage
Copy link
Contributor

@andrewgsavage Thanks! Should we re-kindle the conversation about tagging and releasing 3.2.0?

yea please

jagerber48 added a commit that referenced this pull request Nov 15, 2024
- [x] Closes #270 
- [x] Executed `pre-commit run --all-files` with no errors
- [x] The change is fully covered by automated unit tests
- [x] Documented in docs/ as appropriate
- [x] Added an entry to the CHANGES file

This PR hopes to resolve a few issues with `uncertainty` package
interaction with `codecov.io`.

- #203 introduced `.codecov.yaml`. Unfortunately, I think this was an
invalid configuration. Specifically because the `comment` section is
supposed to be a top-level section, not nested under the `codecov`
section. This means that since that PR the yaml configuration has NOT
been used for our codecov updates. I think this explains why we're
seeing codecov failures despite best attempts to suppress them.
- See for example #268 where a codecov failure is creating an X when we
really just want the PR to go through. This PR will (attempt to) make it
so that codecov coverage is reported, but will never result in a failed
coverage run. This way reviewers can see if patch coverage is < 100% or
if overall coverage drops due to a PR. If reviewers deem a lack or drop
of coverage to be significant they can block PR approval. Otherwise, for
minor coverage drops, the coverage can be easily ignored. It does so
using the `informational` flag in the `.codecov.yaml` file.
- It moves the API token back to using the github secret rather than
exposing it in the `.codecov.yaml` file.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants