## ECJ-INTEREST-L@LISTSERV.GMU.EDU

 Options: Use Monospaced Font Show Text Part by Default Show All Mail Headers Message: [<< First] [< Prev] [Next >] [Last >>] Topic: [<< First] [< Prev] [Next >] [Last >>] Author: [<< First] [< Prev] [Next >] [Last >>]

```On Jul 24, 2005, at 12:32 PM, Steve Butcher (Steve-O) wrote:

> I looked over tutorial4 which is a simple regression on:
>
> x*x*y + x*y + y
>
> Now, if I try to use:
>
> x^4 + x^3 + x^2 + x

tutorial4 uses this value only for example purposes.  Try
ec/app/regression/noerc.params to get the Koza function you're hoping
for (with the appropriate function set).

> 1) Is this typical? Using that function set, is the quartic difficult
> to find? If I use just X, +, *, I get results as quickly as tutorial4
> but that seems like stacking the deck. I only have to add - to the
> function set to make the problem so far unsolved.

Quartic may be one in five or one in ten.

> 2) What functions need to be protected in Java that didn't need to be
> protected in LISP or need additional protections? What protections
> are reasonable?

Java's math functions have the same protection requirements as Lisp's
functions.  But even so there are certain ways of getting NaN anyway.
For example, if you used an expression which produces infinity, and
then ran that through sin().  So you have to check for NaN anyway.

> Initial investigation suggests that Math.exp() goes to infinity very
> quickly...as soon as Math.exp( 1000).  What would be a reasonable
> "protection" on exp? But I'm not sure what would be giving me a NaN
> result. cos and sin should be defined over everything (although my
> trig is a bit rusty).

The simpler solution is to set NaN and infinity to very bad function
sets.  They tend to get weeded out rapidly.

Sean
```