These are chat archives for SHTOOLS/SHTOOLS

29th
Aug 2016
MMesch
@MMesch
Aug 29 2016 09:10
I don't know but this post describes some possibilities: http://stackoverflow.com/questions/20483313/testing-ipython-notebooks
It means we either have to use a module or write some small code to test it
I suggest to post-pone the test issue to a later version
it should be addressed in a good complete way ...
MMesch
@MMesch
Aug 29 2016 09:24
warning: check: missing meta-data: if 'author' supplied, 'author_email' must be supplied too
@MarkWieczorek , do you want to provide your personal email address on pypi ?
Mark Wieczorek
@MarkWieczorek
Aug 29 2016 09:32
could you add my gmail address? mark.a.wieczorek@gmail.com
Also, the last travis build failed for linux, but I can't figure out why. Sometimes it times out because the speed test is really long.
MMesch
@MMesch
Aug 29 2016 09:34
yes. This is fixed in the plot_power PR
Mark Wieczorek
@MarkWieczorek
Aug 29 2016 09:36
actually, I will just add the email myself to the my PR. When you tell me you are happy with it, we can merge it.
MMesch
@MMesch
Aug 29 2016 09:38
ok. I think best is if we merge the phaseonly PR, chose a different name for it. Then we prepare a nicely tagged master version, then I test the pypitest upload, then we put it on pypi
Mark Wieczorek
@MarkWieczorek
Aug 29 2016 09:39
This doesn't bother me, as I'm not sure what the best solution is. One thing that bothers me with using random phases for the m, -m coefficients is that when m=0, the coefficient will always be fixed to the maximum value, as there is no phase with this term.
Also, for the docs: could you add periods (for consistency) at the end of your parameter descriptions?
MMesch
@MMesch
Aug 29 2016 09:41
OK yes. I guess the docs were not ready in general ...
So finally, who is doing what and when?
Mark Wieczorek
@MarkWieczorek
Aug 29 2016 09:42
power = power / (power_per_lm + 1e-50)
is that to avoid a potential divide by zero?
MMesch
@MMesch
Aug 29 2016 09:42
yes ...
Because anisotropy is undefined when power becomes zero. It is really ugly though
Mark Wieczorek
@MarkWieczorek
Aug 29 2016 09:43
is there is numpy expression for the smallest possible value instead?
MMesch
@MMesch
Aug 29 2016 09:43
That's better ~
Mark Wieczorek
@MarkWieczorek
Aug 29 2016 09:43
fortran defines eps (I think).
Or we could just create coefficients using a power spectrum that is "1" for all values, and then multiply by the expected value afterwards.
MMesch
@MMesch
Aug 29 2016 09:45

