Register | Sign In


Understanding through Discussion


EvC Forum active members: 65 (9162 total)
5 online now:
Newest Member: popoi
Post Volume: Total: 915,815 Year: 3,072/9,624 Month: 917/1,588 Week: 100/223 Day: 11/17 Hour: 0/0


Thread  Details

Email This Thread
Newer Topic | Older Topic
  
Author Topic:   The Minkowski's challenge
Percy
Member
Posts: 22391
From: New Hampshire
Joined: 12-23-2000
Member Rating: 5.2


Message 5 of 120 (352098)
09-25-2006 12:53 PM
Reply to: Message 1 by Albert Godwin
09-25-2006 11:37 AM


Albert Godwin writes:
Know computer viruses?
You know that the virus writers started using encryption in the late 80's to avoid detection. If you have a PC virus that mutates, can you force it to evolve an encrypted virus?
And if you can't, will you please stop saying that the whole of those creatures did evolve?
As previously noted by the first reply, no one is saying that PC viruses evolved.
The larger argument encompassed by the Minkowski/Faust dialog back in the thread proposal that asserts that microevolution doesn't lead to macroevolution isn't very precise, so I'll have to make some assumptions.
If microevolution is evolutionary changes within a species and macroevolution is evolutionary changes that result in change from one species to another, then Minkowski has to define species in his simulated world. If, for example (and simplifying for the sake of easy discussion), the "genes" of the original organism were "ABCDEFGHIJKLMNOP", how much change indicates a new species? Minkowski never says. His simulated organism is asexual, so the criteria of interbreeding cannot apply. There therefore needs to be a "genetic" definition of speciation.
--Percy

This message is a reply to:
 Message 1 by Albert Godwin, posted 09-25-2006 11:37 AM Albert Godwin has not replied

  
Percy
Member
Posts: 22391
From: New Hampshire
Joined: 12-23-2000
Member Rating: 5.2


Message 9 of 120 (352328)
09-26-2006 8:10 AM
Reply to: Message 7 by Albert Godwin
09-26-2006 3:30 AM


Albert Godwin writes:
Dear Barbarian,
I am not assembly expert, but please notice that the least mutation in biological systems is disastrous as well. so this program is no difference.
Albert, do you mean to say you posted material you don't understand and can't defend? Tch, tch!
But after all said and done,
Can i now conclude that you all failed to force this program to evolve encryption?
Let's see if I have this straight. You didn't understand what you posted, you didn't understand the rebuttal, but you want everyone to concede anyway. Is that about right?
Proofs of the fallacy of evolution don't come from poorly written novels. I think the suggestion back in the thread proposal that you go off and learn a little about artificial life and genetic algorithms was a good one.
--Percy

This message is a reply to:
 Message 7 by Albert Godwin, posted 09-26-2006 3:30 AM Albert Godwin has not replied

  
Percy
Member
Posts: 22391
From: New Hampshire
Joined: 12-23-2000
Member Rating: 5.2


Message 14 of 120 (352356)
09-26-2006 10:53 AM
Reply to: Message 11 by Albert Godwin
09-26-2006 9:56 AM


Albert Godwin writes:
Dear Barbarian,
I am speaking to you, and only you because it seems that you are the only one here who understands programming.
Only Barbarian? Darn! But then where did all the code for EvC Forum come from?
If you think that the original program did anything that can prohibit evolution of encryption, remove that thing. and if you believe that there is any addition that is needed to be made, make it!
As Barbarian explained, because the code truncates offspring code, it isn't possible for novel features to arise. As he further explained, generating new code from nothing isn't the way evolution usually works. One common way for new genes to arise is through duplication and divergence, where first two copies of a gene are made instead of one through a copying error during reproduction, then the genes accumulate different mutations and diverge in function through subsequent generations. Your code doesn't model this possibility, nor many others.
The other problem you have is that there is no selection pressure for encryption. Minkowski says he can't think of any selection pressure that would evolve encryption, and I can't either. But I also can't think of any selection pressure that would cause horses to evolve wheels. Why do you think the evolution of encryption is a good example of actual evolution in action?
I still think you'd be best served by going off and learning about artificial life and genetic algorithms before attempting to discuss the subject. Barbarian provided the example of Avida, and I agree that that's an excellent example for you, since it also models evolution through assembly code creatures. There are many other examples of artificial life out there, but Avida is very similar to Minkowski's approach. Tierra is another example of the same approach, and both Avida and Tierra are part of active ALife research efforts.
Alternatively, we could discuss artificial life and genetic algorithms in this thread, and you could learn about them through the discussion.
--Percy

This message is a reply to:
 Message 11 by Albert Godwin, posted 09-26-2006 9:56 AM Albert Godwin has not replied

  
Percy
Member
Posts: 22391
From: New Hampshire
Joined: 12-23-2000
Member Rating: 5.2


Message 17 of 120 (352364)
09-26-2006 11:26 AM
Reply to: Message 13 by Barbarian
09-26-2006 10:48 AM


Barbarian writes:
(1) is the task to evolve a mechanism which helps eluding a selector looking at patterns of N bytes? What is N? (I could tell right away if I saw the QBASIC code.) Am I right in calling this a stealth mechanism and not an encryption one?
I don't think Albert is using the proper term when he says "encryption", but he's basing his argument on the Minkowski novel and can't be blamed for that. After rereading the Minkowski/Faust discussion I can see that when Minkowsi says encryption he really means camouflage. Your own term, "stealth", is also much closer to what I think was intended. Camouflage and stealth are much more accurate terms when you consider actual evolutionary examples such as rabbits evolving white fur to blend in with snow.
If all Albert is looking for is an example of a code creature species hiding from a predator or otherwise protecting itself from selection pressures by evolving camouflage, then this should be easy. This happens in ALife all the time. In fact, it's so incredibly common and mundane that I don't think you should even go through the effort of coding yet another one, though it would be a fun exercise and well worth engaging in from that standpoint.
--Percy

This message is a reply to:
 Message 13 by Barbarian, posted 09-26-2006 10:48 AM Barbarian has replied

Replies to this message:
 Message 18 by Modulous, posted 09-26-2006 1:27 PM Percy has not replied
 Message 19 by Barbarian, posted 09-27-2006 7:22 AM Percy has not replied

  
Percy
Member
Posts: 22391
From: New Hampshire
Joined: 12-23-2000
Member Rating: 5.2


Message 24 of 120 (352795)
09-28-2006 9:40 AM
Reply to: Message 20 by Albert Godwin
09-28-2006 6:03 AM


Albert Godwin writes:
No, i am sorry. If you can evolve steath (which will not either happen, ny the way) that's not the challenge. the challenge is to evolve encryption. and do it in real programming, no virual simulations and no formal proofs. i want a practical responce.
I'm not sure why Barbarian didn't bring this up, but in reading the Minkowski/Faust discussion it seemed apparent that by encryption they actually meant camouflage. As Minkowski discovered when he ran his program, it achieved camouflage by slightly altering its code. As Minkowski himself says about the evolution of encryption, "that's not obligatory." Yes, encryption would also achieve the goal of hiding from the selector program, but so do very minor changes to the code sequence.
This is because the selection pressure is for hiding from the selector, not for encryption. As Minkowski makes clear in the discussion, simple mutations achieve the goal of hiding from the selector, and after that there is no selection pressure for further hiding. More complex approaches to hiding, such as actual encryption of the program code, cannot evolve if the code creature has already achieved hiding.
Minkowski said that he couldn't imagine any selection pressure that would evolve encryption, and neither can I, which isn't to say it isn't possible. But you've mistaken the way evolution works, as has been pointed out by others in this thread. Evolution does not lay out a specific goal like flagellum or gills. It lays out a general goal of "Produce more offspring and more viable offspring than everyone else." As genetic algorithms make clear (genetic algorithms is a subject that would be worth your while investigating), evolutionary solutions are often novel, surprising and unexpected. The Mikowski software provides selection pressure for camouflage, but you're requiring a specific solution of encryption, which isn't the way evolution works.
You can try to fine tune the selection pressures to produce encryption (fine tuning selection pressures is a primary topic in genetic algorithms), but what you would really need in that case is for both code creature and selector program to evolve at the same time. The reason the code creature won't evolve encryption is because fooling the selector is so easy that encryption isn't necessary. But if the selector could also evolve to be smarter then the code creature would be forced to develop more sophisticated camouflage techniques, possibly even encryption.
Keep in mind that the selector's task is much easier than the code creature's. All the selector has to do is recognize byte sequences, it doesn't have to know any encryption/decryption algorithms. If, for example, the byte sequence "BFB801BE0001B9B800E86500" from the code creature becomes after encryption "AEA7F0ADFFF0A8A7FFD754FF", recognizing one is as easy as recognizing the other for the selector. All the selector has to do is chance across the proper sequence of bytes through the mutation/reproduction process, it doesn't have to know anything about encryption.
--Percy
Edited by Percy, : Grammar.

