Are pointers important for scientific research?

[Simfish]

A lot of scientific programs are CPU-intensive, so speed is important. Pointers have to do with memory management, which I presume is important since there are often so many array values that memory management becomes important. yet, I don't see it used very often. Are they used very often?

 

[Simfish]

C/C++. Which seems to be one of the most popular languages for scientific computing.

 

[Kajahtava]

I thought that was FORTRAN for numeric intensive computing, Prolog or Lisp for artificial intelligence / language parsing, ADA for space shuttle things and other things that can't go wrong and what-ever ML-spawn for simulations and physics.

But C's probably also decent enough for the first, apparently FORTRAN has better libraries or something, I never got why they all use FORTRAN for that why C is just as good, if not better.

Maybe COBOL works well too.

But to answer your quaestion, pointers are essential and people use pointers implicitly more than they realize. But it depends for what, pointers don't magically 'speed up' things, they just help you program things that would be really cumbersome to program without.

Edit: Also, an array is a pointer, an array of integers is a pointer of type integer, so yeah, if you use array you use pointers.

 

[D H]

No religious arguments on the whether C/C++ is a good or bad language, or on its merits as a language for scientific programming.

In C and in C++ when you pass a primitive array (e.g. double array[3]) to a function you are passing a pointer. C, for good or for bad, pushes things to pointers rather quickly. C++ uses references as well as pointers. References are essentially pointers, but with some of the loosy-goosy nature of raw pointers in C.

C++ offers containers in the Standard Template Library that go well beyond the simple pointers and references. Sometimes these container objects can be very useful, but sometimes they are quite hoggish of CPU and memory.

As far as whether pointers and their more advanced kin are used in scientific programming: Yes. All the time.

 

[Mark44]

Pointers are used a lot in C and C++, particular in functions that have "call by reference" parameters,. Pointers don't necessarily have to do with memory management, as such, but can be used to provide access to a chunk of data rather than having to deal with the individual items of data. For example, a function can be passed the address of a block of memory, rather than the memory block itself.

Certain data structures, such as linked lists, queues, and such, are often implemented so that the individual components that make up the list or queue have pointers to the next and/or preceding structure in the list.

Assembly is fast, assembly doesn't have pointers.

Assembly languages might not have pointers, per se, but the ones I'm familiar with, such as x86 and M68000, certainly have the concept of pointers, in which the contents of memory or a register are considered to be an address an memory, rather than just a plain value.

 

[D H]

I thought that was FORTRAN for numeric intensive computing,

Less and less. Fortran has been losing ground for quite some time. BTW, it's Fortran now, not FORTRAN. Regarding the question raised in the OP, FORTRAN had references very early on, and Fortran 90 has pointers.

ADA for space shuttle things and other things that can't go wrong

Ada is/was a failed experiment. The Shuttle predates Ada; it is programmed in HAL/S. The ISS is programmed in Ada. None since that I know of. DoD removed the Ada mandate in 1997. Most of NASA's new spacecraft are programmed in C++.

Raw pointers (but not references) are pretty much verboten in real-time high-reliability applications such as flight software. Then again, so is almost all of the STL.

 

[alxm]

Seems like a very odd question, asking whether a particular programming-language construct is important to scientific research or not.

I know a lot of stuff I do is still written in fairly old fortran, and doesn't use pointers much.
But in general it just depends on which language you use.

I'd say that in my experience though, most of the work towards optimizing in scientific computing, both with respect to memory and speed, tends to be oriented towards optimizing at the mathematical/algorithmic level rather than at the programming-language/hardware level. That's where the big gains are to be had. Low-level optimization can often be a waste of time, given the rate at which hardware and compilers change.

 

[D H]

I'd say that in my experience though, most of the work towards optimizing in scientific computing, both with respect to memory and speed, tends to be oriented towards optimizing at the mathematical/algorithmic level rather than at the programming-language/hardware level.

To some degree, yes. A lousy algorithm is going to yield lousy performance regardless of the language in which it is implemented. Fine-tuning that lousy algorithm might yield a 10-20% boost in performance. Switching to a better algorithm might yield a n-fold boost.

On the other hand, even the best algorithm can be implemented stupidly. Passing by copy as opposed to reference, etc, can really slow things down.

 

[Speedo]

At least in C++, the goal is generally to use raw pointers only when absolutely necessary by letting the "dirty work" be hidden by things like STL containers and smart pointers.

However, you're still going to need to know how pointers work if you want to be proficient with C++ or C.

 

[D H]

