Re: The "evolution" of GA Math
Al Getz wrote:
> Hi Quark,
>
> I ran a few more times and while some runs seemed to go on forever,
> two runs terminated...one after about an hour and one after about
> five minutes. The two results were exact, or nearly so, and one
> run (the second quick run) came up with the value for e by using it
> as the constant after taking the natural log of it to get the "1"
> in the equation. Cute he he.
>
> To skip function names, i figured eval took anything with more than
> one alpha char to be a function name so i decided to go with that for
> GA Math too:
>
> In function GetFormula()..
>
> f=StripAll(f)
> f=1&f&1 --add leading and trailing non-alpha chars
> x=find('=',f) --zero is an acceptable return value
> cnt=2
> t={}
>
> for i=x+1 to length(f) do
> if Alpha(f[i]) and not Alpha(f[i+1]) and not Alpha(f[i-1])then
> --If it's a var then it wont have a letter before or after it.
> if not find(f[i],t) then
> t&=f[i]
> cnt+=1
> end if
> end if
> end for
>
> f=f[2..length(f)-1] --remove leading and trailing chars
>
> --show the formula and all the variables to allow user to verify:
> printf(1,"\n%s\n",{f})
> printf(1,"%s\n",{t})
>
> sleep(3)
> return {f,t}
>
>
> I also changed the register print out function so that we
> could get more precison output data, and now send it to
> an appending file to hold all previous experiments too.
> Four decimal places seems to be enough for testing the resulting
> functions.
>
>
> There is one question, however, and that is what exactly a 'penalty'
> *should* be for a given function (if that's even the correct way
> to go about it). Right now i know your using zero (0) as penalty,
> but im wondering if this is what threw my first run off as it was
> maybe trying to compensate for values below 1 (between 0 and 1).
> Perhaps you know the reason we are using zero as penalty?
> My question comes up after considering that 0 is a valid answer for
> a multiplication involving zero, an addition involving two zeros,
> and for the natural log of 1: ln(1)=0, so 0 is possibly valid, and
> even the correct result for a certain input, although only one.
> Perhaps it is sometimes led to think that the natural log of 0 is
> 0, and the natural log of any negative number is also zero.
>
>
> Here's my function as it stands right now...
>
> elsif op=11 then
> --natural log
> if p[i][REG][from1]=0 then
> p[i][REG][store]=0
> else
> p[i][REG][store]=log(abs(p[i][REG][from1]))
> end if
>
> which is basically the same thing except it returns a value for
> negative numbers too, which is fine for this particular function
> (maybe not for every formula involving ln() however).
>
>
> So anyway...
> Any theory on that zero penalty available, or what idea led
> to using zero as penalty?
>
>
> Take care,
> Al
Hi Al,
I liked this:
"...and one run (the second quick run) came up with the value for e by using it
as the constant after taking the natural log of it to get the "1" in the
equation. Cute he he." One somehow does not expect to laugh at what computers
do, but GAs can sure be, as you say, cute!
Your solution on the "skip function names" looks fine, nice and simple.
As to the report function number precision: yes it is logical for better
understanding to expand the numbers. I only had short ones for convenience in
printing to the screen.
As to the penalty, you are quite right to question this and want to change it.
It was done in a context of "shipping the product", so to speak, and I knew it
would have to be addressed as an issue.
That leaves the big question: what to do about illegal moves? Or if overflow
comes into play, then threatening to cause it would be a penalty situation. This
sort of gets into programming philosophy territory. How serious is it to do
something wildly inappropriate? There seem to be two ways to go: mess about with
numbers -- implying a poor response of a being -- even though it may come back to
bite you later. Or...simply change the gene's operation to "nop" at the moment of
detection. "NOP is ignored completely by the assessing function, as if it had
never existed.
Again this is "philosophical" in a sense. Should the gene pay for its mistake,
leaving the being intact? Or should the being itself become "invalid", as it
often would in the real world?
I guess I would have to recommend avoiding a number penalty of any kind because
of future problems, and using either gene or being cancelling.
I don't know what to make of "seems to go on forever" for the formulas you have
mentioned, though f="a=(2*x-(3*y))/(4*z)" did take a very long time (maybe I
should have tossed in a few more sets of parentheses). Here I'll just say what
you already know: make sure eval.e is doing its job, and where possible, test
shorter versions of your formulas to make sure the algorithms are popping up as
they should, and so you can identify what slows things down. Doing C versions of
GA Math should improve the speed, but alas, slows down tweaking...
Your reported runs seem long compared with mine, so I assume it is just
processor speed? My machine is 2.5 GHz, but when I have a nostalgic longing for
slowness, I run on the other machine, an old HP NARC (Not A Real Computer) :^D
--Quark
|
Not Categorized, Please Help
|
|
