last day (15 days later) » 

00:46
11
A: Does the Voyager team use a wrapper (Fortran(77?) to Python) to transmit current commands?

LudoThe Voyager spacecraft are not reprogrammed anymore, so the language in which they are programmed is largely irrelevant. The uplink is only 16 bits/second, just enough to send (simple) commands. How these commands are generated is irrelevant to the spacecraft. Any language that can generate a se...

I had read that they probably did not switch to the last version of Fortan. But I am not sure. But I also wanted to know if you could use languages like Python as background.
do you have a reference for "The Voyager spacecraft are not reprogrammed anymore"?
@Hobbes added one, although it is ambiguous enough that I'm starting to doubt myself a bit. It seems that part of the spacecraft could be reprogrammed and thus still might have been until recently as they started shutting things down. Define "reprogramming"...
There's actually a newer standard than Fortran 2008, Fortran 2018 was released last year. It's also not quite as niche as many people seem to think, since most work on supercomputers is still done using Fortran (still relatively niche, I suppose, but not a dead language).
00:46
@llama: I wish people trying to do high-end number crunching would recognize that FORTRAN and Fortran were designed for that purpose, and that C never was not.
@supercat true-er words were never written
@supercat you wish? Most people doing number-crunching “recognize” this all right, though I'd rather say they believe that Fortran is the best language for number-cruching. It isn't, in fact: with modern compilers, Fortran, C and C++ are pretty much on par and fortunately many new high-performance projects are now written in C++ (or even in Rust), which allows for much better software design at the same performance. — Another trend, I'm not so happy about, is that many people now also try using Python, Julia or even Matlab on supercomputers, and that is definitely a bit waste of resources.
opa
opa
@llama I definitely wouldn't say "most", some work might be, but in my experience I've never seen any one working with a modern super computing system use fortran, or at least interface directly with it.
@leftaroundabout: I'm not sure why you say "even" Rust; from what I understand Rust would be way better than C or C++ for high-performance computing. The concept of having pointers to the middle or end of an object, that have no discernible relation to the enclosing object itself, and the ability to treat pointers to isolated objects like pointers to the initial elements of single-element arrays, are both fundamental to both C and C++. They lead to an intractable variety of corner cases, however, which cannot be specified unambiguously in a way that allows effective and robust optimization...
...without significantly changing the language in ways that might be tolerable for C++, but would make C unusable. In C++, for example,the most common situations where one would need to take the addresses of structure members could be handled using references, and those requiring the ability to pass arbitrary-sized arrays could be handled with vector<>, but C supports none of those things.
@opa I definitely can't quantify that statement, and I expect that C++ and others will eventually overtake Fortran if they haven't already, but there are definitely good reasons for Fortran to maintain a large stake especially in physics-based SC (see queue.acm.org/detail.cfm?id=1820518 for a biased take)
opa
opa
00:46
@llama I'm not sure how that article supports "good reasons for fortran to maintain large stake"? The only thing that stood out to me about that was the un-supported assertion that "the ideal language people used was basically fortran", which, also did not actually appear to be the case. "derivative(function)" is no more "basically just fortran" than a for loop is.
@opa the point is more that someone at oracle/sun believes such a thing, than whether it is actually true
@llama: A good language should have many places where behavior is defined as an Unspecified choice among a number of possible alternatives, but the C and C++ Standards tend to use the term "Undefined Behavior" in cases where fully describing the alternatives would be difficult, or where it would be practical on some platforms but not all. I don't know how well Fortran handles such issues, but a language which does could allow many more useful optimizations in cases where every allowable behavior would meet requirements than one where programmers must fully define everything.
@supercat I say “even” Rust simply because it's so much newer and “exotic”, compared to C and C++. I agree that it's better suited for many domains including HPC. — Regarding undefined behaviour: I can't really make sense of what you're trying to say there. A main reason the C and C++ standards always use this term is that it allows the compiler to optimise much more easily, because it knows that when such and such situation arises the developer will be out of their right to complain. By contrast, weakly-typed languages that try to define every stupid edge case are a nightmare to optimise.
@leftaroundabout: Have you ever read the published Rationale for the C Standard? According to the Committee, the purpose of Undefined Behavior was to allow for a variety of implementations that would support "popular extensions" [typically processing constructs in a manner characteristic of the environment] on a "quality-of-implementation" basis dictated by the marketplace, and not to demean useful programs that happened not to be portable. The notion that the authors intended to invite anything like the clang/gcc treatment is a complete fantasy.
@leftaroundabout: As for unspecified behavior, consider a function which must compute for each element of a[i] the value a[i] = (b[i]+c[i]+d[i])>>1 if it can be computed without overflow, must return -1 but may leave all a[i] with arbitrary values if any a[i] can't computed arithmetically-correct fashion because of overflow, and may do either, at its leisure, if it is able to compute arithmetically-correct values in spite of overflow. Compare the optimizations available on a range of machines under those semantics compared with anything that could be expressed in C.
@supercat aha. Ok, I've considered it. Again, no idea what point you're trying to make with that example, but nor do I think this is the right place to discuss it.

last day (15 days later) »