Skip to content
New issue

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

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

Already on GitHub? # to your account

Added a couple of methods to obtain the variogram model points or to save them to a file #94

Merged
merged 4 commits into from
Aug 14, 2018

Conversation

Daniel-M
Copy link
Contributor

Hi, I've added a couple of methods to UniversalKriging and OrdinaryKriging:

  • get_variogram_points: wich returns a numpy.array [lags, variogram_value_at_lags] which can be used of interest for the user (for further computations).
  • save_variogram_to_file: wich saves the variogram to a file output_file with separator separator(which defaults to space ) with the format lag variogram_value_at_lag according to the separator. Making a call with separator="," would save the values as lag,variogram_value_at_lag.

Copy link
Contributor

@rth rth left a comment

Choose a reason for hiding this comment

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

Thank you for this pull request!

A few general comments are below, you would need to add a unit test for get_variogram_points.

pykrige/ok.py Outdated
"""
variogram_points = self.variogram_function(self.variogram_model_parameters, self.lags)

return np.array([self.lags, variogram_points])
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't really see the advantage of concatenating lags and variogram points in term of the API.

Maybe just return the variogram_points would be sufficient? lags can already be accessed as an attribute.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Well, I'll look into that, where can I read more about the API? I'd like to be in full compliance with it.

Copy link
Contributor

Choose a reason for hiding this comment

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

lags is a class attribute that I don't think is documented very well internally (I don't think it's mentioned in any of the docstrings...). You need the lags to do anything with the variogram points, so I actually don't mind returning them both.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I thought it would be better to return them both too, since it makes easier the use of the data points

pykrige/ok.py Outdated
@@ -404,6 +404,34 @@ def display_variogram_model(self):
self.lags), 'k-')
plt.show()

def get_variogram_points(self):
"""Obtain the data pairs for the variogram model.
returns a numpy.array with the form [lag, variogram_value_at_lag]
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I will add docstrings for that

pykrige/ok.py Outdated

return np.array([self.lags, variogram_points])

def save_variogram_to_file(self, output_file, separator=" "):
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not so keen on this addition.

Assuming the above changes are made, this could be done fairly easily with,

import pandas as pd

df = pd.DataFrame({'lag': model.lag,
                   'variogram_points': model.get_variogram_points()})
df.to_csv('<some-file>)

there is not need to include and maintain a custom CSV like format in pykrige for this..

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You are right, i'll take it out

@bsmurphy
Copy link
Contributor

This looks good, thanks for contributing! Agreed the biggest addition we'd ask for is an extended docstring, so it'll play nice with our readthedocs page. Of course, a lot of the get_* routines need better docstrings, something I need to work on one of these days...

I think AppVeyor might be crashing for an unrelated reason, so once you push an update we'll see what happens.

@Daniel-M
Copy link
Contributor Author

I'd like to help on the docstrings side, maybe I don't know the API well, but I could help with styling or infering what each of the method does

@Daniel-M
Copy link
Contributor Author

As for AppVeyor, I figured the problem is with the conda environment for Python 3.5, I did looked what happened, but can't remember the specifics now

@bsmurphy
Copy link
Contributor

With the docstrings, we're trying to follow the numpy docstring convention: https://numpydoc.readthedocs.io/en/latest/format.html#docstring-standard

Most of the main routines (__init__, execute) use these formats now, so you can check them for reference...

@rth
Copy link
Contributor

rth commented May 2, 2018

As for AppVeyor, I figured the problem is with the conda environment for Python 3.5, I did looked what happened, but can't remember the specifics now

We can ignore the failed Appveyor test, it's a known issue that is fixed on master in 0569194

Well, I'll look into that, where can I read more about the API? I'd like to be in full compliance with it.

We don't really have a write-up for API principles, so it mostly a discussion at review time. For my part I think it would make sense to adapt as much as possible of scikit-learn's API design. Also if you are integeresed in general ideas about the scipy API principles, see the second part of this presentation particularly starting from slide 60.

@Daniel-M
Copy link
Contributor Author

Daniel-M commented May 3, 2018

Hey, sorry for the late commits, I've added a couple of tests for the method get_variogram_points and an extendend docstring to them. Do you agree with the name of the method get_variogram_points or is it explicit enough? on the other hand, I hope you like what I've made, It is kinda my first time using pytest, and tried to comply with the use of the already existing test data you have. Looking forward to know what you think.

BTW, the slides you showed me are amazing, is it there a video for them? could'nt find it myself

Daniel.

@Daniel-M Daniel-M changed the title Added a couple of metohods to obtain the variogram model points or to save them to a file Added a couple of methods to obtain the variogram model points or to save them to a file May 3, 2018
@bsmurphy
Copy link
Contributor

bsmurphy commented May 4, 2018

Looks good to me! I think the name is good, fits with the general convention we have going. @rth might have some comments, but I'd say we can go ahead and merge once he takes a look.

@bsmurphy
Copy link
Contributor

bsmurphy commented Aug 6, 2018

@rth, can we merge this?

@rth
Copy link
Contributor

rth commented Aug 14, 2018

Sorry for the late response, yes this LGTM, merging. Thanks @Daniel-M !

@rth rth merged commit db07202 into GeoStat-Framework:master Aug 14, 2018
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants