I am sorry I am a little late to the party but just thought I'd air my opinion.
So since the order was fixed in blender's C code we now have what in math sense is a clear column major order ie. read from right to left. Thus translation for instance is the 4. column of a matrix and the vectors we transform are column vectors. In C terminology the translation is of course not the fourth column but the fourth row. The C terminology of course relates to the memory layout of a doubly indexed array (in C). Given that python is a high level language and memory layout is not exposed for a double indexed array (not a python programmer :)? it would imo make the most sense to use the mathematical interpretation of what a column is and then when a user asks for say the fourth column he'd get entries (in memory) 12, 13, 14 and 15 which is our translation/offset. I think adhering to the mathematical interpretation is more useful from python level than C memory layout of a doubly indexed array. This is my opinion. Cheers, Morten. On Sun, Dec 18, 2011 at 4:07 PM, Campbell Barton <[email protected]>wrote: > 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 > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
