David Clounch wrote:
>
>
> The rest of your post is about specification, not complexity. Anti-ID
> people know one word: complexity. They don't _seem_ to talk about
> specification. Am I wrong?
To a compiler writer such as myself a program is a specification of what
the computer should execute. So yes it is a specification. Not all
things that are highly complex need long detailed specifications but
many do. A fractal image can be quite complex but the specification or
generating program can be quite a simple program. (I think that is the
idea of Chatin/Kolmogorov information although I am not sure they
extended their ideas quite to that extent.) I doubt that any
specification necessary to create life could be reduced to the
equivalent of a small trivial program but maybe I am wrong. When I read
Dembski I thought of the information/complexity that he talked about in
the same way as I do when reading Meyers. Again I am not thinking of
complexity in its technical sense but in the sense that a chemical
engineer would view a complex detailed specification for a chemical
process.
> And nobody talks about partition functions. Why partition functions?
> Because chemical engineering is based on statistics. In my view a
> mutation isn't sufficient. It needs other parts. Parts that are
> produced by previous mutations but which may not be used until a later
> mutation comes along. So its the concatenation of mutations that counts.
As best I understand what you are saying yes.
> A cell isn't just biology. Its really chemical engineering. And that
> mathematics is what governs populations of molecules everywhere -
> organic or inorganic. Do you disagree?
Certainly you could look at the problem of getting a cell going as a
chemical engineering problem similar to getting a chemical process/plant
going. My daughter is trained as a biochemist and what she did when
working sounded like a very specialized area of chem engineering.
Let me explain a point for none programmers. A good program is written
to be read by other programmers who might need to understand the program
at a point in time when the original programmer could well be long gone
to other projects or even to help the author when looking back at
something she wrote in the past, say six months ago. A compiler
translates programs into something that the computer can execute. A
good program contains a huge amount of comments and other verbosity that
is really not essential for translation/specification of the program
logic by the compiler but is there to help a human understand the
program among other reasons. Just like the genome programs over time
contain dead or inactive programming code for all kinds of reasons that
I'm not sure are really germane to my analogy although some could well
remain as remnants of previous function or the process of "improving"
the programming code. Rich I well realize the analogy is not perfect by
any means.
I had meant to congratulate Rich for taking the time and patience to
converse with FoF.
Dave W
ps Programmer talk
> Surely it is XML. ;)
XML as used for inter-program communication is close to undecipherable
by mere mortals and is very verbose. We transferred our Fortran
compiler work to another IBM site and the former team leader of our
Fortran compiler went to work on the XML parser. High performance is
not in the equation but I understand XML solves many format and endian
conversion problems but I have not really looked into it myself and
since much XML is sent down communication links, performance is limited
by other factors.
> Well, mr. huffman sez it will get larger. Been there, done that.
> Seen it in action.
As I recall there are algorithms much better than Huffman but that is
not my area of specialization. Rich would know better.
To unsubscribe, send a message to majordomo@calvin.edu with
"unsubscribe asa" (no quotes) as the body of the message.
Received on Sat Nov 21 10:17:01 2009
This archive was generated by hypermail 2.1.8 : Sat Nov 21 2009 - 10:17:01 EST