Darwinbots Forum

Code center => Suggestions => Specialization, Metabolism, Digestions and Env Grid => Topic started by: shvarz on March 18, 2005, 03:06:08 PM

Title: General approach to metabolism
Post by: shvarz on March 18, 2005, 03:06:08 PM
OK, I worked out the system.  It is very easy to start using, it requires only small changes in existing bots and will be completely backwards-compatible for any bot that is designed with metabolism in mind.  Even if we change the metabolism pathways a lot in the future.  The system is very intuitive, so can be picked up quickly by anyone.

This is very general description, I don't want to go into details and balances.  If you have doubts - ask "how will this work" and I'll explain.  

Finally, this is a summary of many ideas from different people, so don't blame it all on me :)  But do praise me a lot :)


1. We make a molecule array.  Things like venom, poison, fat and energy are now referred to that array instead of usual memlocs.  The molecules can also be addressed as numbers (not by name).  I'd say 256 slots should be enugh.

2. We make an enzyme array.  The enzymes Nums desribed are processed only once, when robot is created (or born) and those found will have 1, those absent - 0.  This is minimal level of enzyme and it never gets lower.  The amounts can go up automatically or bots can make them through DNA.  Enzymes are slowly decayed (but never below 1).  I'd say we'll need 2048 slots for enzymes.

3. Molecules are divided into two types - terminal and intermediate.  In a chain of A>B>C>D, A and D are terminal, while B and C are intermediate.  Terminal molecules are not acted upon unless there is a command from DNA.  Intermediate molecules are automatically processed, but this processing can be overriden by DNA commands.  Only terminal molecules are passed over during feeding.

4. Stomach size is defined by the total number of enzymes.  Its content  is purged every N cycles, which is also defined by total number of enzymes (the more enzymes the longer food stays).  Molecules from stomach are transferred to bot at the rate corresponding to the number of specific enzymes they have (no DNA commands here).  If there is no enzyme, the molecule is not absorbed but is dropped into env. grid (not as waste, as molecule) during purging.

5. Digesting is done by DNA command.  All you need to say is molecule's name (or number) and "break" command.  The program checks if bot has that molecule and if it has appropriate enzymes and will convert the molecule to energy.  The rate of conversion is proportional to the amount of specific enzyme bot has.  The program actually runs the broken molecule through intermediates, but bot does not have to see this.  Digesting can be improved by specifying the path of digestion.  The most efficient way is to spell out each and every step in DNA - then bot can get more energy and it can get it faster.

6. Same goes for making molecules.  All you need to say is molecules' name and "make" command in DNA (no more store commands here).  Program will do it for you.  But you'll be better if you spell out the path.
Title: General approach to metabolism
Post by: PurpleYouko on March 18, 2005, 03:29:28 PM
Like most of it with a few minor problems

Quote
Stomach size is defined by the total number of enzymes. Its content is purged every N cycles, which is also defined by total number of enzymes (the more enzymes the longer food stays).

Purging every N cycles is not very feasible. What if the robot has just eaten 1 cycle before the purge? Does he lose it all. Or are you saying that each food particale only stays in the stomach for N cycles? If so then nice idea but very difficult to implement as each particle of food in each robot's stomach would have to have its own counter. Processor intensive doesn't even come close. Billions of food particles could be present in all the robots combined stomachs at any given time.

Better to purge a small percentage of the stomach contents each cycle

(Also have a secondary storage area like intestines which stores undigested food particles and waste products that will collectively be contained by .waste which needs to be manually purged just like it is now before the bot gets sick.)

Quote
5. Digesting is done by DNA command. All you need to say is molecule's name (or number) and "break" command. The program checks if bot has that molecule and if it has appropriate enzymes and will convert the molecule to energy. The rate of conversion is proportional to the amount of specific enzyme bot has. The program actually runs the broken molecule through intermediates, but bot does not have to see this. Digesting can be improved by specifying the path of digestion. The most efficient way is to spell out each and every step in DNA - then bot can get more energy and it can get it faster.

