Re: The "evolution" of GA Math

new topic     » goto parent     » topic index » view thread      » older message » newer message

DB James wrote:
> 
> 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,
<snip>


Hi again,

Yes, the output was kinda 'cute' that time he he, but i guess it would
have been even more remarkable if it didnt have the ln() function to
work with and still came up with the value for e.  Im not worried about
it however, as that's a tale for another time :)

I wanted to keep the 'skip function names' simple yes, because eval was simple.
I could update eval if you like, which would boost the abilities of this
program too then.  I especially dont like that there is no priority for
multiplication over addition, but that can be fixed.

The penal system comes into question mainly because of what i was saying before,
and also i have to wonder if we shouldnt have the ability to limit the
domain of the various functions or at least the domain of the 'final' algorithm.
In actual use, the final function will usually have an application that has
limited domain, perhaps very limited, so doing that could speed things up
considerably.  Fewer choices means faster determinations.

I took 'nop' out because i thought it was wasting time...is this bad?

I guess i'll have to dig deeper into the program to understand how it works.
So far i've just been tweeking this and that :)

My machine is slower, so that's probably why it's taking longer.
I'll be logging the complete times now too though, in a file.

BTW my latest run gave another 'exact' solution, round about:
  a7=a*ln(abs(ln(k1)-k2-x))  --took 33 minutes (@ 650MHz)
where ln(k1)-k2= -1, so the whole formula boils down to:
  a7=a*ln(abs(-1-x))
<chuckle>

 

Take care,
Al

And, good luck with your Euphoria programming!

My bumper sticker: "I brake for LED's"

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu