[Python-ideas] matrix operations on dict :)
julien at tayon.net
Wed Feb 8 13:12:32 CET 2012
> Why would you want to use a hash table (Python dict) for linear algebra?
* Because it naturally provides matrix. And matrix are an easy way to
formalize and standardize tree manipulations which are a growing
concern in real life computer craft.
* Because actual CS is precise but not exact, and that metrics on
objects enable more exact comparison :
== is the actual way to compare it is precise
, but metrics (cos, norm, dot) enable
is_close_to( Value , modulo error )
For instance no actual langage can tell if two floats are equal,
because, there are error margins.
pi != 3.14159
pi is close to 3.1 [+-.05]
Exactitude and precision are not the same.
> Not sure I can think of a worse datastructure for the purpose.
Well, it is the other way round.
The least surprise principle is that + - * / behave the way it usually
does 90% of the time
at my very personnal opinion, mathematical signs should have been
reserved in all langages to operation analog to mathematics. And
linear algebrae is one of the most accpeted behaviour for these
Since there are more than one way to add / mul / div /sub, at my very
own opinion every and each class defining these signs *should* tell
which arithmetics they supports, so that we can predict the behaviour
of the composition of these operations and conflicts.
We have same symbols, with different meaning, it is a degenerescence
that should disambiguized(? not sure of the orthograph). For instance
in order to raise inconsistency exceptions.
> There are NumPy...
> And in the standard library there is an array module...
Which at the opposite of list() supports + - * / in the algebraic sense.
> For matrix multiplication you can use DGEMM from any LAPACK library if you
> don't like NumPy (e.g. by means of ctypes).
It is stupid to code matrix with an hash, I just say as there is a
strong analogy between dict and vectors, as a result matrix that
operates on dict exists and I can give them a meaning of transforming
rooted trees in rooted trees.
> What really should be discussed is inclusion of NumPy in the standard
> library (that is NumPy, not SciPy).
+1 for the inclusion of numpy in stdlib :)
Even though I think it would need a little syntaxic sugar to make it
More information about the Python-ideas