Added inplace_increment function #326

Closed
wants to merge 27 commits into
from

Conversation

Projects
None yet
7 participants
@jsalvatier
Contributor

jsalvatier commented Jun 27, 2012

I've added an inplace_increment function which allows you to increment an array inplace using advanced indexing. The key feature is that repeated indexes will repeatedly increment the array whereas

a[idx] +=1

will not do this. More discussion here and here.

I've included, documentation, a couple of tests and supported multiple datatypes.

I'm new to doing Python functions in C so a good once over of the C code is a good idea. I'm also new to submitting code for numpy, so I've probably made some mistakes somewhere.

@njsmith

This comment has been minimized.

Show comment
Hide comment
@njsmith

njsmith Jul 6, 2012

Member

I have mixed feelings about this. The functionality is often-requested and clearly useful, but the implementation has a number of problems. The basic features numpy provides are indexing and generic operations over generic types. This code uses numpy's indexing, but ignores the generic operation and type support, so it only supports one operation (addition) and a fixed set of types. All that would be fine if it were just implementation limitations that could be fixed later, but the API is not flexible enough to support other operations -- a "proper" version of this functionality would probably be a method on ufuncs, not a standalone function. So the API is kind of a dead-end as well.

I don't want to make the perfect the enemy of the good, but on balance I think there's enough wrong with this that I'm -0.5 on merging it and making it a permanent part of the numpy API. The best compromise might be to extract the core function and release it as a tiny standalone library? It looks like it only uses public numpy API functions, so it should be easy to do. That way people who want the feature have an easy way to get it until numpy grows a cleaner solution.

Member

njsmith commented Jul 6, 2012

I have mixed feelings about this. The functionality is often-requested and clearly useful, but the implementation has a number of problems. The basic features numpy provides are indexing and generic operations over generic types. This code uses numpy's indexing, but ignores the generic operation and type support, so it only supports one operation (addition) and a fixed set of types. All that would be fine if it were just implementation limitations that could be fixed later, but the API is not flexible enough to support other operations -- a "proper" version of this functionality would probably be a method on ufuncs, not a standalone function. So the API is kind of a dead-end as well.

I don't want to make the perfect the enemy of the good, but on balance I think there's enough wrong with this that I'm -0.5 on merging it and making it a permanent part of the numpy API. The best compromise might be to extract the core function and release it as a tiny standalone library? It looks like it only uses public numpy API functions, so it should be easy to do. That way people who want the feature have an easy way to get it until numpy grows a cleaner solution.

@jsalvatier

This comment has been minimized.

Show comment
Hide comment
@jsalvatier

jsalvatier Jul 6, 2012

Contributor

I'd be in favor of a stand alone library (it was my original intention to put this into a separate package) except that the MapIter interface is unfortunately not public; mapping.c has a comment that explains:

/*

  • The mapiter object must be created new each time. It does not work
  • to bind to a new array, and continue.
    *
  • This was the orginal intention, but currently that does not work.
  • Do not expose the MapIter_Type to Python.
    *
  • It's not very useful anyway, since mapiter(indexobj); mapiter.bind(a);
  • mapiter is equivalent to a[indexobj].flat but the latter gets to use
  • slice syntax.
    */

If MapIter could be exposed, then I'd be happy to make this a function in a separate package. I don't know whether it would be difficult to fix the reuse issue. I think Mark Wiebe was the person who implemented MapIter.

I'll look into making this a function of binary ufuncs like reduce, but I suspect that's still above my skill level.

Contributor

jsalvatier commented Jul 6, 2012

I'd be in favor of a stand alone library (it was my original intention to put this into a separate package) except that the MapIter interface is unfortunately not public; mapping.c has a comment that explains:

/*

  • The mapiter object must be created new each time. It does not work
  • to bind to a new array, and continue.
    *
  • This was the orginal intention, but currently that does not work.
  • Do not expose the MapIter_Type to Python.
    *
  • It's not very useful anyway, since mapiter(indexobj); mapiter.bind(a);
  • mapiter is equivalent to a[indexobj].flat but the latter gets to use
  • slice syntax.
    */

If MapIter could be exposed, then I'd be happy to make this a function in a separate package. I don't know whether it would be difficult to fix the reuse issue. I think Mark Wiebe was the person who implemented MapIter.

I'll look into making this a function of binary ufuncs like reduce, but I suspect that's still above my skill level.

@jsalvatier

This comment has been minimized.

Show comment
Hide comment
@jsalvatier

