Re: Using the STL for scientific programming
Am 30.09.2011 20:10, schrieb nmm1@cam.ac.uk:
In article<j62fp2$tq5$1@dont-email.me>,
=?ISO-8859-15?Q?Daniel_Kr=FCgler?=<daniel.kruegler@googlemail.com> wrote:
I'm indeed working with STL components in purely scientific projects
since years. ...
Thanks very much. I would like to ask a few specific questions,
if I may.
Sure. Free country, free questions, free beer, etc... ;-)
associative containers (Often std::map, but arguably most of them are
unordered containers),
Thanks. That's what I noted as potentially relevant.
a lot of std::vector (internally), std::pair,
But do those really help compared with rolling your own? My point is
not that they don't work, but what practical benefits they convey.
std::vector didn't help me to roll my own analytical vector template,
but I certainly use it nearly always when I have to administrate
sequences of data that have a dynamic length or where the length is
determined by some configuration that is provided during runtime to the
program (but remains fix after this).
When writing classes that needed vectors, I discovered that using
std::vector didn't simplify the code significantly over ordinary
arrays/pointers or provide significant extra checking. It does free
space when writing a simple vector declaration and using exceptions to
jump out, but that's about all I found.
IMO it also simplifies operations on the container, e.g. like insert or
erase operations. Where I use std::vector I usually cannot use native
pointers (except for traversal and such), mostly because of the
dynamicy. I also like the fact, that std::vector is fully
self-administrating, thus my code is easy to proof exception-safe.
I agree that std::pair could be useful for one-off pairs (not as bases
for classes), if one closes one's eyes to the type-matching ambiguities
in the standard, but not everyone does that and some people consider
it bad practice.
I use pair usually internally, where the actual member names are not so
relevant. I typically have wrapper classes that provide functions with
clearer names and which internally delegate to the first and second
member of pair.
IO streams for outputs (IO manipulators),
Are they really a help compared to<cstdio>? I tried hard to use them,
found them painful, and then queried it in a C++ expert forum, only to
discover that even they found<cstdio> easier to use and more flexible.
Indeed, I found them harder to use than Fortran formatted I/O!
Honestly, I use formatting with STL IO rather frequently. I very much
like that it is robust against simple type changes (e.g. long against
int or against uint16_t). Where I really like to use <cstdio> is in
low-level IO, e.g. when I implemented a so-called IO manipulator for
engineering format (it always ensures that the floating-point values are
converted into an exponential form where the exponent is a multiple of 3
to match with the multiple-of-three SI prefixes. But I prefer to use my
C++ engineering format manipulator in my actual code.
std::exceptions
Yes, if your compiler supports tracebacks and cleaning up when you raise
them. If not, they are just trivial syntactic sugar.
I use them a lot for configuration validation of the user input. The
program typically parses a text-like file with a huge amount of program
parameters. It is very helpful to have a simple way of defining a
reasonable message and a quick program-exit but still being able to
perform some necessary post-operations (setting time-stamps and such
things).
std::string
Yes, but relatively few scientific programmers do much string
manipulation. If they do, obviously they should use that.
I'm not using the strings for the actual data processing within the
analytical engine, but usually as a storage room for some string data,
and especially within the implementation of necessary text-analysis
components, e.g. to process the user configuration. In the classical
sense, in the IO layer before and after the number crunching.
Further, I'm taking massively advantage of STL algorithms, including
those from numeric.
Interesting. Do they really save much complication? I find that the
complexity of setting up an iterator outweighs the benefit for most of
them. For example, calculating the trace of a matrix using accumulate.
The number I have looked at where it is significantly simpler to
call the algorithms than write out the code (complex transcendentals
and sorting excepted) is fairly small.
I agree that a bit work is necessary for preparing the iterator types,
especially when I started with my classes and where I didn't have
iterator facades available like those from boost. But actually I rarely
did need to write them from scratch on. And IMO the work done has been
paid back quickly because of the amount of useful functionality
available through iterators.
I found very good usages for std::find, std::fill, std::rotate,
std::partial_sort_copy, std::sort, std::replace, std::accumulate
(internally in my matrix class), std::transform (within vector and
matrix classes), ...
But that doesn't mean that I don't write my loops manually ;-)
When I would restart a new project with a
C++11 library I would have a lot of good usages for the new random
number library
Be warned: those are not very good classes of generator, and the
standard does not specify the quality of implementation. If your
program depends on subtle aspects, and especially if it is parallel as
well, they may not be a good solution.
I'm especially referring to the framework, not necessarily to the
concrete generators. This is quite similar as to concrete hash
implementations. I can still take advantage of the unordered containers
framework from a library, but I don't need to rely on the q.o.i of
concrete hash algorithms.
If anyone wants to look into this area in more depth, a good starting
point is Pierre L'Ecuyer's papers. They are NOT easy reading. Most
Web pages on this topic (and even published papers) are ghastly or
worse :-(
Thanks for the tip, Nick. I will take a look at them.
Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]