Sven Schreiber wrote:
> Tim Hochberg schrieb:
>
>
>>>> -) .I for inverse; actually, why not add that to arrays as well as
>>>> "syntactic sugar"?
>>>>
>>>>
>>>>
>>> Because it encourages people to do the wrong thing numerically speaking?
>>> My understanding is that one almost never wants to compute the inverse
>>> directly, at least not if you're subsequently going to multiply it with
>>> something, instead you want to use linalg.solve or some other similar
>>> approach.
>>>
>>>
>> Also, having an attribute access do an expensive operation behind the
>> scenes seems antisocial.
>>
>
> Ok, you (and Bill) may have a point there. (Although I'm not sure it's
> the best way to educate naive users like me about numerical efficiency
> by making inverse harder to access. Otherwise you should rename
> linalg.inv --way too easy!-- to
> linalg.okay_im_going_to_compute_the_inverse_for_you_but_its_probably_a_stupid_thing_to_do()
> ;-)
>
> However, then why is it possible for matrices?? It's just seems
> incoherent to me.
>
Because matrix users asked for it I imagine. Since I don't use the
matrix, I certainly wouldn't have objected. Also, the matrix class is
supposed to look a lot like matlab and I assume matlab has some trivial
way to produce an inverse -- even if it is a bad idea.
> Maybe you guys as the developers of numpy should really make up your
> mind about the future of matrices in numpy. Either it's supported, then
> eventually I would expect matrix versions of ones, zeros, eye, for
> example. (Although eye().M would come close enough I guess.) Or you
> decide that you don't really like all the problems that it implies and
> officially declare it unsupported.
> That would be valuable information for users like me who have had (and
> still sometimes have) a hard time figuring out whether I should be using
> arrays or matrices.
>
Well, the matrix class could use a champion I think. Preferably someone
who does a lot of matrix work and is capable of doing some development
on it, at least on the python end. Without that I imagine it will stay
kind of incoherent.
>
>
>>>
>>>
>>>> -) * being the matrix product instead of element-wise; Now, I could live
>>>> with using dot and I don't want to push anything, but maybe this is the
>>>> right time to consider another operator symbol as a shortcut for the dot
>>>> function to be used with arrays? (Unfortunately right now I can't think
>>>> of any sensible character(s) for that...)
>>>>
>>>>
>> 2. Backwards compatibility.
>>
>
> I meant a *new* operator symbol.
>
Oh. Well, we're kind of short on those at the moment. The only thing I
know of that would work is to abuse the call operator, thus
dot(A, B) <=> (A)(B)
That's kind of weird though and it's never gotten much support.
>
>> Curmudgeonly yours,
>>
A curmudgeon is an old, cranky, stubborn fixed in his ways kind of person.
>>
> Well I don't know what that means, so here's my hopefully equally
> incomprehensible reaction:
> Mit freundlichen Grüßen,
>
With great (big? much?) friendship (friendliness?)?
-tim
> Sven
>
>
>
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Numpy-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
