Re: OpenCV any Users on List?
On 05/21/2010 06:51 PM, Benjamin Scott wrote: > On Fri, May 21, 2010 at 6:37 PM, Bruce Labitt > wrote: > >> OpenCV appears to require a good C++ background, >> which I don't have now. ... Any advice? >> > Tell your employer you need some C++ training in order to do your > job effectively. > > Or if you're afraid they'll terminate you and hire someone else, > seek learning on your own time and dime. > > I taught C++ at Northeastern and have been employed as a C++ software engineer for quite a while. One of the books that I recommend is the "C++ How to Program" series by Deitel. Harvey Deitel was supposed to be my OS professor when I was working for my MCS degree at BU, but he went to BC. His books are, IMHO, very complete, and while the one that I used at NEU is aging, I still use it for reference. Another book that I liked was the C++ Primer by Lippman and Lajoie, but I don't think it has been updated recently. The issue with C++ (and other OO languages) is that it is important that you think in OO. Template classes in C++ are very powerful as is polymorphism. The product I work with is over a million lines of C++, and it uses polymorphism very heavily, and it is a true C++ system in contrast to some other systems I have worked with that were C compiled with C++ and a few classes mixed in. -- Jerry Feldman Boston Linux and Unix PGP key id: 537C5846 PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C 5846 signature.asc Description: OpenPGP digital signature ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: OpenCV any Users on List?
Jerry Feldman wrote: > > > I taught C++ at Northeastern and have been employed as a C++ software > engineer for quite a while. One of the books that I recommend is the > "C++ How to Program" series by Deitel. Harvey Deitel was supposed to be > my OS professor when I was working for my MCS degree at BU, but he went > to BC. His books are, IMHO, very complete, and while the one that I used > at NEU is aging, I still use it for reference. Another book that I liked > was the C++ Primer by Lippman and Lajoie, but I don't think it has been > updated recently. > > The issue with C++ (and other OO languages) is that it is important that > you think in OO. Template classes in C++ are very powerful as is > polymorphism. The product I work with is over a million lines of C++, > and it uses polymorphism very heavily, and it is a true C++ system in > contrast to some other systems I have worked with that were C compiled > with C++ and a few classes mixed in. > > Thanks for the book recommendations. /ramble on Yes, thinking in OO is key. Mercifully, this list didn't have to listen to my struggles with OOP with python. (Poor PySIG folks did though...) I think I have *some* concept of it now. Actually, I wrote my client server FFT app in python using OOP. I then "translated" the python server to a C++ server. The issue with C++, as I see it, is that one has to deal not only with the OOP part which is not easy, but the C/C++ syntax. Compared to python, for instance, C syntax is pretty ugly. Learning OOP in python first and applying it to C++ worked for me. Originally, when I looked at C++ BP (before python) I was overwhelmed at the 'density' of the language and wondered if I *ever* would be able to learn it. Now that I have some concept of OOP it does not seem as daunting. The original reason I was groaning about C++ was that there is a minimum proficiency required to be productive. That required proficiency, from my perspective, appears to be significantly higher for C++ than say for C, or python. For better or worse, the required expertise is higher. I can't be expert at everything, although I'd like to be. I'm not trying to validate an algorithm - I've already simulated everything in python/numpy to my satisfaction. I *just* need to port this algorithm to an embedded platform. It appears that many embedded platforms (at my price point) don't have sophisticated mathematical libraries readily available. So as you can see, I've been trying to learn other libraries so I can use them as the building blocks to implement my algorithm. Hopefully OpenCV will work. Hmm, just found the OpenCV Yahoo Groups. As of OpenCV 2.0 they now use LAPACK! (My level of trust of OpenCV went up.) Jeesh, I must not have built LAPACK right... /ramble off Looks like more C++ in my future... ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: OpenCV any Users on List?
Jerry Feldman writes: > > The issue with C++ (and other OO languages) is that it is important that > you think in OO. Stroustrup and Stepanov both disagree with this, .cf.: http://www2.research.att.com/~bs/bs_faq.html#Object-Oriented-language http://www.stlport.org/resources/StepanovUSA.html http://www.sgi.com/tech/stl/drdobbs-interview.html However, I'd agree that one had better be able to deal with the OO stuff if one expects to be able to handle anyone else's C++ code-- mainly because the misconception is so widespread. -- "Don't be afraid to ask (λf.((λx.xx) (λr.f(rr." ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Shot in the dark: Anyone ever use CLAPACK routines?
snip > Not too much to report. I even re-compiled ATLAS & LAPACK allowing gcc > & gfortran and got my example code to build. Same problem with the 9x9 > matrix. The 2x2 double complex matrix svd worked! > > I do have to say the interface to LAPACK is much better than CLAPACK. > (C or C++ calling FORTRAN) I can go back to my old (bad) habits of > using bits of C++ to help make the code easier to follow. > > In numpy/scipy the code computed the svd with no problem. > > Not too much activity at the lapack-forum. :( Since the academic term > ended recently at UT Knoxville, maybe everyone is on vacation... > > -Bruce > > Well, I have something to try... If one actually RTFM or in this case the readme, one finds the following: # As a final point, we must stress that there is a difference in the definition # of a two-dimensional array in Fortran and C. # A two-dimensional Fortran array declared as # #DOUBLE PRECISION A(LDA, N) # # is a contiguous piece of LDA X N double-words of memory, stored in # column-major order: elements in a column are contiguous, and elements # within a row are separated by a stride of LDA double-words. # # In C, however, a two-dimensional array is in row-major order. Further, the # rows of a two-dimensional C array need not be contiguous. The array # #double A[LDA][N]; # # actually has LDA pointers to rows of length N. # These pointers can in principle be anywhere in memory. Passing such a # two-dimensional C array to a CLAPACK routine will almost surely give # erroneous results. # # Instead, you must use a one-dimensional C array of size LDA X N # double-words (or else malloc the same amount of space). # We recommend using the following code to get the array CLAPACK will be # expecting: # #double *A; #A = malloc( LDA*N*sizeof(double) ); Umm, yeah, I can do that! My original code had that... For some reason I got rid of it. So a SEG FAULT makes some sense for my 9x9. Because in C the array (matrix) does not have to be contiguous in memory. But FORTRAN is assuming a column major contiguous array. So it seems likely I could access unallocated memory, and hence a seg fault. OK, I can relax now... Saga continues on Monday... ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Shot in the dark: Anyone ever use CLAPACK routines?
Bruce Labitt writes: > Well, I have something to try... If one actually RTFM or in this case > the readme, one finds the following: > > # As a final point, we must stress that there is a difference in the > definition > # of a two-dimensional array in Fortran and C. The difference that you cite here -- the difference between column-major order versus row-major order -- is sort-of a well-known difference between C and Fortran. [...] > # Instead, you must use a one-dimensional C array of size LDA X N > # double-words (or else malloc the same amount of space). > # We recommend using the following code to get the array CLAPACK will be > # expecting: > # > #double *A; > #A = malloc( LDA*N*sizeof(double) ); > > Umm, yeah, I can do that! My original code had that... For some reason I > got rid of it. > So a SEG FAULT makes some sense for my 9x9. Because in C the array (matrix) > does not have > to be contiguous in memory. But FORTRAN is assuming a column major > contiguous array. So it > seems likely I could access unallocated memory, and hence a seg fault. In my opinion, you would do very well to start with a *known working example* from whatever matrix library you are working with...paying special attention to the memory allocation partsand then try to transmogrify this into whatever you are trying to do with this program. --kevin -- alumni.unh.edu!kdc / http://kdc-blog.blogspot.com/ GnuPG: D87F DAD6 0291 289C EB1E 781C 9BF8 A7D8 B280 F24E Wipe him down with gasoline 'til his arms are hard and mean From now on boys this iron boat's your home So heave away, boys. -- Tom Waits ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/