From -4048623240472634816 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,94e9c2bbb0060b48 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-07-31 04:46:20 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.alt.net!comp-std-cpp-robomod!not-for-mail From: John Nagle Newsgroups: comp.std.c++ Subject: Re: Proposals for small vectors? Date: 31 Jul 2002 11:35:18 GMT Organization: Prodigy Internet http://www.prodigy.com Lines: 57 Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: <3D475BF7.1060602@animats.com> References: <87wurryywb.fsf@grue.ucsd.edu> <3D38FB4F.1020909@animats.com> <3D3CB3C6.20106@animats.com> <23b84d65.0207301527.38062bdd@posting.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us X-Complaints-To: abuse@prodigy.net X-Trace: newssvr14.news.prodigy.com 1028086684 ST000 63.195.184.107 (Tue, 30 Jul 2002 23:38:04 EDT) NNTP-Posting-Date: Tue, 30 Jul 2002 23:38:04 EDT X-UserInfo1: TSUGW^_D\JUQB\D[NCOF_W\@PJ_^PBQLGPQRJWQHBATBTSUBYFWEAE[YJLYPIWKHTFCMZKVMB^[Z^DOBRVVMOSPFHNSYXVDIE@X\BUC@GTSX@DL^GKFFHQCCE\G[JJBMYDYIJCZM@AY]GNGPJD]YNNW\GSX^GSCKHA[]@CCB\[@LATPD\L@J\\PF]VR[QPJN Xref: archiver1.google.com comp.std.c++:12908 Allan W wrote: > John Nagle wrote > >> "valmatrix" would support N x M matrices, with >>the size defined at template instantiation. The >>underlying representation would be guaranteed to >>be a built-in array of the specified element type, >>and the underlying representation data would be >>accessable from the outside if needed. >>(There are many APIs in existence that use such >>a representation; this allows efficient C++ >>use or encapsulation of them.) >> >> Both row-major and column-major representations >>would be supported, again, determined at template >>instantiation time. (OpenGL and Direct-X use 4x4 >>matrices of different direction, so we must >>support both.) >> > > I'm worried that a less-than-careful implementation could cause > major code bloat. It might, but if there's a speed gain, that's considered a win in the graphics world. The real point here is that "valmatrix" would guarantee the underlying representation as a dense array of floats or doubles. That's the representation needed for OpenGL or Direct-X (although they're transposed from each other) and by mainstream graphics hardware. Lately, I've been raising various issues relevant to number-crunching in C++. Is there a special-interest group that's working on number-crunching issues for C++0x? The C community seems to be addressing number-crunching more aggressively than the C++ standards community (see C99 variable-length arrays), but there's no fundamental reason that C++ couldn't be as fast as C, if not faster. (It's certainly cleaner.) But it takes some work. Right now, a multitude of encapsulations of common number-crunching data objects tends to result in much copying and reformatting when multiple numeric libraries from different sources are brought together. That can and should be fixed. John Nagle Animats --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]