Re: The "evolution" of GA Math
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"
|
Not Categorized, Please Help
|
|
