<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.comp.python.scientific.user">
    <title>gmane.comp.python.scientific.user</title>
    <link>http://permalink.gmane.org/gmane.comp.python.scientific.user</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.python.scientific.user/31817"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.python.scientific.user/31816"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.python.scientific.user/31815"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.python.scientific.user/31814"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.python.scientific.user/31813"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.python.scientific.user/31812"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.python.scientific.user/31811"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.python.scientific.user/31810"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.python.scientific.user/31809"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.python.scientific.user/31808"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.python.scientific.user/31807"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.python.scientific.user/31806"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.python.scientific.user/31805"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.python.scientific.user/31804"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.python.scientific.user/31802"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.python.scientific.user/31801"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.python.scientific.user/31800"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.python.scientific.user/31799"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.python.scientific.user/31798"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.python.scientific.user/31797"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.python.scientific.user/31817">
    <title>Re: scipy.weave on windows vista compiling error</title>
    <link>http://permalink.gmane.org/gmane.comp.python.scientific.user/31817</link>
    <description>&lt;pre&gt;Have a look at the solution of:

http://stackoverflow.com/questions/10231572/f2py-returns-valueerror-invalid-version-number-4

It is a bug in distutils version comparison.
&lt;/pre&gt;</description>
    <dc:creator>Till Stensitzki</dc:creator>
    <dc:date>2012-05-22T14:57:18</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.python.scientific.user/31816">
    <title>Re: scipy.weave on windows vista compiling error</title>
    <link>http://permalink.gmane.org/gmane.comp.python.scientific.user/31816</link>
    <description>&lt;pre&gt;Your C++ compiler has to match the C++ compiler used to compile Python -
which, I think, by default, on Vista is Visual Studio 2008.

However, the weave module is not actively maintained, and there are much
better options right now for interfacing with C/C++.  I would highly
suggest that if you have some performance-critical part of your code, you
either use Cython, or, if it is a simple numerical expression, use the
amazing numexpr package.

I warn you though - while pure Python code is very portable across
platforms, interfacing Python with other libraries (mostly, C and C++) is a
huge pain on Windows.  If you really want to continue, I strongly advise
you take advantage of Christoph Gohlke's work:

http://www.lfd.uci.edu/~gohlke/pythonlibs/

who has done all the hard work has made binary installers for most of the
hard-to-compile Python libraries with C and C++ dependencies.

Federico
_______________________________________________
SciPy-User mailing list
SciPy-User&amp;lt; at &amp;gt;scipy.org
http://mail.scipy.org/mailman&lt;/pre&gt;</description>
    <dc:creator>federico vaggi</dc:creator>
    <dc:date>2012-05-21T22:13:30</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.python.scientific.user/31815">
    <title>Re: scipy.weave on windows vista compiling error</title>
    <link>http://permalink.gmane.org/gmane.comp.python.scientific.user/31815</link>
    <description>&lt;pre&gt;

On 5/21/2012 4:36 AM, Tobias wrote:

Try `weave.inline("""printf("Hello World!");""", [], compiler='mingw32')`

Worked for me with gcc 4.5.2 on win32-py2.7. The msvc9 compiler also 
works for 64 bit Python.

Christoph
&lt;/pre&gt;</description>
    <dc:creator>Christoph Gohlke</dc:creator>
    <dc:date>2012-05-21T19:37:13</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.python.scientific.user/31814">
    <title>Re: scipy.weave on windows vista compiling error</title>
    <link>http://permalink.gmane.org/gmane.comp.python.scientific.user/31814</link>
    <description>&lt;pre&gt;
Hi Tobias,


