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}

S  M  T  W  T  F  S 





1
(1) 
2
(4) 
3
(1) 
4

5
(2) 
6
(6) 
7
(3) 
8
(2) 
9
(1) 
10

11

12
(3) 
13
(8) 
14

15
(1) 
16
(3) 
17

18

19

20
(6) 
21
(2) 
22
(4) 
23
(1) 
24

25

26

27

28

29
(1) 
30
(1) 
31

From: Jeff Strickrott <jstric01@cs...>  20030513 19:49:30

Hi Ian: Thanks for the response. > I'm pretty sure that the CLAPACK library is a trivial syntacticsugar > interface to LAPACK. It replaces some of the byreference parameters with > byvalue ones. I found it easier to use the ordinary f2c interfaces  which > are identical to the > original fortran ones. My Fortran is very rusty and hence why I originally thought of using the clapack routines. I will study vnl_real_eigensystem.cxx and the file lapack_syev.cxx (sent to me by Frederik Schaffalitzky) to see how you handle the Fortran to C calling issues. Plus I guess I need to get f2c and learn any of its particulars. I will also have to study the appendix in greater detail and will come back with any questions I have on the procedure. > We are always interested in having useful new routines added to VXL, so I'll > try and get some more help...Finally  If you do want to add the routines to > VNL, get yourself a user account on sourceforge, and let me know. I'll set up > write access to the repository for you. I have a user account with sourceforge (user: Jeff_Strickrott) but for now do not need any write access. I want to see what I can get working first and then we can see about adding that to the library. Plus, my development platforms are either Windows (2K prof./XP prof.) or QNX based, no Linux to test with. I have not tried to put vxl under QNX yet so I am not sure if there are any library issues or other conflicts. But that can be handled later. > One other point  it might be worth asking if you really nead the LU > decomposition. Would SVD be suitable instead? The existing code I am porting was written by Adam Baumberg from the University of Leeds. He used NAG libraries for the numerical routines and had wrapper functions for both LU decomposition and SVD. They both seem to be used, so I imagine that maybe he thought one was more efficient than the other for different parts of the code. I am not an expert yet on his work either, but maybe it can be simplified to just use SVD. The first goal though is to just get it to compile and process images. > > > 3. What are (if any) the thread safety issues with vxl, and in > > > particular the vnl libraries? > > I'm pretty sure that LINPACK is not thread safe. In general threadsafety is > an "aim" of vxl, but you may find some code (like vnl_algo/netlib) that > isn't. All of the code in vnl (the classes like vnl_vector, etc. but not the > stuff in vnl_algo) is thread safe if you disable vnl's own memory manager. I > can't see any problems adding any other potentially nonthread safe routines > to netlib. Although if it isn't too hard making them thread safe (in the > sense that two threads can call the same routine at the same time) that > would be great. I will have to look into this as the old code uses NAG's thread safe functions. Thanks again for the suggestions. Regards, Jeff 
From: Andrew Fitzgibbon <awf@ro...>  20030513 17:30:18

> > Original Message > > From: Kaucic, Robert A (Research) [mailto:kaucic@...] > > Sent: Tuesday, May 13, 2003 3:48 PM > > To: 'vxlmaintainers@...' > > Subject: [Vxlmaintainers] XML suport for vxl > > > > > > I was thinking of putting support for XML reading and writing > > into vxl. It > > would entail bringing in a third party package like XERCES > > for parsing the > > XML. Would this be well received? > > > > Bob Kaucic There have been a few posts recently which talk about "bringing in" 3rd party libraries to vxl. In general, the ideal with VXL is that it does not depend on too many 3rd party libraries. The design of VXL is such that it should behave like any thirdparty library you provide. In particular, if your 3rd party library needs its own STL, vxl should be able to use *that* STL via the VCL compatibility layer, not the other way round. I use many 3rd party libraries in my code, but there is no need for the VXL community to know that (unless they look in the appropriate contrib directory). There *are* some libraries in v3p which were so badly written or buggy that they had to be modified to work with VXL, or which were not easily available elsewhere. On the other hand, we don't supply gtk or Qt or glut, nor should we supply any widely available library. We should particularly avoid using one which is under active development, because then we have to track every change to the library in our v3p shadow, which rapidly becomes impossible. 
From: William A. Hoffman <billlist@ny...>  20030513 15:48:35

