[Bf-committers] Change Representation and Initialisation of Matrices to Conform with Standard Notation

Campbell Barton ideasman42 at gmail.com
Tue Dec 27 03:22:36 CET 2011 

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 <mikkelsen7 at gmail.com> 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 <ideasman42 at gmail.com>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 <trumanblending at gmail.com>
>> 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 <ideasman42 at gmail.com
>> >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 <trumanblending at gmail.com>
>> >> 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
>> >> > <domino at dominodesigns.info>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
>> >> >> Bf-committers at blender.org
>> >> >> http://lists.blender.org/mailman/listinfo/bf-committers
>> >> >>
>> >> > _______________________________________________
>> >> > Bf-committers mailing list
>> >> > Bf-committers at blender.org
>> >> > http://lists.blender.org/mailman/listinfo/bf-committers
>> >>
>> >>
>> >>
>> >> --
>> >> - Campbell
>> >> _______________________________________________
>> >> Bf-committers mailing list
>> >> Bf-committers at blender.org
>> >> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>
>> > _______________________________________________
>> > Bf-committers mailing list
>> > Bf-committers at blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-committers
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



-- 
- Campbell

More information about the Bf-committers mailing list