[Bf-committers] Change Representation and Initialisation of Matrices to Conform with Standard Notation
trumanblending at gmail.com
Thu Dec 15 12:15:35 CET 2011
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
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.
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
> 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
> # 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
> 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..
> <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>
> > 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
> > 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
> >> 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
More information about the Bf-committers