1. The "evolution" of GA Math
- Posted by DB James <larch at adelphia.net>
Sep 30, 2005
-
Last edited Oct 01, 2005
Report on the "evolution" of GA Math Version 1.2
To everyone (sorry for any mangled formatting):
I have continued to modify GA Math. The latest update is version 1.2.
It is now flicker-free and the user interface is simple and stripped-down. The
program is now more sophisticated, faster, and capable of handling moderately
complex formulas.
As before the program is a "tweaker's paradise". If you do change the program,
it might be good to modify a copy.
Here is a list of formulas for which it has successfully created matching
algorithms:
"v=l*w*h"
"a=3.14159*(r^2)"--area of circle
"a=4*3.14159*(r^2)"--harder (area of sphere)
"v=4/3*3.14159*(r^3)"--harder (volume of a sphere)
"x=2*a*3*b*4*c"
"a=100*x"
"a=(x-y)/z"
"a=(2*x-y)/z" -- hard, but doable
"a=(2*x-(3*y))/z" -- harder, but doable
"a=(2*x-(3*y))/(4*z)" -- harder, but doable (takes a longish time)
A typical report with comments added:
--------------------------------------------------
GA Math Beings Report
--------------------------------------------------
Math Beings working on formula : a=(x-y)/z -- <<< the formula
Number of try-sets per run : 1200 --<<< maximum number of try sets per
run
Number of runs this session : 3 -- --<<< number of runs this attempt
Number of tries per try-set : 8 --<<< each population has this number of
tries before assessment
This is try-set number : 520 --<<< this many try-sets have occurred
in this run
Target value : 0.0010 --<<< must get within this percentage
to be successful
Current closeness (percent) : 0.000000 --<<< the percentage at moment of
success
Most successful being's original register values:
{[5.46] , [7.53] , [3.70] , [8.99] , [0.30] , [8.00] , [0] , [0] ,
[0]}--<<<nine register locations (in this case)
-- x-val y-val z-val Priv1 Priv2 Priv3 <<<< three variables
& three private numbers
--**********************************************************************************************
-- <<< Note the private numbers above; there is one for each variable. Each
being has a set of randomly
-- <<< generated private numbers that *do not change* in a being's lifetime, but
do change in transferring
-- <<< to a clone.
--**********************************************************************************************
Most successful being's genes: --<<< In this example, there were only two
relevant genes needed to
-- <<< create an algorithm to solve the formula.
Most successful being's original register values: -- <<< Repeating these two
lines
{[5.46] , [7.53] , [3.70] , [8.99] , [0.30] , [8.00] , [0] , [0] ,
[0]}--<<<nine register locations (in this case)
sub, 1, 2, 2
{[5.46] , [-2.07] , [3.70] , [8.99] , [0.30] , [8.00] , [0] , [0] , [0]}
div, 2, 3, 9
{[0] , [-2.07] , [3.70] , [-5.29] , [0.30] , [-8.99] , [-3.70] , [0] ,
[-0.56]}
Last actual answer from formula: -0.560
------------------------------------------------
The above successful being had to deal with at least 16 randomly generated sets
of x, y, and z values, of which you see in this report only the last one.
More general comments:
There are now 7 register locations in each being where the math operations take
place. The final answer must always be in the last register location.
There are 11 operations as follows:
constant OPS={
{"abs",1},
{"rec",1},
{"chg",1},
{"add",2},
{"sub",2},
{"mul",2},
{"div",2},
{"int",1},
{"rem",2},
{"frc",1},
{"nop",0}
}
Note: the number next to each operation is the number of "from" register
locations it uses.
abs=absolute, rec=reciprocal, chg=change-sign, int=floor, rem=remainder,
frc=decimal fraction, and nop=no operation
=============================================================
To ck,
Well, do you think GA Math does exhibit evolution?
Of course you know that I think it does. One thing I've seen over and over is
that there are two different sorts of evolution: gradual and dramatic.
The gradual type is represented, for example, by the way PI is often found.
Beginning with maybe a "3", using the private numbers (which change when
cloning occurs), the program can edge closer and closer to true PI over time,
and consequently its accuracy improves toward success. This gradual type is
what we often think of as "evolution". However, many math algorithms depend
on a set of discrete actions in the right order or it doesn't work at all, that
is, it is not a matter of being close, but of getting a complex thing right bang
on. Evolution can handle that, but it takes much longer.
The formula "a=(2*x-(3*y))/4z" is an example. GA Math can figure it out, but
it takes a while. You might say it works, but isn't pretty. With
bio-evolution, though, once such a thing is made, it then becomes subject to
gradual evolution.
=============================================================
To Al Getz,
The private numbers occur one-to-one for each variable used. They last the
lifetime of the being, so tracking it shouldn't be an issue. They do evolve
over time as the successful half of the population is cloned.
Many thanks for testing this program and letting me know how it went. Most
of the changes have been in response to your investigations.
=============================================================
A recent example of good luck:
--------------------------------------------------
GA Math Beings Report
--------------------------------------------------
Math Beings working on formula : 3.14159*r*r
Number of try-sets per run : 1200
Number of runs this session : 2
Number of tries per try-set : 8
This is try-set number : 121
Target value : 0.0010
Current closeness (percent) : 0.000058
Most successful being's original register values:
{[11.38] , [3.14] , [0] , [0] , [0] , [0] , [0]}
Most successful being's genes:
mul, 1, 1, 7
{[11.38] , [3.14] , [0] , [0] , [0] , [0] , [129.39]}
mul, 2, 7, 7
{[11.38] , [3.14] , [0] , [0] , [0] , [0] , [406.47]}
Last actual answer from formula: 406.492
--------------------------------------------------
It usually takes longer than that!
Keep in mind that though there are checks to try to eliminate "lucky inputs", it
does happen, so some algorithms will not prove out. For that reason, it is a
good idea to make several runs on a formula to assure getting a decent (though
sometimes quite weird) algorithm.
I want to turn my attention to other programming for awhile, so won't be doing
any more upgrades in the near future, though others can do so if they wish and
send them to RDS. However, I'll be around to answer any questions about the
program.
--Quark
2. Re: The "evolution" of GA Math
- Posted by cklester <cklester at yahoo.com>
Sep 30, 2005
-
Last edited Oct 01, 2005
DB James wrote:
>
> To ck,
>
> Well, do you think GA Math does exhibit evolution?
I might not be clear on the concept, but of course it's not evolution. If I
figure out the formula, has evolution occurred? All you've got is an expert-
system calculator that knows how to determine formulas. There's no evolution
involved, unless by "evolution" you mean "figuring out what doesn't work."
It seems to be just a complicated "process of elimination" machine.
-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/
3. Re: The "evolution" of GA Math
cklester wrote:
> DB James wrote:
> >
> > To ck,
> >
> > Well, do you think GA Math does exhibit evolution?
>
> I might not be clear on the concept, but of course it's not evolution. If=
I
> figure out the formula, has evolution occurred? All you've got is an expe=
rt-
> system calculator that knows how to determine formulas. There's no evolut=
ion
> involved, unless by "evolution" you mean "figuring out what doesn't work.=
"
> It seems to be just a complicated "process of elimination" machine.
>
Evolution is a "process of elimination". The animals/plants that are
suited best for the environment will survive, others will die.
The biggest difference between GA Math and evolution in nature is the
environment -- which is immensively more complex in nature than in DB
James' program.
Regards, Alexander Toresson
4. Re: The "evolution" of GA Math
Hi again,
Oh yes, it's looking even better now.
I'll have to try a few more formulas and things with it.
The flicker is gone, and that's really nice. Seems to run
faster too or something now.
Thanks for updating again!
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
5. Re: The "evolution" of GA Math
Al Getz wrote:
>
> Hi again,
>
>
> Oh yes, it's looking even better now.
> I'll have to try a few more formulas and things with it.
> The flicker is gone, and that's really nice. Seems to run
> faster too or something now.
> Thanks for updating again!
>
>
> Take care,
> Al
>
> And, good luck with your Euphoria programming!
>
> My bumper sticker: "I brake for LED's"
>
Hi Quark,
Looks like we might have to add some functions, as im trying a new
formula
y=a*ln(x/b+1) --physically, a 'diode'... a,b constants
and it doesnt seem to be able to find a solution.
Im thinking maybe this is because it takes a great many adds and
subtracts and multiplies to emulate the "ln" (log natural) function.
Im guessing that if "ln" could be added to the list of possible
functions it would find the solution.
I havent studied the code itself in any detail yet, so if you can
give me some tips how best to add functions to the possible set of
useable functions (which are now add, subtract, multiply, etc) that
would help. This way a user could add (or take away) functions that
would most likely fit the situation.
BTW, the error stays approx between 0.2 and 1.0 for the most part
and it keeps restarting.
This could be very interesting for coming up with new Spice models!
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
6. Re: The "evolution" of GA Math
- Posted by DB James <larch at adelphia.net>
Oct 01, 2005
-
Last edited Oct 02, 2005
Al Getz wrote:
>
> Al Getz wrote:
> >
> > Hi again,
> >
> >
> > Oh yes, it's looking even better now.
> > I'll have to try a few more formulas and things with it.
> > The flicker is gone, and that's really nice. Seems to run
> > faster too or something now.
> > Thanks for updating again!
> >
> >
> > Take care,
> > Al
> >
> > And, good luck with your Euphoria programming!
> >
> > My bumper sticker: "I brake for LED's"
> >
>
> Hi Quark,
>
> Looks like we might have to add some functions, as im trying a new
> formula
> y=a*ln(x/b+1) --physically, a 'diode'... a,b constants
> and it doesnt seem to be able to find a solution.
>
> Im thinking maybe this is because it takes a great many adds and
> subtracts and multiplies to emulate the "ln" (log natural) function.
> Im guessing that if "ln" could be added to the list of possible
> functions it would find the solution.
> I havent studied the code itself in any detail yet, so if you can
> give me some tips how best to add functions to the possible set of
> useable functions (which are now add, subtract, multiply, etc) that
> would help. This way a user could add (or take away) functions that
> would most likely fit the situation.
>
> BTW, the error stays approx between 0.2 and 1.0 for the most part
> and it keeps restarting.
>
> This could be very interesting for coming up with new Spice models!
>
>
> Take care,
> Al
>
> And, good luck with your Euphoria programming!
>
> My bumper sticker: "I brake for LED's"
>
Hi Al,
I am all for functions being added to GA Math!
As the program is now, it has no clue about log. The David Cuny library eval.e
would not know what to do with it, though it does have three trig functions I
have not used. David set up eval.e to make it easy to add functions, so you
would first look at his code and modify it so it could calculate a log function.
Then in GA Math, there are two areas to focus on:
1)
constant OPS={
{"abs",1},
{"rec",1},
{"chg",1},
{"add",2},
{"sub",2},
{"mul",2},
{"div",2},
{"int",1},
{"rem",2},
{"frc",1},
{"nop",0}
}
You would stick, say, "log", in above "nop" as: {"log",1},
2)
In the function Animate() you would add the actual Eu functionality associated
with the number of the function (possibly 11, in this case). It would be
something like:
elsif op=11 then
--log
p[i][REG][store]=log(p[i][REG][from1])
Of course remember the limitations on log(), from the docs:
Comments: Note that log is only defined for positive numbers. Your program will
abort with a message if you try to take the log of a negative number or zero.
I hope you do this as it will be a steroid shot to GA Math 
Also a power
function would be slick, but then overflow would be an issue...
--Quark
7. Re: The "evolution" of GA Math
- Posted by Al Getz <Xaxo at aol.com>
Oct 01, 2005
-
Last edited Oct 02, 2005
DB James wrote:
>
> Al Getz wrote:
> >
> > Al Getz wrote:
> > >
> > > Hi again,
> > >
> > >
> > > Oh yes, it's looking even better now.
> > > I'll have to try a few more formulas and things with it.
> > > The flicker is gone, and that's really nice. Seems to run
> > > faster too or something now.
> > > Thanks for updating again!
> > >
> > >
> > > Take care,
> > > Al
> > >
> > > And, good luck with your Euphoria programming!
> > >
> > > My bumper sticker: "I brake for LED's"
> > >
> >
> > Hi Quark,
> >
> > Looks like we might have to add some functions, as im trying a new
> > formula
> > y=a*ln(x/b+1) --physically, a 'diode'... a,b constants
> > and it doesnt seem to be able to find a solution.
> >
> > Im thinking maybe this is because it takes a great many adds and
> > subtracts and multiplies to emulate the "ln" (log natural) function.
> > Im guessing that if "ln" could be added to the list of possible
> > functions it would find the solution.
> > I havent studied the code itself in any detail yet, so if you can
> > give me some tips how best to add functions to the possible set of
> > useable functions (which are now add, subtract, multiply, etc) that
> > would help. This way a user could add (or take away) functions that
> > would most likely fit the situation.
> >
> > BTW, the error stays approx between 0.2 and 1.0 for the most part
> > and it keeps restarting.
> >
> > This could be very interesting for coming up with new Spice models!
> >
> >
> > Take care,
> > Al
> >
> > And, good luck with your Euphoria programming!
> >
> > My bumper sticker: "I brake for LED's"
> >
>
> Hi Al,
>
> I am all for functions being added to GA Math!
>
> As the program is now, it has no clue about log. The David Cuny library
> eval.e would
> not know what to do with it, though it does have three trig functions I have
> not used.
> David set up eval.e to make it easy to add functions, so you would first look
> at his
> code and modify it so it could calculate a log function. Then in GA Math,
> there are
> two areas to focus on:
>
> 1)
> constant OPS={
> {"abs",1},
> {"rec",1},
> {"chg",1},
> {"add",2},
> {"sub",2},
> {"mul",2},
> {"div",2},
> {"int",1},
> {"rem",2},
> {"frc",1},
> {"nop",0}
> }
> You would stick, say, "log", in above "nop" as: {"log",1},
>
> 2)
> In the function Animate() you would add the actual Eu functionality associated
> with
> the number of the function (possibly 11, in this case). It would be something
> like:
> elsif op=11 then
> --log
> p[i][REG][store]=log(p[i][REG][from1])
>
> Of course remember the limitations on log(), from the docs:
>
> Comments: Note that log is only defined for positive numbers. Your program
> will abort
> with a message if you try to take the log of a negative number or zero.
>
> I hope you do this as it will be a steroid shot to GA Math Also a power
> function
> would be slick, but then overflow would be an issue...
>
> --Quark
>
Hi Quark,
Done :)
I added ln() to both programs, and ran the program, but it still was
taking a bit longer than i had time for at that moment...i'll try again
though for sure.
Actually, i was thinking of making a Windows version of your program?
How's that sound? Too bad i dont have a good Linux yet. I went searching
for a boxed linux set at comp stores but didnt have any luck. CompUSA
doesnt seem to carry in the store anymore for some reason.
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
8. Re: The "evolution" of GA Math
- Posted by Al Getz <Xaxo at aol.com>
Oct 01, 2005
-
Last edited Oct 02, 2005
Al Getz wrote:
>
> DB James wrote:
> >
> > Al Getz wrote:
> > >
> > > Al Getz wrote:
> > > >
> > > > Hi again,
> > > >
> > > >
> > > > Oh yes, it's looking even better now.
> > > > I'll have to try a few more formulas and things with it.
> > > > The flicker is gone, and that's really nice. Seems to run
> > > > faster too or something now.
> > > > Thanks for updating again!
> > > >
> > > >
> > > > Take care,
> > > > Al
> > > >
> > > > And, good luck with your Euphoria programming!
> > > >
> > > > My bumper sticker: "I brake for LED's"
> > > >
> > >
> > > Hi Quark,
> > >
> > > Looks like we might have to add some functions, as im trying a new
> > > formula
> > > y=a*ln(x/b+1) --physically, a 'diode'... a,b constants
> > > and it doesnt seem to be able to find a solution.
> > >
> > > Im thinking maybe this is because it takes a great many adds and
> > > subtracts and multiplies to emulate the "ln" (log natural) function.
> > > Im guessing that if "ln" could be added to the list of possible
> > > functions it would find the solution.
> > > I havent studied the code itself in any detail yet, so if you can
> > > give me some tips how best to add functions to the possible set of
> > > useable functions (which are now add, subtract, multiply, etc) that
> > > would help. This way a user could add (or take away) functions that
> > > would most likely fit the situation.
> > >
> > > BTW, the error stays approx between 0.2 and 1.0 for the most part
> > > and it keeps restarting.
> > >
> > > This could be very interesting for coming up with new Spice models!
> > >
> > >
> > > Take care,
> > > Al
> > >
> > > And, good luck with your Euphoria programming!
> > >
> > > My bumper sticker: "I brake for LED's"
> > >
> >
> > Hi Al,
> >
> > I am all for functions being added to GA Math!
> >
> > As the program is now, it has no clue about log. The David Cuny library
> > eval.e would
> > not know what to do with it, though it does have three trig functions I have
> > not used.
> > David set up eval.e to make it easy to add functions, so you would first
> > look at his
> > code and modify it so it could calculate a log function. Then in GA Math,
> > there are
> > two areas to focus on:
> >
> > 1)
> > constant OPS={
> > {"abs",1},
> > {"rec",1},
> > {"chg",1},
> > {"add",2},
> > {"sub",2},
> > {"mul",2},
> > {"div",2},
> > {"int",1},
> > {"rem",2},
> > {"frc",1},
> > {"nop",0}
> > }
> > You would stick, say, "log", in above "nop" as: {"log",1},
> >
> > 2)
> > In the function Animate() you would add the actual Eu functionality
> > associated with
> > the number of the function (possibly 11, in this case). It would be
> > something like:
> > elsif op=11 then
> > --log
> > p[i][REG][store]=log(p[i][REG][from1])
> >
> > Of course remember the limitations on log(), from the docs:
> >
> > Comments: Note that log is only defined for positive numbers. Your program
> > will abort
> > with a message if you try to take the log of a negative number or zero.
> >
> > I hope you do this as it will be a steroid shot to GA Math Also a power
> > function
> > would be slick, but then overflow would be an issue...
> >
> > --Quark
> >
>
> Hi Quark,
>
> Done :)
> I added ln() to both programs, and ran the program, but it still was
> taking a bit longer than i had time for at that moment...i'll try again
> though for sure.
>
> Actually, i was thinking of making a Windows version of your program?
> How's that sound? Too bad i dont have a good Linux yet. I went searching
> for a boxed linux set at comp stores but didnt have any luck. CompUSA
> doesnt seem to carry in the store anymore for some reason.
>
>
> Take care,
> Al
>
> And, good luck with your Euphoria programming!
>
> My bumper sticker: "I brake for LED's"
>
<snip>
Just thought i would mention...
I tried ln(x+1) and it came up with an exact solution!
Pretty cool :)
The solution was a bit round about, but who cares, as it can
be then put into algebraic or at least programatical form and
used in a program to calculate something. Of course the real
use would come with more complex formulas where the original
isnt yet known (only the data), so im hoping it doesnt take too
long to come up with things like that. I'd like to try it with
curve fitting where the more traditional approach is to guess the
formula from the physical properties...but sometimes it's hard to
do that, so a program like this could prove very useful. You
wouldnt have to know 'jack' about the physics, just the curve data,
and you could get a formula! Nice :) Now just hope it's always
going to be sorta quick enough to make it practical. If it runs all
day i guess that's ok, but i wouldnt want to take a week or two on
one problem...hey, saving the state would be nice too...to continue
the run the next day...hmmm...lots to think about i guess here.
If i come up with any future programs involving this sort of thing,
how do you want to be mentioned in the doc's and say an about box...
by 'Quark' or other name?
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
9. Re: The "evolution" of GA Math
Al Getz wrote:
> Hi Quark,
>
> Done :)
> I added ln() to both programs, and ran the program, but it still was
> taking a bit longer than i had time for at that moment...i'll try again
> though for sure.
>
> Actually, i was thinking of making a Windows version of your program?
> How's that sound? Too bad i dont have a good Linux yet. I went searching
> for a boxed linux set at comp stores but didnt have any luck. CompUSA
> doesnt seem to carry in the store anymore for some reason.
>
>
> Take care,
> Al
>
> And, good luck with your Euphoria programming!
>
> My bumper sticker: "I brake for LED's"
>
Hi,
Yes, fine, a Windows version is a good idea because, I'm assuming, it would run
quietly in the background with less drain on the system. (Maybe you could have
the Taskbar button turn green or something when a solution is found :^D)
--Quark
P.S. Did you test eval.e with your added function to make sure all was well?
If it weren't able to give GA Math the correct answer reliably then... well, you
know...
10. Re: The "evolution" of GA Math
Al Getz wrote:
>
> Al Getz wrote:
> >
SNIP> > >
> >
> > Hi Quark,
> >
> > Done :)
> > I added ln() to both programs, and ran the program, but it still was
> > taking a bit longer than i had time for at that moment...i'll try again
> > though for sure.
> >
> > Actually, i was thinking of making a Windows version of your program?
> > How's that sound? Too bad i dont have a good Linux yet. I went searching
> > for a boxed linux set at comp stores but didnt have any luck. CompUSA
> > doesnt seem to carry in the store anymore for some reason.
> >
> >
> > Take care,
> > Al
> >
> > And, good luck with your Euphoria programming!
> >
> > My bumper sticker: "I brake for LED's"
> >
> <snip>
>
> Just thought i would mention...
>
> I tried ln(x+1) and it came up with an exact solution!
> Pretty cool :)
> The solution was a bit round about, but who cares, as it can
> be then put into algebraic or at least programatical form and
> used in a program to calculate something. Of course the real
> use would come with more complex formulas where the original
> isnt yet known (only the data), so im hoping it doesnt take too
> long to come up with things like that. I'd like to try it with
> curve fitting where the more traditional approach is to guess the
> formula from the physical properties...but sometimes it's hard to
> do that, so a program like this could prove very useful. You
> wouldnt have to know 'jack' about the physics, just the curve data,
> and you could get a formula! Nice :) Now just hope it's always
> going to be sorta quick enough to make it practical. If it runs all
> day i guess that's ok, but i wouldnt want to take a week or two on
> one problem...hey, saving the state would be nice too...to continue
> the run the next day...hmmm...lots to think about i guess here.
>
> If i come up with any future programs involving this sort of thing,
> how do you want to be mentioned in the doc's and say an about box...
> by 'Quark' or other name?
>
>
> Take care,
> Al
>
> And, good luck with your Euphoria programming!
>
> My bumper sticker: "I brake for LED's"
>
Hey that's great!
I do think the potential is there to solve problems for which the answer is not
known using this general approach. Also it can potentially solve problems of
some real difficulty. However, be prepared for some serious thinking about
optimizing and speed. In general, and using a marine analogy, where the solution
can be "tacked" toward, the answer can come swiftly, I think. But where the
problem has multiple specific components and "in this order" ones, the answer
will come slower by quite a bunch. Eventually, one would wish to break problems
down to parts, if possible. From a theoretical point of view, I find myself
wishing I knew a lot more about math such that I could clearly identify the
inherent difficulty of problems -- the Mohs Scale of Math Hardness so to speak...
Bottom line: at the very least, such an attempt as you describe would leave you
a wiser man who could appreciate successes where they come, and where they don't
come easily, the cause itself would be fascinating.
Quark is fine for credits. Thanks for asking.
--Quark
11. Re: The "evolution" of GA Math
- Posted by Al Getz <Xaxo at aol.com>
Oct 02, 2005
-
Last edited Oct 03, 2005
DB James wrote:
>
> Al Getz wrote:
>
> > Hi Quark,
> >
> > Done :)
> > I added ln() to both programs, and ran the program, but it still was
> > taking a bit longer than i had time for at that moment...i'll try again
> > though for sure.
> >
> > Actually, i was thinking of making a Windows version of your program?
> > How's that sound? Too bad i dont have a good Linux yet. I went searching
> > for a boxed linux set at comp stores but didnt have any luck. CompUSA
> > doesnt seem to carry in the store anymore for some reason.
> >
> >
> > Take care,
> > Al
> >
> > And, good luck with your Euphoria programming!
> >
> > My bumper sticker: "I brake for LED's"
> >
>
> Hi,
>
> Yes, fine, a Windows version is a good idea because, I'm assuming, it would
> run quietly
> in the background with less drain on the system. (Maybe you could have the
> Taskbar
> button turn green or something when a solution is found :^D)
>
> --Quark
>
> P.S. Did you test eval.e with your added function to make sure all was well?
> If it
> weren't able to give GA Math the correct answer reliably then... well, you
> know...
>
Hi Quark,
Yes, the button could turn green or something to show the user it's done,
good idea.
Yes, i tested ln() with eval and made sure it wouldnt try to evaluate
ln(0) or ln(minusnumber). For ln(0) i have it return a large negative
number just to throw off the 'being' if it happens to choose 0, and
for negative numbers i have it return ln(abs(x)) because i dont care
if the formula has to be changed to use abs() as well.
I tried again with a formula similar the the last one i was trying:
y=a*ln(x+1)
and it didnt seem to get it right this time, but it did work for
numbers above 1 approximately, just not too good for numbers (x)
below 1. Instead of coming up with an equivalent to y=a*ln(x+1)
it came up with the equivalent of:
y=a*ln(x+k)+a*k/(x+k)
which is interesting, but clearly isnt very good for x below 1.00 or
so. For x above 1, however, the error gets better and better
as x increases, but for numbers below 1 it's just not good... 100 percent
off is typical.
This means that whatever numbers it used to check the algorithm were
all above 1.00 i guess. I havent looked for any trend either, assuming
the formula is supposed to be correct for all x.
In the real world there wont be any way to 'break the formula down'
however, because we'll be working with tabular data rather than
a formula. After all, if we already had the formula we wouldnt need
to find it :) I use the formula y=a*ln(x+1) to 'simulate' a set
of data recorded from a series of tests done on a physical device,
so in reality there wont be any formula until after the program runs.
This means in an actual situation where i would want a formula to
be found i wont have anything to break down, like i did here by
knowing a*ln(x+1) could work for a*ln(x/b+1) if b were known.
I wont know (and dont want to know) anything at all about the formula,
such as whether or not it uses ln(x), a+b, a/b, x/m, sin(x+3), etc.
Wont have any idea, and the point is to not have to know anything at
all about the physics...which i believe will make this technique so
useful.
I guess at some point we'll have to estimate the time to completion
for some known formulas, just to get an idea if this can be practical
when we move to more complex problems where there could truely be some
benefit.
Thanks again for doing all the ground work!
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
12. Re: The "evolution" of GA Math
Al Getz wrote:
> Hi Quark,
>
> Yes, the button could turn green or something to show the user it's done,
> good idea.
>
> Yes, i tested ln() with eval and made sure it wouldnt try to evaluate
> ln(0) or ln(minusnumber). For ln(0) i have it return a large negative
> number just to throw off the 'being' if it happens to choose 0, and
> for negative numbers i have it return ln(abs(x)) because i dont care
> if the formula has to be changed to use abs() as well.
>
> I tried again with a formula similar the the last one i was trying:
> y=a*ln(x+1)
> and it didnt seem to get it right this time, but it did work for
> numbers above 1 approximately, just not too good for numbers (x)
> below 1. Instead of coming up with an equivalent to y=a*ln(x+1)
> it came up with the equivalent of:
> y=a*ln(x+k)+a*k/(x+k)
> which is interesting, but clearly isnt very good for x below 1.00 or
> so. For x above 1, however, the error gets better and better
> as x increases, but for numbers below 1 it's just not good... 100 percent
> off is typical.
> This means that whatever numbers it used to check the algorithm were
> all above 1.00 i guess. I havent looked for any trend either, assuming
> the formula is supposed to be correct for all x.
>
> In the real world there wont be any way to 'break the formula down'
> however, because we'll be working with tabular data rather than
> a formula. After all, if we already had the formula we wouldnt need
> to find it :) I use the formula y=a*ln(x+1) to 'simulate' a set
> of data recorded from a series of tests done on a physical device,
> so in reality there wont be any formula until after the program runs.
> This means in an actual situation where i would want a formula to
> be found i wont have anything to break down, like i did here by
> knowing a*ln(x+1) could work for a*ln(x/b+1) if b were known.
> I wont know (and dont want to know) anything at all about the formula,
> such as whether or not it uses ln(x), a+b, a/b, x/m, sin(x+3), etc.
> Wont have any idea, and the point is to not have to know anything at
> all about the physics...which i believe will make this technique so
> useful.
>
> I guess at some point we'll have to estimate the time to completion
> for some known formulas, just to get an idea if this can be practical
> when we move to more complex problems where there could truely be some
> benefit.
>
> Thanks again for doing all the ground work!
>
>
> Take care,
> Al
>
Hi Al,
Having read your post, I scratched my head and decided to replicate your test
with y=a*log(x+1). As you see, I used "log" rather than "ln".
So, I brought up eval.e and made the necessary changes, then had to modify GA
Math to add the log function and to handle multiple-character function-name
input. (You had to do something similar.)
Okay, so I ran the thing and got a weird result, so I created a test for eval.e
to see how it handled the formula "y=a*log(x+1)". Whoa, it only calcuated
"y=log(x+1)", dropping the "a*" part. (I copied the final test to the bottom of
this message.)
So, when David Cuny warned about left-to-right evaluation, he wasn't kidding.
If you use "y=a*(log(x+1))", then it works fine. Here are two example reports:
--------------------------------------------------
GA Math Beings Report
--------------------------------------------------
Math Beings working on formula : y=a*(log(x+1))
Number of try-sets per run : 1200
Number of runs this session : 7
Number of tries per try-set : 8
This is try-set number : 60
Target value : 0.0010
Current closeness (percent) : 0.000785
Most successful being's original register values:
{[10.67] , [9.75] , [7.06] , [0.99] , [0] , [0] , [0]}
Most successful being's genes:
rec, 4, 6
{[10.67] , [9.75] , [7.06] , [0.99] , [0] , [1.01] , [0]}
add, 6, 2, 6
{[10.67] , [9.75] , [7.06] , [0.99] , [0] , [10.76] , [0]}
log, 6, 5
{[10.67] , [9.75] , [0.99] , [0.99] , [2.38] , [10.76] , [7.06]}
mul, 5, 1, 7
{[10.67] , [9.75] , [1.01] , [0.99] , [2.38] , [10.76] , [25.34]}
Last actual answer from formula: 25.339
--------------------------------------------------
GA Math Beings Report
--------------------------------------------------
Math Beings working on formula : y=a*(log(x+1))
Number of try-sets per run : 1200
Number of runs this session : 3
Number of tries per try-set : 8
This is try-set number : 500
Target value : 0.0010
Current closeness (percent) : 0.000000
Most successful being's original register values:
{[9.37] , [1.23] , [2.50] , [1.24] , [0] , [0] , [0]}
Most successful being's genes:
div, 1, 1, 4
{[9.37] , [1.23] , [-2.50] , [1.00] , [0] , [0] , [0]}
add, 2, 4, 2
{[9.37] , [2.23] , [-2.50] , [1.00] , [0] , [0] , [0]}
sub, 1, 5, 4
{[9.37] , [2.23] , [-2.50] , [9.37] , [0] , [0] , [0]}
log, 2, 3
{[9.37] , [2.23] , [0.80] , [9.37] , [0] , [0] , [0]}
mul, 4, 3, 7
{[-2.23] , [2.23] , [0.80] , [9.37] , [0] , [0] , [7.53]}
Last actual answer from formula: 7.531
--Quark
The test:
function RandRangeDec(integer lo, integer hi)
return rand(hi-lo+1)+lo-1 + rand(999)/1000
end function
sequence f
for i=1 to 10 do
var['a']=RandRangeDec(0,11)
var['x']=RandRangeDec(0,11)
printf(1,"a=%f ",var['a'])
printf(1,"x=%f\n",var['x'])
f="y=a*(log(x+1))"
printf(1,"eval(f): %f ",eval(f))
printf(1,"actual: %f\n", var['a']*log(var['x']+1))
end for
13. Re: The "evolution" of GA Math
DB James wrote:
> Hi Al,
>
> Having read your post, I scratched my head and decided to replicate your test
> with
> y=a*log(x+1). As you see, I used "log" rather than "ln".
>
> So, I brought up eval.e and made the necessary changes, then had to modify GA
> Math
> to add the log function and to handle multiple-character function-name input.
> (You
> had to do something similar.)
>
> Okay, so I ran the thing and got a weird result, so I created a test for
> eval.e to
> see how it handled the formula "y=a*log(x+1)". Whoa, it only calcuated
> "y=log(x+1)",
> dropping the "a*" part. (I copied the final test to the bottom of this
> message.)
>
> So, when David Cuny warned about left-to-right evaluation, he wasn't kidding.
>
>
> If you use "y=a*(log(x+1))", then it works fine. Here are two example
> reports:
>
> --------------------------------------------------
> GA Math Beings Report
> --------------------------------------------------
> Math Beings working on formula : y=a*(log(x+1))
> Number of try-sets per run : 1200
> Number of runs this session : 7
> Number of tries per try-set : 8
> This is try-set number : 60
> Target value : 0.0010
> Current closeness (percent) : 0.000785
>
> Most successful being's original register values:
> {[10.67] , [9.75] , [7.06] , [0.99] , [0] , [0] , [0]}
>
>
> Most successful being's genes:
> rec, 4, 6
> {[10.67] , [9.75] , [7.06] , [0.99] , [0] , [1.01] , [0]}
> add, 6, 2, 6
> {[10.67] , [9.75] , [7.06] , [0.99] , [0] , [10.76] , [0]}
> log, 6, 5
> {[10.67] , [9.75] , [0.99] , [0.99] , [2.38] , [10.76] , [7.06]}
> mul, 5, 1, 7
> {[10.67] , [9.75] , [1.01] , [0.99] , [2.38] , [10.76] , [25.34]}
>
> Last actual answer from formula: 25.339
>
> --------------------------------------------------
> GA Math Beings Report
> --------------------------------------------------
> Math Beings working on formula : y=a*(log(x+1))
> Number of try-sets per run : 1200
> Number of runs this session : 3
> Number of tries per try-set : 8
> This is try-set number : 500
> Target value : 0.0010
> Current closeness (percent) : 0.000000
>
> Most successful being's original register values:
> {[9.37] , [1.23] , [2.50] , [1.24] , [0] , [0] , [0]}
>
>
> Most successful being's genes:
> div, 1, 1, 4
> {[9.37] , [1.23] , [-2.50] , [1.00] , [0] , [0] , [0]}
> add, 2, 4, 2
> {[9.37] , [2.23] , [-2.50] , [1.00] , [0] , [0] , [0]}
> sub, 1, 5, 4
> {[9.37] , [2.23] , [-2.50] , [9.37] , [0] , [0] , [0]}
> log, 2, 3
> {[9.37] , [2.23] , [0.80] , [9.37] , [0] , [0] , [0]}
> mul, 4, 3, 7
> {[-2.23] , [2.23] , [0.80] , [9.37] , [0] , [0] , [7.53]}
>
> Last actual answer from formula: 7.531
>
> --Quark
>
> The test:
> function RandRangeDec(integer lo, integer hi)
> return rand(hi-lo+1)+lo-1 + rand(999)/1000
> end function
> sequence f
> for i=1 to 10 do
> var['a']=RandRangeDec(0,11)
> var['x']=RandRangeDec(0,11)
> printf(1,"a=%f ",var['a'])
> printf(1,"x=%f\n",var['x'])
> f="y=a*(log(x+1))"
> printf(1,"eval(f): %f ",eval(f))
> printf(1,"actual: %f\n", var['a']*log(var['x']+1))
> end for
>
Hi Quark,
Yes, i had found that eval.e cant handle a multiplication before
a function such as a*ln(x) or k*sin(x), etc., so i ended up doing
the same thing temporarily. Putting parens around the function
seemed to work so i did that too: y=a*(ln(x+1))
This means i was doing basically the same thing you were doing :)
BTW i used "ln" instead of "log" because in the math world "log"
usually refers to log base 10 and ln refers to log base e, and
in GA Math i ended up making it skip the "l" and the "n" as variables
(it wanted to make l and n variables at first).
The interesting thing is, both of your runs came out algebraically
either exact or nearly so, so perhaps my run was a fluke or something
where it somehow got sidetracked, or perhaps returning a large
negative number as a 'penalty' isnt a good idea?
So what did you use for the log function in GA Math then...
when the number is positive i guess it's log(), but what about
when it's negative, or zero? Those are three possibilities so
if i knew what lines you used in GA Math for function #11 i could
try the same.
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
14. Re: The "evolution" of GA Math
Al Getz wrote:
SNIP
>
> Hi Quark,
>
> Yes, i had found that eval.e cant handle a multiplication before
> a function such as a*ln(x) or k*sin(x), etc., so i ended up doing
> the same thing temporarily. Putting parens around the function
> seemed to work so i did that too: y=a*(ln(x+1))
> This means i was doing basically the same thing you were doing :)
> BTW i used "ln" instead of "log" because in the math world "log"
> usually refers to log base 10 and ln refers to log base e, and
> in GA Math i ended up making it skip the "l" and the "n" as variables
> (it wanted to make l and n variables at first).
>
> The interesting thing is, both of your runs came out algebraically
> either exact or nearly so, so perhaps my run was a fluke or something
> where it somehow got sidetracked, or perhaps returning a large
> negative number as a 'penalty' isnt a good idea?
> So what did you use for the log function in GA Math then...
> when the number is positive i guess it's log(), but what about
> when it's negative, or zero? Those are three possibilities so
> if i knew what lines you used in GA Math for function #11 i could
> try the same.
>
>
> Take care,
> Al
Hello Al,
Here is the relevant code:
elsif op=11 then
--decimal fraction
if p[i][REG][from1]>0 then
p[i][REG][store]=log(p[i][REG][from1])
else
--"null" response...
p[i][REG][store]=0
end if
The GA Math "experience" seems to be a study in the complex interaction of
decisions made in coding. There never seems to be a state where one can say: "I
have ideally optimized this". If we had access to a nice used NSA
super-computer, we could set it to work on ways to evolve self-optimizing code
:^D
By the way, you may want to pop the already existing trig functions of eval.e
into GA Math to see what effect that has on some of your test problems. I dont't
know how you want to handle the modification necessary to get GA Math to deal
with multiple-character tokens in formula entry. Here is what I did, in case it
is useful to you:
At the top I added a new constant to be a list of recognizable functions:
constant EVALKEYWORDS={"log"}--many could be added here
Then I created the MarkMatch function (not tested carefully yet):
-------------------------------------------------
function MarkMatch(sequence s,sequence m)
--Quark 10/05 --create sequence with match locs of m in s where m is a
--sequence like {"this","that","whatever"} and s is a string
integer x,oldx
sequence t
t={}
for i=1 to length(m) do
x=match(m[i],s)
while x do
for j=1 to length(m[i]) do
t&=x+j-1
end for
oldx=x
if x+length(m[i])<=length(s) then
x=match(m[i],{s[x+length(m[i])]})
if x then
x+=oldx+length(m[i])-1
end if
end if
end while
end for
return t -- or sort(t)
end function
-------------------------------------------------
Then used that in GetFormula() this way:
skip=MarkMatch(f,EVALKEYWORDS)--e.g. if f="a=log(x)", skip={3,4,5}
indicating "log"
cnt=2
t={}
for i=x+1 to length(f) do
if not find(i,skip) then--<<<< * This is the key line *
if Alpha(f[i]) then
if not find(f[i],t) then
t&=f[i]
cnt+=1
end if
end if
end if
end for
return {f,t}
-------------------------------------------------------
You may well have a handier way to deal with all that.
Your investigations have been really interesting -- please continue to let me
know how it goes...
--Quark
15. Re: The "evolution" of GA Math
> The GA Math "experience" seems to be a study in the complex interaction of
> decisions
> made in coding. There never seems to be a state where one can say: "I have
> ideally
> optimized this". If we had access to a nice used NSA super-computer, we could
> set
> it to work on ways to evolve self-optimizing code :^D
Is this something that could be done thru a distributed computing project such
as BOINC?
http://boinc.berkeley.edu/create_project.php
Ken Rhodes
SuSE Linux 9.3
100% MicroSoft Free
16. Re: The "evolution" of GA Math
Kenneth Rhodes wrote:
>
>
> > The GA Math "experience" seems to be a study in the complex interaction of
> > decisions
> > made in coding. There never seems to be a state where one can say: "I have
> > ideally
> > optimized this". If we had access to a nice used NSA super-computer, we
> > could set
> > it to work on ways to evolve self-optimizing code :^D
>
> Is this something that could be done thru a distributed computing project such
> as BOINC?
> <a
> href="http://boinc.berkeley.edu/create_project.php">http://boinc.berkeley.edu/create_project.php</a>
>
> Ken Rhodes
> SuSE Linux 9.3
> 100% MicroSoft Free
>
Hi Ken,
Yes, it probably could as it is a massive job. If those elements of a program
like GA Math that affect results (such as a particular level of chance or number
of genes, etc.) are called controls, then the basic idea, as I am imagining it
now, would be:
1) Identify all the discrete controls
2) Establish a new set of controls
3) Perform a very large series of runs on a wide range of problems
4) Record the results for that set of controls
5) Goto 2) until no more meaningful variations of controls can be made
6) Assess the best set of controls for the widest range of problems (Or,
alternately, identify the best controls for a given type of problem.)
A variation on this would be to do the same thing, but do it one control, or
maybe two controls, at a time such that the program was *always* attempting to
optimize itself. It might arbitrarily choose a particular control and vary it
over a period of time to see what gave the best results, keeping records as it
goes.
An example might help here. Currently the length of a run before giving up and
restarting is determined by two controls: MAXRUN (set now at 1200) and MINPERF
(now 25, used this way: 1/mainCnt*MINPERF) which deals with current performance
based on the length of the run. Are these set to give the best results? It
would be astonishing if they were. They are just guesses on my part. It would
be useful, to say the least, to actually know the best settings. (Perhaps
MINPERF really should reflect the difficulty of the problem.)
Another example is the operator "NOP" or no operation which is currently in GA
Math. Is this useful? I think so, but don't really know.
--Quark
17. Re: The "evolution" of GA Math
- Posted by Al Getz <Xaxo at aol.com>
Oct 03, 2005
-
Last edited Oct 04, 2005
DB James wrote:
>
> Al Getz wrote:
> SNIP
> >
> > Hi Quark,
> >
> > Yes, i had found that eval.e cant handle a multiplication before
> > a function such as a*ln(x) or k*sin(x), etc., so i ended up doing
> > the same thing temporarily. Putting parens around the function
> > seemed to work so i did that too: y=a*(ln(x+1))
> > This means i was doing basically the same thing you were doing :)
> > BTW i used "ln" instead of "log" because in the math world "log"
> > usually refers to log base 10 and ln refers to log base e, and
> > in GA Math i ended up making it skip the "l" and the "n" as variables
> > (it wanted to make l and n variables at first).
> >
> > The interesting thing is, both of your runs came out algebraically
> > either exact or nearly so, so perhaps my run was a fluke or something
> > where it somehow got sidetracked, or perhaps returning a large
> > negative number as a 'penalty' isnt a good idea?
> > So what did you use for the log function in GA Math then...
> > when the number is positive i guess it's log(), but what about
> > when it's negative, or zero? Those are three possibilities so
> > if i knew what lines you used in GA Math for function #11 i could
> > try the same.
> >
> >
> > Take care,
> > Al
>
> Hello Al,
>
> Here is the relevant code:
>
> elsif op=11 then
> --decimal fraction
> if p[i][REG][from1]>0 then
> p[i][REG][store]=log(p[i][REG][from1])
> else
> --"null" response...
> p[i][REG][store]=0
> end if
>
> The GA Math "experience" seems to be a study in the complex interaction of
> decisions
> made in coding. There never seems to be a state where one can say: "I have
> ideally
> optimized this". If we had access to a nice used NSA super-computer, we could
> set
> it to work on ways to evolve self-optimizing code :^D
>
> By the way, you may want to pop the already existing trig functions of eval.e
> into
> GA Math to see what effect that has on some of your test problems. I dont't
> know how
> you want to handle the modification necessary to get GA Math to deal with
> multiple-character
> tokens in formula entry. Here is what I did, in case it is useful to you:
>
> At the top I added a new constant to be a list of recognizable functions:
> constant EVALKEYWORDS={"log"}--many could be added here
>
> Then I created the MarkMatch function (not tested carefully yet):
> -------------------------------------------------
> function MarkMatch(sequence s,sequence m)
> --Quark 10/05 --create sequence with match locs of m in s where m is a
> --sequence like {"this","that","whatever"} and s is a string
> integer x,oldx
> sequence t
> t={}
> for i=1 to length(m) do
> x=match(m[i],s)
> while x do
> for j=1 to length(m[i]) do
> t&=x+j-1
> end for
> oldx=x
> if x+length(m[i])<=length(s) then
> x=match(m[i],{s[x+length(m[i])]})
> if x then
> x+=oldx+length(m[i])-1
> end if
> end if
> end while
> end for
> return t -- or sort(t)
> end function
> -------------------------------------------------
>
> Then used that in GetFormula() this way:
> skip=MarkMatch(f,EVALKEYWORDS)--e.g. if f="a=log(x)", skip={3,4,5}
> indicating "log"
> cnt=2
> t={}
> for i=x+1 to length(f) do
> if not find(i,skip) then--<<<< * This is the key line *
> if Alpha(f[i]) then
> if not find(f[i],t) then
> t&=f[i]
> cnt+=1
> end if
> end if
> end if
> end for
> return {f,t}
> -------------------------------------------------------
>
> You may well have a handier way to deal with all that.
>
> Your investigations have been really interesting -- please continue to let me
> know
> how it goes...
>
> --Quark
>
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
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
18. Re: The "evolution" of GA Math
- Posted by DB James <larch at adelphia.net>
Oct 03, 2005
-
Last edited Oct 04, 2005
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
19. Re: The "evolution" of GA Math
- Posted by Al Getz <Xaxo at aol.com>
Oct 03, 2005
-
Last edited Oct 04, 2005
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"
20. Re: The "evolution" of GA Math
- Posted by DB James <larch at adelphia.net>
Oct 03, 2005
-
Last edited Oct 04, 2005
Al Getz wrote:
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
>
hI,
Yes, the thing comes up with some really funny stuff, but choose your audience
carefully when you tell the tale!
In general, Al, you should do whatever you like with GA Math. I would be
pleased with improved versions from however many sources and each different.
From experience, I suggest you keep previous versions, maybe with brief notes
describing what the program was capable of because anyone tweaking this tweakable
program is going to have relative failures as well as successes. Modify eval.e
as you need to -- that is what David Cuny wanted to happen.
As to "nop", well as I said, I thought it might help (sort of a fudginess that
would sometimes avoid stepping on a good answer), but had no way to clearly test
effectiveness. If you left it in, it would probably do little harm at least, and
you would then have the option of converting "bad-acting genes" to "nop".
Yes, dig deep into it and get to know the poor little beings who give their all.
And, seriously, there are so many interacting variables that it does help to get
a feeling for the net of forces acting on the population. Again, be ready to
retreat to an earlier version when some idea doesn't work out.
An idea for the fun of it sometime when time hangs heavily: do a little graph
function that would show the struggle toward fitness. Also, out of that, might
come a clearer idea of how to control the length of a run based on performance.
You have a good reason to justify purchase of a faster computer -- research!
--Quark
21. Re: The "evolution" of GA Math
DB James wrote:
>
> Al Getz wrote:
> 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
> >
>
> hI,
>
> Yes, the thing comes up with some really funny stuff, but choose your audience
> carefully
> when you tell the tale!
>
> In general, Al, you should do whatever you like with GA Math. I would be
> pleased with
> improved versions from however many sources and each different. From
> experience, I
> suggest you keep previous versions, maybe with brief notes describing what the
> program
> was capable of because anyone tweaking this tweakable program is going to have
> relative
> failures as well as successes. Modify eval.e as you need to -- that is what
> David
> Cuny wanted to happen.
>
> As to "nop", well as I said, I thought it might help (sort of a fudginess that
> would
> sometimes avoid stepping on a good answer), but had no way to clearly test
> effectiveness.
> If you left it in, it would probably do little harm at least, and you would
> then have
> the option of converting "bad-acting genes" to "nop".
>
> Yes, dig deep into it and get to know the poor little beings who give their
> all. And,
> seriously, there are so many interacting variables that it does help to get a
> feeling
> for the net of forces acting on the population. Again, be ready to retreat to
> an earlier
> version when some idea doesn't work out.
>
> An idea for the fun of it sometime when time hangs heavily: do a little graph
> function
> that would show the struggle toward fitness. Also, out of that, might come a
> clearer
> idea of how to control the length of a run based on performance.
>
> You have a good reason to justify purchase of a faster computer -- research!
>
> --Quark
>
Hi again,
Hey the graph thing sounds very interesting...might show some trends yes.
What i was beginning to wonder is just how many operations are allowed
for one algorithm...adds, subtracts, multiplies, etc. If my data
requires 50 steps (add 1,2,3 mult 3,4,5 ... etc.) is there any
limit here?
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
22. Re: The "evolution" of GA Math
Al Getz wrote:
>
> Hi again,
>
>
> Hey the graph thing sounds very interesting...might show some trends yes.
>
> What i was beginning to wonder is just how many operations are allowed
> for one algorithm...adds, subtracts, multiplies, etc. If my data
> requires 50 steps (add 1,2,3 mult 3,4,5 ... etc.) is there any
> limit here?
>
>
> Take care,
> Al
>
Hello Al,
Yes, a small graph might be amusing to watch while the populations struggle with
their environment!
Allowed operations? It is currently limited by the number of genes (same as the
number of operations):
constant MINGENES=6--minimum number of genes per being
The code now randomly produces from MINGENES to MINGENES*2 genes. Just change
MINGENES.
However, as with virtually every change, there will be a probable price -- the
more operations, the longer the time per try, etc.
Also your question suggests interesting ruminations. Waxing theoretical, I can
imagine a range of GA Math type programs with different goals. Mine is quite
basic: it is designed to work on simple formulas. What is a simple formula?
Here a math expert could help us. My guess it is a mathematical statement where
all the components are present initially, and where simple math operations will
yield the answer. For example (and I'm not sure of this) it seems that finding
the area of a square given the side is simple, but finding the side given the
area is not so simple and seems different in kind. Of course, GA Math can have
extentions to its "basic" operations set, and so be capable of more complex
calculations.
For the type of problem that involves iteration or some other elaborate series
of steps (i.e. where it is less a real formula and more of an algorithm, in
effect), then a different type of GA is needed. Are you familiar with Core Wars?
Imagine a Core Wars math population that for each being had its own memory work
space and where looping and if-then operations were possible. Such a population
could handle elaborate algorithmic puzzles through evolution.
There is a whole lot of investigation to be done on the simpler level of the
current GA Math (am looking forward to your Windows version). If one understood
the strengths and weaknesses of it, then later elaborations would be more
meaningful...
Oh, nearly forgot to mention that I finally solved all the little issues with
creating C versions of Eu programs, and of course immediately applied it to GA
Math. Wow! I do recommend you create C versions of your modifications to GA
Math. B-I-G difference in speed! Will be able to stick one on my HP NARC to run
while I'm doing other things.
--Quark
23. Re: The "evolution" of GA Math
DB James wrote:
>
> Al Getz wrote:
> >
> > Hi again,
> >
> >
> > Hey the graph thing sounds very interesting...might show some trends yes.
> >
> > What i was beginning to wonder is just how many operations are allowed
> > for one algorithm...adds, subtracts, multiplies, etc. If my data
> > requires 50 steps (add 1,2,3 mult 3,4,5 ... etc.) is there any
> > limit here?
> >
> >
> > Take care,
> > Al
> >
> Hello Al,
>
> Yes, a small graph might be amusing to watch while the populations struggle
> with their
> environment!
>
> Allowed operations? It is currently limited by the number of genes (same as
> the number
> of operations):
> constant MINGENES=6--minimum number of genes per being
>
> The code now randomly produces from MINGENES to MINGENES*2 genes. Just change
> MINGENES.
>
> However, as with virtually every change, there will be a probable price -- the
> more
> operations, the longer the time per try, etc.
>
> Also your question suggests interesting ruminations. Waxing theoretical, I
> can imagine
> a range of GA Math type programs with different goals. Mine is quite basic:
> it is
> designed to work on simple formulas. What is a simple formula? Here a math
> expert
> could help us. My guess it is a mathematical statement where all the
> components are
> present initially, and where simple math operations will yield the answer.
> For example
> (and I'm not sure of this) it seems that finding the area of a square given
> the side
> is simple, but finding the side given the area is not so simple and seems
> different
> in kind. Of course, GA Math can have extentions to its "basic" operations
> set, and
> so be capable of more complex calculations.
>
> For the type of problem that involves iteration or some other elaborate series
> of steps
> (i.e. where it is less a real formula and more of an algorithm, in effect),
> then a
> different type of GA is needed. Are you familiar with Core Wars? Imagine a
> Core Wars
> math population that for each being had its own memory work space and where
> looping
> and if-then operations were possible. Such a population could handle
> elaborate algorithmic
> puzzles through evolution.
>
> There is a whole lot of investigation to be done on the simpler level of the
> current
> GA Math (am looking forward to your Windows version). If one understood the
> strengths
> and weaknesses of it, then later elaborations would be more meaningful...
>
> Oh, nearly forgot to mention that I finally solved all the little issues with
> creating
> C versions of Eu programs, and of course immediately applied it to GA Math.
> Wow!
> I do recommend you create C versions of your modifications to GA Math. B-I-G
> difference
> in speed! Will be able to stick one on my HP NARC to run while I'm doing
> other things.
>
> --Quark
>
Hello again Quark,
Oh ok, perhaps i'll try the C versions at some point. Right now im
wondering about the real life applications a little more...how long it
will take to get an answer once im using it for things that will actually
provide some real benefit. I'll probably do a few more experiments
with it the way it is now. Setting it up to figure out the inverse
function would be very interesting too as sometimes it's hard to find using
other methods, if you can find it at all.
I'll post anything that turns out to be interesting.
Core wars? No, sorry, havent seen that.
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
24. Re: The "evolution" of GA Math
Al Getz wrote:
SNIP
> Hello again Quark,
>
> Oh ok, perhaps i'll try the C versions at some point. Right now im
> wondering about the real life applications a little more...how long it
> will take to get an answer once im using it for things that will actually
> provide some real benefit. I'll probably do a few more experiments
> with it the way it is now. Setting it up to figure out the inverse
> function would be very interesting too as sometimes it's hard to find using
> other methods, if you can find it at all.
> I'll post anything that turns out to be interesting.
>
> Core wars? No, sorry, havent seen that.
>
>
> Take care,
> Al
>
Hi Al,
Core Wars is interesting. Have a look at the Wikipedia entry on it:
http://en.wikipedia.org/wiki/Core_Wars
Though I am doing other programming projects as I wanted to do, I am also very
interested in following your investigations. Also, I wanted to say it was not my
intent to suggest more elaborate GA programming in my mentioning loops, etc. In
fact, I think understanding the simpler form of GA Math-type programs is quite
worthwhile.
To that point, I'll have a report soon from a "research" version of GA Math I
did to get a crude sort of performance line on different math problems. The
program automatically runs through a list of formulas. By controlling the list
and identifying which formulas take longer, one knows better what to attempt to
optimize...
Inverse function?
As to C versions, I have it down to about 30 seconds to generate a C version.
It helped when I made a shortcut to the Command Prompt that pops me directly in
the development folder.
--Quark
25. Re: The "evolution" of GA Math
- Posted by Al Getz <Xaxo at aol.com>
Oct 07, 2005
-
Last edited Oct 08, 2005
DB James wrote:
>
> Al Getz wrote:
> SNIP
> > Hello again Quark,
> >
> > Oh ok, perhaps i'll try the C versions at some point. Right now im
> > wondering about the real life applications a little more...how long it
> > will take to get an answer once im using it for things that will actually
> > provide some real benefit. I'll probably do a few more experiments
> > with it the way it is now. Setting it up to figure out the inverse
> > function would be very interesting too as sometimes it's hard to find using
> > other methods, if you can find it at all.
> > I'll post anything that turns out to be interesting.
> >
> > Core wars? No, sorry, havent seen that.
> >
> >
> > Take care,
> > Al
> >
> Hi Al,
>
> Core Wars is interesting. Have a look at the Wikipedia entry on it:
> <a
> href="http://en.wikipedia.org/wiki/Core_Wars">http://en.wikipedia.org/wiki/Core_Wars</a>
>
> Though I am doing other programming projects as I wanted to do, I am also very
> interested in following your investigations. Also, I wanted to say it was not
> my intent to suggest more elaborate GA programming in my mentioning loops,
> etc.
> In fact, I think understanding the simpler form of GA Math-type programs is
> quite
> worthwhile.
>
> To that point, I'll have a report soon from a "research" version of GA Math I
> did to get a crude sort of performance line on different math problems. The
> program
> automatically runs through a list of formulas. By controlling the list and
> identifying
> which formulas take longer, one knows better what to attempt to optimize...
>
> Inverse function?
>
> As to C versions, I have it down to about 30 seconds to generate a C version.
> It helped when I made a shortcut to the Command Prompt that pops me directly
> in the development folder.
>
> --Quark
>
Hi again,
Oh ok, that Core Wars looks interesting but i have a feeling it would
take some time to investigate it completely.
The "Inverse Function" is the function that gets the 'original' value
of x back from y such as:
y=fn(x) --function
x=gn(y) --its inverse, usually denoted x=fn^(-1)(y)
(fn^(-1) is read: "fn to the minus 1 power or simply 'inverse function'")
An example:
y=2*x --function
x=0.5*y --its inverse
to get this inverse function all we would have to do is solve for
x in y=2*x, which gives us x=y/2 ...no problem...but
y=a*x^3+b*x^2+c*x+d --function
x=gn^(-1)(y) --what is gn^(-1)?
is a lot harder to solve for x even when a,b,c,d are known.
In fact, there are three solutions and many times two of them
are a complex conjugate pair. We would need an 'eval.e' that
handles complex numbers to do this one, but that's not impossible...
( see MathLib in the archives ).
Higher order gets even harder:
y=a*x^4+b*x^3+c*x^2+d*x+e --function
x=gn^(-1)(x) --what is gn^(-1) ?
Even the algebraic solution to this takes a little while to compute!
Go one order higher (fifth degree equation in x) and we step out
of the equations with known (general) algebraic solutions. We then have to
resort to numerical solvers (see again MathLib in the archives) to
solve for x.
What i was thinking was, perhaps, we could somehow use GAMath to
solve for the inverse function. If we could find the inverse for
the fifth degree equation in x:
y=a*x^5+b*x^4+c*x^3+d*x^2+e*x+f
that would really be something! I think that would be a good
indication that this (at least running on the personal computer)
could be beneficial to mankind.
SIXTH order (!) would really be something done for the first time
i think!
On the other hand, if there was no solution perhaps it would run
indefinitely. Any ideas?
http://mathworld.wolfram.com/QuinticEquation.html
One advantage we would have is we wouldnt be confined to certain
functions, having trig and log functions and whatever else we
wanted to add available too.
Maybe we're getting a feel for why conventional math is based on logical
deduction rather than guess work :) On the other hand, logical deduction
begins to take time too once you get past the simpler things. Add human
error and you end up with restarts too! hmmmm... more to think about.
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
26. Re: The "evolution" of GA Math
- Posted by DB James <larch at adelphia.net>
Oct 07, 2005
-
Last edited Oct 08, 2005
Al Getz wrote:
SNIP
>
> Hi again,
>
> Oh ok, that Core Wars looks interesting but i have a feeling it would
> take some time to investigate it completely.
>
> The "Inverse Function" is the function that gets the 'original' value
> of x back from y such as:
> y=fn(x) --function
> x=gn(y) --its inverse, usually denoted x=fn^(-1)(y)
> (fn^(-1) is read: "fn to the minus 1 power or simply 'inverse function'")
>
> An example:
> y=2*x --function
> x=0.5*y --its inverse
> to get this inverse function all we would have to do is solve for
> x in y=2*x, which gives us x=y/2 ...no problem...but
>
> y=a*x^3+b*x^2+c*x+d --function
> x=gn^(-1)(y) --what is gn^(-1)?
> is a lot harder to solve for x even when a,b,c,d are known.
> In fact, there are three solutions and many times two of them
> are a complex conjugate pair. We would need an 'eval.e' that
> handles complex numbers to do this one, but that's not impossible...
> ( see MathLib in the archives ).
>
> Higher order gets even harder:
> y=a*x^4+b*x^3+c*x^2+d*x+e --function
> x=gn^(-1)(x) --what is gn^(-1) ?
> Even the algebraic solution to this takes a little while to compute!
>
> Go one order higher (fifth degree equation in x) and we step out
> of the equations with known (general) algebraic solutions. We then have to
> resort to numerical solvers (see again MathLib in the archives) to
> solve for x.
>
> What i was thinking was, perhaps, we could somehow use GAMath to
> solve for the inverse function. If we could find the inverse for
> the fifth degree equation in x:
> y=a*x^5+b*x^4+c*x^3+d*x^2+e*x+f
> that would really be something! I think that would be a good
> indication that this (at least running on the personal computer)
> could be beneficial to mankind.
>
> SIXTH order (!) would really be something done for the first time
> i think!
> On the other hand, if there was no solution perhaps it would run
> indefinitely. Any ideas?
> <a
> href="http://mathworld.wolfram.com/QuinticEquation.html">http://mathworld.wolfram.com/QuinticEquation.html</a>
> One advantage we would have is we wouldnt be confined to certain
> functions, having trig and log functions and whatever else we
> wanted to add available too.
>
>
> Maybe we're getting a feel for why conventional math is based on logical
> deduction rather than guess work :) On the other hand, logical deduction
> begins to take time too once you get past the simpler things. Add human
> error and you end up with restarts too! hmmmm... more to think about.
>
>
> Take care,
> Al
Yow!, I mean Hi there,
I'll have to absorb this slowly to get it as I am math-challenged, but I'll try.
Will respond later.
Here is the little interim report I referred to:
formulaSet={
"a=x+y", --Runs per completion: 1/1/1/1/1/1
"a=(x+y)*x", --Runs per completion: 1/1/1/1/1/2
"a=(x+y)*(x+y)", --Runs per completion: 1/1/1/1/1/1
"a=(x+y)*(x-y)", --Runs per completion: 1/1/1/1/2/1
"a=(x+y)*(x*x)", --Runs per completion: 2/2/3/1/2/1
"a=(x+y)*(x*y)", --Runs per completion: 1/3/1/1/1/1
"a=(x+y)*(x+2)", --Runs per completion: 5/4/2/3/11/1
"a=(x+y)*(x+20)", --Runs per completion: 12/1/5/5/2/5
"a=(x+y)*((x+y)*2)", --Runs per completion: 4/4/17/1/1/4
"a=(x+y)*((x+y)*23)" --Runs per completion: 5/5/3/2/1/5
}
Using the more automated version of GA Math (with current tweaks of course), I
ran each formula to success (completion) six times. The comments show the runs
necessary for each completion. The runs-number is more useful than time, as it
would apply regardless of processor speed, though I do now have a date and time
in each report. I may redo the automated version to get its formulas from a
standard file, so I can run different formula sets without changing the program.
Also to automatically make a report as above (am doing it by hand now).
With your much better understanding of "order" math, you could work out better
testing formulas to see where optimizations need to be done, or to test the
effect of adding functions to GA Math, etc. At some point, you or someone will
probably have to deal with the power function and its overflow problem.
Minor points:
-I have altered my version to put all three private numbers in to the personal
registers, instead of one for each variable.
-I have added the trig functions, but haven't done much with them yet.
-This stuff I'm reporting is mostly for personal experimentation only, meaning I
won't update GA Math until, and if, major improvements are possible. Would
rather see improvements from others...
-There are nteresting anomalies in formulas #7, 8, and 9 above with large runs
showing up occasionally.
-It is clear that literal values in formulas do slow things down, but that is to
be expected. I have tweaked the range of evolving values... More needs to be
done.
--Quark
27. Re: The "evolution" of GA Math
Hi Quark,
I wont mind if you wait a while to update again as i know we're still looking
at things here and it's going to take a while. Also, if i can get to it i'll
do the Windows version so people with Windows can get a 'normal' gui with
the program. Perhaps multiple threads to have several experiments going
at the same time...
What do you mean about the "power" function? You mean it's a problem if
the numbers become too high or incorrect sign or whatever? That's not
too much of a problem, but did we ever figure out what the penalty would
be for a function that goes out of range? Does zero (0) always work?
We need to know this or the program wont be able to respond to an overflow
anyway right? Maybe you'd be interested in trying a few experiments with
a function that can easily cause an overflow (and then use 0 as penalty)
just to see if the idea of using zero works?
If you would like to add another function to your list to try, please try
this:
x=(-b+sqrt(b*b-4*a*c))/(2*a)
You'll need to make sure your eval.e has 'sqrt()' added, and GAMath also
has sqrt(x) as one of the possible operations.
To 'fix' the power function we'll apply the penalty if it overflows.
We might have to do with with other functions too right?
I've altered my version a little too, but mostly cosmetic stuff to log
experiments
in a file.
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
28. Re: The "evolution" of GA Math
- Posted by DB James <larch at adelphia.net>
Oct 08, 2005
-
Last edited Oct 09, 2005
Al Getz wrote:
>
>
> Hi Quark,
>
>
> I wont mind if you wait a while to update again as i know we're still looking
> at things here and it's going to take a while. Also, if i can get to it i'll
> do the Windows version so people with Windows can get a 'normal' gui with
> the program. Perhaps multiple threads to have several experiments going
> at the same time...
>
> What do you mean about the "power" function? You mean it's a problem if
> the numbers become too high or incorrect sign or whatever? That's not
> too much of a problem, but did we ever figure out what the penalty would
> be for a function that goes out of range? Does zero (0) always work?
> We need to know this or the program wont be able to respond to an overflow
> anyway right? Maybe you'd be interested in trying a few experiments with
> a function that can easily cause an overflow (and then use 0 as penalty)
> just to see if the idea of using zero works?
>
> If you would like to add another function to your list to try, please try
> this:
> x=(-b+sqrt(b*b-4*a*c))/(2*a)
>
> You'll need to make sure your eval.e has 'sqrt()' added, and GAMath also
> has sqrt(x) as one of the possible operations.
>
> To 'fix' the power function we'll apply the penalty if it overflows.
> We might have to do with with other functions too right?
>
> I've altered my version a little too, but mostly cosmetic stuff to log
> experiments
> in a file.
>
>
> Take care,
> Al
Hi Al,
Both a Windows version and the use of multiple threads sounds good to me. I
look forward to it. (Also perhaps this would be a good concept for an OOP
implementation?)
By "power", I mean the Eu power function. If GA Math had it, then overflow
would be a very likely result, e.g. "pow" [3] [2] [7] where [3] is location #3
which contains, say 11.123 and [2] which contains 309 -- and there are many other
possible overflow situations which would potentially be manipulating large
numbers.
And, no, I haven't come up with anything better than using zero for a penalty,
or more accurately, for a number to use when the gene tries to do something
illegal or dangerous. Any other number would get into problems also, and the
zero may be the best way to go. But if you come up with something else, let me
know.
Of course, power() can handle sqrt(), but the advantage would be that only one
number need be supplied for sqrt(). Go ahead and add it if you wish. I may well
do so too.
As for your: "To 'fix' the power function we'll apply the penalty if it
overflows. We might have to do with with other functions too right?" So far all
the functions I've done have not caused overflow and some are restricted to
proper inputs (else they output a zero). It seems like the power function is a
real headache because it is capable of generating very large numbers. Even if we
limited it to say a range of exponent .167 to 6, it could still, by repetition,
or the actions of other functions, give numbers too large. Have tried to think
of a self-limiting "number-space", but my head began to ache... Would be nice to
have a solution that would be simple and not slow the program down. Maybe an
exponent limitation of .333 to 3? would work for most problems?
So, forgetting for the moment about the power problem, I'm still concentrating
on establishing a good base program and a good set of demonstration formulas.
Ideally, I want to know exactly what it is capable of and why. From that base,
expansion of capability should be made easier.
As an example of considerations for the demonstration of capabilities, the
casual observer might assume that "a = (x+20)/30" is easier than
v = (4/3)*3.14159*(r^3), but the "(4/3)*3.14159" can be generated as one number,
while the "20" and the "30" must be generated individually.
--Quark
29. Re: The "evolution" of GA Math
- Posted by Al Getz <Xaxo at aol.com>
Oct 08, 2005
-
Last edited Oct 09, 2005
DB James wrote:
>
> Al Getz wrote:
> >
> >
> > Hi Quark,
> >
> >
> > I wont mind if you wait a while to update again as i know we're still
> > looking
> > at things here and it's going to take a while. Also, if i can get to it
> > i'll
> > do the Windows version so people with Windows can get a 'normal' gui with
> > the program. Perhaps multiple threads to have several experiments going
> > at the same time...
> >
> > What do you mean about the "power" function? You mean it's a problem if
> > the numbers become too high or incorrect sign or whatever? That's not
> > too much of a problem, but did we ever figure out what the penalty would
> > be for a function that goes out of range? Does zero (0) always work?
> > We need to know this or the program wont be able to respond to an overflow
> > anyway right? Maybe you'd be interested in trying a few experiments with
> > a function that can easily cause an overflow (and then use 0 as penalty)
> > just to see if the idea of using zero works?
> >
> > If you would like to add another function to your list to try, please try
> > this:
> > x=(-b+sqrt(b*b-4*a*c))/(2*a)
> >
> > You'll need to make sure your eval.e has 'sqrt()' added, and GAMath also
> > has sqrt(x) as one of the possible operations.
> >
> > To 'fix' the power function we'll apply the penalty if it overflows.
> > We might have to do with with other functions too right?
> >
> > I've altered my version a little too, but mostly cosmetic stuff to log
> > experiments
> > in a file.
> >
> >
> > Take care,
> > Al
>
> Hi Al,
>
> Both a Windows version and the use of multiple threads sounds good to me. I
> look
> forward to it. (Also perhaps this would be a good concept for an OOP
> implementation?)
>
> By "power", I mean the Eu power function. If GA Math had it, then overflow
> would
> be a very likely result, e.g. "pow" [3] [2] [7] where [3] is location #3 which
> contains, say 11.123 and [2] which contains 309 -- and there are many other
> possible
> overflow situations which would potentially be manipulating large numbers.
>
> And, no, I haven't come up with anything better than using zero for a penalty,
> or more accurately, for a number to use when the gene tries to do something
> illegal
> or dangerous. Any other number would get into problems also, and the zero may
> be the best way to go. But if you come up with something else, let me know.
>
> Of course, power() can handle sqrt(), but the advantage would be that only one
> number need be supplied for sqrt(). Go ahead and add it if you wish. I may
> well
> do so too.
>
> As for your: "To 'fix' the power function we'll apply the penalty if it
> overflows.
> We might have to do with with other functions too right?" So far all the
> functions
> I've done have not caused overflow and some are restricted to proper inputs
> (else
> they output a zero). It seems like the power function is a real headache
> because
> it is capable of generating very large numbers. Even if we limited it to say
> a range of exponent .167 to 6, it could still, by repetition, or the actions
> of
> other functions, give numbers too large. Have tried to think of a
> self-limiting
> "number-space", but my head began to ache... Would be nice to have a solution
> that would be simple and not slow the program down. Maybe an exponent
> limitation
> of .333 to 3? would work for most problems?
>
> So, forgetting for the moment about the power problem, I'm still concentrating
> on establishing a good base program and a good set of demonstration formulas.
> Ideally, I want to know exactly what it is capable of and why. From that
> base,
> expansion of capability should be made easier.
>
> As an example of considerations for the demonstration of capabilities, the
> casual
> observer might assume that "a = (x+20)/30" is easier than
> v = (4/3)*3.14159*(r^3), but the "(4/3)*3.14159" can be generated as one
> number,
> while the "20" and the "30" must be generated individually.
>
> --Quark
>
Hi Quark,
Here's a solution for the 'power()' problem. It adds a little to the
overhead but after all we've got to test the domain...
integer EvalError
EvalError=0
sequence ErrorString
ErrorString=""
function Power(atom x, atom y)
--Raise x to the power of y if possible.
--Returns 0 and sets error if not possible.
atom LN
EvalError=0
ErrorString="Ok"
--args have to be tested for range as well as sign and integerality
if x<0 then
LN=log(-x)*y
elsif x>0 then
LN=log(x)*y
else
LN=1 --Allow 0^n to be evaluated as zero (0).
--If this is unacceptable then load ErrorString
--and return 0 here as follows...
--EvalError=1
--ErrorString="0 raised to a power is not allowed"
--return 0
end if
if LN>709 then
EvalError=1
ErrorString="x^(y) operation would result in overflow"
return 0 --error
end if
if x<0 then
LN=floor(y)
if y-LN=0 then --y is an integer (cant test for Eu integer!)
return power(x,LN)
else
EvalError=1
ErrorString="Minus x raised to non integer power"
return 0 --error
end if
else
return power(x,y)
end if
end function
--Testing...
?Power(1.2e11,30)
printf(1," %s\n",{ErrorString})
?Power(5,500)
printf(1," %s\n",{ErrorString})
?Power(-2,3.1)
printf(1," %s\n",{ErrorString})
--large negative exponent allowed:
?Power(5,-800)
printf(1," %s\n",{ErrorString})
--small number raised to large power ok:
?Power(5e-18,800)
printf(1," %s\n",{ErrorString})
sleep(1234)
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
30. Re: The "evolution" of GA Math
Al Getz wrote:
SNIP
> Hi Quark,
>
> Here's a solution for the 'power()' problem. It adds a little to the
> overhead but after all we've got to test the domain...
>
> integer EvalError
> EvalError=0
> sequence ErrorString
> ErrorString=""
>
> function Power(atom x, atom y)
> --Raise x to the power of y if possible.
> --Returns 0 and sets error if not possible.
>
> atom LN
>
> EvalError=0
> ErrorString="Ok"
>
> --args have to be tested for range as well as sign and integerality
> if x<0 then
> LN=log(-x)*y
> elsif x>0 then
> LN=log(x)*y
> else
> LN=1 --Allow 0^n to be evaluated as zero (0).
> --If this is unacceptable then load ErrorString
> --and return 0 here as follows...
> --EvalError=1
> --ErrorString="0 raised to a power is not allowed"
> --return 0
> end if
>
> if LN>709 then
> EvalError=1
> ErrorString="x^(y) operation would result in overflow"
> return 0 --error
> end if
>
> if x<0 then
> LN=floor(y)
> if y-LN=0 then --y is an integer (cant test for Eu integer!)
> return power(x,LN)
> else
> EvalError=1
> ErrorString="Minus x raised to non integer power"
> return 0 --error
> end if
> else
> return power(x,y)
> end if
>
> end function
>
>
> --Testing...
>
> ?Power(1.2e11,30)
> printf(1," %s\n",{ErrorString})
>
> ?Power(5,500)
> printf(1," %s\n",{ErrorString})
>
> ?Power(-2,3.1)
> printf(1," %s\n",{ErrorString})
>
> --large negative exponent allowed:
> ?Power(5,-800)
> printf(1," %s\n",{ErrorString})
>
> --small number raised to large power ok:
> ?Power(5e-18,800)
> printf(1," %s\n",{ErrorString})
>
> sleep(1234)
>
>
> Take care,
> Al
Hi Al,
'Tis the wee hours here and my brain is signaling bailout time nearing. Will
look at your safe power function as soon as I can. I'll be doing some family
stuff tomorrow, so that will delay things.
Meanwhile, I've done some more modifying of my test version of GA Math and it
seems useful so far. I switched to counting try-sets instead of runs for a
better sense of how tough different formulas are. I also now have the top 1/4 of
beings cloning the remaining 3/4 for each try-set to get some better numbers for
the little tykes. The report now shows average try-sets for a multiple run per
formula. Would say more, but my brain left...
--Quark
31. Re: The "evolution" of GA Math
- Posted by Al Getz <Xaxo at aol.com>
Oct 10, 2005
-
Last edited Oct 11, 2005
DB James wrote:
>
> Al Getz wrote:
> SNIP
> > Hi Quark,
> >
> > Here's a solution for the 'power()' problem. It adds a little to the
> > overhead but after all we've got to test the domain...
> >
> > integer EvalError
> > EvalError=0
> > sequence ErrorString
> > ErrorString=""
> >
> > function Power(atom x, atom y)
> > --Raise x to the power of y if possible.
> > --Returns 0 and sets error if not possible.
> >
> > atom LN
> >
> > EvalError=0
> > ErrorString="Ok"
> >
> > --args have to be tested for range as well as sign and integerality
> > if x<0 then
> > LN=log(-x)*y
> > elsif x>0 then
> > LN=log(x)*y
> > else
> > LN=1 --Allow 0^n to be evaluated as zero (0).
> > --If this is unacceptable then load ErrorString
> > --and return 0 here as follows...
> > --EvalError=1
> > --ErrorString="0 raised to a power is not allowed"
> > --return 0
> > end if
> >
> > if LN>709 then
> > EvalError=1
> > ErrorString="x^(y) operation would result in overflow"
> > return 0 --error
> > end if
> >
> > if x<0 then
> > LN=floor(y)
> > if y-LN=0 then --y is an integer (cant test for Eu integer!)
> > return power(x,LN)
> > else
> > EvalError=1
> > ErrorString="Minus x raised to non integer power"
> > return 0 --error
> > end if
> > else
> > return power(x,y)
> > end if
> >
> > end function
> >
> >
> > --Testing...
> >
> > ?Power(1.2e11,30)
> > printf(1," %s\n",{ErrorString})
> >
> > ?Power(5,500)
> > printf(1," %s\n",{ErrorString})
> >
> > ?Power(-2,3.1)
> > printf(1," %s\n",{ErrorString})
> >
> > --large negative exponent allowed:
> > ?Power(5,-800)
> > printf(1," %s\n",{ErrorString})
> >
> > --small number raised to large power ok:
> > ?Power(5e-18,800)
> > printf(1," %s\n",{ErrorString})
> >
> > sleep(1234)
> >
> >
> > Take care,
> > Al
>
> Hi Al,
>
> 'Tis the wee hours here and my brain is signaling bailout time nearing. Will
> look at your safe power function as soon as I can. I'll be doing some family
> stuff tomorrow, so that will delay things.
>
> Meanwhile, I've done some more modifying of my test version of GA Math and it
> seems useful so far. I switched to counting try-sets instead of runs for a
> better
> sense of how tough different formulas are. I also now have the top 1/4 of
> beings
> cloning the remaining 3/4 for each try-set to get some better numbers for the
> little tykes. The report now shows average try-sets for a multiple run per
> formula.
> Would say more, but my brain left...
>
> --Quark
>
Hi Quark,
Hey you reminded me we can also use my 'Scientific Calculator' in the
archives, as it already has a multitude of advanced functions and it
can be accessed as a server from our GA Math programs.
Commands are sent via string sequences.
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
32. Re: The "evolution" of GA Math
Al Getz wrote:
SNIP
> Hi Quark,
>
>
> Hey you reminded me we can also use my 'Scientific Calculator' in the
> archives, as it already has a multitude of advanced functions and it
> can be accessed as a server from our GA Math programs.
> Commands are sent via string sequences.
>
>
> Take care,
> Al
>
> And, good luck with your Euphoria programming!
>
> My bumper sticker: "I brake for LED's"
>
Hi,
I have a lot to catch up on, but have been strictly focused on the testing side
of things. I will be interested if you do some of these things you've mentioned:
Windows version, linking to your Scientific Calculator, higher-order math, and
the safe power function. The latter issue still seems to me to be a big drag,
because the overflow problem is not limited to the power function itself.
It has occured to me that not only would a GA Math type of program be good as an
illustration of OOP (the math beings seem a natural for a class of entity), but
also it should be a good program to illustrate threads programming, such that the
formula searches operate in parallel and the lesser threads wither away when one
is successful. Also, probably just for research, (and this would be advanced
indeed), many formulas are a string of "problem subsets" that could be sent out
for quick partial solution and joined up for a final one.
Some of the fancier things I've tried recently have had very mixed results, and
I have nothing to offer at the moment. Onward...
--Quark