This message is a reply to:
 Message 20 by Albert Godwin, posted 09-28-2006 6:03 AM Albert Godwin has not replied

Replies to this message:
 Message 25 by Barbarian, posted 09-28-2006 10:36 AM Percy has replied

  
Percy
Member
Posts: 22391
From: New Hampshire
Joined: 12-23-2000
Member Rating: 5.2


Message 26 of 120 (352806)
09-28-2006 10:43 AM
Reply to: Message 25 by Barbarian
09-28-2006 10:36 AM


Barbarian writes:
I tried to clarify that in the proposed amendment #1 above, but my English let me down and I could not promptly remember the word 'camouflage', so I proposed 'stealth' instead; nonetheless, 'camouflage' is a much better choice.
Oh, yes, I realize that. But in his Message 20 to you Albert said he wasn't interested in stealth but encryption:
Albert writes:
No, i am sorry. If you can evolve steath (which will not either happen, ny the way) that's not the challenge. the challenge is to evolve encryption. and do it in real programming, no virual simulations and no formal proofs. i want a practical responce.
It didn't seem like you addressed this in your Message 22.
--Percy

This message is a reply to:
 Message 25 by Barbarian, posted 09-28-2006 10:36 AM Barbarian has replied

Replies to this message:
 Message 27 by Barbarian, posted 09-29-2006 4:04 AM Percy has not replied

  
Percy
Member
Posts: 22391
From: New Hampshire
Joined: 12-23-2000
Member Rating: 5.2


Message 29 of 120 (353042)
09-29-2006 5:14 AM


Albert's participation in his own thread is a bit thin. It's been mentioned that Albert has started similar threads at other boards, and I imagine that's where his time is going. Google turned up one of these threads. This is from PhysOrg Forums' The Minkowski Challenge, A practical challenge to evolution:
Albert writes:
So long just more theoritizations
Look boys, There is a programmer guy called barbarian who will take the challenge
EvC Forum: Information
follow up and you will see that he will fail.
It seems he's as brief in discussion at other boards as he is here. He seems to think that the primitive and naive Minkowski evolution program (by the standards of the state of the art 20 years ago, let alone by the standards of today) represents a challenge to evolutionists, when the real challenge is how to bring Albert's understanding up to a level where meaningful discussion can take place.
Albert doesn't appear familiar with programming, artificial life or genetic programming. He's been encouraged to investigate the latter two but shows no apparent interest, and he hasn't engaged any of the replies questioning whether his challenge can say anything meaningful about evolution. It is tactically wise for the unarmed man to avoid the battlefield, but this approach only postpones the inevitable outcome, though Albert is unlikely to comprehend the result if he continues to resist learning about the area he's discussing.
Barbarian indicates he has a couple ideas of how to approach the problem of encouraging the evolution of encryption. Tuning the selection pressures is a common issue in genetic algorithm development, which unlike actual evolution tends to have very specific goals. The key is to fine tune the "environment" so that it provides selection pressures that push evolution in the necessary direction. It remains to be seen whether evolution of encryption is analogous to horses evolving wheels or rocket power, in other words, not a realistic goal.
I encourage Barbarian in his efforts while at the same time entertaining serious doubts about the advisability of this approach. If Barbarian is unsuccessful then evolutionists will properly conclude that the evolution of encryption is either too difficult a problem or simply isn't amenable to evolution, since we already know that evolution has been demonstrated many times in many ways, but Albert will conclude that it demonstrates the impossibility of significant evolution. And if Barbarian is successful then Albert will dispute the results, though at least discussion with him might become possible in this circumstance.
I'm fascinated by the research areas of artificial life and genetic algorithms. Given sufficient time I would be developing my own ALife system, but alas, this board's messages still need integration into the database and my day job is sparing me few cycles these days. But I do have time to discuss these topics. The great value of discussion is that everyone has the opportunity to learn something, so here's hoping that Albert begins discussing the subject soon.
--Percy

  
Percy
Member
Posts: 22391
From: New Hampshire
Joined: 12-23-2000
Member Rating: 5.2