I thought weave never worked under windows ??? maybe with mingw it is better (but no under 64bits windows :(
This is the main reason why most people (like me) moved from weave to cython.

Cheers,

&lt;/pre&gt;</description>
    <dc:creator>Jerome Kieffer</dc:creator>
    <dc:date>2012-05-21T19:00:06</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.python.scientific.user/31813">
    <title>Re: subclassing ndarray : i want slice to return ndarray, not subclass</title>
    <link>http://permalink.gmane.org/gmane.comp.python.scientific.user/31813</link>
    <description>&lt;pre&gt;On Mon, May 21, 2012 at 12:42 PM, Dag Sverre Seljebotn
&amp;lt;d.s.seljebotn&amp;lt; at &amp;gt;astro.uio.no&amp;gt; wrote:

Yes, it's almost always the wrong thing...


You have to override both, actually. After overriding __getitem__, then add
  def __getslice__(self, i, j):
    return self.__getitem__(slice(i, j))
or otherwise your __getitem__ will get skipped in some cases.

The other option would be to just accept that your subclass will be
returned from slices. If the only difference between your subclass and
the base ndarray is that your arrays have an extra ".info" attribute,
then you can just not define __array_finalize__ and check for the
presence of a ".info" attribute instead of checking for the subclass
directly. This depends on what your subclass is actually supposed to
do, obviously.

&lt;/pre&gt;</description>
    <dc:creator>Nathaniel Smith</dc:creator>
    <dc:date>2012-05-21T12:15:24</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.python.scientific.user/31812">
    <title>scipy.weave on windows vista compiling error</title>
    <link>http://permalink.gmane.org/gmane.comp.python.scientific.user/31812</link>
    <description>&lt;pre&gt;Hello!

I'm trying to bring scipy.weave to work on Windows Vista with MinGw. 
I use Python 2.7.1, Scipy 0.10.1 and MinGw 4.6.2
My code looks like the following:

 from scipy import weave
 weave.inline("""print('Hello World!');""", [], compiler = 'mingw32-gcc')

I get the following error message:

 DistutilsPlatformError: don't know how to compile C/C++ code on platform 'nt' 
 with 'mingw32-gcc' compiler

With MinGw come a lot of different compiler. If I choose not 'mingw32-gcc' but 
for example 'gcc' weave complains 

 ValueError: invalid version number '4.'

So I also downloaded the olf MinGW 2.9.5 Version. Then I also get the Error 
"don't know how to compile C/C++ code on platform 'nt'"

The PATH-Variables are set and I also made shure, that there is write access to 
the MinGw and Python folders. Searching for this error message gave no 
progress, but maybe you could help me. Would be great!

All the best
Tobi
&lt;/pre&gt;</description>
    <dc:creator>Tobias</dc:creator>
    <dc:date>2012-05-21T11:36:13</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.python.scientific.user/31811">
    <title>Re: subclassing ndarray : i want slice to return ndarray, not subclass</title>
    <link>http://permalink.gmane.org/gmane.comp.python.scientific.user/31811</link>
    <description>&lt;pre&gt;
Subclassing ndarray is a very tricky business -- I did it once and 
regretted having done it for years, because there's so much you can't do 
etc.. You're almost certainly better off with embedding an array as an 
attribute, and then forward properties etc. to it.

But your answer: You want to override __getitem__, __getslice__ is 
deprecated in Python.

Dag

&lt;/pre&gt;</description>
    <dc:creator>Dag Sverre Seljebotn</dc:creator>
    <dc:date>2012-05-21T11:42:07</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.python.scientific.user/31810">
    <title>subclassing ndarray : i want slice to return ndarray,not subclass</title>
    <link>http://permalink.gmane.org/gmane.comp.python.scientific.user/31810</link>
    <description>&lt;pre&gt;Hello,
all my question is in the title. More precisely, like in scipy doc i try this :
======================================
import sys
import numpy as np

class ArrayChild(np.ndarray):

    def __new__(cls, array, info=None):
        obj = np.asarray(array).view(cls)
        obj.info = info
        return obj

    def __array_finalize__(self, obj):
        print&amp;gt;&amp;gt;sys.stderr, "__array_finalize__"
        if obj is None: return
        self.info = getattr(obj, 'info', None)

if __name__=='__main__':
    a = np.arange(6)
    a.shape=2,3
    a_child = ArrayChild(a)
    for x in a_child : 
        print&amp;gt;&amp;gt;sys.stderr, x, type(x)

=====================================
and i have the answer :
=====================================
__array_finalize__
__array_finalize__
[0 1 2] &amp;lt;class '__main__.ArrayChild'&amp;gt;
__array_finalize__
[3 4 5] &amp;lt;class '__main__.ArrayChild'&amp;gt;

=====================================
but i want
=====================================
__array_finalize__
__array_finalize__
[0 1 2] &amp;lt;class '__main__.np.nda&lt;/pre&gt;</description>
    <dc:creator>pierre puiseux UPPA</dc:creator>
    <dc:date>2012-05-21T09:56:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.python.scientific.user/31809">
    <title>Re: SciPy installation troubles on CentOS 6.2</title>
    <link>http://permalink.gmane.org/gmane.comp.python.scientific.user/31809</link>
    <description>&lt;pre&gt;Magician, since I did not see any mention of it, I think you are missing to include in your build up a "site.cfg" file (see for instance http://www.scipy.org/Installing_SciPy/Linux Step 4: Build numpy(1.5.0) ). In that file you need to specify where your libraries are. That file needs to be used in building both Numpy and Scipy. Sergio ---------------------------------------------------------------------- Message: 1 Date: Sun, 20 May 2012 23:16:48 +0900 From: Magician &amp;lt;f_magician&amp;lt; at &amp;gt;mac.com&amp;gt; Subject: Re: [SciPy-User] SciPy installation troubles on CentOS 6.2 To: ralf.gommers&amp;lt; at &amp;gt;googlemail.com Cc: scipy-user&amp;lt; at &amp;gt;scipy.org Message-ID: &amp;lt;C3368B14-EED1-4E87-A7E9-80F76990A0E2&amp;lt; at &amp;gt;mac.com&amp;gt; Content-Type: text/plain; CHARSET=US-ASCII Hi Ralf, Thanks for your advice. I tried to install BLAS/Lapack/ATLAS as below: &amp;gt; yum install blas-devel lapack-devel atlas-devel Next I installed NumPy as below: &amp;gt; tar xzvf numpy-1.6.1.tar.gz &amp;gt; cd numpy-1.6.1 &amp;gt; export CFLAGS="-L/usr/local/python-2.7.3/lib" &amp;gt; python setup.py build But then I got those&lt;/pre&gt;</description>
    <dc:creator>Sergio Rojas</dc:creator>
    <dc:date>2012-05-20T20:34:44</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.python.scientific.user/31808">
    <title>Re: why do the discrete distributions not have a `fit`?</title>
    <link>http://permalink.gmane.org/gmane.comp.python.scientific.user/31808</link>
    <description>&lt;pre&gt;On Sun, May 20, 2012 at 1:14 PM, Ralf Gommers
&amp;lt;ralf.gommers&amp;lt; at &amp;gt;googlemail.com&amp;gt; wrote:

statsmodels.discrete Logit, Poisson, Negative Binomial (in GLM, but
unfinished in discrete)
http://statsmodels.sourceforge.net/devel/discretemod.html

No integer parameters restriction since I never seen them in the literature.


If hypergeometric works (and I guess boltzmann and binom works from a
quick look) for continuous parameters, then I don't see much reason to
restrict parameters to integers.

I played a bit more with hypergeom.fit and the main problem is to find
starting parameters that are consistent with the data, since the
support moves with the parameters, even if loc and scale are fixed.

For many discrete distributions the problem might be more how to
restrict the parameter space, e.g. if shape parameter is in (0,1)
(Logit or Probit transformation for Bernoulli, or exp transformation
for shape parameters &amp;gt; 0 in Poisson.
Or maybe not, if the optimization routine always finds an interior solution.

Josef



&lt;/pre&gt;</description>
    <dc:creator>josef.pktd&lt; at &gt;gmail.com</dc:creator>
    <dc:date>2012-05-20T17:44:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.python.scientific.user/31807">
    <title>Re: why do the discrete distributions not have a `fit`?</title>
    <link>http://permalink.gmane.org/gmane.comp.python.scientific.user/31807</link>
    <description>&lt;pre&gt;

Which ones? And do you then return non-integer parameters or not?



For functions that work with continuous input, perhaps using the continuous
fit and then looking for the best-fit with integer params near the
continuous optimum would work. I looked for literature on this topic, but
didn't find anything useful yet.

Ralf
_______________________________________________
SciPy-User mailing list
SciPy-User&amp;lt; at &amp;gt;scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-user
&lt;/pre&gt;</description>
    <dc:creator>Ralf Gommers</dc:creator>
    <dc:date>2012-05-20T17:14:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.python.scientific.user/31806">
    <title>Re: SciPy installation troubles on CentOS 6.2</title>
    <link>http://permalink.gmane.org/gmane.comp.python.scientific.user/31806</link>
    <description>&lt;pre&gt;

Note that this overrides CFLAGS instead of appending that flag to the rest.
If it doesn't work without that line, you have to either specify all cflags
or use numscons/bento.

Ralf


_______________________________________________
SciPy-User mailing list
SciPy-User&amp;lt; at &amp;gt;scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-user
&lt;/pre&gt;</description>
    <dc:creator>Ralf Gommers</dc:creator>
    <dc:date>2012-05-20T16:51:12</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.python.scientific.user/31805">
    <title>Re: SciPy installation troubles on CentOS 6.2</title>
    <link>http://permalink.gmane.org/gmane.comp.python.scientific.user/31805</link>
    <description>&lt;pre&gt;Hi Ralf,


Thanks for your advice.
I tried to install BLAS/Lapack/ATLAS as below:

Next I installed NumPy as below:

But then I got those errors:

If I haven't install BLAS/Lapack/ATLAS, NumPy will be
successfully built and installed.


Magician


On 2012/05/20, at 19:40, scipy-user-request&amp;lt; at &amp;gt;scipy.org wrote:

&lt;/pre&gt;</description>
    <dc:creator>Magician</dc:creator>
    <dc:date>2012-05-20T14:16:48</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.python.scientific.user/31804">
    <title>Re: scipy test error: undefined symbol: ATL_buildinfo</title>
    <link>http://permalink.gmane.org/gmane.comp.python.scientific.user/31804</link>
    <description>&lt;pre&gt;



The only failure is a check of the ATLAS version, that shouldn't yield
incorrect results.



Not sure. Perhaps nose isn't counting the one ATLAS test when it passes,
due to that file not having any actual tests in it.



Knownfail indicates tests that are known to fail under some conditions
(usually hardware/compiler dependent), so they aren't reported as new
errors/failures. If we wouldn't do this, we would keep getting the same bug
reports over and over again.

Ralf



_______________________________________________
SciPy-User mailing list
SciPy-User&amp;lt; at &amp;gt;scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-user
&lt;/pre&gt;</description>
    <dc:creator>Ralf Gommers</dc:creator>
    <dc:date>2012-05-20T10:44:34</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.python.scientific.user/31802">
    <title>Re: SciPy installation troubles on CentOS 6.2</title>
    <link>http://permalink.gmane.org/gmane.comp.python.scientific.user/31802</link>
    <description>&lt;pre&gt;


Building ATLAS is much harder than building scipy, so you should try to
find some rpm's for it, like
http://linuxtoolkit.blogspot.com/2010/09/installing-lapack-blas-and-atlas-on.html.
There's no problem building scipy against ATLAS from a binary install.

Ralf
_______________________________________________
SciPy-User mailing list
SciPy-User&amp;lt; at &amp;gt;scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-user
&lt;/pre&gt;</description>
    <dc:creator>Ralf Gommers</dc:creator>
    <dc:date>2012-05-20T08:21:12</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.python.scientific.user/31801">
    <title>SciPy installation troubles on CentOS 6.2</title>
    <link>http://permalink.gmane.org/gmane.comp.python.scientific.user/31801</link>
    <description>&lt;pre&gt;Hi All,


I'm trying to build SciPy from source code,
but I have some troubles.

My environment is below:
I and my colleagues (other users) want to use recent Python,
so I installed Python from sources, and I can't install SciPy
by using yum command.

Now I'm facing ATLAS compiling errors.
Configuration options are "--prefix=/usr/local/atlas-3.8.4 -Fa alg -fPIC".
I tried to build it for several times, and always I got errors as below:

It's very troublesome for me to build ATLAS by myself.
My purpose is just using SciPy on my Python.
Even if it's optimized not so good for my environment, it's OK.

Is there an easy or a sure way to build and install SciPy?


Magician
&lt;/pre&gt;</description>
    <dc:creator>Magician</dc:creator>
    <dc:date>2012-05-19T15:09:39</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.python.scientific.user/31800">
    <title>scipy test error: undefined symbol: ATL_buildinfo</title>
    <link>http://permalink.gmane.org/gmane.comp.python.scientific.user/31800</link>
    <description>&lt;pre&gt;Hello guys,

 After struggling for a while, I just finished the installation
 of scipy using the intel mkl library.

 Ungracefully the tests ended with an error regarding
 "undefined symbol: ATL_buildinfo" (see below)

 Can this scipy installation live with this error? or
 Is it prone to throw out wrong computations?

 Also, why the number of ran test is not a fix number
 (running the tests using a scipy/Atlas installation
 finished succesfully indicating: Ran 5832 tests in 422.155s
 OK (KNOWNFAIL=14, SKIP=42), but the scipy/mkl tests ended with
 Ran 5833 tests in 448.386s FAILED (KNOWNFAIL=14, SKIP=34, errors=1))?

 what is the meaning of KNOWNFAIL=14?

 Sergio

 &amp;gt;$ python_mkl
 Python 2.7.2 (default, May 16 2012, 13:06:17)
 [GCC 4.6.1] on linux3
 Type "help", "copyright", "credits" or "license" for more information.
 &amp;gt;&amp;gt;&amp;gt; import scipy
 &amp;gt;&amp;gt;&amp;gt; scipy.show_config()
 umfpack_info:
 NOT AVAILABLE
 lapack_opt_info:
 libraries = ['mkl_lapack95_ilp64', 'mkl_lapack95_lp64', 'mkl_rt', 'mkl_intel
 _lp64', 'mkl_intel_threa&lt;/pre&gt;</description>
    <dc:creator>Sergio Rojas</dc:creator>
    <dc:date>2012-05-18T22:46:09</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.python.scientific.user/31799">
    <title>Re: about scipy performance</title>
    <link>http://permalink.gmane.org/gmane.comp.python.scientific.user/31799</link>
    <description>&lt;pre&gt;
Is this reproducible, or could it just be timing noise?

In general though, I'm not sure you can expect performance to be strictly monotonic in k - there are all sorts of issues (e.g. cache coherency) which can make some sizes more efficient than others. The departures from monotonicity that you see are really rather small compared to those which are present in e.g. fftw.

Cheers,
David

------------------------------
On Sat, May 19, 2012 8:13 AM NZST Sergio Rojas wrote:

&lt;/pre&gt;</description>
    <dc:creator>David Baddeley</dc:creator>
    <dc:date>2012-05-18T20:28:19</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.python.scientific.user/31798">
    <title>about scipy performance</title>
    <link>http://permalink.gmane.org/gmane.comp.python.scientific.user/31798</link>
    <description>&lt;pre&gt;Running the performance test of scipy presented at
 [ http://software.intel.com/en-us/articles/numpy-scipy-with-mkl/ ] I found it strange a
 decrease in the time that takes the computation for a large K value (see for instance the value of
 tm corresponding to k=192 and k=200). Does this behaviour makes sense? Is there any test suite available
 to better check the performance of a scipy installation?

 Sergio
 PD. the output of np.show_config() is shown below the data.

 K TM GFLOPS
 64, 0.2182408, 34.91556
 80, 0.2414728, 39.50755
 96, 0.2986258, 38.37579
 104, 0.3231602, 38.43295
 112, 0.3429056, 39.01948
 120, 0.3645972, 39.33108
 128, 0.4074092, 37.55438
 144, 0.445568, 38.6473
 160, 0.4914636, 38.9449
 176, 0.5274322, 39.92931
 192, 0.6281674, 36.5826
 200, 0.6149654, 38.92902
 208, 0.6355928, 39.17603
 224, 0.673929, 39.79648
 240, 0.7244088, 39.67373
 256, 0.8612222, 35.60057
 384, 1.185954, 38.80421



 atlas_threads_info:
 libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas']
 library_dirs = ['/ho&lt;/pre&gt;</description>
    <dc:creator>Sergio Rojas</dc:creator>
    <dc:date>2012-05-18T20:13:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.python.scientific.user/31797">
    <title>Re: is it possible to constrain thescipy.optimize.curve_fit function?</title>
    <link>http://permalink.gmane.org/gmane.comp.python.scientific.user/31797</link>
    <description>&lt;pre&gt;17.05.2012 11:51, federico vaggi kirjoitti:
[clip]

Note that Scipy has several solvers that support bounds in optimization
problems --- to use those for least squares, you'll just need to do
"return (r**2).sum()" yourself. This is AFAIK also what lmfit does, in
addition to clipping parameter values within the bounds in the residual
function (I'm not sure how robust the results such clipping produces are).

Pauli
&lt;/pre&gt;</description>
    <dc:creator>Pauli Virtanen</dc:creator>
    <dc:date>2012-05-17T21:02:12</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.python.scientific.user/31796">
    <title>Re: is it possible to constrain thescipy.optimize.curve_fit function?</title>
    <link>http://permalink.gmane.org/gmane.comp.python.scientific.user/31796</link>
    <description>&lt;pre&gt;
I'd caution against using abs, as abs(x) is not differentiable around 0 and could cause a gradient descent solver to get stuck/confused. x**2 on the other hand is fully differentiable, but requires you to take the sqrt of the parameters after fitting.



------------------------------
On Thu, May 17, 2012 9:51 PM NZST federico vaggi wrote:

&lt;/pre&gt;</description>
    <dc:creator>David Baddeley</dc:creator>
    <dc:date>2012-05-17T19:47:43</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.python.scientific.user">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.python.scientific.user</link>
  </textinput>
</rdf:RDF>

