You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(4) |
Dec
(6) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(68) |
Feb
(72) |
Mar
(46) |
Apr
(44) |
May
(40) |
Jun
(54) |
Jul
(26) |
Aug
(86) |
Sep
(95) |
Oct
(151) |
Nov
(65) |
Dec
(34) |
2003 |
Jan
(22) |
Feb
(70) |
Mar
(24) |
Apr
(28) |
May
(50) |
Jun
(31) |
Jul
(17) |
Aug
(42) |
Sep
(27) |
Oct
(71) |
Nov
(27) |
Dec
(71) |
2004 |
Jan
(40) |
Feb
(30) |
Mar
(20) |
Apr
(22) |
May
(41) |
Jun
(9) |
Jul
(24) |
Aug
(41) |
Sep
(35) |
Oct
(8) |
Nov
(5) |
Dec
(4) |
2005 |
Jan
(27) |
Feb
(13) |
Mar
(18) |
Apr
(7) |
May
(10) |
Jun
(36) |
Jul
(28) |
Aug
(17) |
Sep
(1) |
Oct
(11) |
Nov
(12) |
Dec
(15) |
2006 |
Jan
(99) |
Feb
(5) |
Mar
(31) |
Apr
(26) |
May
(20) |
Jun
(33) |
Jul
(45) |
Aug
(18) |
Sep
(2) |
Oct
(19) |
Nov
(3) |
Dec
(8) |
2007 |
Jan
(1) |
Feb
(15) |
Mar
(20) |
Apr
|
May
(4) |
Jun
(6) |
Jul
(11) |
Aug
(11) |
Sep
(11) |
Oct
(19) |
Nov
(25) |
Dec
(46) |
2008 |
Jan
(42) |
Feb
(20) |
Mar
(43) |
Apr
(24) |
May
(4) |
Jun
|
Jul
(19) |
Aug
(63) |
Sep
(33) |
Oct
(17) |
Nov
(36) |
Dec
(20) |
2009 |
Jan
(36) |
Feb
(18) |
Mar
(144) |
Apr
(36) |
May
(11) |
Jun
(7) |
Jul
(8) |
Aug
(21) |
Sep
(33) |
Oct
(7) |
Nov
(2) |
Dec
(1) |
2010 |
Jan
(33) |
Feb
(3) |
Mar
(34) |
Apr
(2) |
May
(1) |
Jun
(2) |
Jul
(3) |
Aug
(28) |
Sep
(8) |
Oct
(12) |
Nov
(11) |
Dec
(44) |
2011 |
Jan
(30) |
Feb
(10) |
Mar
(8) |
Apr
(23) |
May
(8) |
Jun
(9) |
Jul
(3) |
Aug
(9) |
Sep
(5) |
Oct
(9) |
Nov
(11) |
Dec
(24) |
2012 |
Jan
(6) |
Feb
(32) |
Mar
(8) |
Apr
(26) |
May
(13) |
Jun
(51) |
Jul
(21) |
Aug
(7) |
Sep
(9) |
Oct
(13) |
Nov
(5) |
Dec
(10) |
2013 |
Jan
(56) |
Feb
(6) |
Mar
(15) |
Apr
(4) |
May
(24) |
Jun
(4) |
Jul
(9) |
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
(8) |
2014 |
Jan
(7) |
Feb
|
Mar
|
Apr
|
May
(12) |
Jun
(3) |
Jul
(7) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(19) |
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(22) |
Dec
(25) |
2016 |
Jan
(9) |
Feb
(9) |
Mar
(13) |
Apr
|
May
|
Jun
(2) |
Jul
(4) |
Aug
|
Sep
|
Oct
(11) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: William A. H. <bil...@ny...> - 2002-02-18 18:36:09
|
I did some google searching and I think I found a way to avoid the problem. It would seem that it will be OK to keep the dash's. You have to double quote each file name... (not in the manual, but found it on google groups.) -Bill At 05:40 PM 2/18/2002 +0000, Andrew Fitzgibbon wrote: >> > One nice thing is that this is in the Template directory. >> > No makefiles will have to be changed, just the file names. >> >> The disadvantage is that people will have to remember not to >> give their files a name with a dash in it. >> >> I prefer a borland-specific solution which avoids future problems. > >I know, and I love the dash, and hate the underscore; but I think >we've learned over the last several years that lowest-common-denominator >is the only way to be really sure of portability. I'd say we have >to replace our (many) dash-separated filenames with underscores. >I hate it, so I would like to be sure as possible that borland can't >be hacked to overcome it, but I still think that the only thing to do >is remove the dashes. > >A. > > >_______________________________________________ >Vxl-maintainers mailing list >Vxl...@li... >https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Amitha P. <pe...@cs...> - 2002-02-18 18:31:32
|
I agree with Bill and Andrew. The files in Templates are really a hack because compilers don't support export templates, etc. In an ideal world, we wouldn't need the Templates directory at all. It contains stuff that could, in principle, be machine generated. Often, a-b+.cxx contains nothing more than template class a<b>; While I am surprised that Borland breaks on a dash in the filename, I don't think the dash is so vital that we should sacrifice the Borland compiler. Yes, you could do all sorts of scripting and other magic to fix it, but that leaves open situations like shared source builds and non-CMake build environments. The current naming scheme is clear and easy to read, but I'll argue that a small loss in clarity in essentially machine generated code is a small price to pay for supporting another (good) compiler. Amitha. |
From: Andrew F. <aw...@ro...> - 2002-02-18 17:40:55
|
> > One nice thing is that this is in the Template directory. > > No makefiles will have to be changed, just the file names. > > The disadvantage is that people will have to remember not to > give their files a name with a dash in it. > > I prefer a borland-specific solution which avoids future problems. I know, and I love the dash, and hate the underscore; but I think we've learned over the last several years that lowest-common-denominator is the only way to be really sure of portability. I'd say we have to replace our (many) dash-separated filenames with underscores. I hate it, so I would like to be sure as possible that borland can't be hacked to overcome it, but I still think that the only thing to do is remove the dashes. A. |
From: <Pet...@es...> - 2002-02-18 17:30:41
|
> So, when a user does a cvs update, they have to run the script. When using CMake, the `script' is automatically run since it is just a build rule. > Also, the script would have to remove the real files, as the template > directories are compiled with *.cxx. Again, this is a CMake issue: it's up to CMake to include *.cxx files from the Templates directory or not. Peter. |
From: <Pet...@es...> - 2002-02-18 17:27:30
|
> One nice thing is that this is in the Template directory. > No makefiles will have to be changed, just the file names. The disadvantage is that people will have to remember not to give their files a name with a dash in it. I prefer a borland-specific solution which avoids future problems. Peter. |
From: William A. H. <bil...@ny...> - 2002-02-18 16:51:51
|
One nice thing is that this is in the Template directory. No makefiles will have to be changed, just the file names. -Bill At 04:48 PM 2/18/2002 +0000, Andrew Fitzgibbon wrote: >> So, when a user does a cvs update, they have to run the script. >> Also, the script would have to remove the real files, as the template >> directories are compiled with *.cxx. I think the only real solution >> is to rename the files in cvs and be done with it. > >Agreed [-e 's/rename the files/make new files and attic the old ones/' >of course]. > >A. > > >_______________________________________________ >Vxl-maintainers mailing list >Vxl...@li... >https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Andrew F. <aw...@ro...> - 2002-02-18 16:48:45
|
> So, when a user does a cvs update, they have to run the script. > Also, the script would have to remove the real files, as the template > directories are compiled with *.cxx. I think the only real solution > is to rename the files in cvs and be done with it. Agreed [-e 's/rename the files/make new files and attic the old ones/' of course]. A. |
From: William A. H. <bil...@ny...> - 2002-02-18 16:37:42
|
So, when a user does a cvs update, they have to run the script. Also, the script would have to remove the real files, as the template directories are compiled with *.cxx. I think the only real solution is to rename the files in cvs and be done with it. -Bill At 03:40 PM 2/18/2002 +0100, Pet...@es... wrote: >> So, if the borland compiler is to ever be supported, the template file >> names must be changed. > >The easiest solution would be to add a (small) install script that renames >(or copies) files containing a dash (or any invalid character) to one without. > >Something in the following style (gnu make syntax) -- needs some elaboration: > >BORLAND_SOURCES = $(subst -,_,$(SOURCES)) > >$(subst -,_,$(SOURCE_FILE_1)): $(SOURCE_FILE_1) > cp $< $@ > > > Peter. > >_______________________________________________ >Vxl-maintainers mailing list >Vxl...@li... >https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Rittscher, J. (CRD) <rit...@cr...> - 2002-02-18 15:41:14
|
Hi, currently I am trying to build vxl with shared libraries. So far it looks like vxl is not set up to produce dll's. There seem to be the following options: - produce .def files like it was done in TargetJr (at the moment I don't know how one does this using cmake) - work with __declspec(dellexport) __declspec(dellimport) This is how the problem is solved in vtk. They basically define a macro which is then used in every class definition. When working on other platforms the macro is left blank. It would be great if someone has already solved the problem or has any suggestions, Jens |
From: <Pet...@es...> - 2002-02-18 14:40:56
|
> So, if the borland compiler is to ever be supported, the template file > names must be changed. The easiest solution would be to add a (small) install script that renames (or copies) files containing a dash (or any invalid character) to one without. Something in the following style (gnu make syntax) -- needs some elaboration: BORLAND_SOURCES = $(subst -,_,$(SOURCES)) $(subst -,_,$(SOURCE_FILE_1)): $(SOURCE_FILE_1) cp $< $@ Peter. |
From: William A. H. <bil...@ny...> - 2002-02-18 14:18:42
|
So, if the borland compiler is to ever be supported, the template file names must be changed. -Bill At 10:42 AM 2/15/2002 -0500, William A. Hoffman wrote: >Yes. > >$ tlib /a foobar.lib foo-bar.obj >TLIB 4.5 Copyright (c) 1987, 1999 Inprise Corporation >Warning: 'foo.OBJ' file not found >Warning: 'bar' not found in library > >There is no way to escape the dash or plus. > > >-Bill > > >At 03:55 PM 2/15/2002 +0100, Peter Vanroose wrote: >>> There is a larger borland problem that is a bit more of a show stopper. >>> The names of the template files with the + and - stuff in the names confuse the >>> linker that uses those as separators and special symbols. >> >>Does that mean Borland-C cannot work with files that have dashes in their name? >> >> >> Peter. >> >> >>_______________________________________________ >>Vxl-maintainers mailing list >>Vxl...@li... >>https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > > > >_______________________________________________ >Vxl-maintainers mailing list >Vxl...@li... >https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: William A. H. <bil...@ki...> - 2002-02-15 15:47:26
|
Yes. $ tlib /a foobar.lib foo-bar.obj TLIB 4.5 Copyright (c) 1987, 1999 Inprise Corporation Warning: 'foo.OBJ' file not found Warning: 'bar' not found in library There is no way to escape the dash or plus. -Bill At 03:55 PM 2/15/2002 +0100, Peter Vanroose wrote: > > There is a larger borland problem that is a bit more of a show stopper. > > The names of the template files with the + and - stuff in the names > confuse the > > linker that uses those as separators and special symbols. > >Does that mean Borland-C cannot work with files that have dashes in their >name? > > > Peter. > > >_______________________________________________ >Vxl-maintainers mailing list >Vxl...@li... >https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Peter V. <Pet...@es...> - 2002-02-15 14:55:52
|
> There is a larger borland problem that is a bit more of a show stopper. > The names of the template files with the + and - stuff in the names confuse the > linker that uses those as separators and special symbols. Does that mean Borland-C cannot work with files that have dashes in their name? Peter. |
From: William A. H. <bil...@ki...> - 2002-02-15 14:43:07
|
There is a larger borland problem that is a bit more of a show stopper. The names of the template files with the + and - stuff in the names confuse the linker that uses those as separators and special symbols. -Bill At 03:35 PM 2/15/2002 +0100, Peter Vanroose wrote: > > template <class T, class S> > > void vnl_c_vector_rms_norm(T const *p, unsigned n, S *out) > > { > > vnl_c_vector_two_norm_squared(p, n, out); > > *out /= n; > > typedef typename vnl_numeric_traits<S>::real_t real_t; > > *out = (S)(vcl_sqrt(real_t(*out))); // trouble is here > > } > >Try replacing that last line with > > *out = S(vcl_sqrt(real_t(*out))); > > >Probably, > (vnl_rational)(x) >with x of type double is not seen as an "explicit" call of the "double" >constructor, while > vnl_rational(x) >is. (It is used that way a few lines further down.) > > > Peter. > > >_______________________________________________ >Vxl-maintainers mailing list >Vxl...@li... >https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Ian S. <ian...@st...> - 2002-02-15 14:39:15
|
Perhaps the list of functions for any generic numeric vector should be the list of functions that vnl_vector currently supports minus some of the constructors. Some of the other things could be removed for conciseness, however lots of algorithms that you might wish to generalise will expect to see many of the current members of vnl_vector. > -----Original Message----- > From: William A. Hoffman [mailto:bil...@ki...] > Sent: Thursday, February 14, 2002 6:56 PM > To: Paul Smyth > Cc: 'vxl...@li...' > Subject: RE: [Vxl-maintainers] VNL speed of C?? > > > I would argue that it should be done more generically, and > more like stl. > A vector would only need to have the interface: > > T& operator[](int) > T& get(int); > int size(); > > It would not have a T* as that adds an extra 4 bytes to the > fixed version > that it does not need. > Also a virtual function adds to the size of the object. > > Also, some of the operators might be better implemented with > functions: > > vnl_mult_vec(v1, v2, vresult); > > That way people could use these functions in inner loops without > constructors being called. > Right now "new" is called for most vector and matrix > operations which can > be very inefficient. > > -Bill > > > At 06:06 PM 2/14/2002 +0000, Paul Smyth wrote: > >Here's a go... > > > >Arguably there are a few basic properties of vectors > >1) a T* (data) pointing to the first element > >2) a size(), indicating the number of elements, which may be > dynamic or > >static, depending on whether the size is known at compile time > >3) some storage, which may be dynamic or static > > > >I reckon that something like this might be appropriate: > > > > vector_ref > >(has T* data, size() member fn - this would need to be > virtual or have a > >size_ member variable. > >No resize() member fn) > > > > | \ > > | ------------------------------------ > > vector_fixed_ref | > >(has T* data, static size - an enum?) vector_dynamic > > | (has dynamic > storage, resize() > >member) > > | > > vector_fixed > >(has C-array storage plus above) > > > >Operators might be: > >vector_dynamic operator+(const vector_ref&, const vector_ref&); > >vector_fixed operator+(const vector_fixed_ref&, const > vector_fixed_ref&); > >(Obviously you cannot return an object by value that doesn't > own its own > >memory). > > > >Hope this isn't complete rubbish. > >Paul. > > > >-----Original Message----- > >From: William A. Hoffman [mailto:bil...@ki...] > >Sent: Thursday, February 14, 2002 4:33 PM > >To: vxl...@li... > >Subject: [Vxl-maintainers] VNL speed of C?? > > > > > >I know I brought this up several years ago, but I was > wondering if anyone > >has thought about > >this problem. The vnl vector hierarchy is upside down. > vnl_vector should > >inherit from vnl_vector_fixed. > >The problem is that vnl_vector_fixed has 8 extra bytes of > memory. Also all > >the operators +, * , etc call > >new even on the fixed versions of things. This has caused several > >projects to give up on using the vnl_vector > >classes and use hand coded arrays. > > > >-Bill > > > > > > > > > >_______________________________________________ > >Vxl-maintainers mailing list > >Vxl...@li... > >https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > > > >This e-mail, and any attachment, is confidential. If you > have received it in > >error, please delete it from your system, do not use or disclose the > >information in any way, and notify me immediately. > > > >_______________________________________________ > >Vxl-maintainers mailing list > >Vxl...@li... > >https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > > > > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Peter V. <Pet...@es...> - 2002-02-15 14:35:24
|
> template <class T, class S> > void vnl_c_vector_rms_norm(T const *p, unsigned n, S *out) > { > vnl_c_vector_two_norm_squared(p, n, out); > *out /= n; > typedef typename vnl_numeric_traits<S>::real_t real_t; > *out = (S)(vcl_sqrt(real_t(*out))); // trouble is here > } Try replacing that last line with *out = S(vcl_sqrt(real_t(*out))); Probably, (vnl_rational)(x) with x of type double is not seen as an "explicit" call of the "double" constructor, while vnl_rational(x) is. (It is used that way a few lines further down.) Peter. |
From: William A. H. <bil...@ki...> - 2002-02-15 14:08:16
|
1. Yes, for example for 3d vectors the overhead is 66% larger memory size than it should be. If you had a million of them, it is quite a bit. 2. I agree that size should be inline. 3. It does seem that vector_fixed has been fixed, but the same thing has not been done with matrix_fixed. Given that all the operators are duplicated now anyway, then going to a more generic interface might not be as painful. The big change would be the algo stuff. This : template <class T> vnl_svd<T>::vnl_svd(vnl_matrix<T> const& M, double zero_out_tol): m_(M.rows()), would have to be this: template <class MatrixType> vnl_svd<T>::vnl_svd(MatrixType const& M, double zero_out_tol): m_(M.rows()), .... MatrixType would be either fixed or dynamic and it would require a certain interface. (a size function, rows, cols, etc) I think it can be done so that no user code can be changed. -Bill At 10:44 AM 2/15/2002 +0000, Ian Scott wrote: >Summary: > >1. Is there really a big problem here? >2. If there is the please fix it without harming users of big vectors. > > >Details >Point 2 first: >As a user of big vectors (size > 100) I don't object to anyone messing >around with the hierarchy of vectors so long as I don't pay a penalty. For >instance - virtual or otherwise non-inlined functions for vector lookup, >size, etc., or more than 1 extra unsigned data member would be unacceptable. > >If it requires a modification of existing client code - that also isn't a >problem if someone provides a perl script that covers most of the mods. > > >Point 1: >It looks as if the code is already designed to do as you want. > >e.g. vnl_vector_fixed.h >00132 template <class T, int n> >00133 inline vnl_vector_fixed<T,n> operator+(T const t, >vnl_vector_fixed<T,n> const & rhs) >00134 { return (vnl_vector_fixed<T,n> (rhs) += t); } > >Where is the new here ? > > >I understand that doing a = b + c makes an extra temporary on the stack. >However this is very hard to avoid unless we move to a Blitz-style approach >for fixed length vectors. Last I heard Blitz didn't compile on very many >platforms. > >With ordinary vectors a=b+c does cause a new(), but that is why most of the >code in VXL does things like a += b instead. > >Ian. > > > >_______________________________________________ >Vxl-maintainers mailing list >Vxl...@li... >https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Phil P. <p.p...@2d...> - 2002-02-15 14:07:02
|
We have compiled the bits we use (most of the core libs) on Windows 2000 on an AMD box. Also I know its been succesfully compiled under Windows XP but I don't know what processor that machine was running. Phil > -----Original Message----- > From: Geoffrey Cross [mailto:ge...@cr...] > Sent: Friday, February 15, 2002 2:03 PM > To: vxl...@li... > Subject: [Vxl-maintainers] AMD vs. Intel > > > > I've just been asked if vxl compiles under windoze running on an AMD > processor. I presume it does, but has anyone tried this? > And how about > Windows XP? > > Geoff. > > > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > This e-mail, and any attachment, is confidential. If you have received it in error, please delete it from your system, do not use or disclose the information in any way, and notify me immediately. |
From: Geoffrey C. <ge...@cr...> - 2002-02-15 14:03:37
|
I've just been asked if vxl compiles under windoze running on an AMD processor. I presume it does, but has anyone tried this? And how about Windows XP? Geoff. |
From: Paul S. <pau...@vi...> - 2002-02-15 11:15:46
|
One question is: to what extent people writing client code use is-a relationships, plugging vector_fixeds into algorithms that take vectors, and to what extent generic algorithms would fit into the way people work. If one was going to go for generic algorithms, the matrix template library http://www.osl.iu.edu/research/mtl/, which works with vector and matrix iterators might be worth at least looking at - if only for the approach. e.g. matrix-vector multiply: template < class Matrix, class VecX, class VecY > void matvec_mult(const Matrix& A, VecX x, VecY y) { typename Matrix::const_iterator i; typename Matrix::OneD::const_iterator j; for (i = A.begin(); i != A.end(); i) for (j = (*i).begin(); j != (*i).end(); j) y[j.row()] += *j * x[j.column()]; } Paul. -----Original Message----- From: William A. Hoffman [mailto:bil...@ki...] Sent: 14 February 2002 18:56 To: Paul Smyth Cc: 'vxl...@li...' Subject: RE: [Vxl-maintainers] VNL speed of C?? I would argue that it should be done more generically, and more like stl. A vector would only need to have the interface: T& operator[](int) T& get(int); int size(); It would not have a T* as that adds an extra 4 bytes to the fixed version that it does not need. Also a virtual function adds to the size of the object. Also, some of the operators might be better implemented with functions: vnl_mult_vec(v1, v2, vresult); That way people could use these functions in inner loops without constructors being called. Right now "new" is called for most vector and matrix operations which can be very inefficient. -Bill At 06:06 PM 2/14/2002 +0000, Paul Smyth wrote: >Here's a go... > >Arguably there are a few basic properties of vectors >1) a T* (data) pointing to the first element >2) a size(), indicating the number of elements, which may be dynamic or >static, depending on whether the size is known at compile time >3) some storage, which may be dynamic or static > >I reckon that something like this might be appropriate: > > vector_ref >(has T* data, size() member fn - this would need to be virtual or have a >size_ member variable. >No resize() member fn) > > | \ > | ------------------------------------ > vector_fixed_ref | >(has T* data, static size - an enum?) vector_dynamic > | (has dynamic storage, resize() >member) > | > vector_fixed >(has C-array storage plus above) > >Operators might be: >vector_dynamic operator+(const vector_ref&, const vector_ref&); >vector_fixed operator+(const vector_fixed_ref&, const vector_fixed_ref&); >(Obviously you cannot return an object by value that doesn't own its own >memory). > >Hope this isn't complete rubbish. >Paul. > >-----Original Message----- >From: William A. Hoffman [mailto:bil...@ki...] >Sent: Thursday, February 14, 2002 4:33 PM >To: vxl...@li... >Subject: [Vxl-maintainers] VNL speed of C?? > > >I know I brought this up several years ago, but I was wondering if anyone >has thought about >this problem. The vnl vector hierarchy is upside down. vnl_vector should >inherit from vnl_vector_fixed. >The problem is that vnl_vector_fixed has 8 extra bytes of memory. Also all >the operators +, * , etc call >new even on the fixed versions of things. This has caused several >projects to give up on using the vnl_vector >classes and use hand coded arrays. > >-Bill > > > > >_______________________________________________ >Vxl-maintainers mailing list >Vxl...@li... >https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > >This e-mail, and any attachment, is confidential. If you have received it in >error, please delete it from your system, do not use or disclose the >information in any way, and notify me immediately. > >_______________________________________________ >Vxl-maintainers mailing list >Vxl...@li... >https://lists.sourceforge.net/lists/listinfo/vxl-maintainers This e-mail, and any attachment, is confidential. If you have received it in error, please delete it from your system, do not use or disclose the information in any way, and notify me immediately. |
From: Ian S. <ian...@st...> - 2002-02-15 10:41:36
|
Summary: 1. Is there really a big problem here? 2. If there is the please fix it without harming users of big vectors. Details Point 2 first: As a user of big vectors (size > 100) I don't object to anyone messing around with the hierarchy of vectors so long as I don't pay a penalty. For instance - virtual or otherwise non-inlined functions for vector lookup, size, etc., or more than 1 extra unsigned data member would be unacceptable. If it requires a modification of existing client code - that also isn't a problem if someone provides a perl script that covers most of the mods. Point 1: It looks as if the code is already designed to do as you want. e.g. vnl_vector_fixed.h 00132 template <class T, int n> 00133 inline vnl_vector_fixed<T,n> operator+(T const t, vnl_vector_fixed<T,n> const & rhs) 00134 { return (vnl_vector_fixed<T,n> (rhs) += t); } Where is the new here ? I understand that doing a = b + c makes an extra temporary on the stack. However this is very hard to avoid unless we move to a Blitz-style approach for fixed length vectors. Last I heard Blitz didn't compile on very many platforms. With ordinary vectors a=b+c does cause a new(), but that is why most of the code in VXL does things like a += b instead. Ian. |
From: William A. H. <bil...@ki...> - 2002-02-14 19:00:45
|
I would argue that it should be done more generically, and more like stl. A vector would only need to have the interface: T& operator[](int) T& get(int); int size(); It would not have a T* as that adds an extra 4 bytes to the fixed version that it does not need. Also a virtual function adds to the size of the object. Also, some of the operators might be better implemented with functions: vnl_mult_vec(v1, v2, vresult); That way people could use these functions in inner loops without constructors being called. Right now "new" is called for most vector and matrix operations which can be very inefficient. -Bill At 06:06 PM 2/14/2002 +0000, Paul Smyth wrote: >Here's a go... > >Arguably there are a few basic properties of vectors >1) a T* (data) pointing to the first element >2) a size(), indicating the number of elements, which may be dynamic or >static, depending on whether the size is known at compile time >3) some storage, which may be dynamic or static > >I reckon that something like this might be appropriate: > > vector_ref >(has T* data, size() member fn - this would need to be virtual or have a >size_ member variable. >No resize() member fn) > > | \ > | ------------------------------------ > vector_fixed_ref | >(has T* data, static size - an enum?) vector_dynamic > | (has dynamic storage, resize() >member) > | > vector_fixed >(has C-array storage plus above) > >Operators might be: >vector_dynamic operator+(const vector_ref&, const vector_ref&); >vector_fixed operator+(const vector_fixed_ref&, const vector_fixed_ref&); >(Obviously you cannot return an object by value that doesn't own its own >memory). > >Hope this isn't complete rubbish. >Paul. > >-----Original Message----- >From: William A. Hoffman [mailto:bil...@ki...] >Sent: Thursday, February 14, 2002 4:33 PM >To: vxl...@li... >Subject: [Vxl-maintainers] VNL speed of C?? > > >I know I brought this up several years ago, but I was wondering if anyone >has thought about >this problem. The vnl vector hierarchy is upside down. vnl_vector should >inherit from vnl_vector_fixed. >The problem is that vnl_vector_fixed has 8 extra bytes of memory. Also all >the operators +, * , etc call >new even on the fixed versions of things. This has caused several >projects to give up on using the vnl_vector >classes and use hand coded arrays. > >-Bill > > > > >_______________________________________________ >Vxl-maintainers mailing list >Vxl...@li... >https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > >This e-mail, and any attachment, is confidential. If you have received it in >error, please delete it from your system, do not use or disclose the >information in any way, and notify me immediately. > >_______________________________________________ >Vxl-maintainers mailing list >Vxl...@li... >https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Paul S. <pau...@vi...> - 2002-02-14 18:10:42
|
Here's a go... Arguably there are a few basic properties of vectors 1) a T* (data) pointing to the first element 2) a size(), indicating the number of elements, which may be dynamic or static, depending on whether the size is known at compile time 3) some storage, which may be dynamic or static I reckon that something like this might be appropriate: vector_ref (has T* data, size() member fn - this would need to be virtual or have a size_ member variable. No resize() member fn) | \ | ------------------------------------ vector_fixed_ref | (has T* data, static size - an enum?) vector_dynamic | (has dynamic storage, resize() member) | vector_fixed (has C-array storage plus above) Operators might be: vector_dynamic operator+(const vector_ref&, const vector_ref&); vector_fixed operator+(const vector_fixed_ref&, const vector_fixed_ref&); (Obviously you cannot return an object by value that doesn't own its own memory). Hope this isn't complete rubbish. Paul. -----Original Message----- From: William A. Hoffman [mailto:bil...@ki...] Sent: Thursday, February 14, 2002 4:33 PM To: vxl...@li... Subject: [Vxl-maintainers] VNL speed of C?? I know I brought this up several years ago, but I was wondering if anyone has thought about this problem. The vnl vector hierarchy is upside down. vnl_vector should inherit from vnl_vector_fixed. The problem is that vnl_vector_fixed has 8 extra bytes of memory. Also all the operators +, * , etc call new even on the fixed versions of things. This has caused several projects to give up on using the vnl_vector classes and use hand coded arrays. -Bill _______________________________________________ Vxl-maintainers mailing list Vxl...@li... https://lists.sourceforge.net/lists/listinfo/vxl-maintainers This e-mail, and any attachment, is confidential. If you have received it in error, please delete it from your system, do not use or disclose the information in any way, and notify me immediately. |
From: William A. H. <bil...@ki...> - 2002-02-14 16:36:53
|
I know I brought this up several years ago, but I was wondering if anyone has thought about this problem. The vnl vector hierarchy is upside down. vnl_vector should inherit from vnl_vector_fixed. The problem is that vnl_vector_fixed has 8 extra bytes of memory. Also all the operators +, * , etc call new even on the fixed versions of things. This has caused several projects to give up on using the vnl_vector classes and use hand coded arrays. -Bill |
From: Bill H. <bil...@ki...> - 2002-02-12 16:08:26
|
I am not sure I have the time to do this. However, I do not think it would be a waste of time. There are several compilers that should be able to work. The SGI and HP compilers would have this problem. I don't think you would need to go to the extreme of all 542 symbols. I think the three would be enough: STL (list, vector, etc. ) IOSTREAM (iostream) STDLILB (sqrt, printf, fprintf) Fred, is there perhaps an easier way to insert this into the existing headers? It would be easy enough to test for those three things in configure. Once you have done that, you could auto-generate a file that is included in the iso directory. It could put stuff into std like this: #ifndef VCL_IOSTREAM_HAS_STD namespace std { using ::ostream; using ::istream; using ::ios; using ::cout; using ::cerr; using ::cin; using ::ifstream; using ::ofstream; using ::strstream; using ::endl; using ::ends; using ::flush; } #endif I am not familiar enough with vcl to insert this in the right place. However, I think it would greatly add to the portability of vcl/vxl. -Bill At 03:51 PM 2/12/2002 +0000, Frederik Schaffalitzky wrote: >Yes, Bill is right but he is proposing to do a lot work (right? :) ) when >in fact the job may be more quickly and easily fixed by adding ad hoc >#ifdefs in vcl (not vxl). But if someone thinks that adding these >configure tests will save him or her time, I support the initiative >completely. > >What went wrong with a single test for std:: was that, in certain vendor >libraries, some symbols are in namespace std and some aren't. It would not >surprise me if there exists a library which place only some of the stream >stuff (say) in std:: which takes us back close to where we started >yesterday. The worst case would be a configure test for every single >symbol in the standard library. There are only 542 symbols currently >wrapped by vcl so this may actually be feasible. > >F > > >On Tue, 12 Feb 2002, Amitha Perera wrote: > >> I agree with Bill. I'm not much of a compiler guru, so I'd like to >> just use stuff in vcl, safe in the knowledge that someone better than >> me has fixed everything to work on every (supported) >> compiler. Ideally, there won't be any compiler related ifdefs in vxl >> code at all. >> >> I'll add that if some particular compiler is so far from the standard >> that it is difficult to vcl it, then we remove that compiler from our >> "supported set". (As we did with gcc 2.7.2 in Zurich.) >> >> Amitha. >> >> On Tue, Feb 12, 2002 at 10:24:18AM -0500, Bill Hoffman wrote: >> > I thought the idea was to have the configure script figure out the >> > compiler so we would not need all the ifdef stuff. From cmake, I >> > know there are serveral compilers that put stl in std but not the >> > streams. Also, there are compilers that put iostream and stl in std >> > but not the sqrt stuff. Seems like it would be better to have this >> > stuff figured out by configure, so we would not have to go ifdef'ing >> > the code every time we move to a new compiler. >> > >> > -Bill |