At least in C++, the goal is generally to use raw pointers only when absolutely necessary by letting the "dirty work" be hidden by things like STL containers and smart pointers.

... and references. Many development organizations prefer references over pointers if for no other reason than there is no such thing as a null reference. That said, some organizations ban call by non-const reference (e.g., google; http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Reference_Arguments ) because there is no "take the reference of" operator in C++. Suppose you see a function call foo (bar); in some code. There is no way to tell by looking at the function call alone whether bar is based as a value (i.e. a copy) or a reference. Not that I agree with that standard, but it is out there.

Regarding STL containers and smart pointers, some organizations ban the use of these. These same organizations are also likely to ban or strongly limit the use of new and delete (and malloc and free). That's because these organizations are building real-time / embedded software. A lot of avionics code is now written in C++.

However, you're still going to need to know how pointers work if you want to be proficient with C++ or C.

Agreed.

 

[rcgldr]

Assembly languages might not have pointers, per se, but the ones I'm familiar with, such as x86 and M68000, certainly have the concept of pointers, in which the contents of memory or a register are considered to be an address an memory, rather than just a plain value.

Depends on the machine. It's called indirect addressing mode, where memory contains an address instead of a value. It was (is?) used on some machines. On machines like x86 and 68000, there is no indirect addressing mode, so pointers require two steps, one to load the memory based address into a register, then to use the address in that register, optionally along with a fixed offset and/or a register based index. Page tables on x86 and 68000 mmu have arrays of pointers to pages for virtual to physical address translation. Caches also have arrays of addresses. DMA devices that also work in page mode will have an array of descriptor structures containing pointers and lengths to data in pages used for I/O.

 

[Speedo]

... and references. Many development organizations prefer references over pointers if for no other reason than there is no such thing as a null reference.

I was more speaking in terms of dynamic memory. You can't use references there (well, you can, but it's convoluted and back-asswards and frankly, anyone doing it should be shot).

That said, pass by [const] reference should pretty much be the default for non-POD function arguments in C++. I personally am in the "only use pointer arguments when the parameter is optional" camp. YMMV.

Regarding STL containers and smart pointers, some organizations ban the use of these. These same organizations are also likely to ban or strongly limit the use of new and delete (and malloc and free). That's because these organizations are building real-time / embedded software. A lot of avionics code is now written in C++.

Like pointers, you can't really call yourself proficient in C++ without knowing the SC++L (including STL), IMO. There will be times when you can't use all the language features because of system limitations or not so great implementations for your target platform, and in those circumstances you do what you have to. Most of the time though, you should be using those features.

 

[D H]

I was more speaking in terms of dynamic memory. You can't use references there (well, you can, but it's convoluted and back-asswards and frankly, anyone doing it should be shot).

Sure you can. What's bass-ackwards about dereferencing a pointer, particularly before passing it to some function? There is a huge advantage to passing a reference versus passing a pointer: A reference cannot be null. The function with the pointer had dang well better have a test for a null pointer. That this function can throw an error, fail an assertion, or use some installation-specific error handling mechanism needs to be documented. A test case needs to be constructed to achieve 100% code coverage. The function that takes a reference does not have to do any of that stuff.

That said, pass by [const] reference should pretty much be the default for non-POD function arguments in C++.

The same goes for pointer arguments, unless of course the function truly is altering the contents of the object -- and that is ideally the only case in which the argument should be non-const.

I personally am in the "only use pointer arguments when the parameter is optional" camp. YMMV.

That is one of the more bizarre camps I've heard of -- and I've seen some doozies (e.g., the "no magic numbers" rule taken to such an extreme that one cannot use 0. One must use something along the lines of OVERLY_PEDANTIC_INSTALLATION_ZERO instead.)

ike pointers, you can't really call yourself proficient in C++ without knowing the SC++L (including STL), IMO. There will be times when you can't use all the language features because of system limitations or not so great implementations for your target platform, and in those circumstances you do what you have to. Most of the time though, you should be using those features.

I heartily disagree. This is a scientific site, one that deals primarily in physics and engineering related to physics. We are talking about scientific programming here. The mental skills needed to do the physical modeling needed for that scientific are quite distinct from the mental skills needed by a typical computer programmer.

From my experience, those skill sets are nearly orthogonal to one another. Scientists and engineers, for the most part, make for rather lousy programmers. So why do organizations involved in scientific programming even allow scientists and engineers to write code? The answer is simple: Lousy as the typical scientist/engineer may be regarding programming skills, the scientific reasoning skills of the typical computer programmer are even worse.