I would recommend a simpler package like expat for xml parsing. XERCES is rather large as I remember. http://expat.sourceforge.net/ expat is a very small c based package that we are using in VTK, and some other projects here. Bill At 10:48 AM 5/13/2003, Kaucic, Robert A (Research) wrote: >I was thinking of putting support for XML reading and writing into vxl. It >would entail bringing in a third party package like XERCES for parsing the >XML. Would this be well received? > >Bob Kaucic > > > > >Enterprise Linux Forum Conference & Expo, June 46, 2003, Santa Clara >The only event dedicated to issues related to Linux enterprise solutions >www.enterpriselinuxforum.com > >_______________________________________________ >Vxlmaintainers mailing list >Vxlmaintainers@... >https://lists.sourceforge.net/lists/listinfo/vxlmaintainers 
From: Ian Scott <ian.scott@st...>  20030513 15:24:32

Hmmm, My own opinion... A little more detail would be useful. For instance do you want to be able to save and reload the state of large complex objects (as vsl does,) or are you intending to use it to parse control files, etc. If it is more of the former, and is heavily integrated into VXL then I guess I'd be fine by that. However, I've found that for large objects the speed/precision advantages of vsl over any text format are pretty large. One thought. It would be pretty straightforward to generalise vsl_b_write(vsl_b_stream&, const myclass &) to vsl_write(vsl_stream&, "Foo", const myclass &) vsl binary streams would ignore the "Foo" tag, but XML streams would use that for an element name or something. On the other hand, if the XML support is to provide a parser for config files for various applications, or to provide XML IO support for a strictly limited number of classes, then it is less clear what the advantage to the VXL community (including you) is for having vxl/v3p/xerces instead of linking against the library in your private code. Ian. > Original Message > From: Kaucic, Robert A (Research) [mailto:kaucic@...] > Sent: Tuesday, May 13, 2003 3:48 PM > To: 'vxlmaintainers@...' > Subject: [Vxlmaintainers] XML suport for vxl > > > I was thinking of putting support for XML reading and writing > into vxl. It > would entail bringing in a third party package like XERCES > for parsing the > XML. Would this be well received? > > Bob Kaucic > > > >  > Enterprise Linux Forum Conference & Expo, June 46, 2003, Santa Clara > The only event dedicated to issues related to Linux > enterprise solutions > http://www.enterpriselinuxforum.com > > _______________________________________________ > Vxlmaintainers mailing list > Vxlmaintainers@... > https://lists.sourceforge.net/lists/listinfo/vxlmaintainers > 
From: Kaucic, Robert A (Research) <kaucic@cr...>  20030513 14:48:54

I was thinking of putting support for XML reading and writing into vxl. It would entail bringing in a third party package like XERCES for parsing the XML. Would this be well received? Bob Kaucic 
From: Ian Scott <ian.scott@st...>  20030513 10:11:51

