On Aug 12, 1:53*am, John Smith wrote:
On 8/11/2010 12:43 PM, K1TTT wrote:

On Aug 11, 7:20 pm, John *wrote:
On 8/11/2010 11:53 AM, K1TTT wrote:

what is intuitive to you is a patented or copyrighted work from a
lawyer's point of view. *while you can't patent or copyright maxwell's
equations you can patent or copyright a method of applying them to
come up with solutions to practical problems. *these are common things
now in the software and business world, though some countries have
stopped issuing software patents and others are considering that move
also. *but the copyright process is well ingrained in the software
world. *So much so that there are specific copyright notices you can
use to specify that you DON'T want to stop anyone from using your
code, just so you don't get bothered by people asking all the time.

I never seen this as a problem or a road block. You are simply a matter
of all the knowledge you have picked up from others along the way, most
likely, a large portion of this came from copyrighted materials.
Indeed, if I read a copyrighted book, then turn around and write a book,
containing all I have read, I have done no wrong; If I copied the work,
I am.

When it comes to math, removed from other works, it is exactly the same.
You would have to be an idiot to do it in such a way as to cause problems..

This is all so self-apparent, it always puzzles me when I am brought to
putting the concept(s) to text, or even spoken speech!

Regards,
JS

it may be self apparent to you, but it is how corporate lawyers make
their living.

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.

And, none of the above is of any real importance, other than complete,
or even substantial fragments of, programs can be copyrighted. But, I
am sure there are millions of "for statements", etc. in code that are
exact duplicates of some found in Microsoft Windows, etc. To claim that
the truths of mathematics is patentable is just stoopid.

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.)

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

Regards,
JS

On Aug 12, 8:25*pm, 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.

And, none of the above is of any real importance, other than complete,
or even substantial fragments of, programs can be copyrighted. *But, I
am sure there are millions of "for statements", etc. in code that are
exact duplicates of some found in Microsoft Windows, etc. *To claim that
the truths of mathematics is patentable is just stoopid.

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.)

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

Regards,
JS

don't bet on it. microsoft just had to remove a major feature from
word because of patent infringement. and there are lots of cases
where companies have to buy rights to use patented features before
they can release their products, compression algorithms are just one
of many things that have been patented. even the cursor and the mouse
have patents. fortunately most of my work is using standard tools
that come with distribution licenses, and the stuff i develop that is
unique is from our own research programs so we obviously own the
rights. but if i find a free tool that has something that will make my
job much easier i have to submit the license to our software quality
and then maybe legal offices to be sure we can use it without
infringing. you know those long license statements that no one ever
reads before installing something?? most of them unfortunately make
sense to me now.

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.

On 8/12/2010 3:34 PM, Jim Lux wrote:
John Smith wrote:

....


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.


These days, I choose to program, almost exclusively, in assembly and
C/C+/C++ (all C looks the same to someone writing in it.) If someone
hands me a FORTRAN coded work, I can read it, but it tends to look like
a mess to me. I simply run it though a source translator/optimizer and
I have C code. When I am done, if they requested the result in FORTRAN,
I run it back through the translator in reverse. C is simply a
universal language which has the most favor with engineers and which has
become the industry standard. Like I said, arguing language is a moot
point ...

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.


FORTRAN is not "hard to beat" at anything. Assembly instructions are
the only "real code" which a processor understands, it is the binary
language of processing units. There is not a computer language in
existence which does not translate to assembly before execution.
FORTRAN and C only differ in semantics. While FORTRAN was an attempt to
make the language more readable in translation, C is an attempt to make
the language more efficient in translation. The goals of the two
languages are not exact.

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)


The meaning of that is just moot, and implies an argument for leaving
something unoptimized would be someones goal, somewhere, for what
purpose that would be baffles me!


There's even new versions of FORTRAN coming out.


As I admitted, there are almost religious devotions to some languages
.... another point which baffles me.



....

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.


That is some gobble-de-gook which defies meaningful translation ...
perhaps a dynamic demonstration of obfuscation? To someone outside the
field, I can see how it might just work!

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 best ones have not even been thought-of/invented yet! However, you
remind me of that patent office employee who once mentioned "the fact"
that most patents had already been patented ... and your statement is
just as valid as his!

....

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.


.... more obfuscation ... but does acknowledge the basic truth that
truths cannot be patented.

Regards,
JS

On 8/12/2010 5:34 PM, Jim Lux wrote:
John Smith wrote:
snip

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.


My daughter just got her doctorate from Columbia University. Her thesis
was all about data sets massaged with FORTRAN.

It ain't dead. Far from it.

tom
K0TAR

On 8/12/2010 2:33 PM, K1TTT wrote:

First, I would like to point out and "slap right on the table",
obfuscation, diversion, slight-of-hand and wordiness look lame to me ...
for whatever reason, they strike me as tools of the "uneducated con
man." That out of the way ...

...
don't bet on it. microsoft just had to remove a major feature from
word because of patent infringement. and there are lots of cases
where companies have to buy rights to use patented features before
they can release their products, compression algorithms are just one
of many things that have been patented.

Microsoft stole Java from Sun and attempted to make it, its' own.
Microsoft has a long history of this. The type(s) of individual(s) who
do such seem to infiltrate large corporations in large numbers.
However, really a moot point to the direction in which this conversation
first started ...

even the cursor and the mouse have patents.

Yeah, as if someone grasping at straws and thinking that "just owning a
patent", in someway, is some kind of status symbol ... something which
fails to impress anyone worth impressing.

fortunately most of my work is using standard tools
that come with distribution licenses, and the stuff i develop that is
unique is from our own research programs so we obviously own the
rights. but if i find a free tool that has something that will make my
job much easier i have to submit the license to our software quality
and then maybe legal offices to be sure we can use it without
infringing. you know those long license statements that no one ever
reads before installing something?? most of them unfortunately make
sense to me now.

Yeah, most people double check their work(s) and have others do so, if
available ...

Regards,
JS

On 8/12/2010 6:24 PM, tom wrote:

...
My daughter just got her doctorate from Columbia University. Her thesis
was all about data sets massaged with FORTRAN.

It ain't dead. Far from it.

tom
K0TAR

Frankly, I find that amazing, indeed, it implies insanity to me.

Why anyone would allow a thesis to be done which would favor a
particular language defies rationality. As, language is only a device
for the implementation of truths, ideas, algorithms and laws. It is the
underlying structure of math and logic which are the only important
points. To express these in a form speaking to computer engineers, a
"language" such as pseudo-code would be the logical choice. To do any
different simply implies there are interests at work other than pure
science.

Are you sure a FORTRAN compiler/developer with financial interests did
not back this academic venture? ROFLOL

Regards,
JS

On Thu, 12 Aug 2010 19:06:21 -0700, John Smith
wrote:

My daughter just got her doctorate from Columbia University.

Frankly, I find that amazing, indeed, it implies insanity to me.

And our friend Mr. Ostrom, the computer scientist, got his AS degree
in Chico something more than a dozen years ago. There's authority on
the topic speaking for ya'.

On Thu, 12 Aug 2010 15:34:14 -0700, Jim Lux
wrote:

There's even new versions of FORTRAN coming out.

Yep. Intel has several Fortran compilers for Windoze, Mac, and Linux.
http://software.intel.com/en-us/intel-compilers/
Rumors of the demise of Fortran have been greatly exaggerated.


--
Jeff Liebermann
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558