Re: Architecture question
Douglas Aberdeen <[email protected]> Wed, 8 Mar 2006 09:05:14 +1100
| Newsgroups | gmane.comp.lib.mtl.devel |
|---|---|
| Message-ID | <[email protected]> |
Thanks for the quick reply Peter, Everything you say makes sense. I'll look forward to seeing v4 :) On 08/03/2006, at 2:35 AM, Peter Gottschling wrote: > Dear Douglas, > > Thank you for your interest in MTL and your suggestions. > > On Mar 6, 2006, at 9:19 PM, Douglas Aberdeen wrote: > >> Dear MTL developers, >> >> I've recently come across MTL and I'm starting to use it. It seems to >> be the only c++ matrix package that handles sparse and dense >> matricies in a fairly uniform way, with basic linear algebra >> supported seemlessly between matrix formats. So thank you! >> >> There seem to be a couple of obvious things missing and I'm wondering >> if the architecture of MTL makes them bad, or if they are just things >> that the developers haven't gotten to? >> >> In short, I find it weird to call routines like >> set_value(A, val); >> print_vector(x); >> print_all_matrix(A); >> copy(A, B); >> It seems more intuitive (and notationally neater when using pointers >> to objects) to use >> A.set_value(val) > > Member functions are less flexible than free functions in their > interplay. Other than that for given data types it is favorable to > add a free function instead of writing a wrapper to introduce more > member functions (and later a wrapper of the wrapper ... ). > >> cout<<x; >> cout<<A; > > Agreed. > >> B = A.copy() >> > What should be the type of 'A.copy()' ? And where should it be > stored? Anyway, there will be B = A which deals with conversion and > other issues. Operator notation has often the problem of requiring > temporary variables to store intermediate results. We will deal with > this in terms of expression templates (which in turn might induce > compile time overhead). >> I understand the dangers of operator overloading in a matrix context, >> but things like stream operators should be okay? >> >> I'm also wondering whether development is still active since the last >> sign of activity was a gcc 4.0 compliant version more than 6 months >> ago? > > Yes, it is. But as we completely redesigned MTL, it takes some time. > > Best Regards > > Peter >> >> -- >> Dr Douglas Aberdeen >> Senior Researcher >> Statistical Machine Learning >> >> >> National ICT Australia Limited >> Locked Bag 8001 >> Canberra ACT 2601 >> Tel. +61 2 6125 8647 >> Fax. +61 2 6125 8645 >> Email. [email protected] >> Web. www.nicta.com.au >> >> The imagination driving Australia's ICT future. >> >> To receive the latest NICTA information register at http:// >> nicta.com.au/registration.cfm >> >> >> _______________________________________________ >> This list is archived at http://www.osl.iu.edu/MailArchives/mtl- >> devel/ > > ------------ > Peter Gottschling > Research Associate > Open Systems Laboratory > Indiana University > 301i Lindley Hall > Bloomington, IN 47405 > Tel.: +1 812 855-8898 Fax: +1 812 856 0853 > http://www.osl.iu.edu/~pgottsch > > > _______________________________________________ > This list is archived at http://www.osl.iu.edu/MailArchives/mtl-devel/ -- Dr Douglas Aberdeen Senior Researcher Statistical Machine Learning National ICT Australia Limited Locked Bag 8001 Canberra ACT 2601 Tel. +61 2 6125 8647 Fax. +61 2 6125 8645 Email. [email protected] Web. www.nicta.com.au The imagination driving Australia's ICT future. To receive the latest NICTA information register at http:// nicta.com.au/registration.cfm _______________________________________________ This list is archived at http://www.osl.iu.edu/MailArchives/mtl-devel/