On Thu, Jun 14, 2012 at 8:06 PM, Matthew Brett wrote:
> Hi,
>
> I noticed that numpy.linalg.matrix_rank sometimes gives full rank for
> matrices that are numerically rank deficient:
>
> If I repeatedly make random matrices, then set the first column to be
> equal to the sum of the second and third
Hi,
I noticed that numpy.linalg.matrix_rank sometimes gives full rank for
matrices that are numerically rank deficient:
If I repeatedly make random matrices, then set the first column to be
equal to the sum of the second and third columns:
def make_deficient():
X = np.random.normal(size=(40,
> Hi,
>
> I second James here, Theano do many of those optimizations. Only
> advanced coder can do better then Theano in most case, but that will
> take them much more time. If you find some optimization that you do
> and Theano don't, tell us. We want to add them :)
>
> Fred
I am sure Theano does
> Of course, maybe you were pointing out that if your derivative
> calculation depends in some intrinsic way on the topology of some
> graph, then your best bet is to have an automatic way to recompute it
> from scratch for each new graph you see. In that case, fair enough!
That is indeed what I h
On Thu, Jun 14, 2012 at 5:53 PM, Nathaniel Smith wrote:
> On Thu, Jun 14, 2012 at 9:22 PM, srean wrote:
> No, I'm saying I totally see the advantages. Here's the code I'm talking
> about:
>
> def _loglik(self, params):
> alpha, beta = self.used_alpha_beta(params)
> if np.any(alp
On Thu, Jun 14, 2012 at 9:22 PM, srean wrote:
>>
>> For example, I wrote a library routine for doing log-linear
>> regression. Doing this required computing the derivative of the
>> likelihood function, which was a huge nitpicky hassle; took me a few
>> hours to work out and debug. But it's still
On Jun 14, 2012, at 1:53 PM, James Bergstra wrote:
> On Thu, Jun 14, 2012 at 11:01 AM, Nathaniel Smith wrote:
>
>>> Indeed that would be great as sympy already has already excellent math
>>> expression rendering.
>>>
>>> An alternative would be to output mathml or something similar that
>>> co
On Mon, Jun 11, 2012 at 1:31 AM, Travis Oliphant wrote:
> It is unfortunate that this was committed to master. This should be backed
> out and is a blocker for 1.7. Can someone help me identify which commit
> made the change?
>
> This is a rather significant change and changes the documented
Hi,
On Thu, Jun 14, 2012 at 4:49 PM, James Bergstra
wrote:
> You're right - there is definitely a difference between a correct
> gradient and a gradient is both correct and fast to compute.
>
> The current quick implementation of pyautodiff is naive in this
> regard. However, it is delegating th
I think we should go ahead and merge this PR. It would be ideal to make a
branch with the current code and then merge this into master.
I haven't had the time to do this. If you can do this Nathaniel, then it will
really help with 1.7 release.
Thanks,
-Travis
On Jun 14, 2012, at 11:17
>
> You're right - there is definitely a difference between a correct
> gradient and a gradient is both correct and fast to compute.
>
> The current quick implementation of pyautodiff is naive in this
> regard.
Oh and by no means was I criticizing your implementation. It is a very
hard problem to
On Thu, Jun 14, 2012 at 4:22 PM, srean wrote:
>>
>> For example, I wrote a library routine for doing log-linear
>> regression. Doing this required computing the derivative of the
>> likelihood function, which was a huge nitpicky hassle; took me a few
>> hours to work out and debug. But it's still
On Thu, Jun 14, 2012 at 3:38 PM, Nathaniel Smith wrote:
> On Thu, Jun 14, 2012 at 7:53 PM, James Bergstra
> wrote:
>> On Thu, Jun 14, 2012 at 11:01 AM, Nathaniel Smith wrote:
>>
Indeed that would be great as sympy already has already excellent math
expression rendering.
An al
>
> For example, I wrote a library routine for doing log-linear
> regression. Doing this required computing the derivative of the
> likelihood function, which was a huge nitpicky hassle; took me a few
> hours to work out and debug. But it's still just 10 lines of Python
> code that I needed to figu
On Thu, Jun 14, 2012 at 7:53 PM, James Bergstra
wrote:
> On Thu, Jun 14, 2012 at 11:01 AM, Nathaniel Smith wrote:
>
>>> Indeed that would be great as sympy already has already excellent math
>>> expression rendering.
>>>
>>> An alternative would be to output mathml or something similar that
>>> c
On Thu, Jun 14, 2012 at 11:01 AM, Nathaniel Smith wrote:
>> Indeed that would be great as sympy already has already excellent math
>> expression rendering.
>>
>> An alternative would be to output mathml or something similar that
>> could be understood by the mathjax rendering module of the IPytho
On Thu, Jun 14, 2012 at 5:20 PM, David Cournapeau wrote:
>
>
>
> On Thu, Jun 14, 2012 at 5:17 PM, Nathaniel Smith wrote:
>>
>> On Wed, Jun 6, 2012 at 11:08 PM, Nathaniel Smith wrote:
>> > Just submitted this pull request for discussion:
>> > https://github.com/numpy/numpy/pull/297
>> >
>> > As
On Thu, Jun 14, 2012 at 10:17 AM, Nathaniel Smith wrote:
> On Wed, Jun 6, 2012 at 11:08 PM, Nathaniel Smith wrote:
> > Just submitted this pull request for discussion:
> > https://github.com/numpy/numpy/pull/297
> >
> > As per earlier discussion on the list, this PR attempts to remove
> > exact
On Thu, Jun 14, 2012 at 5:17 PM, Nathaniel Smith wrote:
> On Wed, Jun 6, 2012 at 11:08 PM, Nathaniel Smith wrote:
> > Just submitted this pull request for discussion:
> > https://github.com/numpy/numpy/pull/297
> >
> > As per earlier discussion on the list, this PR attempts to remove
> > exactl
On Wed, Jun 6, 2012 at 11:08 PM, Nathaniel Smith wrote:
> Just submitted this pull request for discussion:
> https://github.com/numpy/numpy/pull/297
>
> As per earlier discussion on the list, this PR attempts to remove
> exactly and only the maskna-related code from numpy mainline:
> http://mail
On Thu, Jun 14, 2012 at 3:42 PM, Olivier Grisel
wrote:
> 2012/6/14 James Bergstra :
>> On Thu, Jun 14, 2012 at 4:00 AM, Olivier Grisel
>> wrote:
>>> 2012/6/13 James Bergstra :
Further to the recent discussion on lazy evaluation & numba, I moved
what I was doing into a new project:
2012/6/14 James Bergstra :
> On Thu, Jun 14, 2012 at 4:00 AM, Olivier Grisel
> wrote:
>> 2012/6/13 James Bergstra :
>>> Further to the recent discussion on lazy evaluation & numba, I moved
>>> what I was doing into a new project:
>>>
>>> PyAutoDiff:
>>> https://github.com/jaberg/pyautodiff
>>>
>>>
Hi,
I am pleased to announce a new release of bento, a packaging solution
for python which aims at reproducibility, extensibility and simplicity.
The main features of this 0.1.0 release are:
- new commands register_pypi and upload_pypi to register a package
to
pypi and uplo
On Thu, Jun 14, 2012 at 4:00 AM, Olivier Grisel
wrote:
> 2012/6/13 James Bergstra :
>> Further to the recent discussion on lazy evaluation & numba, I moved
>> what I was doing into a new project:
>>
>> PyAutoDiff:
>> https://github.com/jaberg/pyautodiff
>>
>> It currently works by executing CPytho
On Wed, Jun 13, 2012 at 8:54 PM, Wes McKinney wrote:
> Nathaniel: my experience (see blog posting above for a bit more) is
> that khash really crushes PyDict for two reasons: you can use it with
> primitive types and avoid boxing, and secondly you can preallocate.
> Its memory footprint with large
On 6/13/12 8:12 PM, Nathaniel Smith wrote:
>>> I'm also worried that I still don't see any signs that you're working
>>> with the downstream libraries that this functionality is intended to
>>> be useful for, like the various HDF5 libraries and pandas. I really
>>> don't think this functionality ca
On 06/14/2012 12:06 AM, Bryan Van de Ven wrote:
> On 6/13/12 1:12 PM, Nathaniel Smith wrote:
>> your-branch's-base-master but not in your-repo's-master are new stuff
>> that you did on your branch. Solution is just to do
>> git push master
>
> Fixed, thanks.
>
>> Yes, of course we *could* wri
2012/6/13 James Bergstra :
> Further to the recent discussion on lazy evaluation & numba, I moved
> what I was doing into a new project:
>
> PyAutoDiff:
> https://github.com/jaberg/pyautodiff
>
> It currently works by executing CPython bytecode with a numpy-aware
> engine that builds a symbolic exp
28 matches
Mail list logo
