These guys don't know what they're missing! :-)
"Share what you know. Learn what you don't."
The mind boggles. At least they had the honesty to publish Van Snyder's
response, which points out many of their delusions.
Seconded. Though I'm not sure if it's C++ bigots or F77 diehards that
Look closely. From the few clues, it seems this petition is over five
years old. People are signing on at the astounding rate of 46
signatures per year. Check out the refutations in "Informed Responses"
on the same website.
Don't get your knickers in a twist over this one.
> Hmm... somebody sent me the following link today:
Ignore them. I recall seeing that when it was first put up. They are
basically just ignorant. Van pointed out many, but not all, of their
inaccuracies. It is nothing but a misinformed temper tantrum posted on
line. It isn't going anywhere. It won't have any effect.
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
>Hmm... somebody sent me the following link today:
>These guys don't know what they're missing! :-)
That's as old as bible. Just ignore them, and like everything else,
they'll go away.
I think petitioning for the retirement of a Language Standard is best left to
the users of that language. However, if you believe that position is not
correct, you should start by petitioning the retirement of Java based on
Kahan's arguments about the violence the mere presence of Java does to numerical
computation in all languages.
After Java, C++ would be the next logical candidate. After all, Objective-C
is better in all ways except backward compatibility; and C++ has proven, in
the real world, to be even more error prone than C and of greater development
cost without corresponding (actually realized) benefit.
As for Fortran, I'd actually rather have PL/I, but that didn't catch on in quite
the same way, and it is harder to write a good PL/I compiler in some ways because
of the vast variety of data types.
Finally, I would suggest that Object Oriented programming LANGUAGES are not
yet ready for prime time -- because of the write-only problem. FORTH has been
known for write-only code, because of the definitions of all the new Forth words
that are needed to make a complex functional program. The problem of making
user defined language constructs accessible to other than the original programmer
remains an UNsolved issue. This issue is a major one for any language that is
based on programmer defintions of new language elements -- which is one of the
hearts of OOP.
Until the write-only problem is solved, OOP remains OOPS-prone.
MHOO -- YMMV
I'm pretty much an F77 diehard (apologies to George Marsaglia for
the use of that word in this context) and I have written to the
petition author to object. That petition is wrong-headed.
I find F77 perfectly adequate to my needs, but that does not mean
I wish to freeze the language development. Although I do have strong
reservations about the OO implementations, anything that stops growing
has started to die.
It would seem to me that Fortran 2003 compilers are harder
to write than PL/I compilers, but maybe Fortran 95 compilers
are not so hard. Not having to maintain backward compatibility
made it somewhat easier for PL/I. (PL/I only has assumed
shape arrays, for example. No assumed size for backward
The number of data types shouldn't be so much of a problem,
in most cases the result is the same as the SELECTED_??_KIND
in Fortran. That is, they are different names for the same type.
Most IBM compilers support FIXED DECIMAL with the S/360
BCD format, but it can be done in binary. (It requires
multiply and divide by powers of ten in some cases, instead
of shifts for BCD.)
It was significantly harder to write good and fast compilers
than Fortran 66, especially in the limited memory available
at the time. Also, the generated code ran somewhat slower.
> Finally, I would suggest that Object Oriented programming
> LANGUAGES are not yet ready for prime time -- because of the
> write-only problem.
I presume you are separating OO languages from OO programming.
It is possible to do OO programming even in Fortran 66.
It does seem that some overuse the OO features.
> FORTH has been known for write-only code,
> because of the definitions of all the new Forth words
> that are needed to make a complex functional program.
> The problem of making user defined language constructs
> accessible to other than the original programmer
> remains an UNsolved issue. This issue is a major one
> for any language that is based on programmer defintions
> of new language elements -- which is one of the hearts of OOP.
PostScript (though not a general purpose language) had a
similar problem. PDF, in some ways a restricted version
of PostScript, fixed that and seems now to be much more
popular than PS.
> Until the write-only problem is solved, OOP remains OOPS-prone.
PDF is popular because Adobe provides a free reader.
PDF is not a programming language; it's just a document format. It
uses Postscript syntax and features. There are PDF readers, like the
ones provided by Adobe, and programs and drivers that produce PDF files,
but nobody reads or writes PDF files manually ... except for those of us
fools who work with code that reads or writes PDF.
True, but much of the format is a reduced form of PostScript.
In the early days of PDF, and when readers didn't exist for
all systems, there was a program called pdftops.
The PDF writer that I wrote only does bit images, which use
a fairly small set of the PDF operations. The line and text
commands, though, are very similar to the related PS commands,
but there is no def command. Unlike EPS (which is also a
postscript based file format), PDF removed the language
Many years ago, when the Internet was much slower than today,
a group I was working with had sent hundreds of megabytes
of PS (generated by dvips) to someone, and then found an
error in it. The fix was to send a small postscript program
that went ahead of the files with the error that defined the
fixed operators, and then redefined def such that the fix
wouldn't be changed later.
A little closer to Fortran, the Mortran language was based
on a macro processor with macros that could generate other
macros. (I don't believe it allowed redefining the macro
define operator, though.)
Reformatting pdftops(1), please wait...
>A little closer to Fortran, the Mortran language was based
>on a macro processor with macros that could generate other
>macros. (I don't believe it allowed redefining the macro
>define operator, though.)
You could always use TeX as a Fortran preprocessor, I suppose.
[Withheld] Math. engeneering student Leuven Belgium
Is this a signature?
Mistakes are a part of being human. Appreciate your mistakes for what they
are: precious life lessons that can only be learned the hard way. Unless
it's a fatal mistake, which, at least, others can learn from.
~~ Al Franken,
On 2009-04-09 20:31:55 -0400, Franken Sense <fr...@example.invalid> said:
> [Withheld] Math. engeneering student Leuven Belgium
> Is this a signature?
It is, according to a usually reliable source. :-)
So what are your sentiments about Fortress? According to Guy Steele,
Fortress is intended "[T]o do for Fortran what Java did for C"
The Wikipedia entry for Fortress states that "Fortress] is intended to
be a successor to Fortran". Does this suggest that there is some
expectation that Fortran will become obsolete?
But Java came along and C is obviously not going away any time soon.
Do you think this will be the case for Fortran? How much migration of
the Fortran community to Fortress do you foresee?
Freedom - no pane, all gaiGN!
I'm not sure exactly why this is a followup to my post above; I don't
see any particular connection. Guy Steele certainly isn't in the same
class as the authors of the above-mentioned temper tantrum.
My thoughts about Fortrass are mostly... not much. I briefly skimmed it
when it was first publicized. I decided that it looked like more hype
than substance and wasn't of much interest to me. I haven't noticed any
reason to change that evaluation.
There is "some expectation" of just about anything, including that the
world will come to an end tomorrow. Whether that expectation is widely
shared is a different question.
I don't see a measurable migration of any community to Fortress. Of
course, I could be wrong, but you did ask for an opinion and that's
I'm not prepared to do a detailed analysis of Fortress and go into pros
and cons of all of its alleged features. I just don't think it is worth
my time to do that. If someone else wants to, they can feel free.
For just one con... well... try to take some Fortress code for.. well
anything. It doesn't have to be long or complete. A dozen lines or so
will do. You could even grab the code sample from the Fortress FAQ page
if you like. Now try to post that code... say... on this newsgroup. And
do so in a way that is actually readable. No binary image attachements
or the like. Have fun with that exercise.
Some people obviously think the issue alluded to in the above para is an
improvement. Guy touts it as a plus. I'm not one of those people. I'm
more reminded of some of the languages that Knuth discussed in his paper
about precursors to Fortran. Some of them were purely handwritten as I
recall and didn't have the limitation of being expressed as a stream of
characters as in a text file.
If it the paper I am thinking of, he also talks about
Fortran 0, that is, the language as designed before they
started writing the compiler. It changed along the way
of actually writing the compiler.
heh-heh, I like this one better:
#238 Eat Shit You Assholes
It's amazing how widespread delusions about Fortran are...was in a
conference this week when someone decided to ridicule people "stuck in
the past" (meaning not moving on to C++ or Java from Fortran), but
mentioning their steadfast usage of Fortran. Its an unwinable battle.
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
>The Wikipedia entry for Fortress states that "Fortress] is intended to
>be a successor to Fortran". Does this suggest that there is some
>expectation that Fortran will become obsolete?
Other than the first 5 letters of their names, I fail to see that
Fortress is any more a replacement for Fortran than any of a dozen
established languages are.
I took a look at Chapel, X10 and Fortress. X10 is interesting, and
it is on my list for a closer look, but VERY unlike Fortran. Chapel
is a worthy attempt at designing a modern language along now what
are the conventional lines, but isn't exciting. Fortress was the
same old, tired, ideas that Java has demonstrated don't work.
To give it its due, people had been trying to get write once, run
anywhere languages to fly for 25 years, but Java was the first to
succeed. But (for reasons that were wholly predictable) it failed
to make any headway into the 'general' computing arena, let alone
against the area where Fortran still leads.
>But Java came along and C is obviously not going away any time soon.
>Do you think this will be the case for Fortran? How much migration of
>the Fortran community to Fortress do you foresee?
Of Course not! It was not my intention to link Guy with the tantrum
(Guy, if you're reading this, my humble apologies).
The connection between the tantrum and Fortress, however, is that the
petition seeks to retire Fortran, while Fortress is being touted as a
successor to Fortran. Perhaps some more knowledgeable person should
update/correct the Wikipedia entry?
> My thoughts about Fortrass are mostly... not much. I briefly skimmed it
> when it was first publicized. I decided that it looked like more hype
> than substance and wasn't of much interest to me. I haven't noticed any
> reason to change that evaluation.
Guy's not likely to be spending time designing and promoting anything
that's more hype than substance, though. I suspect that computer
scientists of his ilk are concerned with analysing the drawbacks
associated with various languages and trying to create a new
Having a look at Fortress is an allocatable on my rather long "To do"
list, which I'll get to - sometime. I need a "MOV_ALLOC" somewhere to
create more space in that array.:-)
Well thank goodness! After spending all this effort updating my
knowledge of Fortran , I'm understandably relieved.
Well, maybe. I remember reading about Java when it was first touted,
and thinking that 90% of the claims were more hype than substance.
As things have turned out, I was more-or-less right and the Java
brigade were wrong. Now, to damn Guy Steele for that would be unfair,
as I cannot remember the exact claims nor whether he personally made
But I did a little more than briefly skim the Fortress description,
and my conclusions were the same as Richard's - and not just from a
Fortran viewpoint. Its claims to be a successor to Fortran were
obviously nothing but hype, but I was trying to evaluate it as a
new language for the multi-core systems of today and the future.
The only thing that ought to concern Fortranners is usage. Whether it
is praised or vilified is irrelevant. Emmanuel Derman, a guy who went
to finance from Physics in the 1980s has a few digs against Fortran in
his autobiography (but then he calls C "elegant"). His book suggests
why it disappeared from the large banks and brokerage houses -
probably there were may like him in the 1980s (from Bell Labs) with
their anti-Fortran bias.
I think the core of Fortran (77 onwards) plus or minus a few things is
close enough to a universal language - but abysmal marketing has led
to the present sorry state of affairs.
I just got email from Guy, and it seems that the Fortress Wikipedia
entry really ought to be amended:
Thanks for the pointer to an interesting conversation.
If I may offer my two cents' worth: I don't think Fortress
will ever replace Fortran, because I don't think *anything*
will ever replace Fortran. And Wikipedia is often helpful
but seldom definitive.
I think of Fortress as an attempt to explore certain new
combinations of old ideas. DARPA asked us to take a risk,
and we did. ...
I think Guy is being modest though. I expect Fortress to introduce new
ideas in language design.
> I think of Fortress as an attempt to explore certain new
> combinations of old ideas. DARPA asked us to take a risk,
> and we did. ...
>I think Guy is being modest though. I expect Fortress to introduce new
>ideas in language design.
Why? Seriously. His statement that it is a new combination of old
ideas is correct, and many experts believe that the problem is with
the old ideas and not the way they are put together. My objection to
Fortress is not that they took too much of a risk, but that they took
far too little of one!
Are you really?:-)
I didn't want him to think that I was assigning him to a tantrum
In the first thread to which I posted in this group (clf) I believe I
considered whether I should just learn Fortress instead of 90/95/2003,
because I mistakenly assumed that Fortran was on the way out. I first
heard about Fortress on comp.lang.lisp some months ago, so learning
Fortress has been on my mind.
> > I think of Fortress as an attempt to explore certain new
> > combinations of old ideas. DARPA asked us to take a risk,
> > and we did. ...
> >I think Guy is being modest though. I expect Fortress to introduce new
> >ideas in language design.
> Why? Seriously.
Maybe just because he is Guy Steele, co-author of Scheme, and someone
with plenty of ideas? As I pointed out earlier, I haven't yet had the
opportunity to delve into Fortress. When I do get round to calling
MOVE_ALLOC on my "To Do" array, I'll be better able to answer your
In the meantime, I'm off to experiment with f90/95 fft's. G95 seems to
have a problem compiling Burkardt's FFTPACK5.f90. If someone knows of
a real f90/95 fft that doesn't require the number of data samples to
be a power of two, or alternatively where (on the web)to find a how-to
on converting a complex fft to efficiently fold real data into both
the real and imaginary parts, please post here.
My DSP, like my Fortran is pretty rusty. And yes, I know there's
As a wikipedia editor, I am prepared to have a go. The article is called
"Fortress (programming language)" and is at:-
What do you want updating or correcting? Then, do you have a source for
your changes. Wikipedia does not use "knowledgeable persons". It uses
people with sources that they can use to write material.
The relevant para is:-
"It is intended to be a successor to Fortran, with improvements
including Unicode support and concrete syntax that is similar to
mathematical notation. The language is not designed to be similar to
What is wrong with this? It may not become a successor to Fortran, but
that is the intention of the project. That sentence does need a source
>> My thoughts about Fortrass are mostly... not much. I briefly skimmed it
>> when it was first publicized. I decided that it looked like more hype
>> than substance and wasn't of much interest to me. I haven't noticed any
>> reason to change that evaluation.
> Guy's not likely to be spending time designing and promoting anything
> that's more hype than substance, though. I suspect that computer
> scientists of his ilk are concerned with analysing the drawbacks
> associated with various languages and trying to create a new
> Having a look at Fortress is an allocatable on my rather long "To do"
> list, which I'll get to - sometime. I need a "MOV_ALLOC" somewhere to
> create more space in that array.:-)
> Freedom - no pane, all gaiGN!
> Code Art Now
> Email: a...@codeartnow.com
Brian Salter-Duke Melbourne, Australia
My real address is b_duke(AT)bigpond(DOT)net(DOT)au
Use this for reply or followup
"A good programmer can write Fortran in any language"
Given Guy Steele's remarks (posted above, in this thread) Perhaps you
should email him at Sun. It does not seem to me that the current goals
of the Fortress project include becoming a successor to Fortran. Let
the Fortress development team be your source for editing.
Not according the Fortress Project. The revision 1.0 of the
The first 3 paragraph in the Introduction do not reflect a desired
to replace Fortran. It simply is a new language that is intended
to solve problems traditionally solved with Fortran.
I'd like to see Fortran relieved of much of its historical baggage, but
the changes I'd make would be mostly truely eliminating some older
features such as fixed format source. If would like very much the same
(but not identical)
OK, that is a source that can be used. I'll try to have a look at it and
then have a go at the article.
> In the meantime, I'm off to experiment with f90/95 fft's. G95 seems to
> have a problem compiling Burkardt's FFTPACK5.f90. If someone knows of
> a real f90/95 fft that doesn't require the number of data samples to
> be a power of two, or alternatively where (on the web)to find a how-to
> on converting a complex fft to efficiently fold real data into both
> the real and imaginary parts, please post here.
Clive Temperton wrote a couple of papers on the subject, search for
some of his code. Also Okan Ersoy. There are a bunch of algorithms
on my website: http://home.comcast.net/~kmbtib/ which are mostly
written out for complex FFTs but by design may simply have the
imaginary parts deleted and still work. I have several times seen
the claim in literature that it's straightforward to convert any
complex FFT to real-half complex but I've never seen anybody that
could make it go in interesting cases. The stuff on my website is
mostly prime-order FFTs and for odd orders n > 3 is minimum-operation
or at least minimum-add compared to others, although a trick I found
after I wrote most of the stuff that would shave off some operations
hasn't been implemented except for smaller odd orders and for powers
Don't expect reasonable performance for compiled code. Once I tried
taking an SSE2 assembly language program for real-half complex FFT and
converting it to Fortran 90, with a one-to-one correspondence between
machine instructions and fortran statements. ifort generated pitiful
code with this absolute freebie, and the situation is even worse when
it actually has to do some work to schedule instructions and allocate
registers and so on.
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
I have made a small change that I hope reflects that source and this
discussion. The article does need more work by someone who knows more
about it. I left a comment on the talk page.
Depending on quite what you mean it might not fit ... But take a look
It's not written in Fortran, but has Fortran callable interfaces,
> I'd like to see Fortran relieved of much of its historical baggage, but
> the changes I'd make would be mostly truely eliminating some older
> features such as fixed format source.
This would eliminate the British English spelling of "program", i.e.
It is left to the reader if this would be a good thing or a bad thing :-)
I found the FFTW page sometime ago. FFTW is kind of heavyweight for C-
Graph, which just displays graphs, and is not concerned with rigorous
spectral analysis. Also, FFTW is callable from Fortran, but I would
just prefer an FFT coded in Fortran.
Thanks anyway. I'll no doubt want to try FFTW for other analytical
So that's what a "real-half complex fft is; I've been eyeballing your
fft page for a while, bemoaning the rust deposited on my dsp. I
discovered that there was a folding method to efficiently use real
data with a complex fft only in the last couple of days or so! If the
method is involved it's best left until I have the time to do some
The stuff on my website is
> mostly prime-order FFTs and for odd orders n > 3 is minimum-operation
> or at least minimum-add compared to others, although a trick I found
> after I wrote most of the stuff that would shave off some operations
> hasn't been implemented except for smaller odd orders and for powers
> of two.
I'm now working with the simple but complex (:-) ) FFT from Alan
Miller's page <http://users.bigpond.net.au/amiller/> just to enable me
to finish writing the code. I'll Google Temperton and Ersoy as you
suggested, and tinker with your own code until I decide which FFT to
go with. The FFT I choose will likely be included in its own module.
By the way, did you know that the link for your "fft64t.i90" is
" It is intended to "produce a secure Fortran ..."
Yes, that's how I would have amended the line. I noted the relevant
paragraph from the above cited research.sun.com page.
No! Say it ain't so!
I use GINO. It has a lot of similar spelling "annoyances" :)
But recent versions have duplicates to accommodate those that spell
I am no expert in the matter myself, but I've had British friends tell
me (likely on this newsgroup) that this is the wrong spelling for that
meaning of "program".
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
> By the way, did you know that the link for your "fft64t.i90" is
Comcast tries its best to break your web pages. I don't know why they
couldn't just leave well enough alone. If you're really interested in
this subroutine you can also find it in codelets.i90 in codelets.ZIP
on the same web page.
Got it. Thanks
> Michel Oui wrote:
>> Franken Sense wrote:
>>> [Withheld] Math. engeneering student Leuven Belgium
>>> Is this a signature?
> I was puzzled by Franken Sense's original post. Is he claiming
> that people who don't use their correct names should be ignored?
> Dick Hendrickson
I thought it ironic that the name was withheld and the discipline
misspelled. BTW, when I sign a petition, I use my real name and give it my
John Hancock. It differs from a pseudonym.
How many recounts can Norm Coleman buy?
>> heh-heh, I like this one better:
>> #238 Eat Shit You Assholes
[Roger Ailes, Fox News Founder, Chairman and CEO, and former
Nixon-Reagan-Bush strategist, is] a cynical Republican ideologue with no
regard for fairness and balance.
~~ Al Franken,
On 2009-04-11 16:27:02 -0400, Franken Sense <fr...@example.invalid> said:
> when I sign a petition, I use my real name and give it my
> John Hancock.
Thereby avoiding the perjury count? :-)
Or just trying to actually benefit the petitioneer,
(when checked against the rolls) who you presumably support? :-)
Well, yeah. They usually show up at my door with some environmental
concern that I basically agree with, asking for money but getting my
Acorn got in trouble for this type of thing this election. They'd have
people signing "mickey mouse," and it caused huge problems for them. I
don't think there was anything malicious at its core, but a petition
without real names is not worth the paper it's written on.
I said that Sean Hannity took residence up Newt Gingrich's butt from 94 to
98. I got that from British intelligence. It turns out he only took up
residence in 95.
~~ Al Franken
Before this sub-theme dies about wikipedia, let me make the point that
to do you what you suggest would be quite unacceptable. Asking Guy would
be original research and that is not allowed on wikipedia. Sources have
to be verifiable - that is the reader can in principle go and look at
them either on the web or in a library. In other words we have to rely
on what the Fortress project publishes that everyone can see.
Obviously, given that your intent was to amend the Wikipedia
reference, I assumed that Steele would have been able to point you to
the official position adopted by Sun, but someone on this thread
managed to find the url for the Fortress 1.0 specification. It was
clear to me that the Wikipedia statement was in conflict with Sun's
Also, having had another look, while your phrase:
'It is intended to "produce a 'secure Fortran' ....." '
might capture the import of the cited reference in Sun's
'The name “Fortress” is derived from the intent to produce a “secure
Fortran" ...” '
The facts are that Fortress is not a Fortran and never will be. Would
it not be more accurate for you to say something like:
'The name "Fortress" is intended to connote a "secure Fortran" ...' ?
Just a suggestion.
Just to be clear, wikipedia "rules" are actually "guidelines". They
aren't hard and unbreakable. Of great pertinence is serious and
thoughtful assessments whatever the original form.
I'm almost British, and recognize a clear distinction between
"programme" and "program".
Most "rules" are. as you say, guidelines, but "Verifiability" is policy.
That does not mean that every statement is verifiable with a source, but
they should be. I certainly try to source everything I add to wikipedia
to ensure that it is verifiable. If you added something and made clear
on the talk page that you had confirmed it by asking someone, you would
certainly be told to get a proper reference and to not do original
research. All that said, however, there is still the policy that says
"Ignore all rules".
You can have a sneak peek at the preview of C-Graph version2 here:
> You can have a sneak peek at the preview of C-Graph version2 here:
I just took a glance. The convolution stuff seems a bit disappointing
to me. After all, it has been known for some time that doing an FFT,
multipling by the FFT of the signal to be convolved with, then doing
an inverse FFT is wasteful.
First off, you are doing a full complex FFT on real data (at least I
think so) and this results in a little more than 2X as much work as
performing a real-half complex FFT. Also doing even a real-half
complex FFT means that you perform extra work like for example bit-
reversal which is not needed for convolution. See djbfft for an
example which skips this step. Finally, it's more efficient, at least
in term of operation counts to reduce the convolution matrix to 4X4
blocks rather than 2X2 blocks (as the FFT method does) or 8X8 blocks
(no method actually does this) and reduction to bigger blocks has the
side benefit that operations are manifestly aligned for SIMD execution.
See "A new matrix approach to real FFTs and convolutions of length 2**k"
T. Lundy and J. Van Buskirk, Computing vol. 80, pp. 23-45 (2007).
James, I think you missed the point.:-(
I'll explain in the morning. Just now I'm quite exhausted. Nice of you
to take a look.:-)
I would think it would depend on the length of the convolution
function. FFT is O(N logN), and convolution, if I have
it right, is O(m n), where m and n are the lengths of the two
sequences. For large enough m, it would seem that FFT should
The FFT algorithm with real inputs is well known. In this case,
it would seem that you would also want to do less computation on
the iFFT, since the result is known to be real. I believe that
there is a known algorithm for that, too.
There is a well known FFT for real inputs written in f77 by Henrik
Sorensen that requires the number of samples to be a power of two. I'm
having a look at John Burkardt's f90 conversion of FFTPACK, which also
includes a real FFT not limited to a power of 2.
C-Graph is, fundamentally, a rewrite of my 1983 BSc Honours thesis
from the University of Aberdeen. The actual task set by my thesis
supervisors was to create a demo for undergraduate students that would
illustrate all nine properties of the Fourier Transform, but I -
understandably :-) - limited the exercise to the convolution theorem.
All Honours students were required to submit a thesis/dissertation in
addition to completeing 9 other courses and a design project. The
theoretical basis of C-Graph is accordingly elementary.
You were probably disappointed because my question posed earlier in
this thread, on modification of the complex FFT to efficiently handle
real data, might have led to the assumption that C-Graph was concerned
with algorithmic representations. However, the question arose only
because of my natural disposition towards mathematics and algorithms
in engineering. The treatise on convolution and transform theory will
come later as part of my larger research in computer vision. C-Graph
(version 2) is not intended to address these complexities.
> See "A new matrix approach to real FFTs and convolutions of length 2**k"
> T. Lundy and J. Van Buskirk, Computing vol. 80, pp. 23-45 (2007).
Thank you. I made a note of this reference from Wikipedia some weeks
ago for my reading list. I'm glad you had a look at C-Graph. As you
can see, I made use of your lesson on non-advancing i/o!