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

Morten Mikkelsen mikkelsen7 at gmail.com
Mon Dec 19 01:28:24 CET 2011 

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
>

More information about the Bf-committers mailing list