Add one-dimensional Fermi-Hubbard model

[bartandrews]

Fixes #102

[CLAassistant]

All committers have signed the CLA.

[bartandrews]

I have fixed the lint and format errors (as per the readme instructions), and the tox runs successfully on my computer now

[bartandrews]

Thank you for the code review! I have implemented your suggestions and have added some tests, which benchmark the ground-state energies for an L=4 chain against known results (from pyblock3, TeNPy, etc.). The tox runs successfully on my computer

[bartandrews]

Thanks again for the suggested improvements -- I have implemented these changes now

[bartandrews]

Thanks for catching this, I have implemented these changes now. Also, I want to confirm that in the docstring, when I write :math: `\mu`, is it okay to use to use a single slash here? Sometimes the backslash needs to be escaped/doubled for proper rendering

[kevinsung]

Thanks for catching this, I have implemented these changes now. Also, I want to confirm that in the docstring, when I write :math: \mu, is it okay to use to use a single slash here? Sometimes the backslash needs to be escaped/doubled for proper rendering

I think the single slash is fine because it's in a raw string (the string is prefixed by r). I've just added instructions to the README for building and viewing documentation locally. Please check that the docs you wrote render correctly.

[bartandrews]

Thank you for adding a note on how to compile the docs locally. The mu was indeed rendered correctly, but viewing the docs allowed me to fix a different issue, which was useful. I have renamed to fermi_hubbard_1d in anticipation of a fermi_hubbard_2d in fermi_hubbard.py and corresponding functions test_fermi_hubbard_2d... in fermi_hubbard_test.py. I can implement that in a separate PR if needed

[bartandrews]

Thank you for catching these inconsistencies, I have implemented the changes now :rocket: The next pull request should be smoother once I have learnt your code conventions :+1: (I have also changed the test location to be in the python subdirectory.)

[bartandrews]

As requested, in the tests I have now "compared the dictionary of the operator with one constructed explicitly without any for loop logic", for open and periodic boundary conditions. In the process, I also noticed that some existing tests in ffsim use assert A == B rather than np.testing.assert_equal(A, B), which seems to go against your convention. Should these also be fixed?

[kevinsung]

assert A == B rather than np.testing.assert_equal(A, B)

The reason to use np.testing.assert_allclose is that the error message displays the values of the arrays being compared. When A and B aren't arrays then the error messages from pytest are good enough. In any case, unrelated improvements should be done in a separate PR.