Message 30 of 120 (353046)
09-29-2006 5:37 AM
Reply to: Message 28 by Barbarian
09-29-2006 4:29 AM


Hi Barbarian,
I hadn't yet seen this, your most recent message, when I posted my previous message. You've done a great job breaking down the problem and identifying the key issues.
The most important issue derives from the primitive approach taken my Minkowski. I had forgotten that the actual running and pruning of the offspring programs was manual. This definitely needs to be automated in order for any meaningful evolution to take place. It shouldn't run under DOS but Windows or Linux so that all illegal accesses and instructions can be trapped, and so that your mutation algorithm doesn't have to concern itself with the potential for generating destructive code.
You're actually giving yourself the very ambitious goal of developing an ALife system, which could be extremely time-consuming. Perhaps you have resources or existing code at your disposal that would shorten the development time, in which case I encourage you to go for it. But if this would be a significant effort for you why not instead translate Minkowski's code into an existing ALife framework like Avida? The Minkowski program would be one ALife creature, the selector (or selectors) would be another and the equivalent of a predator.
Anyway, best of luck. I wish I had sufficient available time to extend an offer to help.
--Percy

This message is a reply to:
 Message 28 by Barbarian, posted 09-29-2006 4:29 AM Barbarian has not replied

  
Percy
Member
Posts: 22391
From: New Hampshire
Joined: 12-23-2000
Member Rating: 5.2


Message 32 of 120 (353058)
09-29-2006 7:42 AM