6. Same goes for making molecules. All you need to say is molecules' name and "make" command in DNA (no more store commands here). Program will do it for you. But you'll be better if you spell out the path.

Not so keen on this in its present form. I see problems with running this from DNA. It would be impossible under the present DNA scanning to perform more than one of your break or make commands per cycle as subsequent instances will simply overwrite the first one such that only the very last one would ever be performed.

Another possibility would be to design custom paths in a setup section of the DNA file in a similar way to the enzyme list. Maybe only allow a limited number of path slots (say 10). Then they can run automatically each cycle or be accessed by a series of sysvars like make1, make2....break1, break2. These controls will take up minimal space in the sysvars registry and will allow the custom make and break paths to be executed from DNA.

How does that sound?

 :D  PY  :D
Title: General approach to metabolism
Post by: shvarz on March 18, 2005, 03:44:31 PM
About purging:  It was Nums idea.  The timer starts when bot eats something.  N cycles later ALL food is purged even the one just swallowed and timer is reset.  If N is >10, this should not handicap bots too much.

About multiple break commands: Is there absolutely no way to make it so that "molecule array" is changed after each command?
Title: General approach to metabolism
Post by: shvarz on March 18, 2005, 03:57:15 PM
I am confused.  Again, how come "break" commands will override each other?  Store commands don't.

You can say

1 2 store
3 4 store
5 6 store

Same here:
you have molecules called 1, 2, and 3

1 break
2 break
3 break

"break" command simply means decrease value in molloc (molecular location) 1, increase value in molloc 2

Works like this:

Before: 9 0 0 (these are values in mollocs 1, 2,3 correspondingly)
Cycle 2: 8 1 0
Cycle 3: 7 1 1
Cycle 4: 6 1 2

Should work, or am I dumb?
Title: General approach to metabolism
Post by: PurpleYouko on March 18, 2005, 04:00:07 PM
NO NO NO NO NO NO to infinity.

I Hate that idea.

Besides which that would really penalize heavy duty tank type bots or a bot who spends a lot of energy powering up a shot.

Just imagine that a stray shot containing tiny amounts of food hits this bot and sets off the timer.

Then a couple of cycles later he manages to land a really big shot on his target grabbing about 1000 energy in one go after spending about 200 to make the supershot. It takes at least 3 cycles for the shot to reach its target, then another 3 to get back. That is 8 cycles gone before he fills his stomach.

Cycle 9 he gets to digest about 50 points of the 1000 that he just went to a whole bunch of trouble and expense to get.

Then 950 points of food is dumped to the grid!

