Just to add to Gemma’s answer, without addressing all the valid points she raises, I would say we should ONLY allow the axis name and not the axis number. Allowing both will lead to ambiguity, additional overhead and be error prone.

 

As per the “Zen of Python” ( https://www.python.org/dev/peps/pep-0020/ )  “There should be one-- and preferably only one --obvious way to do it.”

 

For developers like us used to access numpy arrays, yes axis=0 seems initially simpler, but we cannot know that “horizontal_x” or whatever is always held at a certain index. The design choice we have made, and the intention is to make life simple for the user by not needing to worry about which index holds what, is to access data by its axis name.

 

The last point on whether to have a “Gradient” class at all, or allow FiniteDifference to work on multiple directions – in my view the latter is a very good idea. I support that for the following reasons:

-          We would have just a single finite-difference/derivative-type operator FiniteDifference. This makes life simpler because we would not need to explain to people what the difference between Gradient and FiniteDifference is. We also only need to maintain the documentation of the single file, rather than ensuring the two are aligned and tested against each other.

-          Technically the name Gradient may not be fully correct. There may be different conventions, but I would say “gradient” is normally considered defined for a scalar-valued function of multiple variables (https://en.wikipedia.org/wiki/Gradient). This is why we have “gradient” as a method inside our Function objects, since these are exactly scalar-valued functions of multiple variables, namely of all the pixels. This is in the discrete setting. In the continuous setting, yes we consider an image a scalar-valued function of say x and y variables. As such when applying Gradient I guess we really evaluate the image gradient in all of the different points on the grid, so it returns more of a collection of (finite-difference approximations of) gradients. In any case, using the name “gradient” for both Function object gradients and the block operators of finite differences may be confusing.

 

Jakob

 

 

The axis number can change, the data could be read in in a different-order or transposed by the user or by the code. The axes names’ move with them, so it’s good to use the axis name as the value as it will always mean the same thing to the user. Otherwise the user has to query dimension_labels to figure out the data-order before they use FD or resizer. I don’t have a problem with it taking the axis index too, but we would need to be consistent across the code and this adds some overhead to each function.

 

The name of the argument is something that needs unifying across the code. I think we currently have subset (which eventually will be aliased to slice and transpose) which takes ‘dimensions’ as an ordered list of axes names for the transpose, and key-worded arguments of the axis name and slice index so ‘vertical=0’ for sliceing.

 

I would be up for using that as the standard. ‘dimensions’  (or ‘axes’ if people prefer?) to specify a list to run over, which could take the axis name or the axis index. And key-worded arguments on axis names and values for slicing, cropping, binning etc. So Resizer could be aliased to crop and bin with bin(vertical=2, horizontal=2) and crop(vertical=(1,10)). This wouldn’t make sense to use the axis index however, I think we want to avoid slice(0=10).

 

It doesn’t seem often we restrict functions to a single axis only… I guess this is the conversation we started about having both FD and gradient. I don’t see why FD couldn’t take in more than one axis as an argument and construct a BlockOperator. So in your example FD(direction=[‘horizontal_x’, ‘vertical’]) could be valid.

 

Gemma

 

 

 

 

 

To unsubscribe from the CCPI-DEVEL list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCPI-DEVEL&A=1

This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses. Opinions, conclusions or other information in this message and attachments that are not related directly to UKRI business are solely those of the author and do not represent the views of UKRI.

 

To unsubscribe from the CCPI-DEVEL list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCPI-DEVEL&A=1