Thread: [Lapackpp-devel] Memory assignment in LaSymmMatDouble
Status: Beta
Brought to you by:
cstim
Menu
▾
▴
lapackpp-devel
|
From: Dominik W. <dom...@ar...> - 2006-11-14 14:18:11
|
Hello, assigning a matrix per LaGenMatDouble or LaSymmMatDouble does not have any effect to memory savings because the constructor of the symmetric matrix will only call the standard constructor of a general matrix. Why do you choose this approach? You can save some (or better half of the) memory you use yet. Best wishes, Dominik PS: Your archive http://sourceforge.net/mailarchive/forum.php?forum=lapackpp-devel seems to be down sometimes. I only get Internal Error 500... I hope the subscription will work. |
|
From: Christian S. <sti...@tu...> - 2006-11-14 15:40:14
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Dominik, Dominik Wagenfuehr schrieb: > assigning a matrix per LaGenMatDouble or LaSymmMatDouble does not have > any effect to memory savings because the constructor of the symmetric > matrix will only call the standard constructor of a general matrix. Why > do you choose this approach? You can save some (or better half of the) > memory you use yet. yes, that's true, the LaSymmMatDouble doesn't store its matrix content any different than LaGenMatDouble (although it accesses only half of the memory). This approach was chosen by the original authors of the lapackpp-1.x code and this code has never been touched or improved by myself. You can see that by the fact that there is almost zero documentation comments in the header file. I've only worked on those classes where you have a lot of comments in the header file. So if you think those other classes are badly designed or even contain errors, then the blame goes on the original authors. If you want to use that part of lapackpp and you think the class should be changed, then feel free to propose a code change. Simply submit a patch here, ideally together with a test case that demonstrates that your code delivers correct calculations. In terms of the storage decision, IMHO the matrix should be stored in the same way as the Fortran-LAPACK expects it. I'm not an expert for sparse or symmetric matrices in LAPACK (only for dense ones), so I rather don't touch this part of the code. But if you have any suggestion, feel free to go ahead with this. > PS: Your archive > http://sourceforge.net/mailarchive/forum.php?forum=lapackpp-devel seems > to be down sometimes. I only get Internal Error 500... I hope the > subscription will work. The subscription obviously worked. I know that the link to the archive on sourceforge is broken and I have no idea why they don't fix it. :-( Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRVnjUWXAi+BfhivFAQKd2QP/dbq9q4uHRn+Frd7rOOpEK1Md3281cKIh MuanfyVWa8h4v4EzyeOzCS1IWcnHHxc4bJlQasagyDPILqAT79VTjTENQvsAJpaa c2LmW5EHw1l6+xhYKBp1/3keIXFGhNukpWCUu+W7ArdJUx7QPjQ5YIDng3M+L6qP /DCmoa8Zu0Y= =o3Uk -----END PGP SIGNATURE----- |
|
From: Dominik W. <dom...@ar...> - 2006-11-15 07:54:23
|
Hello Christan, Christian Stimming schrieb: > This approach was chosen by the original authors of the > lapackpp-1.x code and this code has never been touched or improved by > myself. [...] > If you want to use that part of lapackpp and you think the class should > be changed, then feel free to propose a code change. Yes, I probably will do. It will take a time but I think it would help most of the programmers if the header file is documented better. In many cases I have to look into the cc-files to see what the function actually does. If I'm finished I will report later... Greetings, Dominik |
|
From: Christian S. <sti...@tu...> - 2006-11-15 09:03:01
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dominik Wagenfuehr schrieb: > Hello Christan, > > Christian Stimming schrieb: >> This approach was chosen by the original authors of the >> lapackpp-1.x code and this code has never been touched or improved by >> myself. [...] >> If you want to use that part of lapackpp and you think the class should >> be changed, then feel free to propose a code change. > > Yes, I probably will do. It will take a time but I think it would help most > of the programmers if the header file is documented better. In many cases > I have to look into the cc-files to see what the function actually does. Look into the header files of the general/dense matrices, include/gmd.h and others. The function names are pretty much the same as in symd.h, so that should give you an idea about what these functions are supposed to do, and most of the comments can directly copied into e.g. symd.h as well. I didn't add any documentation there because I wanted to document only those parts that I 1. understand, 2. tested, and 3. really know they do the right thing. symd.h doesn't meet those criteria, so I didn't bother to add any (potentially wrong) documentation. > If I'm finished I will report later... Sure. If you are interested, you could also get direct developer CVS access for lapackpp. (Sourceforge username needed.) Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRVrXtmXAi+BfhivFAQIIHgP+JmmqGo1RiA3IiSIfBj9cxwi8YSjAnLj6 uCS36yad/Fwo6RUlBtF7iKo5S37LahI5pF05KB1dwMeZF6FMFhtAK79qZD9NXEyl HALvr76pobre9ACupWBUC37jkosnfd5ShhOC99ei5+VlPy4wqHeOt8ny2kb+1bHN UfIZ0Gn+RE0= =bDD7 -----END PGP SIGNATURE----- |
|
From: Dominik W. <dom...@ar...> - 2006-11-16 12:53:01
|
1. I havent' found the exact error yet, but if I debug my program I will
get a segmentation fault in
LaGenMatDouble B(A);
or
LaGenMatDouble B;
B.copy(A);
A is a (4 x 2)-matrix with some values I have calculated before.
Unfortunately I cannot debug the lapack-libary so I don't know where the
error could be. I try to extract the relevant code parts from my program
to reconstruct it.
2. Is it possible that you forgot to create the copy-function for
LaSymmBandMatDouble? I only get
/usr/local/include/lapackpp/sybmd.h:51: warning: inline function
'LaSymmBandMatDouble& LaSymmBandMatDouble::copy(const
LaSymmBandMatDouble&)' used but never defined
I have created my own copy-function yet but as I see you have used some
templates for this. I don't understand much about templates but it would
be great if you can fix it.
3. Is there such a simple thing like A := A + alpha*B ? I have only
found Blas_Mat_Mat_Mult and actually I perform
Blas_Mat_Mat_Mult(B, I, A, alpha);
where I as the Identity Matrix. Especially for LaSymmBandMatDouble you
could save a lot lot lot of time if there would be such a simple
operation for different types of matrices. I don't know if there exists
a BLAS-function for it (I haven't found it yet), but I have named my
function
void Blas_Mat_Mat_Add(LaSymmBandMatDouble& A, const LaSymmBandMatDouble&
B, const double& alpha = 1.0)
{
assert(A.size(0) == B.size(0));
assert(A.size(1) == B.size(1));
int n=A.size(0), p=A.subdiags(), n2;
int i,j;
for (i=0; i<n; i++)
{
n2 = (i+p+1 < n) ? i+p+1 : n;
for (j=0, j<n2; j++)
{
A(i,j)+=alpha*B(i,j);
}
}
}
4. Same with the operation A = B^T * B. There seems to be no
BLAS-function for it even if you know that A is symmetric. You could
save half of the time. And further if you know that B has a special
structure and A will be banded symmetric...
Greetings, Dominik
PS: I have tested the functions in sybmd.h and sybfd.h and they seem to
work fine. (Ignoring the little copy-incident above!) I will try to
comment the functions...
|
|
From: Christian S. <sti...@tu...> - 2006-11-16 13:29:46
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dominik Wagenfuehr schrieb: > 1. I havent' found the exact error yet, but if I debug my program I will > get a segmentation fault in > > LaGenMatDouble B(A); > > or > > LaGenMatDouble B; > B.copy(A); > > A is a (4 x 2)-matrix with some values I have calculated before. > Unfortunately I cannot debug the lapack-libary so I don't know where the > error could be. I try to extract the relevant code parts from my program > to reconstruct it. That's a serious error. I have spent a lot of checking on the LaGenMatDouble methods, including the ::copy() method. If you can extrace the relevant code portion than that would be really helpful. > 2. Is it possible that you forgot to create the copy-function for > LaSymmBandMatDouble? I only get > > /usr/local/include/lapackpp/sybmd.h:51: warning: inline function > 'LaSymmBandMatDouble& LaSymmBandMatDouble::copy(const > LaSymmBandMatDouble&)' used but never defined > > I have created my own copy-function yet but as I see you have used some > templates for this. I don't understand much about templates but it would > be great if you can fix it. In fact the copy() method is declared "inline" but its definition is in matrix/src/sybmd.cc, so it is not at all inline. You can fix this yourself by removing the "inline" keyword in front of copy() in sybmd.h. Again, this isn't "my fault" :-) because this code has been untouched from the original lapackpp authors, see the version history of sybmd.h at http://lapackpp.cvs.sourceforge.net/lapackpp/lapackpp/include/sybmd.h?view=log - - I only started to work on that file after you asked for these issues yesterday. > 3. Is there such a simple thing like A := A + alpha*B ? I have only > found Blas_Mat_Mat_Mult and actually I perform > > Blas_Mat_Mat_Mult(B, I, A, alpha); > > where I as the Identity Matrix. Especially for LaSymmBandMatDouble you > could save a lot lot lot of time if there would be such a simple > operation for different types of matrices. I don't know if there exists > a BLAS-function for it (I haven't found it yet), The point with these "simple arithmetics" for the matrices is that surprisingly few of these are actually available as BLAS functions. Especially the direct addition of two matrices (with or without scalar factor) is *not* available in BLAS or LAPACK, see http://www.netlib.org/blas/blasqr.pdf or http://www.netlib.org/blas/faq.html or http://www.cs.colorado.edu/~jessup/lapack/aboutBlas.html I don't know the reasons for this decision. I'm an engineer, not a numerical mathematician. I can only *guess* that the plain addition of matrices for whatever reason is never being computed explicitly in "real numerics". The goal of lapackpp, on the other hand, is to be a C++ interface to BLAS and LAPACK. So if you're asking for functionality that isn't available in there, then I'm hesitating to put it into lapackpp. Rather, I'd like to ask you to implement this yourself - I just guess the LAPACK/BLAS people do have their reasons for deciding what to implement and what not to implement, and since they are more intelligent than me, I'd rather stick to their decision. Sorry. > 4. Same with the operation A = B^T * B. There seems to be no > BLAS-function for it even if you know that A is symmetric. You could > save half of the time. And further if you know that B has a special > structure and A will be banded symmetric... This function is surely available in BLAS (I've looked this up on the Quick Reference Guide). It is called DSYRK there (see "man dsyrk" if you have lapack-manpages installed). The correct place for the C++ function declaration is include/blas3pp.h and the implementation (=definition) in blaspp/src/blas3pp.cc, and it turns out this function is already available as Blas_R1_Update(), search for LaSymmMatDouble and set alpha=1, beta=0. I have no idea why that name was chosen - maybe I should add a better function name like Blas_RK_Update(). For the reference, if you discover more such functions that *are* available in BLAS but not yet in LAPACKPP, here's what we would need to do: 1. Find the BLAS function name (say, dsyrk in level-3-blas) 2. Check whether a declaration of that function name exists in include/blas3.h (no C++ here, only plain C) - if it doesn't exist, add the declaration by copy&paste a similar declaration and suitable reordering of the arguments. 3. Invent a C++ function name (say, Blas_RK_Update) and add a suitable declaration for that function into include/blas3pp.h. 4. Add the implementation for the C++ function to blaspp/src/blas3pp.cc; follow the existing checks and argument conversions from the other existing wrapper functions. 5. (slightly optional) Add some testing code into blaspp/test/tblas++.cc that will make the tblas++.cc program fail if your new function doesn't work as expected. This ensures that "make check" will always check your newly added function. > PS: I have tested the functions in sybmd.h and sybfd.h and they seem to > work fine. (Ignoring the little copy-incident above!) I will try to > comment the functions... Good. Again I'd invite you to submit any code changes that you consider an improvements. That is great. Thanks a lot. Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRVxnvGXAi+BfhivFAQJstAP/f9Vf6T/XwqyypyOkP5SgELWpB1YmC0Yd Fdl672DGaWVExRowrmfWzaXIhED1vXPyU+4rd1tfF28dmAiHa0+1w5SDZVwNIQmm WrI5lTNRZIwpDfncp0C3sVoDxXWAWhBLlVmwcmSytTxE/b1tf43daOKfAqPNFbDE q+sMQbhPYO4= =KT/y -----END PGP SIGNATURE----- |
|
From: Christian S. <sti...@tu...> - 2006-11-16 13:45:22
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dominik Wagenfuehr schrieb: > PS: Your archive > http://sourceforge.net/mailarchive/forum.php?forum=lapackpp-devel seems > to be down sometimes. I only get Internal Error 500... I hope the > subscription will work. This is a known sourceforge bug: https://sourceforge.net/tracker/index.php?func=detail&aid=1588125&group_id=1&atid=200001 The suggested "workaround" (urgh): Try the same URL again but without being logged into sourceforge (i.e. try it in a different browser). Indeed the same URL will work in that case, except that the archive seems to have stopped working in mid-October, which is yet another known sourceforge bug. That sucks. Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRVxrZ2XAi+BfhivFAQLcdQP9HzXx5uxVtSRcW1NLm/0qGkxBHoqVTZWp e0JatfNrLGBo5R9RwJ6IEK3VKC1EqjasTYiQD/DnPsv70Fg/irnqU82Tpoa6MrB+ yRtaRGBvjORWEaWUig/Vs3h/ojY5Ptyw2LFhA6YUk1oOLnNvFYVIcWuWG+igFE+Y 5ZmvStG0nxw= =kzi9 -----END PGP SIGNATURE----- |
|
From: Christian S. <sti...@tu...> - 2006-11-16 15:33:29
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dominik Wagenfuehr schrieb: >> That's a serious error. I have spent a lot of checking on the >> LaGenMatDouble methods, including the ::copy() method. If you can >> extrace the relevant code portion than that would be really helpful. > > Ok, the program crashed at LaGenMatDouble but the error is in sybfd.h in > the factorize-function I have called earlier. I have fixed it and will > send you a new file with documentation later (see at the end). Thanks. Looking forward to this. >> Again, this isn't "my fault" :-) because this code has been untouched >> from the original lapackpp authors > > I have never said that. ;) I took a look at the old lapack++ classes from 96 > and it's almost unbelievable that there are errors inside these functions > for more than 10 years. I totally agree. >> and it turns out this function is already >> available as Blas_R1_Update(), > > Found it, thanks. :) The bad with these old lapack++ code > is that these parts you have never touched are not documented and > if you don't know the correct phrase or Fortran-Name you > probably will never found it. :( Yes. When I'm looking for something I'd usually start with the LAPACK documentation at http://www.netlib.org/lapack/lug/lapack_lug.html , and if there is a LAPACK routine, then I'd grep over the full lapackpp source code to see whether it is being used anywhere. > Maybe I will have documented the two most important files > sybmd.h and sybfd.h tomorrow. > > Another question concerning the changed. How far can I change it? > I think the LaSymmBandFactDouble is ... hm, to be honest, useless. > The functions inside can be used with the simple > LaSymmBandMatDouble. But however it works.. I think this is the > important part. ;) I agree that several of the FactDouble classes are indeed relatively useless. I have added the class LaGenQRFactComplex http://lapackpp.sourceforge.net/html/classLaGenQRFactComplex.html and I consider it useful. It isn't anything more than a wrapper around the matrix A and vector Tau that make up the complex-valued QR decomposition in LAPACK, but it additionally encapsulates the two other interesting functions that would need these A and Tau as input. In other words, if the existing factorization class is useless, just go ahead and throw it out and/or replace it by your own class if you came up with a design that is more useful. Regards, Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRVyEqmXAi+BfhivFAQLK2QQAs+FliK2pcO165m999IBWlAYShx4eIs1E SHFfA9er1iCW62AU1cz9GPXXoqdFhdTgmS2mnCjamty8orxZr8ujBtC9Z1n7/Wt/ m+jClS8UPyycZtku8jmktQCc51OS8gqPXEyQ+iQk2MSNEi7oJaeOxWZGrMEmg1Ju T+q1uXsjSAE= =jle0 -----END PGP SIGNATURE----- |
|
From: Christian S. <sti...@tu...> - 2006-11-17 10:41:30
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dominik Wagenfuehr schrieb: > So, I have attached the three files for LaSymmBandMatDouble and > LaSymmBandFactDouble. I hope this mailing list accept attachments... You didn't send it to the mailing list, only to me directly. In the future please make sure you always send a CC to the mailing list (or vice versa, but I still suggest sending to both, see [1]). > Most of the sybmd.h-parts are original. I have only commented them > properly. There was a copy-Functon in sybmd.cc but however I've only got > an error if I remove the "inline" from sybmd.h as you suggested the last > time. So I deleted this copy-function (It was wrong anyway!) and add a > new one in sybmd.h. Further the programmer forgot to reset N_ and kl_ > when copying or referencing another matrix. Ok, thanks for fixing the missing parts. Some remarks: * Please always use the code from CVS, now that you're actually working with it. I already did some changes. This time I did the merging myself, but in the future it is expected that any patches are against the up-to-date CVS, not any released versions (which might already be outdated). See [2] for CVS. * As for inline vs. non-inline: I want to reduce the "inline" functions to a minimum, because they contradict the OO-paradigm of "hiding the implementation" (and make debugging harder, among other things). Therefore if I review a class, I want to keep only those methods "inline" where it actually makes sense. Inlining a function makes sense if and only if the execution cost of the function is on the order of the cost of the function call. OTOH if the cost of the function call is negligible compared to the execution cost of the function, then inlining is complete nonsense. Most prominent example here is copy(), which obviously has a large execution cost, so there is no point at all in marking this as inline. Same for any constructor. According to this criterion I've moved many functions to the .cc file, and I've moved the operator() to the header file, because this one is the counterexample where inlining *does* make sense. Also, having the operator() inline enables the client application to decide on the amount of error checking by defining or not defining LA_BOUNDS_CHECK, which was the whole point of that macro. * In the other functions I'd like to encourage you to re-use more of the existing functions, i.e. have copy() simply call operator=() or vice versa. > Please take a close look at the documentation. I'm not that much > experienced with doxygen syntax... Most parts I have copied from gmd.h. > I hope this is okay. :) Sure. Looks good. I'll have one last round of documentation proofreading during the next hour, but then you have those files (in CVS) back to your work without more interference from me. > The class in sybfd.h should be clear. The function > LaSymmBandMatFactorize is mostly original. The serious error was > > integer = A.size(0) > > what was incorrect, because it returns the wrong dimension. > > The first LaLinearSolve-function is original too. I only set the info > flags... Ok. Looks good on a first glance. I accepted your file unchanged, but mostly because the original one was complete nonsense anyway :-) . If possible, please think about splitting the code to a .cc file so that only the useful functions stay inline and the others are defined in the .cc file. Also, please think about adding a test program (in matrix/test/blablabla.cc) so that the correct functioning can be tested automatically. > The second LaLinearSolve-function is because often people want to solve > a matrix and have no need to factorize them before. So this function > will do it. I would prefer not to have such convenience functions, because eventually this might drive people to not think about the internally used factorization. Once people know that the solving is done in two steps, they might keep in mind that the left hand side in many applications could be reused several times, hence they would require only half the calculations. However, the decision about which functions to add and which not is obviously in part a matter of taste, so in this case it's probably fine. In that LaLinearSolve() case you even made this quite clear by simply calling these other functions. Actually I'm not so sure whether the function LaSymmBandMatFactorize() is useful. If that functionality better lives inside some LaSymmBandFactDouble class methods then I'd encourage you to remove the function and move the code to suitable class methods. > The LaLinearSolveIP-function is because I think often the arguments can > be overwritten because they are not needed any longer. So it would be > rather useless to allocate memory for a new factorization. I hope you agree. An additional "IP"-function is almost always a *good* thing. You might even think about implementing the non-IP version of that function in terms of the IP-version... but I think I've already said this. > Several other things: > > 1. You have written in gmd.h > > * Optional runtime bounds checking (0<=i<=m, 0<=j<=n) is set > * by the compile time macro LA_BOUNDS_CHECK. > > This is wrong, it should be (0<=i<m, 0<=j<n), m and n are already out of > bounds. You are correct. The comment is wrong. > 2. What is the correct meaning of A.size(int d) ? I think the code > > for (int i=0; i<A.size(0); i++) > for (int j=0; j<A.size(1); j++) > A(i,j)=1.0; > > should never fail. Do you agree? No, I think size() should give the dimensions in terms of the "mathematical" viewpoint, not in terms of the internal storage implementation. So I think this code in fact does fail as soon as the internal storage is different from the "mathematical" matrix dimension in question, which is probably true for all matrix classes except the "General" (dense) ones. At least that's what I *thought* until I started to look at LaSymmBandMatDouble::size() -- > If so, the size-function in > LaSymmBandMatDouble is still wrong, because it does not return size(0)=N > and size(1)=N but size(0)=2*P+1 and size(1)=N. I don't know if it's part > of the programmer (of the library) to set this correct so that size(0) > returns N or if the user of the library should pay attention to this. > What do you think? The size() function in LaSymmBandMatDouble might very well be wrong. If you're redesigning this class, the decision is pretty much up to you. Only make sure you clearly explain the meaning of size(), especially if it is different from my described meaning above which would hold for the General/dense matrices. Regards, Christian [1] http://cstimming.de/index.php?option=com_content&task=view&id=28&Itemid=41 [2] http://sourceforge.net/cvs/?group_id=99696 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRV2RwmXAi+BfhivFAQJ+DwP8CcQVRXtK2MAeQwRKeMJzArv9ctJcHsSU KpRCrkLVTCDIBjYc9ycIUO6d5YxVNvzUK0iUCHT4b74UtczkxiQIH57kPhDhXG1f zMW0r3UCAhlvt88QaHqw9CjzhAtZtP4rrMct/sjMrRife46B1o95ETZGpqF8pMtB p7ma2djAVMQ= =XuiU -----END PGP SIGNATURE----- |
|
From: Dominik W. <dom...@ar...> - 2006-11-19 08:33:44
|
> You didn't send it to the mailing list, only to me directly. In the > future please make sure you always send a CC to the mailing list I'm sorry for that. Would be easier, if the mailing list would be standard and your mail as CC. ;) > Please always use the code from CVS, now that you're actually working > with it. I already did some changes. You see, this is the first "project" I working with where several other people are workig with. Sorry again. > As for inline vs. non-inline: I want to reduce the "inline" functions > to a minimum, because they contradict the OO-paradigm of "hiding the > implementation" (and make debugging harder, among other things). Hm, maybe I'm more mathematican than programmer. I've never heard of these "inline" before and have left these entries as they were before. I have read what "inline" stands for but I cannot decide where it useful, because I would never use it on my own. But I try to guess the correct usage. > If possible, please think about splitting the code to a .cc file so that > only the useful functions stay inline and the others are defined in the > .cc file. I can do this the next week. > Also, please think about adding a test program (in > matrix/test/blablabla.cc) so that the correct functioning can be tested > automatically. I will take a look at the other files in there. I doesn't have a clue what I should test. ;) > Actually I'm not so sure whether the function LaSymmBandMatFactorize() > is useful. If that functionality better lives inside some > LaSymmBandFactDouble class methods then I'd encourage you to remove the > function and move the code to suitable class methods. Me too. In my first changes I do not want to change too many things at once. But I haven't understood it either why not assigning / referencing a Matrix in the constructor and do the factorization with a class method. I will do this the next time. >> 2. What is the correct meaning of A.size(int d) ? > No, I think size() should give the dimensions in terms of the > "mathematical" viewpoint, not in terms of the internal storage Okay, I will change this. I hope it's okay, if I paste the other mail below for answering... > Are you subscribed to the lapackpp-cvs list? You should. I wilI! :) > Is sybmd.h really a *symmetric* banded matrix? Is this fact of symmetry > used anywhere inside this class? > Surely, in terms of optimized storage, > we would need to store only 1*p+1 instead of 2*p+1 elements... No and yes. ;) The memory space is not optimized for the same reason as LaSymmMatDouble uses the same memory as LaGenMatDouble. In each Lapack-function you can use the upper or lower part of a matrix to do the changes. Of course only one side is necessary in symmetric matrices but that is not interesting for lapack-functions. It must use the whole memory. Do you know how the memory is accessed by lapack or blas? Maybe we could change it. In other methods like copy or operator() the symmetry is used of course. > Seems to me the matrix class itself rather implements a general band matrix No. It is a banded matrix with same bandwith in subdiags and superdiags. :) So it's a type of special band matrix in terms of memory usage. But the class LaSymmBandMatDouble uses internally only half of the memory. I do not know much about Lapack storage but I think you could not and should not change it or Lapack-functions will fail. But I do not know it for sure. Again two other hints: 1. In laslv.h you forget to #include LA_VECTOR_DOUBLE_H You will get an error including this file without including lavd.h yourself before. 2. Last time you suggested Blas_R1_Update for C := A' * A. Unfortunately this function is broken or does not work that way. The reason is that the lapack-function inside will alway perform C := alpha*A*A' + beta*C because "trans" is set to 'N'. You have no chance to do C := A' * A. The same with Blas_R2_Update. You only perform C := alpha*A*B' + alpha*B*A' + beta*C but alpha*A'*B + alpha*B'*A + beta*C is not acessable. You should add some new parameter for these functions or create different function as you have done with Blas_Mat_Mat_Mult and Blas_Mat_Trans_Mat_Mult. Greetings, Dominik |
|
From: Christian S. <sti...@tu...> - 2006-11-19 20:50:50
|
Am Sonntag, 19. November 2006 09:33 schrieb Dominik Wagenfuehr: > > Please always use the code from CVS, now that you're actually working > > with it. I already did some changes. > > You see, this is the first "project" I working with where several other > people are workig with. Sorry again. No problem. > > As for inline vs. non-inline: I want to reduce the "inline" functions > > to a minimum, because they contradict the OO-paradigm of "hiding the > > implementation" (and make debugging harder, among other things). > > Hm, maybe I'm more mathematican than programmer. I've never heard of > these "inline" before and have left these entries as they were before. I > have read what "inline" stands for but I cannot decide where it useful, > because I would never use it on my own. But I try to guess the correct > usage. Ok, and it's of course a good approach to leave the stuff as it is as long as you don't know the reasons for it. So for "inline" in general: Usually you don't need this and don't have to think about it - simply declare the functions in the .h file and define (implement) them in the .cc file. However, at runtime there is a certain fixed overhead for each time when a function is called. For some specific functions that are called a *lot* one wants to avoid that overhead, and the compiler can do that by directly inserting "the body" of the called function into the place where it has been called. This is called inlining. For this to work, the function's definition (not only the declaration) has to be in the header file, which contradicts the whole point of OOP "hiding the implementation" paradigms. Therefore it should be used only when one is really sure about the benefit. The obvious example is operator(): This is called a *lot* as soon as a client application uses a(i,j)=... inside of the O(n^2) loop. And its function definition contains very few statements - probably only one if-clause and one address calculation. In that case inlining that function may give a noticable performance improvement at runtime. In those classes that I've reviewed already, I made sure to keep only those methods inline. Everything else is just a normal function. > > Also, please think about adding a test program (in > > matrix/test/blablabla.cc) so that the correct functioning can be tested > > automatically. > > I will take a look at the other files in there. I doesn't have a clue > what I should test. ;) Look into matrix/test/tgc.cc which should give a good idea about what to test for such a matrix class. > > Actually I'm not so sure whether the function LaSymmBandMatFactorize() > > is useful. If that functionality better lives inside some > > LaSymmBandFactDouble class methods then I'd encourage you to remove the > > function and move the code to suitable class methods. > > Me too. In my first changes I do not want to change too many things at > once. But I haven't understood it either why not assigning / referencing > a Matrix in the constructor and do the factorization with a class > method. I will do this the next time. I think there are several possibilities how such a factorization class can make sense. IMHO include/gfqrc.h is one such possibility. Not having a class at all but instead offer several functions (which will then be wrapper functions for the LAPACK factorizations) is also one such possibility. Your current sybfd.h is probably also fine. The current (very old) version of gfd.h, on the other hand, is no useful possibility. > >> 2. What is the correct meaning of A.size(int d) ? > > > > No, I think size() should give the dimensions in terms of the > > "mathematical" viewpoint, not in terms of the internal storage > > Okay, I will change this. Fine. > > Is sybmd.h really a *symmetric* banded matrix? Is this fact of symmetry > > used anywhere inside this class? > > Surely, in terms of optimized storage, > > we would need to store only 1*p+1 instead of 2*p+1 elements... > > No and yes. ;) The memory space is not optimized for the same reason as > LaSymmMatDouble uses the same memory as LaGenMatDouble. In each > Lapack-function you can use the upper or lower part of a matrix to do > the changes. Of course only one side is necessary in symmetric matrices > but that is not interesting for lapack-functions. It must use the whole > memory. Do you know how the memory is accessed by lapack or blas? Maybe > we could change it. > > In other methods like copy or operator() the symmetry is used of course. Ah! Oh! Ok! Suddenly I've understood the whole point of symmetric matrices in LAPACK! No, I think the rationale in LAPACK is that you will store two symmetric matrices U and L in the memory space of one non-symmetric matrix A - for U you only access the upper part of A, and for L you only access the lower part. That's why all these functions (e.g. dsysv) say that you can choose which part of A is being used as the symmetric matrix. However, that means that memory saving is only obtained when U references the same memory space as L. That can easily be done in Fortran or C, when the programmer allocates the matrix A by himself/herself anyway. However, in lapackpp when the LaSymmMatDouble class allocates the matrix A itself, it obviously cannot use the same allocated storage as another LaSymmMatDouble currently. So right now I'd say the classes are prepared to use the memory space of A for both one U and one L, but there are not class methods available to actually put both U and L into the same memory space A. And I also cannot think of an easy solution here that would be all of this: 1. easy for non-mathematics, 2. give the correct results, and 3. is powerful enough to actually achieve this memory optimization. Sigh. > > Seems to me the matrix class itself rather implements a general band > > matrix > > No. It is a banded matrix with same bandwith in subdiags and superdiags. > :) So it's a type of special band matrix in terms of memory usage. But > the class LaSymmBandMatDouble uses internally only half of the memory. I > do not know much about Lapack storage but I think you could not and > should not change it or Lapack-functions will fail. But I do not know it > for sure. Yes. Agreed. > 1. In laslv.h you forget to > > #include LA_VECTOR_DOUBLE_H > > You will get an error including this file without including lavd.h > yourself before. Thanks. Applied to CVS. > 2. Last time you suggested Blas_R1_Update for C := A' * A. Unfortunately > this function is broken or does not work that way. The reason is that > the lapack-function inside will alway perform > > C := alpha*A*A' + beta*C > > because "trans" is set to 'N'. You have no chance to do C := A' * A. > > The same with Blas_R2_Update. You only perform > > C := alpha*A*B' + alpha*B*A' + beta*C > > but alpha*A'*B + alpha*B'*A + beta*C is not acessable. You should add > some new parameter for these functions or create different function as > you have done with Blas_Mat_Mat_Mult and Blas_Mat_Trans_Mat_Mult. Yes, I know the "transpose" argument isn't solved in a nice way in lapackpp. The current functions use the "Different function names for different arguments" approach. Alternatively, one could boolean argument(s) to control the transpositions. Actually I'd probably prefer the latter approach with explicit boolean arguments (with reasonable default values). So if you're working on "dsyrk" of Blas_R1_Update, you can just as well add an alternative function where the transpose setting is controlled by an additional boolean argument. And since you're adding a new function, you can even choose the name for yourself :-) For the existing matrix multiplications I might add something like that in the future. (The existing functions will still be kept, of course.) You're still invited to give me your sourceforge username and join the lapackpp project as a developer :-) Regards, Christian |
|
From: Dominik W. <dom...@ar...> - 2006-11-20 10:54:36
|
> Not having a class > at all but instead offer several functions (which will then be wrapper > functions for the LAPACK factorizations) is also one such possibility. I think this makes more sense for sybfd.h than a a whole class you don't use. So I will delete the class and will only use functions. The first function will then be delete as well. > And I also cannot think of an easy solution here that would be all of this: 1. easy > for non-mathematics, 2. give the correct results, and 3. is powerful enough > to actually achieve this memory optimization. Sigh. Did you take a look at the PP-classes that means "real symmetric positive definite matrix stored in packed format", see http://docs.sun.com/source/806-7993/dpptrs.html. I haven't found a description what this matrices looks like but I would guess that only one half of the matrix is stored. > So if you're > working on "dsyrk" of Blas_R1_Update, you can just as well add an alternative > function where the transpose setting is controlled by an additional boolean > argument. And since you're adding a new function, you can even choose the > name for yourself :-) I will do so. But boolean is not enough because it could be N, T or C as argument. Although I have never heard of Blas_R1_Update before I will use the same name and will set the last char parameter as default='N'. So we have backward compatibility and could use the new function. :) > You're still invited to give me your sourceforge username and join the > lapackpp project as a developer :-) Yes. The username is "deedw" without quotes of course. :) But I have never used CVS so it may be that I will send the new files to the mailing list. Greetings, Dominik |
|
From: Christian S. <sti...@tu...> - 2006-11-21 10:30:15
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dominik Wagenfuehr schrieb: >> And I also cannot think of an easy solution here that would be all of >> this: 1. easy >> for non-mathematics, 2. give the correct results, and 3. is powerful >> enough to actually achieve this memory optimization. Sigh. > > Did you take a look at the PP-classes that means "real symmetric > positive definite matrix stored in packed format", see > http://docs.sun.com/source/806-7993/dpptrs.html. I haven't found a > description what this matrices looks like but I would guess that only > one half of the matrix is stored. Thanks for pointing this out. The link to "dpptrs" and "dpptrf" can be added to the documentation of LaSymmMatDouble, just for future reference. The description of the format is in the description of the input argument "A" and/or in the man-page of dpptrf, "man dpptrf". See also http://www.netlib.org/lapack/lug/node121.html and its subsections which is probably an even better explanation. However, currently lapackpp doesn't use the "packed storage" matrix format at all. That means none of the packed-storage LAPACK function are declared in the C header files include/blas*.h. Obviously all the "symmetric" classes and related LAPACK solver functions were only using the normal storage scheme, where no storage savings were achived. You can now either add the packed storage with its related solver functions as an additional set of classes and functions (LaPSymmMatDouble, for example). Or we can decide to switch the existing symmetric classes over to packed storage. Unfortunately I have no idea whether anyone relies on the existing symmetric classes. To be on the safe side, I'd definitely prefer to have the packed storage as additional classes... Funny enough, LAPACK seems to have some more functionality for the conventional storage than for the packed storage. For example, the eigenvalue decompositions (dsyev,dsyevd, dsyevr, dsyevx) seems to be unavailable for packed storage. >> So if you're working on "dsyrk" of Blas_R1_Update, >> you can just as well add an alternative >> function where the transpose setting is controlled by an additional >> boolean argument. > > I will do so. But boolean is not enough because it could be N, T or C as > argument. Although I have never heard of Blas_R1_Update before I will > use the same name and will set the last char parameter as default='N'. > So we have backward compatibility and could use the new function. :) What is the difference between 'T' or 'C'? I don't see any. Therefore there are only two possibilities. >> You're still invited to give me your sourceforge username and join the >> lapackpp project as a developer :-) > > Yes. The username is "deedw" without quotes of course. :) But I have > never used CVS so it may be that I will send the new files to the > mailing list. You are added as a developer now. If the anonymous CVS access is too slow, you can switch over to the developer access. Submitting changes by email is still fine, though. Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRWLVHmXAi+BfhivFAQJiGgP8CxMVDuMpFsBFOYaE878YOvBYWGNb0DFQ ATECzWqQOn/YwtS8OA4T9bRrraLKPlS0EhrNtyBGpS5MMaSuVOvmidoWedLyU6/y yaSwRb3+5aplAorq7HxeUsGRymud4gj5Hiiw/HnGsZR9Co3IvFlDk8h6VIIaLgg/ ObWesLXvcq8= =DADX -----END PGP SIGNATURE----- |
|
From: Dominik W. <dom...@ar...> - 2006-11-20 18:38:01
Attachments:
lapackpp.tar.bz2
|
Attached you find the new files. This time I used the cvs-ones. ;) What I have changed: blas3pp.h - add documentation and default value for trans blas3pp.c - set default value and add assert sybfd.h - delete old factorize class and use functions only sybfd.cc - create new file with functions sybmd.h - set correct class description and set size(0)=size(1) > Look into matrix/test/tgc.cc which should give a good idea about what to test > for such a matrix class. Unfortunately my test class does not what it should do. LaSymmBandMatDouble is okay but LaSymmBandFactDouble returns a "wrong" Cholesky factorization. I'll try to fix the error. BTW: Have you thought about a better error handling? I think a library should never ever break a program. But your assertion does nothing else. The program quits without any message. I use Lapack++ in a GUI so I only see an output if I create console test case and try to reproduce the crash. Anyway: A backend should never crash a frontend. Greetings, Dee |
|
From: Dominik W. <dom...@ar...> - 2006-11-21 10:06:19
Attachments:
blas3pp.cc
tsybmd.cc
|
Attached you find a corrected version fo blas3pp.cc (There were some errors in it, sorry for that!) and a test case tsybmd.cc for LaSymmBandMatDouble and LaSymmBandFactDouble. The classes were correct only my example was wrong. ;) Another question: doxygen does not show the new comments in blas3pp.h because of the #ifdef before. What do we do here? Greetings, Dominik |
|
From: Christian S. <sti...@tu...> - 2006-11-21 12:20:20
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Dominik,
thanks a lot for your contributions. By now I've reviewed all of them
and commited them into CVS. In blas3pp.{h,cc} I've replaced the "char"
argument back to "bool" just as I proposed before.
Dominik Wagenfuehr schrieb:
> Attached you find a corrected version fo blas3pp.cc (There were some
> errors in it, sorry for that!) and a test case tsybmd.cc for
> LaSymmBandMatDouble and LaSymmBandFactDouble. The classes were correct
> only my example was wrong. ;)
In this mail from 11:06 Uhr you attached a file blas3pp.cc that was
identical to the CVS version of that file at that time, not one with
some errors fixed. I've committed your file of yesterday into CVS. If
there are still errors, feel free to send me an updated / corrected
version now.
> Another question: doxygen does not show the new comments in blas3pp.h
> because of the #ifdef before. What do we do here?
There doesn't seem to be an easy solution in terms of doxygen commands.
However, these whole functions don't need to have the full class
definition of LaSymmMatDouble available - it is sufficient for the
compiler to have a forward declaration of those classes only. Therefore
I've removed the ifdef that asks for the included header, and instead
I've added the appropriate forward declaration. As a nice side effect,
this solved the doxygen issues as well.
Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQCVAwUBRWLu92XAi+BfhivFAQK5oQP/TkizqagPUKTooN1n44wgAREaMCK1s3i8
8omwkJVgujk54GiQsw+DTUun1YV1SYlfh9I+H+aolAE9bcWAQH7I7DBi8SoDO1h+
hmcakLyJb4hN+cV7yPrGzkMN/6nAUbwKisDlTkYnXL6KMDggX0FQJTEVi/rQOg3p
o86MA1+Utsc=
=1FGS
-----END PGP SIGNATURE-----
|
|
From: Christian S. <sti...@tu...> - 2006-11-21 13:44:41
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dominik Wagenfuehr schrieb:
> BTW: Have you thought about a better error handling? I think a library
> should never ever break a program. But your assertion does nothing else.
> The program quits without any message. I use Lapack++ in a GUI so I only
> see an output if I create console test case and try to reproduce the
> crash. Anyway: A backend should never crash a frontend.
Yes and no. For "normal" error events that can occur during runtime
("file not found" or similar) this is perfectly true. However, the
assertions in lapackpp are intended to check for *programming* errors.
The header file documentation clearly says (well, it *should* say) that
for certain operations, certain conditions have to be fulfilled. E.g.,
the matrix dimensions of Blas_Mat_Mat_Mult must fit to each other. This
is a condition which the application can easily check *before* it calls
these functions - and for this reason lapackpp can rely upon these
conditions being fulfilled. That's the meaning of such an assertion.
If those conditions are not met, then most probably the application
programmer just made a programming error. Having some exceptions instead
of assertions IMHO don't change this much - in any case a user cannot do
anything about this failed condition; the programmer must fix the
application anyway. Therefore I want to have these checks as easy as
possible, and simply writing assert(...) IMHO is the easiest way.
In principle each of these assertions should be mentioned in the
documentation, like "This function requires the following assertions to
be true: A.size(0) == bla bla bla". In practice, the assertion are a
very helpful tool to find out programming errors as early as possible.
As a rule of thumb I'd suggest in every (non-trivial) function, the
correct value range of the function arguments should be checked by
assertions.
Depending on your libc and the compile flags during compiling lapackpp,
a failed assertion should indeed print an error message including the
source code file name, line number, and the failed condition. If this
isn't the case, you should consider recompiling lapackpp with
- --enable-debug and/or CXXFLAGS="-g -O0" and so on.
Regards,
Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQCVAwUBRWMCvGXAi+BfhivFAQLgsAP9ElQxrNBXVeYjNMCgGEphCy0kyDzRua85
Vt8Wf6spWEqzN+dR5/5oXlLBl8wQIX80Ydga2N+xkSp40jODxz52yq5UZJvsP6wu
ihq6kOmSlGOcwUhUNyofvEbZfzrypL0dCIEjiyRzPdF4PZ2j0jeNVz1o50lioUhP
CZ2/rddqX3E=
=tYvX
-----END PGP SIGNATURE-----
|
|
From: Dominik W. <dom...@ar...> - 2006-11-22 11:12:52
Attachments:
resize.tar.bz2
|
Hello, could you please add the resize-methods in the files attached (These are the changed CVS-files!). I need to resize a symmetric matrix and a vector and therefore had to implement it in these classes. I have changed nothing else, so the matrix classes are far from optimized. Do you know why LaSymmMatDouble needs two arguments in the constructor? Unfortunately it's not even checked if they are the same, I mean "assert ( m ==n );" ... Greetings, Dominik |
|
From: Christian S. <sti...@tu...> - 2006-11-22 12:05:31
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dominik Wagenfuehr schrieb: > could you please add the resize-methods in the files attached (These are > the changed CVS-files!). I need to resize a symmetric matrix and a > vector and therefore had to implement it in these classes. I have > changed nothing else, so the matrix classes are far from optimized. Ok, applied. Thanks a lot. I've modified your proposed version in the LaVectorDouble in order to have the same behaviour as the existing size arguments in the constructor. > Do you know why LaSymmMatDouble needs two arguments in the constructor? > Unfortunately it's not even checked if they are the same, I mean "assert > ( m ==n );" ... Interesting :-) . No, I don't know. In the current form this is obviously wrong. The LaSymmMatDouble matrix, as well as the LowerTriangBlaBlaBla matrix, should have a one-argument constructor each. Regards, Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRWQ882XAi+BfhivFAQK6HgQAqCJePmHhzxP19t4DGn3+vC/KuaJJ7FHM yWvl2PLLOeyOG7L2/eOidRBrhz0JYer7qiF+YZYb8aYZPTvXNCtCThqgUyNTCSAG f5Kv+rbOVM4D7c3tp5PbmQAJ/tMFHsTma8QQJexW6kgfnp6nXf1AofZgOK3tK0MB y4Jo5IoYUrI= =EDWd -----END PGP SIGNATURE----- |
|
From: Dominik W. <dom...@ar...> - 2006-11-24 13:29:20
|
>> Do you know why LaSymmMatDouble needs two arguments in the constructor? >> Unfortunately it's not even checked if they are the same, I mean "assert >> ( m ==n );" ... > Interesting :-) . No, I don't know. In the current form this is > obviously wrong. The LaSymmMatDouble matrix, as well as the > LowerTriangBlaBlaBla matrix, should have a one-argument constructor each. I agree. At this time someone can allocate a "symmetric" matrix with dimension 10x100 if he likes to do. I do not know what the result is if you call a Lapack-function with it... I don't use symmetric matrices that much so I do not know why it's "derived" from a triangular matrix and why it uses two dimension. Maybe I have time to review the code at my holidays at end of december. > However, currently lapackpp doesn't use the "packed storage" matrix > format at all. [...] You can now either add the packed storage with its > related solver functions as an additional set of classes and functions > (LaPSymmMatDouble, for example). As I said above I do not use symmetric matrices and I do not know much about the storage scheme for Lapack. So I'm afraid I won't be a help here... > Or we can decide to switch the existing > symmetric classes over to packed storage. Unfortunately I have no idea > whether anyone relies on the existing symmetric classes. Hm, good question. As in lapackpp-classes you have no choice to directly access the "dead" part of the memory. So it may be no difference if we change it to packed storage. But as you point out, not all Lapack-functions are implemented for packed storange so a new class would be much better. Greetings, Dee |
|
From: Dominik W. <dom...@ar...> - 2006-11-24 13:05:39
|
> However, the assertions in lapackpp are intended to check for *programming* errors. Okay. I have another aim here... In my libs I try to catch all errors even programming errors. But it's okay if you do not want to add a real error class. > a failed assertion should indeed print an error message including the > source code file name, line number, and the failed condition. Without a console no output! :) As I said before if you use your in lib in a GUI-Tool the tool just quits without any hint why it does crash... Of course it's a programming error of the GUI-programmer because he has made a mistake in matrix allocation or something, but I do not know if a user cares about that. He only sees his GUI crash and loose all data. ;) Greetings, Dominik |
|
From: Christian S. <sti...@tu...> - 2006-11-24 14:58:28
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dominik Wagenfuehr schrieb: >> However, the assertions in lapackpp are intended to check for > *programming* errors. > >> a failed assertion should indeed print an error message including the >> source code file name, line number, and the failed condition. > > Without a console no output! :) As I said before if you use your in lib > in a GUI-Tool the tool just quits without any hint why it does crash... > Of course it's a programming error of the GUI-programmer because he has > made a mistake in matrix allocation or something, but I do not know if a > user cares about that. He only sees his GUI crash and loose all data. ;) I still believe modifying the assertions is the wrong place to do something about this. As for the output - I think this is usually redirected to ~/.xsession-errors, and you could just as well redirect the stdout of your GUI-Tool to somewhere else. Additionally, you can install a different handler for abort()... but whatever. You've challenged me to do something here. By now I've modified the LaException class so that you can switch the assert() behaviour from the normal abort() to throwing a LaException exception. To do this, you will have to uncomment some lines in the laexcp.h header file, which will effectively redefine the assert() macro so that it throws an exception instead of aborting. So: Checkout the latest CVS code; change the laexcp.h header; compiler and install; and at the next failed assert() you will get a thrown LaException instead of a failed assert. Is this what you wanted? Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRWcIe2XAi+BfhivFAQKpLQP/dtQ7x+58g+nqSPPSIR5azNkjOB0u2wQ4 3Iqr331itGsngCGs9z9ZFcBH8YM2R5xQ/AS+s5mkE4/PGFsOka/pwOVlDF2dh+gd Eq1peR918lFLiiRnDm5fIsXgGdEocjJO+cwssZ1S6tzVIu5VYv8HWypW9YtlUkCg rSwydZirhRw= =/Bp9 -----END PGP SIGNATURE----- |
|
From: Dominik W. <dom...@ar...> - 2006-11-24 15:26:14
|
> As for the output - I think this is usually redirected to
~/.xsession-errors,
What's the Windows pendant?
> and you could just as well redirect the stdout of your GUI-Tool to
somewhere else.
Unfortunately I'm not programming the GUI at all. I just programm
another library used by a GUI. Somewhat complicated here...
> and at the next failed assert() you will get a thrown LaException
instead of
> a failed assert. Is this what you wanted?
I will take a look at it. Maybe I should describe how I do my error
handling in libraries. :)
I have a special static class called MyMessage with different enums for
each error that can occur. If in a function an error occures I do
MyMessage::Set(ERROR_DEFINEMENT, "Class::FunctionA");
return(true);
The functionB that called this failed functionA sees in the return
argument that something went wrong. It now can decide if to goes one or do
MyMessage::Append("Class::FunctionB");
return(true);
In this way I will create an error stack in the static class. At top
level (that means in the GUI in most cases) I finally now can get the
error and the stack
MyMessage::GetMessage() and MyMessage::GetStack()
and give the user a correct output. This means in a console application
a console output, in a GUI-app maybe a little window message.
Further sometimes the user can decide what he wants to do now. In most
cases he should copy the message, save all his data (as far as this is
possible) and send a bug report to me. But if the GUI just crashes
(maybe after an hour of computing something) without any output the user
may become a little impatient. ;)
I know that this is complicated especially implementing the return
values of all functions (it took me a dew days to change my code.) And
now I could not return something else but do most things by call by
reference. The advantage of it is that my library (or better the program
of a user with my library) never crashes unless the programmer does not
catch my error output and just go on as nothing happens.
You can read something about this indirect error control in
Piegl/Tiller: "The NURBS Book", p. 607, chapter "B-spline Programming
Concept / Error control". There my be better programming books for it
but this one explained it clear enough. :)
Greetings, Dominik
|
|
From: Christian S. <sti...@tu...> - 2006-11-24 15:39:36
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dominik Wagenfuehr schrieb:
>> As for the output - I think this is usually redirected to
> ~/.xsession-errors,
>
> What's the Windows pendant?
I don't know. I don't know windows that much.
>> and at the next failed assert() you will get a thrown LaException
>> instead of a failed assert. Is this what you wanted?
>
> I will take a look at it. Maybe I should describe how I do my error
> handling in libraries. :)
>
> I have a special static class called MyMessage with different enums for
> each error that can occur. If in a function an error occures I do
>
> MyMessage::Set(ERROR_DEFINEMENT, "Class::FunctionA");
> return(true);
>
> The functionB that called this failed functionA sees in the return
> argument that something went wrong. It now can decide if to goes one or do
>
> MyMessage::Append("Class::FunctionB");
> return(true);
>
> In this way I will create an error stack in the static class. At top
> level (that means in the GUI in most cases) I finally now can get the
> error and the stack
>
> MyMessage::GetMessage() and MyMessage::GetStack()
>
> and give the user a correct output. This means in a console application
> a console output, in a GUI-app maybe a little window message.
I think you can do this very well by using the new modifications in
laexcp.h, and then you enclose each lapackpp call by
try{
// ...
}
catch (LaException &e) {
MyMessage::Set(BLA, e.what() );
}
and continue accordingly.
> Further sometimes the user can decide what he wants to do now. In most
> cases he should copy the message, save all his data (as far as this is
> possible) and send a bug report to me. But if the GUI just crashes
> (maybe after an hour of computing something) without any output the user
> may become a little impatient. ;)
>
> I know that this is complicated especially implementing the return
> values of all functions (it took me a dew days to change my code.) And
> now I could not return something else but do most things by call by
> reference. The advantage of it is that my library (or better the program
> of a user with my library) never crashes unless the programmer does not
> catch my error output and just go on as nothing happens.
>
> You can read something about this indirect error control in
> Piegl/Tiller: "The NURBS Book", p. 607, chapter "B-spline Programming
> Concept / Error control". There my be better programming books for it
> but this one explained it clear enough. :)
This kind of error handling seems a bit twisted to me, and at least the
"one static class" concept isn't any different than the standard libc
approach with one static variable errno. Whatever. I guess it will work
anyway.
Have fun,
Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQCVAwUBRWcSK2XAi+BfhivFAQIUsAP+Phm/2i46JL2y66nkCvCs0U/pmEHHF7KA
2733vCd20WC8KReXdret1dbE8eWCO3tf4D3hpJ3hEJ9edFGPtZEgDrPuRynt8cXZ
oYSDBRok/fHCZFyje7TU5goWRywhOqWwdellG/zQW4N+UTv4NLBlxAgUh/xeMXbz
i10y18RRIuw=
=zNOb
-----END PGP SIGNATURE-----
|
|
From: Christian S. <sti...@tu...> - 2006-11-17 11:11:07
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dominik Wagenfuehr schrieb: > Please take a close look at the documentation. I'm not that much > experienced with doxygen syntax... Most parts I have copied from gmd.h. > I hope this is okay. :) Review finished. Feel free to work with the latest CVS code now. Are you subscribed to the lapackpp-cvs list? You should. But after I read the wikipedia page http://en.wikipedia.org/wiki/Band_matrix I actually asked myself: Is sybmd.h really a *symmetric* banded matrix? Is this fact of symmetry used anywhere inside this class? Surely, in terms of optimized storage, we would need to store only 1*p+1 instead of 2*p+1 elements... Seems to me the matrix class itself rather implements a general band matrix, and only the particular LAPACK functions will use this only as symmetric matrix. Maybe in that case we might consider renaming this class to LaBandMatDouble and have a different class make up a LaSymmBandMatDouble? Whatever. I don't really care. Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRV2Yv2XAi+BfhivFAQKItAP8DOd0a01RlOPPDpaaqQtkMrjBOc00kR7c 6BApgPQtuNeXn4vKSbxNh2ZTZE0iw9wnq9xIln9x7+gSvgwqlz6MmiTLxBctADno DS/3roxSQOe63F8srQtq21oxrMgikXeAtRG3qRLzb0/R9+zE2mGwvNGCWblG2FTH 9iNIyr4WJKI= =9FlK -----END PGP SIGNATURE----- |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X