jsalvatier Jul 6, 2012

Contributor

Actually looking at the implementation of PyUFunc_ReduceWrapper, it doesn't look like it would be too difficult to do something similar for this. However, I'm having a hard time picturing how the added generality would be used. Can you think of some useful cases where this would be used on ufuncs besides add? I can imagine it being useful on prod and pow, but I can't think of any concrete uses.

Contributor

jsalvatier commented Jul 6, 2012

Actually looking at the implementation of PyUFunc_ReduceWrapper, it doesn't look like it would be too difficult to do something similar for this. However, I'm having a hard time picturing how the added generality would be used. Can you think of some useful cases where this would be used on ufuncs besides add? I can imagine it being useful on prod and pow, but I can't think of any concrete uses.

@njsmith

This comment has been minimized.

Show comment
Hide comment
@njsmith

njsmith Jul 6, 2012

Member

I don't have any concrete cases in mind for using this with prod and pow, but I bet someone will show up with one sooner or later... automatically supporting all numpy dtypes is the more useful part, I think.

If MapIter isn't exposed then that'll be a hurdle, though, because ufuncs (which live in the "umath" library) don't have access to the "multiarray" library internal functions. @mwiebe, is there any reasonable way to do ndarray indexing via the public C API?

Member

njsmith commented Jul 6, 2012

I don't have any concrete cases in mind for using this with prod and pow, but I bet someone will show up with one sooner or later... automatically supporting all numpy dtypes is the more useful part, I think.

If MapIter isn't exposed then that'll be a hurdle, though, because ufuncs (which live in the "umath" library) don't have access to the "multiarray" library internal functions. @mwiebe, is there any reasonable way to do ndarray indexing via the public C API?

@teoliphant

This comment has been minimized.

Show comment
Hide comment
@teoliphant

teoliphant Jul 17, 2012

Member

While in an ideal world, perhaps this functionality would be on ufuncs. However, that is actually quite a bit of work. The fancy-indexing feature is just not exposed to the ufunc machinery. Thus, I think that currently this patch does a pretty good job as is. I don't think it would be too difficult to add a verison for mul and pow using a similar API at some point.

Member

teoliphant commented Jul 17, 2012

While in an ideal world, perhaps this functionality would be on ufuncs. However, that is actually quite a bit of work. The fancy-indexing feature is just not exposed to the ufunc machinery. Thus, I think that currently this patch does a pretty good job as is. I don't think it would be too difficult to add a verison for mul and pow using a similar API at some point.

numpy/core/bscript
@@ -428,6 +428,7 @@ def pre_build(context):
"src/multiarray/arraytypes.c.src",
"src/multiarray/nditer_templ.c.src",
"src/multiarray/lowlevel_strided_loops.c.src",
+ "src/multiarray/mapping.c.src",

This comment has been minimized.

@teoliphant

teoliphant Jul 17, 2012

Member

Indentation problem.

@teoliphant

teoliphant Jul 17, 2012

Member

Indentation problem.

numpy/core/setup.py
@@ -688,6 +688,7 @@ def generate_multiarray_templated_sources(ext, build_dir):
join(local_dir, subpath, 'arraytypes.c.src'),
join(local_dir, subpath, 'nditer_templ.c.src'),
join(local_dir, subpath, 'lowlevel_strided_loops.c.src'),
+ join(local_dir, subpath, 'mapping.c.src'),

This comment has been minimized.

@teoliphant

teoliphant Jul 17, 2012

Member

Indentation problem again.

@teoliphant

teoliphant Jul 17, 2012

Member

Indentation problem again.

numpy/core/src/multiarray/mapping.c.src
+ }
+
+
+ //body

This comment has been minimized.

@teoliphant

teoliphant Jul 17, 2012

Member

Do we support // -style comments in C in NumPy. Last I knew we did not.

@teoliphant

teoliphant Jul 17, 2012

Member

Do we support // -style comments in C in NumPy. Last I knew we did not.