> Hi All: > > I am not sure if I have fallen victim to your antispam effort, I am > reposting my query. Since my last post, I have obtained and compiled > clapack. At this point I must decide between using the old VisSDK > library and integrating clapack and an mpeg library, or > integrating the > required routines into vxl's vnl library. I suspect, you have fallen victim to "nobody around on Monday who really knows the answer." We wrapped the fortran public maths libraries in vnl_algo for a reason  most of us don't want to worry about it! BTW  You may as well keep this discussion to vxlmaintainers. I'll have a go at your questions, but I'm not one of the original authors, so I may not be of much help. We are always interested in having useful new routines added to VXL, so I'll try and get some more help. > >  Original Message  > > Subject: Integration of portion of LAPACK/CLAPACK routines to vnl > > Date: Fri, 09 May 2003 15:39:08 0400 > > From: Jeff Strickrott <jstric01@...> > > To: > vxlusers@...,vxlmaintainers@... > > > > Hello All: > > > > I am new to the vxl environment and I am trying to port > code that was > > written to use the NAG numerical library and/or a subset of > LAPACK and > > need to have the following LAPACK/CLAPACK or NAG routines: > > > >  DSYEV  compute all eigenvalues and, optionally, eigenvectors of a > > real symmetric matrix A. > >  DGETRF  compute an LU factorization of a general MbyN matrix A > > using partial pivoting with row interchanges. > >  DGETRI  compute the inverse of a matrix using the LU > factorization > > computed by DGETRF. > >  DGEEV  compute for an NbyN real nonsymmetric matrix A, the > > eigenvalues and, optionally, the left and/or right eigenvectors. I > > believe that your vnl_real_eigensystem will do the same thing. > > > >  F04AEF: calculates the accurate solution of a set of real linear > > equations with multiple righthand sides using an LU > factorization with > > partial pivoting, and iterative refinement. That is given a > set of real > > linear equations AX = B , the routine first computes an LU > factorization > > of A with partial pivoting, PA =LU , where P is a > permutation matrix, L > > is lower triangular and U is unit upper triangular. An > approximation to > > X is found by forward and backward substitution. The > residual matrix R > > =B  AX is then calculated using additional precision, and > a correction > > D to X is found by solving LUD = PR . X is replaced by X + > D and this > > iterative refinement of the solution is repeated until full machine > > accuracy has been obtained. > > > > My expertise is not with computer vision or numerical > routines (yet :) > > ) and I have the following questions: > > 1. Would it be easier to just obtain CLAPACK and use the appropriate > > routines from there? Has anyone compiled both CLAPACK and > vnl together? I'm pretty sure that the CLAPACK library is a trivial syntacticsugar interface to LAPACK. It replaces some of the byreference parameters with byvalue ones. When I did some experiments (Comparing the speed of VNL's matrixvector multiplications and the stuff in Intel's optimised BLAS library MKL (which BTW, gcc+vnl won)http://sourceforge.net/mailarchive/message.php?msg_id=3628964) I found it easier to use the ordinary f2c interfaces  which are identical to the original fortran ones. > > 2. Add the FORTRAN routines per the procedures in the appendix? It would be great to add the fortran routines, and write an vnl_algo interface. You could model the C++ interface design for the LU decomposition on the others, e.g. vnl_svd and vnl_cholesky. > > 3. What are (if any) the thread safety issues with vxl, and in > > particular the vnl libraries? I'm pretty sure that LINPACK is not thread safe. In general threadsafety is an "aim" of vxl, but you may find some code (like vnl_algo/netlib) that isn't. All of the code in vnl (the classes like vnl_vector, etc. but not the stuff in vnl_algo) is thread safe if you disable vnl's own memory manager. I can't see any problems adding any other potentially nonthread safe routines to netlib. Although if it isn't too hard making them thread safe (in the sense that two threads can call the same routine at the same time) that would be great. > > 5. Any other suggestions? To give you some explanation, most of the complex routines in vnl are imports of the older LINPACK. I think the authors found it easier to use the LINPACK routines  since they had less dependencies. Replacing all the LINPACK routines with full LAPACK ones is something that needs to be done  but which noone has yet had the time to do. I am not aware of any problems with LINPACK and LAPACK routines coexisting. They share the the same BLAS routines, but as I mentioned LAPACK needs more helper routines than the authors converted for the existing LINPACK code. Have a look at how vnl/algo/vnl_real_eigensystem.cxx to see how vnl accesses the contents of the netlib library. One other point  it might be worth asking if you really nead the LU decomposition. Would SVD be suitable instead? Finally  If you do want to add the routines to VNL, get yourself a user account on sourceforge, and let me know. I'll set up write access to the repository for you. Ian. 
From: Jeff Strickrott <jstric01@cs...>  20030513 03:52:25

Hi All: I am not sure if I have fallen victim to your antispam effort, I am reposting my query. Since my last post, I have obtained and compiled clapack. At this point I must decide between: using the old VisSDK library and integrating clapack and an mpeg library, or integrating the required routines into vxl's vnl library. Can anyone answer my questions below and suggest a development path? Thanks in advance for the help. Regards Jeff Strickrott Multimedia Database Laboratory Dept. of Computer Science Florida International University Miami, FL >  Original Message  > Subject: Integration of portion of LAPACK/CLAPACK routines to vnl > Date: Fri, 09 May 2003 15:39:08 0400 > From: Jeff Strickrott <jstric01@...> > To: vxlusers@...,vxlmaintainers@... > > Hello All: > > I am new to the vxl environment and I am trying to port code that was > written to use the NAG numerical library and/or a subset of LAPACK and > need to have the following LAPACK/CLAPACK or NAG routines: > >  DSYEV  compute all eigenvalues and, optionally, eigenvectors of a > real symmetric matrix A. >  DGETRF  compute an LU factorization of a general MbyN matrix A > using partial pivoting with row interchanges. >  DGETRI  compute the inverse of a matrix using the LU factorization > computed by DGETRF. >  DGEEV  compute for an NbyN real nonsymmetric matrix A, the > eigenvalues and, optionally, the left and/or right eigenvectors. I > believe that your vnl_real_eigensystem will do the same thing. > >  F04AEF: calculates the accurate solution of a set of real linear > equations with multiple righthand sides using an LU factorization with > partial pivoting, and iterative refinement. That is given a set of real > linear equations AX = B , the routine first computes an LU factorization > of A with partial pivoting, PA =LU , where P is a permutation matrix, L > is lower triangular and U is unit upper triangular. An approximation to > X is found by forward and backward substitution. The residual matrix R > =B  AX is then calculated using additional precision, and a correction > D to X is found by solving LUD = PR . X is replaced by X + D and this > iterative refinement of the solution is repeated until full machine > accuracy has been obtained. > > My expertise is not with computer vision or numerical routines (yet :) > ) and I have the following questions: > 1. Would it be easier to just obtain CLAPACK and use the appropriate > routines from there? Has anyone compiled both CLAPACK and vnl together? > 2. Add the FORTRAN routines per the procedures in the appendix? > 3. What are (if any) the thread safety issues with vxl, and in > particular the vnl libraries? > 4. Any idea for a source for the F04AEF routine? > 5. Any other suggestions? > > Thanks in advance for the help. > > Regards > Jeff Strickrott > Multimedia Database Laboratory > Dept. of Computer Science > Florida International University > Miami, FL 
From: Jeff Strickrott <jstric01@cs...>  20030513 03:51:29

Hi All: I am not sure if I have fallen victim to your antispam effort, I am reposting my query. Since my last post, I have obtained and compiled clapack. At this point I must decide between using the old VisSDK library and integrating clapack and an mpeg library, or integrating the required routines into vxl's vnl library. Can anyone answer my questions nelow and suggest a development path? Thanks in advance for the help. Regards Jeff Strickrott Multimedia Database Laboratory Dept. of Computer Science Florida International University Miami, FL >  Original Message  > Subject: Integration of portion of LAPACK/CLAPACK routines to vnl > Date: Fri, 09 May 2003 15:39:08 0400 > From: Jeff Strickrott <jstric01@...> > To: vxlusers@...,vxlmaintainers@... > > Hello All: > > I am new to the vxl environment and I am trying to port code that was > written to use the NAG numerical library and/or a subset of LAPACK and > need to have the following LAPACK/CLAPACK or NAG routines: > >  DSYEV  compute all eigenvalues and, optionally, eigenvectors of a > real symmetric matrix A. >  DGETRF  compute an LU factorization of a general MbyN matrix A > using partial pivoting with row interchanges. >  DGETRI  compute the inverse of a matrix using the LU factorization > computed by DGETRF. >  DGEEV  compute for an NbyN real nonsymmetric matrix A, the > eigenvalues and, optionally, the left and/or right eigenvectors. I > believe that your vnl_real_eigensystem will do the same thing. > >  F04AEF: calculates the accurate solution of a set of real linear > equations with multiple righthand sides using an LU factorization with > partial pivoting, and iterative refinement. That is given a set of real > linear equations AX = B , the routine first computes an LU factorization > of A with partial pivoting, PA =LU , where P is a permutation matrix, L > is lower triangular and U is unit upper triangular. An approximation to > X is found by forward and backward substitution. The residual matrix R > =B  AX is then calculated using additional precision, and a correction > D to X is found by solving LUD = PR . X is replaced by X + D and this > iterative refinement of the solution is repeated until full machine > accuracy has been obtained. > > My expertise is not with computer vision or numerical routines (yet :) > ) and I have the following questions: > 1. Would it be easier to just obtain CLAPACK and use the appropriate > routines from there? Has anyone compiled both CLAPACK and vnl together? > 2. Add the FORTRAN routines per the procedures in the appendix? > 3. What are (if any) the thread safety issues with vxl, and in > particular the vnl libraries? > 4. Any idea for a source for the F04AEF routine? > 5. Any other suggestions? > > Thanks in advance for the help. > > Regards > Jeff Strickrott > Multimedia Database Laboratory > Dept. of Computer Science > Florida International University > Miami, FL 