Weekly Edition
Return to the Press page
| |||||||||||||
|
| |||||||||||||
GNU Toolchain Update: September 2008
Nick Clifton, a Red Hat employee, has started a series of
blogs describing monthly changes in the GNU Toolchain. "This is
the first in what I hope will be a continuing series of blogs describing
monthly changes in the GNU Toolchain (gcc, binutils, newlib and possibly
gdb as well). One of my jobs at Red Hat is to take the changes in the
public versions of the toolchain sources and copy them into our internal
repository. I do this on a monthly basis and I produce a short report each
time detailing what has happened. One of my friends here suggested that
people outside of Red Hat might be interested in these monthly reports and
so that is why I have started this blog." (Thanks to Mark Wielaard)
(Log in to post comments)
GNU Toolchain Update: September 2008 Posted Oct 1, 2008 16:06 UTC (Wed) by moxfyre (guest, #13847) [Link] A "series of blogs"? Is that anything like a series of tubes? Sorry, just poking a little fun... I think you mean a "series of blog posts"? ;-)
FORTRAN! Posted Oct 1, 2008 17:15 UTC (Wed) by felixfix (subscriber, #242) [Link]
Wow, haven't seen FORTRAN (or is it spelt Fortran nowadays?) in ages. Learned it eons ago, back when we had no water, had to smash our own hydrogen and oxygen atoms together to make it, and don't ask about snow.
I like it in those examples, a nice clean language there. But it was a bit of a shock. My brain took a few seconds to wonder what modern language had the look of FORTRAN and was I so out of the loop that I hadn't been keeping track of new languages ...
FORTRAN! Posted Oct 1, 2008 17:39 UTC (Wed) by asamardzic (guest, #27161) [Link]
I guess it depends on what you're doing these days - I, for one, can assure you that for doing numerics Fortran (it's not spelled FORTRAN any more, btw) rocks just as much as ever.
FORTRAN! Posted Oct 1, 2008 19:19 UTC (Wed) by rahvin (subscriber, #16953) [Link]
Anyone that's used Fortran knows why that's true. The language was designed specifically for the needs of scientists. IMO it's far easier to pick up, understand and use for those trained in engineering and science because it's structure is aligned with classical equation notation much more than any of the popular languages (and yes, it's features outside pure computation such as strings blows but show me another programing language with built in handling of complex numbers and equations containing them). It's Numeric capabilities are the reason it's still around and being used daily.
another programing language with built in handling of complex numbers Posted Oct 1, 2008 22:23 UTC (Wed) by mejd (subscriber, #42290) [Link]
python!
with no libraries imported
>>> (-1+0j)**.5
the standard library cmath has all the useful transcendentals
FORTRAN! Posted Oct 1, 2008 23:26 UTC (Wed) by njs (subscriber, #40338) [Link]
> show me another programing language with built in handling of complex numbers and equations containing them
Well, C, actually. (Not actually standardized until C99, but gcc has supported them forever.) But that's nit-picking.
FORTRAN! Posted Oct 2, 2008 0:33 UTC (Thu) by flewellyn (subscriber, #5047) [Link] show me another programing language with built in handling of complex numbers and equations containing them Common Lisp. And in terms of performance, some CL compilers (CMUCL, for instance) can outperform Fortran at such tasks, using the same algorithms.
FORTRAN! Posted Oct 2, 2008 5:49 UTC (Thu) by eru (subscriber, #2753) [Link] I can believe that a state-of-the-art Common List compiler might generate as fast code as Fortran (after you have completely decorated the Lisp code with type declarations that you normally don't use with Lisp, and which make the code less readable), but how could it be faster than code from a state-of-the-art Fortran compiler? Shouldn't both converge on the same optimal machine-language representation of the algorithm?
FORTRAN! Posted Oct 2, 2008 12:20 UTC (Thu) by flewellyn (subscriber, #5047) [Link]
Assuming that there is one! It's likely that the optimal machine-language representation would differ depending on the number and size of the inputs, number of iterations/recursions, etc. In such cases, assuming a sufficiently smart compiler, you'd still have to either settle for a "sub-optimal" general case, or else recompile for every run.
FORTRAN! Posted Oct 3, 2008 13:09 UTC (Fri) by donbarry (guest, #10485) [Link]
Also APL and J. Sadly, J only exists as "freeware" (i.e., *not* free software). I am always saddened that scientific computations didn't follow the APL/J route, giving us only a fraction of the array primitives that we'd otherwise have in bastardized scientific array languages like IDL and Matlab.
FORTRAN! Posted Oct 3, 2008 16:28 UTC (Fri) by jengelh (subscriber, #33263) [Link] Anyone that's used Fortran knows why that's true. The language was designed specifically for the needs of scientists. IMO it's far easier to pick up, understand and use for those trained in engineering and science For science: dumbed down. I may be able to live with the fact that offsets start at 1. I might be able to get used to the odd indent rules. But I as hell am so not amused by it (pgf90) not having a fucking type checking system. Pass an array of integers in where a single integer is expected and all things will go crazy (also segfaults will be seen less often even), and I wish you a pleasant time debugging that. Because whenever the scientist gets it wrong, I engineer am getting called to have it figured out. I don't claim correctness, but this is the idea:
FORTRAN! Posted Oct 4, 2008 7:11 UTC (Sat) by asamardzic (guest, #27161) [Link] I may be able to live with the fact that offsets start at 1. Use whatever start index you like - start index 1 is just the default, here is an array with indices ranging from -5 to 5: I'd say this capability is actually big advantage over C-like array handling, where indices have to start with 0. As for default of 1 as start index, one should have in mind that Fortran came before other languages, so 0 as start index is actually convention that came later.real, dimension(-5:5) :: foo I might be able to get used to the odd indent rules. Don't know what you mean here: from Fortran 90 onwards, the code could be written in free form, and there are no particular indent rules - the editor (well, emacs at least) is usually indenting the code for you, and the structure of the Fortran code written this way looks pretty much alike as the code written in any contemporary language. But I as hell am so not amused by it (pgf90) not having a fucking type checking system. There are no type checks for external procedures, you'd have to put this subroutine into the module in order to have types checked:
FORTRAN! Posted Oct 8, 2008 0:36 UTC (Wed) by jengelh (subscriber, #33263) [Link]
>There are no type checks for external procedures
And I am exactly barfing about that!
|
|
||||||||||||