numpy/core/src/multiarray/mapping.c.src
+ //body
+ PyArrayMapIterObject * mit = (PyArrayMapIterObject *) PyArray_MapIterNew(index, 0, 1);
+ if (mit == NULL)
+ {

This comment has been minimized.

@teoliphant

teoliphant Jul 17, 2012

Member

Indentation issues. Please put the if aligned with the previous line.

@teoliphant

teoliphant Jul 17, 2012

Member

Indentation issues. Please put the if aligned with the previous line.

numpy/core/src/multiarray/mapping.c.src
+ Py_DECREF(mit);
+
+ Py_INCREF(Py_None);
+ return Py_None;

This comment has been minimized.

@teoliphant

teoliphant Jul 17, 2012

Member

Align this line with the previous one.

@teoliphant

teoliphant Jul 17, 2012

Member

Align this line with the previous one.

@jsalvatier

This comment has been minimized.

Show comment
Hide comment
@jsalvatier

jsalvatier Jul 18, 2012

Contributor

I think I've fixed those formatting issues.

Contributor

jsalvatier commented Jul 18, 2012

I think I've fixed those formatting issues.

numpy/core/src/multiarray/mapping.c.src
+ inplace_binop add_inplace = NULL;
+ int type_number = PyArray_TYPE(a);
+ int i =0;
+ while (type_numbers[i] >= 0 && addition_funcs[i] != NULL)

This comment has been minimized.

@charris

charris Jul 19, 2012

Member

wrong curly braces style for while and if.

@charris

charris Jul 19, 2012

Member

wrong curly braces style for while and if.

@charris

This comment has been minimized.

Show comment
Hide comment
@charris

charris Jul 19, 2012

Member

Not quite, there are still lots of style issues. There is a C style guide in doc/C_STYLE_GUIDE.rst.txt. Also check that there are no hard tabs anywhere, some of the indents still look odd.

Member

charris commented Jul 19, 2012

Not quite, there are still lots of style issues. There is a C style guide in doc/C_STYLE_GUIDE.rst.txt. Also check that there are no hard tabs anywhere, some of the indents still look odd.

numpy/core/src/multiarray/mapping.c.src
+//is something like this already defined somewhere? where?
+/**begin repeat
+* #type = npy_int8, npy_int16, npy_int32, npy_int64, npy_uint8, npy_uint16, npy_uint32, npy_uint64, npy_float16, npy_float32, npy_float64#
+* #typen = NPY_INT8, NPY_INT16, NPY_INT32, NPY_INT64, NPY_UINT8, NPY_UINT16, NPY_UINT32, NPY_UINT64, NPY_FLOAT16, NPY_FLOAT32, NPY_FLOAT64#

This comment has been minimized.

@hgomersall

hgomersall Jul 19, 2012

Contributor

Isn't this missing a few types? What happens for bit lengths bigger than 64? (forgive me if this should be apparent!)

@hgomersall

hgomersall Jul 19, 2012

Contributor

Isn't this missing a few types? What happens for bit lengths bigger than 64? (forgive me if this should be apparent!)

This comment has been minimized.

@jsalvatier

jsalvatier Jul 23, 2012

Contributor

I just chose the ones that I had seen used. How large should this go up to?

@jsalvatier

jsalvatier Jul 23, 2012

Contributor

I just chose the ones that I had seen used. How large should this go up to?

numpy/core/src/multiarray/mapping.c.src
+
+/**begin repeat
+* #type = npy_complex64, npy_complex128#
+* #typen = NPY_COMPLEX64, NPY_COMPLEX128#

This comment has been minimized.

@hgomersall

hgomersall Jul 19, 2012

Contributor

As for the reals above, what happens for the longer complex types?

@hgomersall

hgomersall Jul 19, 2012

Contributor

As for the reals above, what happens for the longer complex types?

@travisbot

This comment has been minimized.

Show comment
Hide comment
@travisbot

travisbot Jul 23, 2012

This pull request fails (merged 16603b5 into f2f0ac0).

This pull request fails (merged 16603b5 into f2f0ac0).

@travisbot

This comment has been minimized.

Show comment
Hide comment
@travisbot

travisbot Jul 23, 2012

This pull request fails (merged 6a80aba into f2f0ac0).

This pull request fails (merged 6a80aba into f2f0ac0).

@jsalvatier

This comment has been minimized.

Show comment
Hide comment
@jsalvatier

jsalvatier Jul 23, 2012

Contributor

I read through the C style document and went through and tried to make this patch conform.

I've also added support for all int,uint, float, complex datatype bit-width sizes that are listed at the bottom of here: http://docs.scipy.org/doc/numpy/reference/c-api.dtype.html

Contributor

jsalvatier commented Jul 23, 2012

I read through the C style document and went through and tried to make this patch conform.

I've also added support for all int,uint, float, complex datatype bit-width sizes that are listed at the bottom of here: http://docs.scipy.org/doc/numpy/reference/c-api.dtype.html

numpy/core/src/multiarray/mapping.c.src
+ &inc)) {
+ return NULL;
+ }
+ if (arg_a->ob_type != &PyArray_Type){

This comment has been minimized.

@bfroehle

bfroehle Jul 25, 2012

Contributor

I think you meant to write if (!PyArray_Check(arg_a)) {.

@bfroehle

bfroehle Jul 25, 2012

Contributor

I think you meant to write if (!PyArray_Check(arg_a)) {.

This comment has been minimized.

@jsalvatier

jsalvatier Jul 25, 2012

Contributor

Thanks, I was looking for that function.

@jsalvatier

jsalvatier Jul 25, 2012

Contributor

Thanks, I was looking for that function.

numpy/core/src/multiarray/mapping.c.src
+typedef void (*inplace_binop)(char *, char *);
+
+
+/*is something like this already defined somewhere? where?*/

This comment has been minimized.

@bfroehle

bfroehle Jul 25, 2012

Contributor

Doubtful, because calling a function just to add two integers or floats together would be exceptionally slow. Instead I would expect that the function you generate here would perform the entire loop...

Edit: I now see PyArray_GetMap and PyArray_SetMap do something similar for the constructions a[b] and a[b] = c, but I must say I'm a bit surprised.

@bfroehle

bfroehle Jul 25, 2012

Contributor

Doubtful, because calling a function just to add two integers or floats together would be exceptionally slow. Instead I would expect that the function you generate here would perform the entire loop...

Edit: I now see PyArray_GetMap and PyArray_SetMap do something similar for the constructions a[b] and a[b] = c, but I must say I'm a bit surprised.

This comment has been minimized.

@jsalvatier

jsalvatier Jul 25, 2012

Contributor

I hadn't understood why this was true before, but now I do. I've changed it the specialized functions to do the entire loop.

@jsalvatier

jsalvatier Jul 25, 2012

Contributor

I hadn't understood why this was true before, but now I do. I've changed it the specialized functions to do the entire loop.

numpy/core/src/multiarray/mapping.c.src
+ PyErr_SetString(PyExc_RuntimeError,
+ "array is not writeable");
+ return NULL;
+ }

