Hi Evgeni - thanks for the feedback! 

On Fri, Aug 28, 2015 at 11:33 AM, Evgeni Burovski <evgeny.burovskiy@gmail.com> wrote:
Hi Ariel,

Off-the-cuff, I'd think that the value of epsilon is best managed on
the user side.
[I can't say anything intelligent about the issue in dipy, so I'd
rather say nothing about it].

That was my intuition. Just wanted to make sure we're not doing anything crazy. 

In general, it seems that scipy's rbf implementation could use some
work, and here's one issue which summarizes some suggestions for it:

https://github.com/scipy/scipy/issues/4790

There is also a PR,

https://github.com/scipy/scipy/pull/5070

which was closed by the author, and I'm not sure what's the status of it.

As things stand, chances are that we'll be tempted to break backwards
compat for scipy.interpolate.Rbf. Since you're using it, your
suggestions are most welcome (and patches are even more so!)

OK - I will read up on this topic (I see there are some suggestions on that issue), and try to see whether I can be helpful. 

Thanks again, 

Ariel
 
Cheers,

Evgeni



On Thu, Aug 27, 2015 at 1:11 AM, Ariel Rokem <arokem@gmail.com> wrote:
> Hi everyone,
>
> In our work on dipy, we've run into a small issue moving from 0.15 to 0.16:
>
> https://github.com/nipy/dipy/issues/688
>
> The gist of this is that we are using RBF to interpolate a signal measured
> on the unit sphere. To do this, we have designed a custom 'norm' function
> based on the angle between measurements (rather than the default Euclidean).
> Code is here:
>
> https://github.com/nipy/dipy/blob/master/dipy/core/sphere.py#L500
>
> This seemed to work fine with 0.15, but the changes to the default epsilon
> introduced here: https://github.com/scipy/scipy/pull/4643 seem to be
> throwing us off.
>
> I've taken a look at the discussion on that PR and the issue that led to
> this work, and it does make sense, but I wanted to get some feedback to see
> how we should proceed. Setting a larger default epsilon in our code
> (effectively undoing this change) would be one way to go, but I want to make
> sure that it wouldn't be an obvious blunder, and that there isn't some issue
> on scipy that we should be thinking about.
>
> Thanks!
>
> Ariel
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev@scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
_______________________________________________
SciPy-Dev mailing list
SciPy-Dev@scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-dev