Maybe this answer (http://stackoverflow.com/questions/26248654/numpy-return-0-with-divide-by-zero) would be useful to be included in any case:

def div0( a, b ):
    """ ignore / 0, div0( [-1, 0, 1], 0 ) -> [0, 0, 0] """
    with np.errstate(divide='ignore', invalid='ignore'):
        c = np.true_divide( a, b )
        c[ ~ np.isfinite( c )] = 0  # -inf inf NaN
    return c

div0( [-1, 0, 1], 0 )
array([0, 0, 0])

That's a clean division by 0

Mark Wieczorek
@MarkWieczorek
Aug 29 2016 09:51
I don't know. The only thing that really bothers me is that 1.e-50 is arbitrary.
print(np.finfo(float).eps)
MMesch
@MMesch
Aug 29 2016 09:52
yes, it is ugly as it is ...
Mark Wieczorek
@MarkWieczorek
Aug 29 2016 10:39
@MMesch for info: make notebooks will execute all the notebooks and convert them to html. This is an easy way to verify that everything is working.
Also, do we need to uncomment this line in setup.py for PyPI? # version='3.3.2', # this line is only for testing
MMesch
@MMesch
Aug 29 2016 10:45
ok nice
If the version is tagged, get_version() returns a version string that is compatible with pypi
otherwise version has to be hard coded by uncommenting this line and commenting the previous
phaseonly is changed to exact_power now
#49 can be merged if you want
Mark Wieczorek
@MarkWieczorek
Aug 29 2016 10:49
after lunch...
MMesch
@MMesch
Aug 29 2016 10:51
#53 fixes the travis issues. Can be merged as well
Mark Wieczorek
@MarkWieczorek
Aug 29 2016 11:34
#49. I made a couple small changes to docs. Could you accept the proposed changes, and then merge this branch with develop?
just merge #53 as well.
After this: I just want to update all internal version numbers (with docs, etc) to 3.3.1, and add a couple sentences in docs saying that this can be installed by: pip install pyshtools
At this point, we might want to run all notebooks and tests to make sure there are no problems. I suggest merging this with master and tagging tomorrow. Then I'll let you deal with PyPI.
Mark Wieczorek
@MarkWieczorek
Aug 29 2016 13:41
small problem using v3.3.1:
 File "/Users/lunokhod/SphericalHarmonics/shtools-git/setup.py", line 60, in get_version
        version = '{:.1f}'.format(float(version) + 0.1)
    ValueError: could not convert string to float: '3.3.1'
MMesch
@MMesch
Aug 29 2016 13:42
is this the tagged version?
I ran into this issue as well ...
Mark Wieczorek
@MarkWieczorek
Aug 29 2016 13:51
No. this is develop. Its not able to parse "3.3.1" as a float. I think we need to treat this as a string (unless you want to be lazy and bump this to 3.4)
everything should be on develop, and as soon as this is fixed it is a release-candidate.
Mark Wieczorek
@MarkWieczorek
Aug 29 2016 14:00
This should all be pushed to develop as of a few minutes ago. Besides this issue, everyone should take a look at the README, index.html, www/install.html files to make sure you are ok with the install instructions.
Mark Wieczorek
@MarkWieczorek
Aug 29 2016 14:16
a = distutils.version.StrictVersion('3.3.1')
a.version

The output is (3, 3, 1)

Maybe this would work?

Mark Wieczorek
@MarkWieczorek
Aug 29 2016 14:52
@ioshchepkov I don't suppose you can look into this version numbering issue, could you? I'm not quite sure the best way to do this, and I probably won't have the time to look at this in any detail until friday.
MMesch
@MMesch
Aug 29 2016 16:22
the get_version() function increases the version number 3.2 by 0.1 if there is a dash in the git version (new revision after a tag)
This is not great for our purposes but maybe standard?
I just deactivated this, now if there is a dash, it gets appended to the version number that is given in the file
without increasing anything
Ilya Oshchepkov
@ioshchepkov
Aug 29 2016 16:45
Sorry, I was away. @MMesch, the problem with your modification is that it is not compatible with PEP440, because all what is after release can be only with post (and it is final) suffix, not dev. While we always start the new development stage with changing a version in the VERSION file it's ok, but if only in the end of development and right before release, it is not... I think, this can be written in the developments docs. So, after merging 3.3.1 with master branch, in develop branch VERSION have to be changed to 3.4 immediately...
In the other hand we can completely remove get_version() and use hard versioning, like with distutils.version or something else. But again it have to be explicitly determined by someone before every development stage
Mark Wieczorek
@MarkWieczorek
Aug 29 2016 16:54
@MMesch @ioshchepkov I am done for today. If you fix this, could you just merge this (plus the notebook PR) to develop? Everything, including all tests, work right now. If you want I can tag this as a release-candidate, but I don't see the point. If possible, I would like to merge with master and tag tomorrow afternoon.
MMesch
@MMesch
Aug 29 2016 16:58
ok. I don't really care which versioning system to use
also we need to quickly make the notebooks python2 compatible. I'll do this tomorrow.
@ioshchepkov what do you think is better for the version naming?
I am off for today. I'll follow your suggestion :)
Ilya Oshchepkov
@ioshchepkov
Aug 29 2016 17:13
@MMesch Ok, I'll think about it tomorrow morning
Mark Wieczorek
@MarkWieczorek
Aug 29 2016 22:16
@MMesch I added python 2 compatability to the notebooks. This was just importing the print function from future.