It is a very pleasant surprise that you remember my interest in your
project. I am indeed reworking my C# code to keep in sync with ECJ as it
continues to mature. I'm mostly done with v25 but there are remaining
issues, newly introduced.

The boxing issue is miniscule compared to the conversion of EJML for some of
the new EDA stuff! Sheesh, imagine converting and maintaining that external
gem! The closest I can come to it without tackling yet another major
longevity loss is parlaying something like this:

I'll worry about that later. 

In the meantime, I've come across a few problems with the NEAT
implementation, though some potential problems already seem to be commented
with warnings (special thanks to Ermo Wei). 

I can run CartPole and it gives the "disconnected output" every time
(something about that "while" loop). 
I can run the XOR sample and it sometimes does fine, other times failing
because "best" is null (not checking).

I am absolutely thrilled about your new grant and I look forward to much FUN
tracking and hopefully contributing to ECJ from afar. LONG LIVE ECJ and your

Best Regards,
Ben Stabile
[log in to unmask]

-----Original Message-----
From: ECJ Evolutionary Computation Toolkit
[mailto:[log in to unmask]] On Behalf Of Sean Luke
Sent: Saturday, November 11, 2017 4:15 PM
To: [log in to unmask]
Subject: Re: IntBag Motivation

We needed a way to store integers in an extensible array to keep track of
indexes of parents.  And boxing and unboxing is costly.  You could just do
boxing in the C# implementation.

Ben, we should keep you more in the loop as we make modifications to ECJ 25
and (coming) 26, since I know you've been working to keep your C# version up
to date.


On Nov 11, 2017, at 4:08 PM, Ben Stabile <[log in to unmask]> wrote:

> What is the motivation for adding IntBag and DoubleBag to ECJ v25? 
> I maintain a C# fork and I am not sure why they are needed?
> Is it simply a convenient way to achieve "Boxing" and "Unboxing" of value
types to and from the heap?