This comment has been minimized.

@bfroehle

bfroehle Jul 25, 2012

Contributor

I think you meant:

if (PyArray_FailUnlessWriteable(a, "input/output array") < 0) {
    return NULL;
}
@bfroehle

bfroehle Jul 25, 2012

Contributor

I think you meant:

if (PyArray_FailUnlessWriteable(a, "input/output array") < 0) {
    return NULL;
}
@travisbot

This comment has been minimized.

Show comment
Hide comment
@travisbot

travisbot Jul 25, 2012

This pull request fails (merged 73b36f4 into f2f0ac0).

This pull request fails (merged 73b36f4 into f2f0ac0).

@njsmith

This comment has been minimized.

Show comment
Hide comment
@njsmith

njsmith Jul 26, 2012

Member

It's great that you guys are interested in this, but I'm worried that you're spending a lot of time in ways that aren't really getting the patch closer to merging. The main obstacle is still the points that I raised. IMHO the best way forward would be to work out how to expose an API for doing indexing:
http://mail.scipy.org/pipermail/numpy-discussion/2012-July/063411.html

Of course there may be other options as well, but this approach doesn't seem too difficult and AFAICT everyone seems to like it.

Member

njsmith commented Jul 26, 2012

It's great that you guys are interested in this, but I'm worried that you're spending a lot of time in ways that aren't really getting the patch closer to merging. The main obstacle is still the points that I raised. IMHO the best way forward would be to work out how to expose an API for doing indexing:
http://mail.scipy.org/pipermail/numpy-discussion/2012-July/063411.html

Of course there may be other options as well, but this approach doesn't seem too difficult and AFAICT everyone seems to like it.

@jsalvatier

This comment has been minimized.

Show comment
Hide comment
@jsalvatier

jsalvatier Jul 26, 2012

Contributor

What would be necessary to do that?
On Jul 26, 2012 4:31 AM, "njsmith" <
reply@reply.github.com>
wrote:

It's great that you guys are interested in this, but I'm worried that
you're spending a lot of time in ways that aren't really getting the patch
closer to merging. The main obstacle is still the points that I raised.
IMHO the best way forward would be to work out how to expose an API for
doing indexing:
http://mail.scipy.org/pipermail/numpy-discussion/2012-July/063411.html

Of course there may be other options as well, but this approach doesn't
seem too difficult and AFAICT everyone seems to like it.


