> Okay, but look at the syntactic support complex numbers needed. Just > "j". The same for string processing. We just reused most of the existing > operators. If you guys made a really kick-ass matrix package that > everyone loved and didn't need any new syntax, Guido might be tempted to > make matrices a built-in type also! Right, but I think that making a kick-ass matrix package without syntax modification is not possible... Indeed, what characterize the numeric languages around (e.g. matlab, octave, yorick, r-lab, ...) is precisely the presence of a syntax able to naturrally express linear algebra expression. All of them introduce easy matrix concatenation, multiplication, division and bloc-adressing...By the way, all matrix package are more or less cloning the matlab way, with minor differences (except for yorick, which have a more general syntax able to deal with multidimensional arrays cleanly, but probably make things less easy with 2D matrix). I think that such convergence comes probably from the fact that the Matlab way is the good way for numeric stuff... > The funny thing is that most of the Python syntax that I don't use today > is ALREADY for matrix operations: > > foo[x,y:a,b] > foo()[...] This is inevitable, I agree that numeric stuff is completely off-topic for a lot of peoples...But unicode support is also an excess-feature for numerical code. Of course, when you write something which must compute linear regressions and you want to ask input to a user which only speek japanese...In fact, what attracts me in Python the first time I've heard of it (3 weeks ago, so do not take my words too seriously...) is that it seems to be able to do numeric stuff quite well, except for matrix...the Python+NumPy package improve that, but not to the point of beeing matlab-like. Python+NumPy+MatPy is better in that sense, but still lack some operators to be THE solution...I tried to implement those operators as a way to check how python is extensible (a must, as the intended use of this - or anoteher numeric language) is to serve as command tools for c++ Finite element software, and I was surprise how easy it was...So here they are! I do not really see a problem in adding new operators, except when - it slows down the old ones, and I do not think it could be noticed in the present case...more ifs in the source code is certainly not something to worry about... - it makes python code unintelligible, and this is not relevant either: No numeric -> do not use them, but if you do numeric stuff, everything becomes clearer. - it makes python source more complex: true, but so little than I think it makes no practical difference. It is really a small change, after all I was able to implement it in a matter of day after looking for the fist time in the code...Arguably, this change is of the same order of magnitude as the 1.0j stuff...perhaps smaller - It is a hole which will unleash the craziest operators , and makes python look like binary with expressions soup like k=(a*$$^b)%/(@~c): That's the only risk I would be affraid of, but as already mentioned, linear algebra is a well established field , used almost everywhere in numerics and we have a bunch of languages which already support these kind of operators...
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4