John Smith wrote:


I did wonder why the authors bothered to convert from FORTRAN to C++...
but I think they did that as a separate activity, previously, for other
reasons. There's a comment in their paper about not using automated
translators, too (presumably to avoid any sort of claim that the output
of the translator is somehow contaminated with the proprietaryness of
the translator? Kind of like Intel copyrighting the assembler
instruction mnemonics for the 8080, so Zilog had to use different ones)

Probably it's just a historical artifact.. when they started their
development a while ago, they happened to start with the Richmond code,
as opposed to the Burke and Poggio code.

FORTRAN is pretty much a dead language, although you will find strong
argument to that statement in some math circles. While I do agree that
language makes little difference to software engineers, most being
fluent in many/multiple languages, a C translation just keeps the code,
more, up-to-date.


FORTRAN is far from dead in applications processing massive arrays (just
about any finite element program). For instance, I'd venture that most
weather prediction codes are in FORTRAN (MM5, which is a widely used
mesoscale modeling code, is in FORTRAN, as is WRF), as are a lot of
structural analysis (e.g. NASTRAN is in FORTRAN), and virtually ALL
electromagnetics codes.

FORTRAN is hard to beat when it comes to specifying array operations,
and such. Running gridded models doesn't require much in the way of
pointers or string manipulation, which are admittedly a pain in older
FORTRANs (pre FORTRAN-90 or FORTRAN-77). FORTRAN also has an intrinsic
Complex type which is nice.

Compilers for numerical analysis applications (e.g. those weather grid
models) for FORTRAN are highly optimized, too. There's also nifty tools
like FLIC (FORTRAN Loop and Index Converter)


There's even new versions of FORTRAN coming out.



However, all that said, there are such things as "encoder algorithms",
for an example, and such, which are so narrow and contain such an exact
and specific set of math instructions to execute and obtain reproducible
results from, that the validity for a patent is quite obvious. However,
as has been demonstrated, for any patented algorithm which has yet been
created, a freeware solution which is either so close in effectiveness
as to make it a moot point, or even greater in effectiveness--an example
is MP3 format (patented) as relates to Ogg Vorbis format (public domain.)

Unless you need compatibility and interoperability. Sure, there are
non-patented communications coding schemes like LDPC that give better
performance than, say, Turbo codes (patented), but if you need to build
a radio that interoperates with a radio using Turbo codes, you're pretty
well stuck.

All the various high performance low bit rate voice codecs have similar
issues. All the "good" ones are patented, as well as most of the "not
quite so good", and the patents are broad enough that you would have a
tough time designing around them. (which is actually, I think, how it
should be.. patents *should* be for fairly general conceptual leaps, not
for some fiddly little detail that's different.. that's what "design
patents" are about)

Fortunately, the patents *will* expire. Unlike copyright, which has an
ever longer tail.


The future where patents cause real road blocks in software development,
or even "hoops to be jumped through", is still in software engineers'
future.

I don't think so. It's here now, especially if you consider advanced
signal processing or protocol handling in software. The software is just
the means by which the invention is realized, and it's no different than
doing it with discrete hardware components. While raw "algorithms" and
"math" can't be patented, a clever and efficient implementation
technique certainly can be.