Examining Avida
I've resisted investigating any ALife systems in detail because I was much more interested in developing my own system, but faced with the practical impossibility of this at present I've broken down and started reading the Avida documentation.
My first impression after 5 minutes: what an incredibly arcane virtual instruction set! What an incredibly obtuse virtual CPU! I assume that as I read on I'll come to see that this derives from necessity, but the initial impression is of general bewilderment. I've programmed in PDP-8 assembler and PDP-11 assembler, and I have read-only familiarity with PDP-10 assembler and VAX assembler, and I've examined Sparc assembler and Intel x86 assembler. I'm familiar with the general architecture of the associated CPUs. But I've never seen anything even vaguely like this Avida instruction set and architecture, though perhaps PDP-10 byte pointers come close in some respects. But I've little experience with virtual machines, maybe they are conceptually more "freeing". Maybe Avida makes sense as a virtual machine. I'll reserve judgment for now.
Still, get a load of some of these instructions:
(d) if-n-equ Execute next instruction only-if ?BX? does not equal its complement
Say what??? Okay, let's not panic, let's try to figure this out.
?BX? is register BX. The question marks are an indicator that a NOP immediately following the instruction can alter the register to be AX, BX or CX, depending upon whether the NOP is NOPA, NOPB or NOPC (not much of a NOP if it actually has an effect).
So the next instruction is executed if register BX is not equal to its complement? When is anything ever equal to its complement (which is where all 0 bits become 1 and all 1 bits become 0)? Never, that's when! So what the heck do they mean by complement?
Reading on, it turns out that "complement" has a special (and stupid (I have a feeling I'll be using this word alot)) meaning in Avida. A register's complement is the next in the sequence. There are three registers AX, BX and CX in that order, wrapping at the end. The complement of BX is CX. So the if-n-equ instruction executes the next instruction if BX doesn't equal CX.
Avida also defines something called a "template complement." A template is a sequence of registers, e.g., ABAAC. The complement of this template is the next register in the sequence for each register, BCBBA. A template is defined by a sequence of NOP instructions, so the ABAAC sequence would be defined by this sequence of NOP instructions:
NOPA
NOPB
NOPA
NOPA
NOPC
Why do they feel the need for this?
Reading The Instruction Set File documentation I see that the unit of mutation is the instruction. Each instruction has these attributes:
Redundancy: the frequency of the instruction. It controls the likelikhood of being mutated to.
cost: number of CPU cycles to execute
ft cost: addition cost the first time an instruction of this type is executed.
prob fail: the probability that the instruction doesn't work, in which case it is a NOP for that cycle.
Omigod, reading on I just realized the reason for the template complement, and it's incredibly arcane. They use it as a labeling system. This is unbelievable, let me explain.
They can search through the program for a given template using the h-search instruction. The h-search instruction is followed by a template, and it searches through the program looking for the complement of the template. For example, this h-search instruction searches through the program looking for the template AB:
h-search
NOPC
NOPA
Why does h-search look for the complement of the template instead of the template? Because otherwise it would find itself!!!
All they really needed was a labeling system. All the macro assembly languages have them. I can see that because instructions can mutate, and because labels in the program are made up of instructions, that the labels can mutate, but there are more straightforward ways to accomplish the same thing. I can see the problem they're attempting to address. A single mutation to the label ABC might cause it to become ABB, but if your label is permitted to consist of all 26 letters then the odds of neutral and negative mutations might become prohibitively high.
I believe they were driven in this direction because of their desire to make the copying code (the reproductive code) part of the program. I can see the desireability of this, even the necessity, but I think there are far better approaches than this. I'm sure that once you've lived with Avida virtual code for a while that it all begins to make intuitive sense, but I would want something more accessible that anyone already familiar with assembly code could grasp intuitively after just a few minutes.
I couldn't find prebuilt Avida executables for Windows on line, and I don't have the tools for building C++ programs on my system. I could do it on a Unix or Linux machine, but now this is beginning to seem like it requires too much time, given that my workday must begin soon. So that's all I have to say about Avida.
--Percy

Replies to this message:
 Message 33 by Barbarian, posted 09-29-2006 8:06 AM Percy has replied

  
Percy
Member
Posts: 22391
From: New Hampshire
Joined: 12-23-2000
Member Rating: 5.2


Message 34 of 120 (353066)
09-29-2006 8:17 AM
Reply to: Message 33 by Barbarian
09-29-2006 8:06 AM


Re: Examining Avida
I had already downloaded that. I didn't notice any Windows binaries.
--Percy

This message is a reply to:
 Message 33 by Barbarian, posted 09-29-2006 8:06 AM Barbarian has replied

Replies to this message:
 Message 35 by Barbarian, posted 09-29-2006 8:36 AM Percy has replied

  
Percy
Member
Posts: 22391
From: New Hampshire
Joined: 12-23-2000
Member Rating: 5.2


Message 36 of 120 (353080)
09-29-2006 9:07 AM
Reply to: Message 35 by Barbarian
09-29-2006 8:36 AM


Re: Examining Avida
Oh, I see where I went wrong. I had clicked on the "Current Release" link that appears in the list of links for Avida site navigation. This took me to a page that sent me to SourceForge which has the 2.6 release, but sources only.
I now see the Windows Binary link in the Current Release box on the home page. It's for version 2.0, but that should be fine for giving it a try. Both viewers seem to work for me. I started with qt-viewer, it's running the default simulation now. Thanks for the help!
--Percy

This message is a reply to:
 Message 35 by Barbarian, posted 09-29-2006 8:36 AM Barbarian has not replied

  
Percy
Member
Posts: 22391
From: New Hampshire
Joined: 12-23-2000
Member Rating: 5.2


Message 44 of 120 (353604)
10-02-2006 11:05 AM
Reply to: Message 43 by Barbarian
10-02-2006 9:56 AM


Hi Barbarian,
I think you may be creating extra and unnecessary work for yourself by including an explicit "does it work" test. The determination of whether it works or not is made by the outcome of the evolutionary process. If the organism survives to reproduce as do its offspring for generation after generation, then it works. If its line of descendents eventually dies out, then it doesn't work.
--Percy

This message is a reply to:
 Message 43 by Barbarian, posted 10-02-2006 9:56 AM Barbarian has replied

Replies to this message:
 Message 45 by Barbarian, posted 10-02-2006 2:27 PM Percy has replied

  
Percy
Member
Posts: 22391
From: New Hampshire
Joined: 12-23-2000
Member Rating: 5.2


Message 46 of 120 (353657)
10-02-2006 3:01 PM
Reply to: Message 45 by Barbarian
10-02-2006 2:27 PM


I think you're addressing a superset of the problem and making your task more difficult. If given your skill set and available resources it doesn't really seem difficult to you then pay this no mind, but given that you're only working on weekends you do sound time-limited.
Once you begin predefining outcomes you're more in the realm of genetic algorithms than artificial life. Just as the mutation algorithm needn't be part of the code creature, a design decision you've already made, replication needn't be part of the code creature, either. It *can* be, but it doesn't have to be for the problem you're solving.
The primary required components are a virtual machine, a replication and mutation mechanism, and an evaluator (selector) that assesses a code creature's fitness as measured by ability to produce encryption, no matter how rudimentary. The selector is actually your biggest problem, or it would be for me if I were doing this.
--Percy

This message is a reply to:
 Message 45 by Barbarian, posted 10-02-2006 2:27 PM Barbarian has replied

Replies to this message:
 Message 53 by Barbarian, posted 10-06-2006 3:27 AM Percy has not replied

  
Percy
Member
Posts: 22391
From: New Hampshire
Joined: 12-23-2000
Member Rating: 5.2


Message 70 of 120 (356835)
10-16-2006 9:43 AM
Reply to: Message 69 by Barbarian
10-15-2006 4:03 PM


Barbarian writes:
As promised earlier, I have summarized the rules I try to work within. I am doing this for my own amusement...
That's good, because...
... - I am done with the tedious work of testing the assembler, the virtual machine, the debugger and the mutation mechanism - and have no idea when will I finish. At the current rate, sometime around the end of the year ...
That's a lot of effort. Albert has already demonstrated a lack of interest in discussion or in investigating the relevant fields. His sole source of information is a fictional novel where the accompanying software example is naive in the extreme (manual selection, for one very significant example). I assume that Albert's attention span on this topic will be similarly shallow, and I doubt that he will be anywhere to be found by year's end.
Even if Albert sticks around, he's incapable of understanding the results anyway, so even if you successfully evolve encryption he will cast unsubstantiated and nonsensical criticisms that's he's unable to defend, accompanied by an inability to comprehend that he lacks the necessary background and knowledge to assess or discuss the results, but he'll keep posting anyway.
Normally I'm not so personal and critical of another member, but I have limited myself to those qualities that Albert has already amply demonstrated and that are substantively affecting this thread, for example, his reluctance to engage in discussion or to inform himself of the current state of the art. You're making a substantial investment of your personal time, and so I think you should be very certain that you are doing this for it's own rewards, because proving to Albert that he's wrong won't be one of them.
--Percy

This message is a reply to:
 Message 69 by Barbarian, posted 10-15-2006 4:03 PM Barbarian has replied

Replies to this message:
 Message 71 by Barbarian, posted 10-17-2006 4:54 AM Percy has not replied

  
Percy
Member
Posts: 22391
From: New Hampshire
Joined: 12-23-2000
Member Rating: 5.2


Message 83 of 120 (357345)
10-18-2006 7:39 PM
Reply to: Message 81 by Dr Jack
10-18-2006 7:53 AM


The level of abstraction of a machine is not a consideration for this issue. Whether or not a particular machine architecture has ever been realized in actual hardware, i.e., is virtual, is irrelevant.
--Percy

This message is a reply to:
 Message 81 by Dr Jack, posted 10-18-2006 7:53 AM Dr Jack has not replied

Replies to this message:
 Message 84 by Jazzns, posted 10-19-2006 11:25 AM Percy has replied

  
Newer Topic | Older Topic
Jump to:


Copyright 2001-2023 by EvC Forum, All Rights Reserved

™ Version 4.2
Innovative software from Qwixotic © 2024