Reply to this email directly or view it on GitHub:
#326 (comment)

Contributor

jsalvatier commented Jul 26, 2012

What would be necessary to do that?
On Jul 26, 2012 4:31 AM, "njsmith" <
reply@reply.github.com>
wrote:

It's great that you guys are interested in this, but I'm worried that
you're spending a lot of time in ways that aren't really getting the patch
closer to merging. The main obstacle is still the points that I raised.
IMHO the best way forward would be to work out how to expose an API for
doing indexing:
http://mail.scipy.org/pipermail/numpy-discussion/2012-July/063411.html

Of course there may be other options as well, but this approach doesn't
seem too difficult and AFAICT everyone seems to like it.


Reply to this email directly or view it on GitHub:
#326 (comment)

@teoliphant

This comment has been minimized.

Show comment
Hide comment
@teoliphant

teoliphant Jul 26, 2012

Member

Exposing an API for indexing would be a good start. Basically, expose the bound MapIter functions that you used (MapIter_Next, etc.)

Then, this API could be used to add in-place indexing as a method to ufuncs more easily (re-using the inner loops of those ufuncs to do the actual calculation).

-Travis

On Jul 26, 2012, at 8:56 AM, john salvatier wrote:

What would be necessary to do that?
On Jul 26, 2012 4:31 AM, "njsmith" <
reply@reply.github.com>
wrote:

It's great that you guys are interested in this, but I'm worried that
you're spending a lot of time in ways that aren't really getting the patch
closer to merging. The main obstacle is still the points that I raised.
IMHO the best way forward would be to work out how to expose an API for
doing indexing:
http://mail.scipy.org/pipermail/numpy-discussion/2012-July/063411.html

Of course there may be other options as well, but this approach doesn't
seem too difficult and AFAICT everyone seems to like it.


Reply to this email directly or view it on GitHub:
#326 (comment)


Reply to this email directly or view it on GitHub:
#326 (comment)

Member

teoliphant commented Jul 26, 2012

Exposing an API for indexing would be a good start. Basically, expose the bound MapIter functions that you used (MapIter_Next, etc.)

Then, this API could be used to add in-place indexing as a method to ufuncs more easily (re-using the inner loops of those ufuncs to do the actual calculation).

-Travis

On Jul 26, 2012, at 8:56 AM, john salvatier wrote:

What would be necessary to do that?
On Jul 26, 2012 4:31 AM, "njsmith" <
reply@reply.github.com>
wrote:

It's great that you guys are interested in this, but I'm worried that
you're spending a lot of time in ways that aren't really getting the patch
closer to merging. The main obstacle is still the points that I raised.
IMHO the best way forward would be to work out how to expose an API for
doing indexing:
http://mail.scipy.org/pipermail/numpy-discussion/2012-July/063411.html

Of course there may be other options as well, but this approach doesn't
seem too difficult and AFAICT everyone seems to like it.


Reply to this email directly or view it on GitHub:
#326 (comment)


Reply to this email directly or view it on GitHub:
#326 (comment)

@jsalvatier

This comment has been minimized.

Show comment
Hide comment
@jsalvatier

jsalvatier Jul 26, 2012

Contributor

Can the API be exposed as-is or do we need to solve the problem of
resetting the MapIterObject? Where do you say which functions are exposed
as interface?

On Thu, Jul 26, 2012 at 7:36 AM, Travis E. Oliphant <
reply@reply.github.com

wrote:

Exposing an API for indexing would be a good start. Basically, expose
the bound MapIter functions that you used (MapIter_Next, etc.)

Then, this API could be used to add in-place indexing as a method to
ufuncs more easily (re-using the inner loops of those ufuncs to do the
actual calculation).

-Travis

On Jul 26, 2012, at 8:56 AM, john salvatier wrote:

What would be necessary to do that?
On Jul 26, 2012 4:31 AM, "njsmith" <
reply@reply.github.com>
wrote:

It's great that you guys are interested in this, but I'm worried that
you're spending a lot of time in ways that aren't really getting the
patch
closer to merging. The main obstacle is still the points that I raised.
IMHO the best way forward would be to work out how to expose an API for
doing indexing:
http://mail.scipy.org/pipermail/numpy-discussion/2012-July/063411.html

Of course there may be other options as well, but this approach doesn't
seem too difficult and AFAICT everyone seems to like it.


Reply to this email directly or view it on GitHub:
#326 (comment)


Reply to this email directly or view it on GitHub:
#326 (comment)


