You are here
Your preferences in scientific/engineering/numerical programming
Hello everyone,
I am working on a project related to helping the everyday researcher do his/her programming easier and faster.
I have done a fair amount of research work at OSU and have gotten a feel for the way they program on a daily basis, but realize that it could be and probably is drastically different on different parts of the planet. As such, I am here to ask the following questions (really, any opinion helps, so feel free to respond with whatever you want):
1) What is/are your language(s) of preference? (e.g. MATLAB/Octave, Fortran, C, C++, Java, Python, etc.)
2) Do you use a certain programming style? (e.g. procedural, object-oriented, etc.)
3) What, if anything, is cumbersome with what you use now?
Thanks in advance for your replies.
- Epyon's blog
- Log in or register to post comments
- 10032 reads
Comments
1) Prefer C++ and
1) Prefer C++ and Python
2) Prefer a style that defers design decisions and allows me (or others) to change my mind -- some would call it object-oriented
3) Although it has conveniences for matrix operations, Fortran is a real problem as codes get larger; it does not scale well to large instruction sets, IMO. Many smart people will disagree with that though.
Re. preferences in scientific/engineering/numerical programming
1) Matlab/Octave for testing out ideas and C++ for implementation. Java for hand held devices.
2) Procedural for testing and object oriented for production code.
3) Need frameworks that make possible computationally efficient plugins for material models (nonlinear elasticity, plasticity, viscoelasticity, anisotropy) for parallel computations.
Re. preferences in scientific/engineering/numerical programming
1. First choice: C++. Second: C++. Third: C++. Fourth: SciLab. Java and the rest: Only out curiosity, to look up, so to speak (e.g. the JAMA library). However, for coding, I never take any of the rest of them very seriously.
2. Object-oriented, that starts from a simpler subset of C++ (classes, a derived class hierarchy no deeper than 1 or 2 levels, little polymorphism, almost no operator overloading) and then iteratively goes on to using the more advanced object-oriented features (templates). I try to think through use-case scenarios, but without doing full-fledged UML---not really necessary most times. However, I do try to keep Design Patterns somewhere at the back of the mind all the time---it really helps me understand, in a way, the what of programming.
3. Cumbersome:
3.1 The lack of commonly accepted, standardized interfaces (even if not implementations) or classes for: math. objects like vectors, tensors, and numerical algorithms for solution of linear and nonlinear systems (for both sparse and dense matrices), for eigenvalue computations, etc. Also, the lack of similar interfaces for geometry and mesh import/export, results import/export... The whole field here is far too fragmented. In view of the utterly diverse usages, which imply oftentimes conflicting goals, a standardized implemenation is probably not a good idea. However, we surely could have standardized interfaces (language bindings). Despite the incovenience, and decades of even Open Source development, we still don't! Weird. Engineers in any other field/industry would have settled on standardized interfaces long time ago. The software industry remains notorioulsy unruly---not always a good thing. Today, even if I have to write a very simple toy code for FDM of Poisson-Laplace equation, I still have to begin with my own Point3D class, and write down my own utiltity functions for equality testing of floating point numbers to a given precision. This situation is not bad, it is pathetic.
3.2 Believe me, something as simple as the lack of a good IDE! The last good IDE I used was when VC++ 6 came out in 1998 or there abouts. It had a fast browse info feature. It had a great set of debugging and tracing features. ... Since then, despite heavy development and features-bloat, it's been downhill---for VC++ as well as other IDEs. Even VC 10 is not good enough---not for me, anyway. On Linux, a good integration of a debugger is a permanent headache. (Why, sometimes I can't even tell if I have forgotten to kill a prior exe instance or not! And that, in this day and age of having to debug massively parallelized code!!) On Linux, QTCreator is somewhat better of the lot, but it enforces only one way of using the IDE. (For instance, I can't have a customized toolbar button for the Save All Files feature---I cannot customize even for something as simple as that.) CodeBlocks too, doesn't allow customizations (e.g. for accelerator keys), and is outright clunky in appearance and usage. As to VC, the day they began treating C++ at par with VB (as far as the IDE goes), they thereby botched up what actually was a great C++ IDE. The MBAs in Redmond (and other places) just don't ever get in their head the difference that C++ has from other languages. (Sometimes, even programmers don't get what is meant by ease of use: just have a look at the Ubuntu Unity and the floating launchbar and "scrollbars"! Argh!) And then, the recent VC IDEs heavily use the outright sluggish SQLServer for browse info, and still don't carry the comprehensiveness and ease of use of the VC6 Browse Info database. Further, both VC IDEs and QTCreator take forever to preprocess the code as soon as you make even a tiny change in the code, esp. in class templates. None knows how to deal with namespaces (how to allow user to have a customizable browse info access to namespaces). On the Linux platform, almost every IDE I saw had extremely poor or outright non-existent help file feature---try checking out the syntax for "sprintf" in QTCreator, for example---something that could be easily done on VC6. Overall, that's why even today, I still find myself doing the first cut only in VC++ 6, and then only reluctantly moving the codebase to other IDEs.
3.3 The lack of good simulators for developing parallelized code---whether using shared memory, clustering or GPGPU models. I can understand if GPGPU simulators or debuggers lag behind the development on the hardware side. However, I cannot understand why good tools don't exist at least for the multi-core and multi-node (clustering) environments. It doesn't have to be a real-time debugger; it could even be just a simulator. Yet, unfortunately, good tools for parallel processing simply don't exist.
Since this looks like too much of cribbing, let me provide just two examples to show how even very large and complex projects can be accomplished: (i) OpenGL, (ii) ParaView, Blender, etc. That, apart from, of course, the great STL containers library. ...Why can't they have good C++ interface definitions for mathematical objects and algorithms on similar lines, or have good parallel IDEs (and in fact have gone downhill even for the simpler serial code IDEs)? I have no idea.
- - - - -
[E&OE]
Re. preferences in scientific/engineering/numerical programming
I prefer non pure numeric research but both analytic and as result partial solutions in numerical mode. In part doing math my choice is one of three systems:
1. Wolfram Mathematica, Maple or Maxima
2. In part of fast creation of something like UI I use Visual Basic NET.