Re: [Swarm-Support] development priorities (was Re: Membership in Swarm Developmen Group)

[glen e. p. ropella]

Marcus G. Daniels wrote:
> It's a simple matter to control foreign code from R.  Of the hundreds of
> contributed packages for R, many of them physically include compiled C++
> and Fortran.

It's a simple matter?  So, if I polled the community, how many of them
do you think could do it?  If it's simple, then the majority of them
could do it, correct?

> R can run MPI codes, or SOAP (RPCs over http/XML), and
> so on.   The point is to leverage the expertise of people that know
> actually know about these algorithms.

I agree with that.  The point I don't agree with is your continued
insistence that the current Swarm codebase is useful.  If I were going
to integrate R into a simulation or integrate a simulation into R, I
would not use Swarm.  It's as simple as that.  And I believe that other
users have similar attitudes.

> Search:  iterating over a set.  Evolution:  removing bad objects from a
> set and reproducing good ones.
> Fitness evaluation:  Evaluating a function on a set of objects.   
> Optimization: acting on that function.
> Yep, you can do those things in R.

Now you're just being silly.  It's just more of the same intimidation
tactic you've used to drive away all Swarm's user base.

> Like, say, a Swarm model written in Java?

There is no such thing as a Swarm model written in Java.  A Swarm model
uses the Swarm scheduler, which is written in Objective-C.

>> I agree that an embeddable simulator would be a good thing.  And perhaps
>> that's the direction the SDG should take... I don't know.  But, I do
>> know that it's not feasible to embed the current Swarm codebase.  Hence
>> such a requirement would, again, argue against wasting more money adding
>> new features or targets (like the Cell) to the current code.
>>   
> As a matter of fact you are completely wrong about this.

No, I'm not wrong.  But, it is in your best interest to convince me (and
others) that I am wrong.

> It is entirely feasible with the current codebase.

"Feasible" is not synonymous with "possible".  It is certainly
_possible_ to embed Swarm in all sorts of things.  But, it is not
feasible for most projects because a) they lack the technical expertise
and/or 2) other requirements (like running simulations in a jvm started
from a web browser) conflict with Swarm's architecture.

> Swarm runs fine
> inside a Java virtual machine -- it's a DLL and a jar file.

DLLs don't run inside the jvm.  Saying so won't make it true.

> That's it. 
> It's relatively easy to retarget at this point for other environments.  
> It generates documentation from itself as well as interface definitions.
>  It can generate the IDL for the Cell processor, which is virtually
> identical to the COM IDL that was started for Mozilla.   Swarm is
> embeddable.   That's a fact.

It is possible but usually infeasible to embed it.  That's a fact.

> No, the question is what new and interesting things could only be done
> by starting from scratch.  One is runtime code generation, which would
> be useful for the performance of evolutionary models (or inferences
> about possible models).

No.  That's not the question.  The question is "How does the SDG best
accomplish its mission?"  The SDG was not formed to do innovative
computer science or systems engineering.  It was formed to support ABMers.

-- 
glen e. p. ropella, 971-219-3846, http://tempusdictum.com
Remember that there is nothing stable in human affairs; therefore avoid
undue elation in prosperity, or undue depression in adversity. -- Socrates