To follow up on this topic, Andrews patch has been committed, and I've added a 'col' attribute for scripts that still need column access still,
2.61: mat[2] = 1, 2, 3 2.62: mat.col[2] = 1, 2, 3 See: http://wiki.blender.org/index.php/User:TrumanBlending/Matrix_Indexing#Cheat_Sheet Scripts in trunk are all be up to date, some addons still need updating, On Mon, Dec 19, 2011 at 11:28 AM, Morten Mikkelsen <[email protected]> wrote: > 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 -- - Campbell _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
