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

Campbell Barton ideasman42 at gmail.com
Mon Dec 19 01:07:50 CET 2011 

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

More information about the Bf-committers mailing list