Reply to this email directly or view it on GitHub:
#326 (comment)

Contributor

jsalvatier commented Jul 26, 2012

Can the API be exposed as-is or do we need to solve the problem of
resetting the MapIterObject? Where do you say which functions are exposed
as interface?

On Thu, Jul 26, 2012 at 7:36 AM, Travis E. Oliphant <
reply@reply.github.com

wrote:

Exposing an API for indexing would be a good start. Basically, expose
the bound MapIter functions that you used (MapIter_Next, etc.)

Then, this API could be used to add in-place indexing as a method to
ufuncs more easily (re-using the inner loops of those ufuncs to do the
actual calculation).

-Travis

On Jul 26, 2012, at 8:56 AM, john salvatier wrote:

What would be necessary to do that?
On Jul 26, 2012 4:31 AM, "njsmith" <
reply@reply.github.com>
wrote:

It's great that you guys are interested in this, but I'm worried that
you're spending a lot of time in ways that aren't really getting the
patch
closer to merging. The main obstacle is still the points that I raised.
IMHO the best way forward would be to work out how to expose an API for
doing indexing:
http://mail.scipy.org/pipermail/numpy-discussion/2012-July/063411.html

Of course there may be other options as well, but this approach doesn't
seem too difficult and AFAICT everyone seems to like it.


Reply to this email directly or view it on GitHub:
#326 (comment)


Reply to this email directly or view it on GitHub:
#326 (comment)


Reply to this email directly or view it on GitHub:
#326 (comment)

@njsmith

This comment has been minimized.

Show comment
Hide comment
@njsmith

njsmith Jul 26, 2012

Member

There's a script that runs over the source and generates the actual API proper. To mark a function to be exported, you just put a magic comment that says NUMPY_API in front of it. If you grep the source you'll find some examples to follow. Then you should also add it to the list in numpy/core/code_generators/numpy_api.py.

I'm not familiar enough with the details of the MapIterObject interface to comment off-the-cuff on whether it can be exposed as is. If no-one else speaks up, though, then you can always make a first hackish attempt and post it for review. (Note that Travis did have a suggestion about how the interface should look in that comment I posted up above, though.) I think the solution to the resetting problem is to just not expose any functionality that would let people run into the problem, though I don't know what the problem is in detail so I might be missing something.

Member

njsmith commented Jul 26, 2012

There's a script that runs over the source and generates the actual API proper. To mark a function to be exported, you just put a magic comment that says NUMPY_API in front of it. If you grep the source you'll find some examples to follow. Then you should also add it to the list in numpy/core/code_generators/numpy_api.py.

I'm not familiar enough with the details of the MapIterObject interface to comment off-the-cuff on whether it can be exposed as is. If no-one else speaks up, though, then you can always make a first hackish attempt and post it for review. (Note that Travis did have a suggestion about how the interface should look in that comment I posted up above, though.) I think the solution to the resetting problem is to just not expose any functionality that would let people run into the problem, though I don't know what the problem is in detail so I might be missing something.

@jsalvatier

This comment has been minimized.

Show comment
Hide comment
@jsalvatier

jsalvatier Aug 6, 2012

Contributor

I've made a separate pull request, for njsmith's recommendation to expose the MapIter API (#375).

Contributor

jsalvatier commented Aug 6, 2012

I've made a separate pull request, for njsmith's recommendation to expose the MapIter API (#375).

@jsalvatier

This comment has been minimized.

Show comment
Hide comment
@jsalvatier

jsalvatier Aug 7, 2012

Contributor

I've made a cleaned up pull request (#377).

Contributor

jsalvatier commented Aug 7, 2012

I've made a cleaned up pull request (#377).

@jsalvatier jsalvatier referenced this pull request Sep 26, 2012

Closed

MapIter API #377

@nouiz nouiz referenced this pull request in Theano/Theano Oct 29, 2012

Closed

Implement GpuAdvancedIncSubtensor #930

@jsalvatier jsalvatier referenced this pull request in Theano/Theano Dec 14, 2012

Closed

Full advanced Indexing support + gradient #1083

@jsalvatier

This comment has been minimized.

Show comment
Hide comment
@jsalvatier

jsalvatier Feb 8, 2013

Contributor

We decided not to move ahead with this pull request and instead just added API support: #377

Contributor

jsalvatier commented Feb 8, 2013

We decided not to move ahead with this pull request and instead just added API support: #377

@jsalvatier jsalvatier closed this Feb 8, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment