Discussed this with Andrew and Benoit further, From their feedback I gather row-major is the convention with math libs, so I propose to go ahead with this within the next 2 weeks.
Rationale & general comments (re-iterating whats been said somewhat)... - Either way can be rationalized - depending on how strongly you want to draw between python `mathutils` and OpenGL (or CG convention in general), its a valid point but python devs are not coding OpenGL typically. - Docs that discuss this issue for C/C++ apis I think don't really apply IMHO, (panda3d doc for example). since the internal layout and what is passed to OpenGL/DirectX need to be consistent in those cases. - Row major fits in with numpy - a popular python math module which has some overlap with mathutils and some script devs are already using with blender. - Will add a better __str__ function for matrix types which isn't so confusing (this was needed anyway). Regarding the change, - Will update existing scripts in SVN - Will add docs describing the difference between mathutils & opengl ordering. -- - Campbell On Thu, Dec 15, 2011 at 10:15 PM, Andrew Hale <[email protected]> wrote: > Hi all, > > With the controlled chaos of the release (and what a release!) dying down, > I felt I should write again to more succinctly express the issue as I see > it: > > The issue here is not how we index arrays internally (i.e. in C) as this > has concerns around the layout in memory etc. The issue is that once we > expose this data to the user via Python, we currently break the extremely > well established mathematical convention of indexing the row first. This is > where my concern lies. Since we translate from C to a Python matrix > already, it is a relatively simple change to maintain the mathematical > convention of row first indexing. > > I do not know of another major mathematical package which indexes by column > first; Mathematica, GNU Octave, MatLab, Fortran and Numpy all use row first > indexing. It is also the case that Fortran, GNU Octave and MatLab use > column major storage for their matrices but maintain the mathematical > convention of row first indexing. > > Thanks again, > Andrew > > On Sat, Dec 10, 2011 at 9:05 AM, Campbell Barton <[email protected]>wrote: > >> Changes to the __repr__ function should evaluate, since this is common >> practice, >> see: http://docs.python.org/py3k/library/functions.html#repr >> >> currently mathutils and bpy do this where possible, eg. >> >> >>> Euler() >> Euler((0.0, 0.0, 0.0), 'XYZ') >> >> >>> bpy.context.object >> bpy.data.objects['Armature'] >> >> # note how str does _not_ always do this, though for mathutils we only >> have repr at the moment. >> >>> print(bpy.context.object) >> '<bpy_struct, Object("Armature")>' >> >> >> If we want a better way to represent mathutils data, I'd prefer to use >> __str__, or add a method that returns a pretty formatted matrix. >> >> Another reason this would be nice is repr on floats gives hard to read >> results sometimes, a custom printing function can give aligned columns >> without too many decimal places, same goes for vectors and other >> types. >> eg: >> >> Matrix(((1.0, 3.142857074737549, 0.0, 0.0), >> (0.0, 1.0, 0.0, 1.0000000195414814e-24), >> (0.0, 0.0, 1.0, 0.0), >> (3.1415927410125732, 0.0, 0.0, 1.0))) >> >> a str could display this in a more humanly readable way - something like.. >> >> http://pastie.org/2993250 >> --- >> <Matrix [1.0, 0.0, 0.0, 3.1415], >> [3.1428, 1.0, 100001.0, 0.0 ], >> [0.0, 0.0, 1.0, 0.0 ], >> [0.0, 1.0, 0.0, 1.0 ] >> > >> --- >> >> The main annoyance of this is that script authors will need to know >> that str(matrix) gives a different result to repr(matrix), but we can >> document it so don't think its too bad. >> print(matrix), uses str(), so its mainly the console where devs will >> see the repr output by default. >> >> I don't think we'll get much resistance to having humanly readable >> __str__ output, the functionality is fairly easy to add and this kind >> of change can be made at any time, so I rather keep this discussion >> focused on changing behavior of the api. >> >> On Sat, Dec 10, 2011 at 2:01 AM, Andrew Hale <[email protected]> >> wrote: >> > Perhaps we could consider this as two separate proposals; >> > >> > 1. Change the repr function for matrices so that they print columns as >> > columns. >> > 2. Change how Python gets/sets data from C so that matrices in Python >> > maintain the standard math notation of matrix[row][column] >> > >> > The first should not effect any scripts as it only relates to printing in >> > the console but should hopefully decrease confusion with users. The >> second >> > will break compatibility for some scripts and so will require more >> > discussion. >> > >> > Thanks, >> > Andrew >> > >> > On Sat, Dec 10, 2011 at 12:27 AM, Domino Marama >> > <[email protected]>wrote: >> > >> >> On Fri, 2011-12-09 at 23:57 +1100, Andrew Hale wrote: >> >> > Also, note that MatLab stores arrays in column major format but still >> >> uses >> >> > matrix[row, column] for indexing entries. >> >> >> >> numpy also uses row, column indexing >> >> >> >> http://docs.scipy.org/doc/numpy/reference/generated/numpy.matrix.html >> >> >> >> >>> import numpy >> >> >>> m = numpy.matrix("1 2; 3 4; 5 6") >> >> >>> m >> >> matrix([[1, 2], >> >> [3, 4], >> >> [5, 6]]) >> >> >>> m[0] >> >> matrix([[1, 2]]) >> >> >>> m[0,1] >> >> 2 >> >> >> >> This is the order I'd expect for any matrix implementation without >> >> reading any docs too.. >> >> >> >> >> >> _______________________________________________ >> >> Bf-committers mailing list >> >> [email protected] >> >> http://lists.blender.org/mailman/listinfo/bf-committers >> >> >> > _______________________________________________ >> > Bf-committers mailing list >> > [email protected] >> > http://lists.blender.org/mailman/listinfo/bf-committers >> >> >> >> -- >> - Campbell >> _______________________________________________ >> Bf-committers mailing list >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers >> > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
