Re: [harmonic_entropy] Digest Number 78

Hi Paul,

I may take a look some time and try to catch on what it all is about.

However, meanwhile, if you want me to code it quickly, you could
specify the algorithm itself, as an algorithm for a mathematician
or programmer to read. I wouldn't need to "understand it" in terms
of knowing why one wants to use that formula, just need to
know what the formula is that needs to be calculated.

Or as pseudo code if that is clearer.

Sorry, got a lot to think about at present, but may get to it
eventually, most likely once I get to working on the chords
section of FTS, as I might then be thinking about what counts
as a consonant chord anyway, and want to read a bit about some
of the various theories that have been developed for that.

That would be after first getting FTS 1.09 beta done and
released, the messages archiver finished, the FAQ tree program
done, and VRML trees released, and a few other things
that take less time. (at least that is my plan and order of
priorities at present)

However, if you can present an easy to read algorithm, and if
I think it would take very little time to program, I could do
it on one of my "days off" as it were. Maybe. I have other things
of that nature I also want to do, and your algorithm doesn't
directly relate to anything I'm involved in doing right now.

I think though, also, if doing as distributed computing, one would
like to take a bit of care and thought to make sure the program
will work nicely, exit gracefully and immediately when needed,
regularly saves to disk to avoid losing info, and so on.

Might take a little while, possibly more than one would think
at first, these things do sometimes become rather open ended.

I wonder if there are any other programmers who would like to
take up the challenge instead in the interim?

One could just write a program that takes a list of coords
as data, and for each one calculates the values and outputs
them, could be a console app. Something like that
wouldn't take much programming. Then another program that
just makes a series of data files for the first one:

data1.txt
data2.txt
data3.txt
etc.

You send some of the data files to the recipients who are
interested in running it in the background, console app
goes through it's working directory looking for all files
of type data*.txt, looks for any that lack a matching
output*.txt, reads each in turn, and outputs to output*.txt

When it is actually working on data, every second or so,
outputs to the console so you can see it is still
doing something, even if it is just "Still running".
or "Time so far for this session %d secs" or whatever.

When none are left to do, you are finished, and to indicate
that, program shows a message "Finished" and stops.

User then sends the data back to you, and you send them some
more input files to process.

One wouldn't need to be a windows programmer to do that.

One needs to take account of possibility that the user shuts
the computer down while program is in the middle
of making one of the output files.

To cope with that, first save each one as output1~.txt,
and only copy it to output1.txt when it is complete. So,
if shut down unexpectedly while making output1~.txt, then next
session, will look for output1.txt, not find it,
and so start again. Not very sophisticated, but
would work.

If I did do a fast job of it at some point, I suppose that
is how I'd do it, and could do it, but wouldn't want
to promise anything at present.

But, maybe this is a useful idea, maybe I can help in that
way by suggesting it?

Robert