Terrible Terrible idea.

 :(  PY  :(
Title: General approach to metabolism
Post by: shvarz on March 18, 2005, 04:10:55 PM
OK, I don't care about the exact mechanics of pooping.  As long as there is stomach and enzymes are needed to absorb stuff, I am OK.  These are details.

What about break/make commands?
Title: General approach to metabolism
Post by: PurpleYouko on March 18, 2005, 04:15:34 PM
Quote
I am confused.  Again, how come "break" commands will override each other?  Store commands don't.

You can say

1 2 store
3 4 store
5 6 store

Same here:
you have molecules called 1, 2, and 3

1 break
2 break
3 break

"break" command simply means decrease value in molloc (molecular location) 1, increase value in molloc 2

Works like this:

Before: 9 0 0 (these are values in mollocs 1, 2,3 correspondingly)
Cycle 2: 8 1 0
Cycle 3: 7 1 1
Cycle 4: 6 1 2

Should work, or am I dumb?
Hmm hadn't thought of it that way. Would that work I wonder?

Let's work through this logically.

The store command is an "operator" rather than a command

That is to say that it manipulates the stack and nothing else. That is how come we can use it multiple times in the genome, just like you can with inc, dec, add etc.
You can't do this with .refup or .mkshell or any of the sysvars.

Operators are scanned during DNA parsing and are used only to manipulate values on the stack and in memory locations. Each robot's entire DNA file is parsed this way on each cycle.

At the end of the parsing cycle, the program passes the robot memory files over to the main loop which then acts on whatever value is now in each memory location.
At this stage the actual DNA is irrelevent since we only care about memory locations. All actions are performed during this step of the program based only on memory locations and the values in them therefore only one instance of a sysvar command can be executed per cycle.

Now could we put digestion into the DNA parser?

I think it would be possible but it would be extremely difficult as the entire parsing engine would have to be changed quite dramatically so that it is able to recognise your new functions as operators instead of sysvars.
I could do it, but wouldn't it just be easier to add a small bank of sysvars which wouldn't involve any changes to the layout of the program wahtsoever?

How many molecules are we talking about here. If you want to add 100s then it will be worth changing the parser but if there are just 10 it will be so much easier to add a bank of sysvars.

 :D  PY  :D
Title: General approach to metabolism
Post by: Botsareus on March 18, 2005, 04:20:08 PM
(I'll try to prove my point again , good luck to me)

How about a three enzyme system, and one gas in the e-grid.

The Robots starts out Having enzymeA:

Quote
cond
start
20
.useenzymeA
store
stop

It slowly eats up all the gas in the e-grid and mutates.

It cant have bouth enzymeB and enzymeC in the same time. ex:

Quote
cond
start
20
.useenzymeB
store
20
.useenzymeC
store
stop
can't happen

then if it evolves to use enzymeB (e-grid gas ran out slowly)

we will have

Quote
' Alga minimalis
'
' Vegetable
'
' This robot has a single gene,
' necessary for it to reproduce.
' Energy is given to it by the sun!!!,
' forget about the Fe#5!"autotroph" box.

cond
start
  20
  .useenzymeB
  store
  50
  .repro
  store
  15
  .aimdx
  store
  50 'no enzymeC so does not work
  .up 'no enzymeC so does not work
  store 'no enzymeC so does not work
 -1 'no enzymeC so does not work
  .shoot 'no enzymeC so does not work
  store 'no enzymeC so does not work
stop
end

or it can evolve to use enzymeC (e-grid gas ran out slowly, time to eat the alga)

Quote
cond
start
  20
  .useenzymeC
  store
  20 ' No way , enzymeC found so this does not work
  .useenzymeB ' No way , enzymeC found so this does not work
  store ' No way , enzymeC found so this does not work
  20 ' Dam,it No more gas
  .useenzymeA ' Dam,it No more gas
  store ' Dam,it No more gas
  50 'I hunt for food now.
  .up 'I hunt for food now.
  store'I hunt for food now.
 -1 'I hunt for food now.
  .shoot 'I hunt for food now.
  store 'I hunt for food now.stop
end

But hey , thats only the simple and the programer frandly idea , who needs it right?
Title: General approach to metabolism
Post by: PurpleYouko on March 18, 2005, 04:27:01 PM
It is too simple in many ways, you couldn't go far with only 3 enzymes. What we need are infinite variability of enzymes.

On the other hand it involves exactly what I am trying to avoid at all costs.
It make the DNA directly handle the mechanics of digestion.
I don't like that idea one little bit.
Digestion has to be automatic or every bot built without those specific controls will be unable to survive. This would efectively wipe out every existing robot completely. We would have empty league table and a bunch of pissed off bot-programmers.

 <_<  PY  <_<
Title: General approach to metabolism
Post by: Botsareus on March 18, 2005, 04:29:09 PM
Thats why you make the program "patch" every single bot to use a sertain enzyme in the bigging of the simulation.
Title: General approach to metabolism
Post by: Botsareus on March 18, 2005, 04:47:41 PM
Py, you are saying we change the system on the bots without effecting the DNA? There is practicaly no way to do that.
Title: General approach to metabolism
Post by: PurpleYouko on March 18, 2005, 05:05:15 PM
There are loads of ways to do it

here is one way to do it.

Infinite (almost anyway) kinds of enzymes defined in hexidecimal bit patterns and stored in a pattern at the end of the DNA. User programmable and mutates.

At the start of the sim or when a robot is born, the list of enzymes contained in the pattern is scanned into the robots enzyme array and all present enzymes are turned on for that robot.

The robot shoots normally.

It diverges into two different possible systems at this point.

Method 1
Method 2
No direct DNA control at all. Everything behind the scenes and fully automated yet also able to evolve with successive generations.

 :D  PY  :D
Title: General approach to metabolism
Post by: PurpleYouko on March 18, 2005, 05:09:18 PM
Where the enzyme interacts with the e-grid directly then it will do so automatically as a robot with the correct enzyme passes over an e-grid location that contains a substance that it can metabolize.

No direct DNA control. Automated, fully backward compatible with older bots and able to mutate.

 :D  PY  :D
Title: General approach to metabolism
Post by: PurpleYouko on March 18, 2005, 05:10:22 PM
Simple, Easy, To the point and minimal hassle

 :D  PY  :D
Title: General approach to metabolism
Post by: Botsareus on March 18, 2005, 05:10:37 PM
Ok , what If I want to write a simple robot that only eats the e-grid gas and reproduces , under your system how will dna of this robot look like?

(This robot is not a plant or a hunter, It eats a gas that slowly runs out in the e-grid)
Title: General approach to metabolism
Post by: PurpleYouko on March 18, 2005, 05:15:05 PM
Just like any other robot.

The only difference is that you will need to design, copy, mutate or otherwise adjust the enzyme bit pattern to be able to interact with the e-grid in the way that you want.

There will be millions of variations to the enzyme bit pattern so some of them will work. You just need to find the right ones. After you find the right short pattern then you can build it into any long pattern file that you like.

The system is simple on the surface yet can become very complicated if you want to get deep into it. The fine tuning implications are absolutely phenomenal

 :D  PY  :D
Title: General approach to metabolism
Post by: PurpleYouko on March 18, 2005, 05:19:22 PM
Quote
(This robot is not a plant or a hunter, It eats a gas that slowly runs out in the e-grid)

For this to work you would have to be able to

1  Be able to read the e-grid. That is in the plans for the sysvars.

2  Assume that the robot will mutate before the food supply is exhausted

3  Have another species that metabolizes in the opposite direction so that the gas on which the first species feed, is the waste product of the second species. Maybe a plant that changes sunlight to methane. Any route is possible, not just real ones.

Either way it will all be automatic. the only thing that DNA will control is locating the best pockets of food gas.

 :D  PY  :D
Title: General approach to metabolism
Post by: Botsareus on March 18, 2005, 05:21:47 PM
No , I Dont want to mutate a bot that feeds on the grid, I want a bot a simple bot to start with , and to evolve it into using sun light , or hunting for food.

The DNA I had in mind was somthing like

cond
*.nrg
3000
>
Start
'reproduce
store
Stop
Cond
Start
20
*.feedongas
Stop

Then I will watch this robot develope Photosinthasize(speller) or hunting strategy.
Title: General approach to metabolism
Post by: Botsareus on March 18, 2005, 05:22:31 PM
Whats the DNA you have in mind , post it here.

If its more then DNA , post the DNA an the OTHER SETTING as well.
Title: General approach to metabolism
Post by: PurpleYouko on March 18, 2005, 05:22:43 PM
I could see this working as a small group of methane producing veggies slowly releasing methane to the e-grid.

Then a few robots that feed on methane will gradually converge on the veggies location then sit peacefully around them while they feed on the plentiful gas.

One of them might mutate the ability to live on a different gas and move out to a new place to start another colony.

Cool eco-system without a single DNA controlled enzyme in sight.

 :D  PY  :D
Title: General approach to metabolism
Post by: Botsareus on March 18, 2005, 05:25:20 PM
I was thinking "Hunter Robots" can eat the plants "Directly"

P.S.

You still did not post any dna or settings...
Title: General approach to metabolism
Post by: PurpleYouko on March 18, 2005, 05:35:26 PM
OK here is a simple robot with a possible enzyme array.

Just an idea. I haven't entirely worked out the best way to read the grid yet

Code: [Select]
' reads the grid one ahead. If it has more stuff than this one then move ahead
cond
*.gridahead *.grid >
start
1 .up store
stop

cond
*.nrg 6000 >
start
50 .repro store
stop
end

enzyme ff12b56cae

All this will do is move straight ahead, constantly feeding from the e-grid using its enzymes

I have no idea what this enzme number will contain but the chances are that it will have one or two useful enzymes in it. The enzyme coding hasn't been worked out yet.

Imagine that 2b56c represents an enzyme that is pretty good at extracting methane from the egrid. It will constantly work based on the present concentration of the methane at the bot's current location.

Maybe 22b56 is another enzyme that is able to extract energy from sunlight. This robot doesn't have it right now but a small mutation of the enzyme pattern will easily enable it for the next generation.

 :D  PY  :D
Title: General approach to metabolism
Post by: PurpleYouko on March 18, 2005, 05:38:21 PM
Quote
I was thinking "Hunter Robots" can eat the plants "Directly"

P.S.

You still did not post any dna or settings...

1 yes they can if their DNA includes shooting and if they carry the right enzyme to digest plant material

2 Dude! Give me a chance! I do have a life outside of DB you know. And it involves working!

 :rolleyes:  PY  :rolleyes:
Title: General approach to metabolism
Post by: Botsareus on March 18, 2005, 05:39:33 PM
ok , nice , code it , code it. take a week off and then code it.
Title: General approach to metabolism
Post by: PurpleYouko on March 18, 2005, 05:44:24 PM
As I said with my two possible options, the shot will either return pure energy after pre-digesting a small part of the target or it will return undigested material that the robot will process internally.

As it is now, a robot without -1 shoot store can evolve it but is not that likely to.

All a robot would need in additin to this is the correct (or one of the many correct yet differently efficient) enzymes that will allow it to metabolize fat, protein, lignin(trees) or cellulose(leaves) or any of the other myriad things that a bot could specialize in.

Without the correct enzyme a shot will just return a bunch of useless material .

Anyway. Gotta go home now.

Catch ya all later.... maybe

 :outahere: PY  :outahere:
Title: General approach to metabolism
Post by: Botsareus on March 18, 2005, 05:47:56 PM
Quote
As it is now, a robot without -1 shoot store can evolve it but is not that likely to.

I think it must be %50 as likely to become a plant and %50 as likely to become a "hunter witch uses .shoot"

Not sure how to work it out yet , any bright minds out there can help me out?
Title: General approach to metabolism
Post by: Botsareus on March 18, 2005, 06:04:40 PM
I know: Make enzymes that digest plant material and "meat" cheaper then enazymes that feed on gases and sunlight.

Everyone agree? That gives us the 50%/50% I was looking for.
Title: General approach to metabolism
Post by: Anonomous Guest Person on March 18, 2005, 06:12:24 PM
Erm. May I say something? If not, then tough. :P
Anyway... I think that we need simplicity. Variability, but simplicity.
And I personally think it wouldn't be much of an improvement to make enzymes automatic.
If real organisms actually create enzymes automatically, without any influence from their DNA, then I'd be rather surprised, as well.

Personally, I think digestion should be handled by genes. So what if all the bots go obsolete? Have you seen how pathetic I Flamma is? When I first got this program, I was amazed by how dangerous it was, but now it's sorta crappy.
And also, we are going from 2.35 to 3.0, which is a rather large jump. Either way, bots'll become rather obsolete.
Even my two uberfied bots Duo Minimalis and Deathgrip, will probably need to be rewritten!

Anyway, I'd much rather like it if DNA handled digestion. It'd put more challenge into it!

And also, other then making it a bit easier to program (and I don't think it'd be that much harder to make digestion manual), what advantages do automatic enzymes have?
I don't even think it's really lifelike.

Now, if you propose that we do some kind of system where a bot gets up to 10 enzymes, which their DNA can control, but can't modify, that'd be pretty neat.
In fact, that's not a bad idea.
Title: General approach to metabolism
Post by: shvarz on March 18, 2005, 06:21:24 PM
Concentrate people!  If you have your own idea on how to do this stuff, just start another topic.  Seriously, it distracts a lot.

Anyway, PY - you said it right, I want break-make commands to be operators.  And very complex ones.  They should check whether enzyme is available, adjust for enzyme amount, adjust for enzyme efficiency, then consult metabolism sytem and perform actions on several cells - the molecule (or several) that comes in, the molecule(s) that come out, energy.

I know this may be a lot of coding.  But as I said, once set up, this system will have a very long life, will be backwards compatible and easy to use.
Title: General approach to metabolism
Post by: PurpleYouko on March 18, 2005, 07:36:33 PM
OK Shvarz

I think you have a valid point and coding the controls for the stuff into the operators would certainly get around a lot of the perceived problems.

Your make break stuff would work pretty well with my proposed atomated enzymes. As you said, the program would take your "make" or "break" operator then find the best available enzyme to carry out the process. It would then perform the action using the efficiency of the enzyme that it finds.

I still don't really like the idea of making actual enzymes ahead of time.

Using this system outlined above and in your earlier post, I still think the enzymes should be created on demand automaticaly.

Now to figure out how to actually code this stuff

 :D  PY  :D
Title: General approach to metabolism
Post by: shvarz on March 18, 2005, 07:45:02 PM
Yay, PY is on my side!

Now who wants to fight me and PY?!

 :cheers: :clap:  :shoot:

On the serios note:  think back to this morning, PY.  As soon as you saw that pizza, your stomach started releasing enzymes for carbs/fats digestion.

But this is details....
Title: General approach to metabolism
Post by: Botsareus on March 18, 2005, 08:00:43 PM
Quote
Yay, PY is on my side!

Now who wants to fight me and PY?!

Shvartz , If you and PY are ok with it ( I don't get it so I dont care ) then I am ok with it. So I think its time to summarize it and post it here: http://s9.invisionfree.com/DarwinBots_Foru...p?showtopic=202 (http://s9.invisionfree.com/DarwinBots_Forum/index.php?showtopic=202)

Just make sure that the summery feets nicely with my 50/50 system (http://s9.invisionfree.com/DarwinBots_Forum/index.php?showtopic=206)
Title: General approach to metabolism
Post by: Numsgil on March 22, 2005, 03:15:41 AM
Can I make a suggestion?

First of all this is strictly about digestion.  As I said before vacation, what we really have here are two interrelated but seperate systems.  One for foreign matter and the other for internal metabolism.

schvarz seems to be thinking in terms of internal, which I haven't even begun to think about.

Okay:

Here's the only DNA control you should have over digestion.

100 .fat induce

(induce is probably the worng word, but I'm tired)

This induces the stomach into producing enzymes as if there were 100 more fat than there is.  For digestion, more control is unnecessary and probably destructive.  This is very close to real life.  Our stomachs have a mind of their own for the most part, digesting things as it sees fit.  But the brain can give the stomach a heads-up if food is around and digestion is iminant.
Title: General approach to metabolism
Post by: PurpleYouko on March 22, 2005, 09:38:22 AM
I still don't really think it is necessary to get that much into the operating controls for enzymes but if we do then couldn't we just use a variation of the "make" operator for this?

Assuming that as many enzymes as necessary are always present would be my choice but if we want to be able to make more than a bare minimum by DNA control then here is my outline of how to do it. Still need to give the robot some enzymes for backward compatability.


You just need a bunch of what are effectively code numbers for make to grab and use.

Something like

157 make

where 157 represents a generic command to find and create the best enzyme for fat.

158 make would find and create the best available enzyme for carbs etc.

Of course we can add a series of labels to represent these numbers but they will need to be a separate set then the sysvars or things will get confusing.

Coding it won't be a problem now that I have gotten my head around the make/break commands as operators.


 :D  PY  :D
Title: General approach to metabolism
Post by: Numsgil on March 22, 2005, 01:21:20 PM
Okay, these are my thoughts on the original idea after I've had a chance to stew them over.  Tell me if I repeat something already said and resolved.

1.  Each substance should have a number assigned to it that's unique to that substance.  For instance, the word carbs could be 51.  carbs will always be 51, no matter the order it's in.  So when you refer to carbs in the DNA, it is always translated as 51.

How's that different?  sysvars, for instance, have a number assigned to them from a text file.  What I'm proposing is that a number is assigned to a substance not from a text file, but from a function that gives a nubmer based onthe substance's name.

That should allow custom substances to be easily made and shared.  No worrying about if your custom substance overlaps with anyone else's.

2.  Enzyme array is not quite a good idea.  In your system we search through all the enzymes and enlist the best ones, ignoring others that aren't as good.  Here's what I would like:

Imagine you have a bowl of enzymes.  All possible enzymes that a bot can produce are in this bowl.  Now you add a substance.  All enzymes that can work on that substance do so, not just the best ones!  This encourages multiple copies of good enzymes and deleting less good ones.  If you have 5 copies of a good one and 1 copy of a bad one, the reaction is more likely to use a good one simply by chance.  Real DNA does contain this kind of example of multiple copies of the same gene.

This stops the program from artificially biasing enzyme use by artificial criterion, such as 'best one for the job'.  All the enzymes work at the same time.

I don't know a good answer to how to promote enzyme production though.  Maybe all enzyme production is stimulated at once, so you begin producing the less efficient ones and the efficient ones.  What this means is that less efficient ones have a opportunity cost but no penalty, meaning that a bot is encouraged to remove bad enzymes without penalyzing the bot for not doing so.

3.  I agree full heartedly.

4.  The purging was my idea in respect to the mouth purging it's contents to the stomach.  Not hte same thing you propose here.  Enzymes are like connection speed to the internet.  Have more and you increase your bandwidth.  But the larger your bandwidth the more you have to pay per month (or cycle in DB).

5.  You should not be able to directly say "I want this substance to be turned into that substance, and here's how I want to do it."  That's very bad.  Rather, I'd like enzymes to each know what they do.

These enzymes are always on, always working.  If you want a stable reaction, you simple have as many A->B as B->A.  Homeostasis.  If you want a net movement of A->B you simple produce more A->B than B->A.

You do that py specifying, in the DNA, a certain origin and final product, and the strength of the resulting net movement you want.

For instance, say I want to store energy as fat.  I would do something like NRG FAT 100 strengthen (the command words are still open).  This would go through all possible enzyme pathways, and for all that are part of some nrg->fat reaction (perhaps as an intermediary) it would produce more of those enzymes.  The opposite is true too, you can weaken a reaction by doing something like NRG FAT -100 strengthen.

Okay now, say we did that, and their is now an unequilibrium.

nrg s turned into intermediary A.

Now, since A is an intermediary, all enzymes that do A-> something activate.  If their are multiple paths possible, A follows all those paths.  Like a large water pipe.  If you have a split in the pipe, the amount of liquid going through each one is a function of the size of the split off pipes.  The more enzymes a certain path has, though, the more A will go through those.  Note that it is possible some A will turn back into nrg.

The point of this system is that the enzymes have no idea how A was created.  They don't know what direction it's coming from, or where the DNA wants it to go to.  It just does what it does.  The DNA doesn't know what individual enzymes do, but it can encourage particular directions of net movement.

This is an object-oriented approach.  Specifically, abstraction.  I've mentioned that I'm trying to get bots in DB to be object oriented in design, but I realize not everyone know what I'm talking about.  Here's a wiki on it (http://en.wikipedia.org/wiki/Object_oriented).  If you still don't understand what I mean, ask a specific question(s) and I'll show you what I mean with an example.

That's what I would like.  That keeps the DNA's command over the metabolism absolute, without muddying it up with the exact details.

The only problem: If I have A-> nrg and A->B->3 nrg, I need a way to decide which of these two to promote.  Something as simple as a set of other keywords in the above command would be the ticket.

Like:

NRG FAT 100 strengthen
HighResult 10 favor

again, the exact keywords and DNA syntax is debatable.  But the idea is that the DNA doesn't know how the enzymes are doing what they do, and the enzymes don't know anyhting about the DNA.

Also, it recognizes that different paths aren't necessarily 'better' than others.  For instance, say I have a path for protein + nrg -> shell.  Say one route is: nrg + 3 protein -> 2 shell and another is 3 nrg + protein -> 2 shell.  Which is better?  Well, it depends on the scarcity of the resources.  If protein is scarce, you might be willing to spend more energy.

by using the favor keyowrd, you can define different paths to favor and by how much.  HighResult could favor those reactions that give the most for the bang.  MinimizeNRG might favor those reactions that take less energy than others.  Etc. etc.

Again, the exact workings or paths of the enzymes are hidden from the DNA, and vice versa.
Title: General approach to metabolism
Post by: shvarz on March 22, 2005, 03:16:00 PM
Nums, your system is actually more complicated than mine.  If that's good or bad I don't know.  From what I hear from PY he wants it more starightforward.  Carefull adjusting of amounts of enzymes, having multiple routes and so on - I dropped all that.  It will be very easy to do stuff.  

You want to make fat, just say

fat
make

You want to convert glucose to fat, say

glucose
break
fat
make

The intermediates can be addressed directly from DNA to optimize things, but they don't have to.

Crap, I'm late.  Talk to you all later...
Title: General approach to metabolism
Post by: PurpleYouko on March 22, 2005, 04:41:05 PM
Yep I like the simpler approach but with the option to get more complicated if you reeeeeeeaaaaaaallllly want to.

 :D  PY  :D
Title: General approach to metabolism
Post by: Botsareus on March 22, 2005, 04:42:22 PM
Num , we already desided on the "make...breack" system as the final virsion , sorry it happend without you.
Title: General approach to metabolism
Post by: Numsgil on March 22, 2005, 05:11:25 PM
Okay, but when you say break carb, how does the program know which route to take?  That is, imagine you have:

carbs -> A + nrg -> B + nrg -> 20nrg
and
carbs -> 10 nrg

How does the program know which one to use?  Which is default?  That's what I was getting at.

Basically I guess I'm saying:

MinNRG favor
glucose make

That is, I'm talking about a subset of what schvarz has.
Title: General approach to metabolism
Post by: shvarz on March 22, 2005, 06:14:48 PM
Quote
carbs -> A + nrg -> B + nrg -> 20nrg
and
carbs -> 10 nrg


So far I was able to avoid scenarios like this.  If need arises, then we can come up with algorithms, including (but not limited to) arbitrarily assigning which path is chosen.  

I am off work in 30-40 minutes.  I'll be home in an hour or so.  So expect a post with first version of metabolism in a couple of hours.
Title: General approach to metabolism
Post by: Numsgil on March 22, 2005, 06:15:30 PM
We all eagerly await.
Title: General approach to metabolism
Post by: Numsgil on March 22, 2005, 06:24:20 PM
Quote
So far I was able to avoid scenarios like this.  If need arises, then we can come up with algorithms, including (but not limited to) arbitrarily assigning which path is chosen.
Remember that we need to keep the system as general as possible.  As Paul said before, the beauty of the program is in the vast range of sims you can run.