Letters to the editor may be sent via email to [email protected], or via the postal service to Letters to the Editor, C/C++ Users Journal, 1601 W. 23rd St., Ste 200, Lawrence, KS 66046-2700.
In a footnote to his article on complex numbers in the March 2002 issue of CUJ, Matt Austern suggests that the name “norm” used to denote the square of the absolute value of a complex number is somehow arbitrary. I disagree: this is a perfectly standard term in algebraic number theory for the product of the conjugates of an element of a field extension and applies perfectly to a templated complex number class.
John Wilkinson
In the world of algebraic number theory, then, we’re in good shape. Perhaps Matt was commenting on that fact that in many areas of applied mathematics, “norm” usually denotes the square root of that product, most notably, the Euclidean norm for finite-dimensional vector spaces. In fact, in the theory of linear spaces, “norm” is considered a generalization of length, which supports using the square root. Because of the similarity of two-dimensional Euclidean space to the complex plane, the term “norm” most often refers to the Euclidean norm, which is the square root of what std::norm computes. Both quantities satisfy the properties of norms, of course, but most practitioners in disciplines with physical, scientific applications (i.e., those that use computers in their daily work of numerical computation) find a function named “norm” that returns the square of the Euclidean norm a bit odd, so they naturally look askance at std::norm.
By the way, in the footnote of that article, my editorial comment should have read “how about norm2,” (for some reason it was edited incorrectly to read “how about norml”) to suggest “norm-squared.”
Thank you for the positive feedback. (We need all we can get!). — cda
Hello.
I do some numerical programming and would be interested in issues on floating-point math algorithms: tips for enhanced speed and accuracy, etc.
For example, a specific program I am working on at the moment requires me to write a matrix inversion utility for dynamic two-dimensional arrays (an N by N array) in C++. The user will input the size, N, of the array he wants to analyze, the data will then be read from a file, and my utility will solve it. I have been on several forum sites, and everybody has a different way of doing it. I would like to know if there is a “best practices” for the input of dynamic two-dimensional arrays in C++.
I would be interested in similar “best practices” for other generic scientific/engineering applications; for example, matrix inversion, numerical integration, root finding, etc.
Do you have an upcoming issue planned that will address some of these issues? Or if they have already been covered in previous issues, please let me know the issues, so I can dig up the relevant back issues.
Thank you.
David Binner
We occasionally run articles of this nature, especially in our Scientific Programming theme issue (November). You can find many answers in the excellent book, Numerical Recipes in C++, by William H. Press et al, Cambridge University Press, 2002.
CUJ,
After reading Fabio Lopiano’s article, “Sending Objects across Platforms” (October 2001), I decided to go ahead and try his approach. However, what I soon realized was that there was no support for sending char * (eg. char *t=new char[10];) class members easily using his method. Of course, you can cheat by using the netarray class (or something very similar to it), but that means you need to specify the size of the char * both when sending and receiving to/from the buffer. This leaves me wondering if there’s a better way to implement the support of char * class members (and most other pointer types, by the way).
When sending an object through the network, both sides need to know the object’s exact size. If the object is an array (or in general a sequence of objects of the same fixed size), there are two possibilities: either both sides know in advance the number of elements of the sequence, or this information must be sent along with the objects. The first case is addressed by the class NetArray<>, the latter by NetVector<>.
So, if you use those two classes (or other containers structured in the same way) to store your sequences, you should not have any problems.
On the other hand, if you insist on using a char * member in your class, you should keep track of how many elements it holds in some way (not only in order to send them through the network, but also to access them in your program).
It is enough to send the length before the data and use it in the receiving side to allocate enough memory to store the array. For example:
class A : public NetObject { char * data; // ... other members omitted void netWrite(NetBuffer &buf) const { // get number of elements in data[] int len = ... buf << len; for(int i=0; i<len;++i) buf << data[i]; } void netRead(NetBuffer &buf) { int len; buf >> len; char new_data = new char[len]; for (int i=0; i<len;++i) but >> new_data[i]; delete[] data; data = new_data; } };
Note that there is no portable way to determine the size of memory pointed to by a char *, so it’s up to your class to keep the accounting for the length of the array. But again, I suggest using standard containers like std::vector<> to store your data and wrapping them with NetObject-derived classes like NetVector<> to use them inside objects that must be sent over the Internet.
A final note about your piece of code: in order to delete[] an array, the compiler may keep track of the number of elements pointed to, but not where you are looking at it. In fact, this information should survive the function where the data is allocated (in order to allow the deletion in other functions), so the information must be kept in the heap and not in the stack. For example, this information may be put in the few bytes before the start of the array. Again, the information is compiler-dependent, and usually it does not match the exact size of the array, but the size actually allocated (which may be rounded up to some multiple of eight, for example).
Best regards,
Fabio Lopiano
Dear CUJ,
I’m sure you’ve gotten a hundred letters on this, but Mark Nelson’s daughter’s homework problem (March 2002, “C++ Algorithms: next_permutation”) has no solution. His code (Listing 1, page 42) lists only five of the six constraints on the magic square. When the sixth constraint is added,
(a[3] + a[4] + a[5]) == 17
the program fails to return any results.
Grant Schultz
Hi Grant,
You are quite correct that the figure in the article has an error. Mea culpa! This is an example of a common programming problem: the documentation doesn’t match the code. And as always, you have to trust the code.
I posted an updated copy of the figure with the article on my website, <http://dogma.net/markn/articles/Permutations/>.
Thanks for keeping an eye on things!
Mark Nelson
CUJ,
I just recently read Andrew Koenig and Barbara Moo’s article “C++ Made Easier: Naming Unknown Types” (February 2002). In the article, they present three solutions to finding out the type of an expression. I think there is also a fourth way of discerning the type; however, I’m not sure as GCC 2.96 won’t compile it and I don’t know if it is a problem with GCC or with the code; so, here it is to be examined:
template< class T > class CTypeof { public: typedef T Type; }; template< class T > CTypeof<T> type_of(T) { return CTypeof<T>(); } int main() { type_of(3)::Type x = 5; }
I would really appreciate if you could tell me whether my solution is valid C++ or not, as well as if it is a general solution to determining the compile time type of an expression.
Thanks!
Tanton Gibbs
I’m sorry to say that this solution doesn’t work. The problem is that type_of is a template function, and functions return values rather than types. Whenever you use the :: operator, whatever is on the left of the :: must be the name of a scope, such as a type or a namespace, rather than an expression that denotes a value.
What you’d really like is to be able to use the . (dot) operator to select a type member. Then you could refer to type_of(3).Type and it would work. However, there is the problem that the type_of function would presumably have to be called — either that or there would have to be a rule that in an expression of the form x.y, where y represents a member that is a type, the implementation is not permitted to evaluate x.
If it were possible to extract type members of expressions in this way, I can see a number of uses for that ability. Unfortunately, the language doesn’t allow it at present.
Regards,
Andrew Koenig
