opticspy / lightpipes

LightPipes for Python, "Pure Python version"
https://opticspy.github.io/lightpipes/
BSD 3-Clause "New" or "Revised" License
227 stars 52 forks source link

Inconsistent definitions of waist w and xshift #51

Open jmmelko opened 3 years ago

jmmelko commented 3 years ago

I love Lightpipes but there are still a few inconsistencies in parameters definitions, some of them going beyond mere cosmetical problems.

Besides, I may we wrong, but to be more Pythonic I would suggest to override the len() function for Field objects so that len() returns .siz

ldoyle commented 3 years ago

Dear jmmelko, thanks for your feedback. Regarding the GaussBeam, you are right, it seems x_shift/y_shift are the better choice. Maybe Fred or I can update this in the coming week or so (feel free to change yourself and create a Pull Request, best try to keep it backward compatible by optionally probing for xshift/yshift in the kwargs)

@FredvanGoor regarding the w of the plane wave, I agree D/d or R/r would be more instructive. Since most other functions are defined via some radius, this would be better here, too. However, that would change the behaviour of existing code. It seems the function is fairly recent (introduced in 2.0), so do you think we can risk the change?

Regarding the Field, your other Git Issue is absolutely right it should be documented better, however I'm not sure about adding pythonic gimmicks to the field. It acts more like a container for the parameters grid size, lambda,... and the actual complex field data (Field.field which is a numpy array having all the nice capabilities like .size,.shape and so on). If documented better, this seems sufficient to me.

jmmelko commented 3 years ago

Ok, I’ll do that.

I fail to grasp what would be the risk of changing the PlaneWave parameter: backward compatibility or misuse? It is already confusing as it is.