Re: [swarm-hackers] Still learning the framework...

On Thu, Nov 19, 2009 at 6:29 PM, Scott Christley <address@hidden> wrote:

This is a general issue with modeling and something I had to deal with. In my own models, I don't use the Swarm Grid2d classes, instead I've created my own set of Grid classes with a controller type object that can manage a whole set of grids. Why? Because in my biological models, I often have multiple molecular species, cells, etc. that all live in grid space. When you want to work with a grid, just get it from the controller object.

I could go with two designs. One, where I have a single grid but each entry in the grid is a complicated object that contains all of my biological things. The other design is to have multiple grids with each grid responsible for a single biological thing. I went with the latter design because I also need to deal with multiple spatial scales, so biological cells live on a grid, but that grid is on at a different spatial scale then the molecular species which also live on a grid but at a smaller spatial scale.

I've been meaning to release my framework of classes as open source, I just haven't done it yet. Most of it is all bio oriented.

In Heatbugs you have two "things" that live on a grid, the bugs themselves and the heat, thus the two grids.

Scott

On Nov 18, 2009, at 10:50 PM, Nima Talebi wrote:

Yeah - I have done that too, which is why I said I'll probably get rid of the forwarders. I'm still largely in my experimental phase, just trying ideas out and seeing how they go.

The dual-layer world (Grid2d + Diffuse2d) has kept me confused for a while. I understand it ~ 30% now, which is better than ~1% last week, but still quite some work to do before it becomes natural to me.

On Thu, Nov 19, 2009 at 5:21 PM, Scott Christley <address@hidden> wrote:

That seems pretty heavy and complicated, forwarding messages... Is it worth it?

Why not add a -getGrid method to HeatSpace, then you can get the grid and call it directly without all the overhead of forwarding.

On Nov 18, 2009, at 10:11 PM, Nima Talebi wrote:

Closing off this "Ticket"...

Why?

Subclassing is your friend in object-oriented programming. HeatSpace is already a subclass of Grid2d, actually it is a subclass of Diffuse2d which is a subclass of Grid2d, so maybe you just want to enhance the HeatSpace class?

My final fix was this...

I maintain 1 "world" object, and that takes care of and hides "details". By details, I am talking about...

@interface HeatSpace:Diffuse2d {
   Grid2d *grid;
}

...that is - the 1 representation of the world, handles and hides the complexities of the Grid2d, as well as the Diffuse2d. I inherited from 1, and implemented the other as a data member.

Optionaly, (but I think I may take this out as I prefer these things to be explicite), I implemented...

- (void)forwardInvocation:(NSInvocation*)i;
- (NSMethodSignature *)methodSignatureForSelector:(SEL)s;

...which forwards messages that the world (Diffuse2d) doesn't understand, over to the Grid2d data member.

#pragma mark -
- (void)forwardInvocation:(NSInvocation*)i {

SEL s = [i selector];

#if ((DEBUG != 0) || (DEBUG_SINGLE_AGENT !=0 ))
NSLog(@"SEL: %@", s);
#endif

if([grid respondsToSelector:s]) [i invokeWithTarget:grid];

else {
[self doesNotRecognizeSelector:s];

assert(1==0);
}
}

- (NSMethodSignature *)methodSignatureForSelector:(SEL)s {

NSMethodSignature* sig = [super methodSignatureForSelector:s];
if(sig == nil)
sig = [grid methodSignatureForSelector:s];

#if ((DEBUG != 0) || (DEBUG_SINGLE_AGENT !=0 ))

NSLog(@"SEL: %@", s);
#endif

assert(sig);
return sig;

}

Thoughts?

Nima

On Tue, Nov 17, 2009 at 7:47 PM, Nima Talebi <address@hidden> wrote:

Yes, it looks like I've completely confused Discrete2d, and Diffuse2d, they're unrelated, and both required, and I've tried to magically merge them. Back to work.

On Tue, Nov 17, 2009 at 7:35 PM, Nima Talebi <address@hidden> wrote:

Err... disregard this particular and embarrassing email. I can't spell.

I still can't figure out why I'm getting the warnings though.

Nima

On Tue, Nov 17, 2009 at 6:52 PM, Nima Talebi <address@hidden> wrote:
Ahh crap, I think this is the problem...

From the source, this is what I was expecting to get....

@interface Diffuse2d: Ca2d <Diffuse2d>
{
  double diffusionConstant;

  double evaporationRate;
}
+ create: aZone setSizeX: (unsigned)x Y: (unsigned)y setDiffusionConstant: (double)d setEvaporationRate: (double)e;
+ createBegin: aZone;
- initializeLattice;

- setDiffusionConstant: (double)d;
- setEvaporationRate: (double)e;
- stepRule;
@end

...and this is what I actually got...

@interface Discrete2d: SwarmObject <Discrete2d>
{
BOOL objectFlag;
@public
unsigned xsize, ysize;
id *lattice;
long *offsets;

}

+ create: (id <Zone>)aZone setSizeX: (unsigned)x Y: (unsigned)y;
- setSizeX: (unsigned)x Y: (unsigned)y;
- createEnd;
- makeOffsets;
- (id *)allocLattice;

- (unsigned)getSizeX;
- (unsigned)getSizeY;

- getObjectAtX: (unsigned)x Y: (unsigned)y;

- (long)getValueAtX: (unsigned)x Y: (unsigned)y;

- putObject: anObject atX: (unsigned)x Y: (unsigned)y;
- putValue: (long)v atX: (unsigned)x Y: (unsigned)y;

- fastFillWithValue: (long)aValue;
- fastFillWithObject: anObj;

- fillWithValue: (long)aValue;
- fillWithObject: anObj;

- setLattice: (id *)lattice;
- (void)setObjectFlag: (BOOL)objectFlag;

- (id *)getLattice;
- (long *)getOffsets;

- copyDiscrete2d: (id <Discrete2d>)a toDiscrete2d: (id <Discrete2d>)b;
- (int)setDiscrete2d: (id <Discrete2d>)a toFile: (const char *)filename;

- hdf5InCreate: hdf5Obj;
- hdf5In: hdf5Obj;
- (void)hdf5OutShallow: hdf5Obj;

- (void)hdf5OutDeep: (id <OutputStream>)hdf5Obj;
- (void)lispOutShallow: (id <OutputStream>)stream;

- (void)lispOutDeep: stream;
@end

...now to figure out why. :/

On Tue, Nov 17, 2009 at 5:29 PM, Nima Talebi <address@hidden> wrote:

Hi Scott, Okay I've taken your advice which has hugely simplified my code, and made things made a little more sense to me...

I now have:

@interface HeatSpace:Grid2d {
HBSize size;
HeatbugsModel *model;

}

...and looking at Grid2d...

@interface Grid2d: Discrete2d <Grid2d>
{
  BOOL overwriteWarnings;
}

...and looking at Discrete2d...

@interface Discrete2d: SwarmObject <Discrete2d>
{
  BOOL objectFlag;
@public
  unsigned xsize, ysize;
  id *lattice;
  long *offsets;

}

...so far, so good.

Now what I don't get is this...

/Users/xerxes/devel/heatbugs/HeatbugsModel.m:127:0 /Users/xerxes/devel/heatbugs/HeatbugsModel.m:127: warning: 'HeatSpace' may not respond to '-setDiffusionConstant:'

/Users/xerxes/devel/heatbugs/HeatbugsModel.m:128:0 /Users/xerxes/devel/heatbugs/HeatbugsModel.m:128: warning: 'HeatSpace' may not respond to '-setEvaporationRate:'

...why not? HeatSpace is a Grid2d, which is a Diffuse2d, which offers those exact methods - what have I done that the inheritance is broken?

Note that the warning is real - and the code does crash - so it's not because I've used forward declarations and not #imported a header file or something silly like that.

I'm almost there though!

Just as a note - I had to set the display of both heatspace display, and heatbug displays to the 1 world (since I merged the Grid2d heatbugDisplay and Discrete2d heatSpaceDisplay into a single class based on our previous discussion.

heatSpaceDisplay = [Value2dDisplay createBegin:[self getZone]];

[heatSpaceDisplay setDiscrete2dToDisplay:[mainModel world]];

[heatSpaceDisplay setDisplayMappingM:DISP_MAP_M C:DISP_MAP_C]; //turn [0,32768) -> [0,64)

heatSpaceDisplay = [heatSpaceDisplay createEnd];

[heatSpaceDisplay updateDisplay];

heatbugDisplay = [Object2dDisplay createBegin:[self getZone]];

[heatbugDisplay setDiscrete2dToDisplay:[mainModel world]];

heatbugDisplay = [heatbugDisplay createEnd];

[heatbugDisplay updateDisplay];

...I'm not sure if that's going to cause a problem.

Nima

On Tue, Nov 17, 2009 at 4:08 PM, Scott Christley <address@hidden> wrote:

On Nov 16, 2009, at 7:32 PM, Nima Talebi wrote:

Hi All,

This bit of code about to be presented is merely a proof-of-concept (POC) for myself in learning the framework, and specifically the memory zoning.

What I have here, is an attempt to create a new "HeatbugsWorld", which hides details such as....

* The fact that it "is-a" Swarm

Why?

* it conforms to Grid2d

Subclassing is your friend in object-oriented programming. HeatSpace is already a subclass of Grid2d, actually it is a subclass of Diffuse2d which is a subclass of Grid2d, so maybe you just want to enhance the HeatSpace class?

...and adds a few utility methods, for example...

@class HeatbugsModel;

@protocol HeatbugsWorld
- (HBLength)width;

- (HBLength)height;
- (HBSize)size;
@end

@interface HeatbugsWorld:Swarm <Grid2d> {
   HBSize size;

}

+ (id)createBegin:(id)aZone withModel:(HeatbugsModel *)m andSize:(HBSize)s;

- (HBLength)width;
- (HBLength)height;
- (HBSize)size;

@end

@implementation HeatbugsWorld

+ (id)createBegin:(id)z withModel:(HeatbugsModel *)m andSize:(HBSize)s {
   HeatbugsWorld *this = [Grid2d create:m setSizeX:(int)s.width Y:(int)s.height];

   /*! Now set up the grid used to represent agent position... */
   this->size = s;
   return self;
}

- (HBLength)width {

   return size.width;
}

- (HBLength)height {
   return size.height;
}

- (HBSize)size {
   return size;

}

@end

...however, that crashes on `[Grid2d create:m setSizeX:(int)s.width Y:(int)s.height];'. The stack & crashlog...

2009-11-17 14:20:40.679 Heatbugs[1157:6807] +[HeatbugsModel allocIVars:]: unrecognized selector sent to class 0xa3b0

2009-11-17 14:20:40.680 Heatbugs[1157:6807] An uncaught exception was raised
2009-11-17 14:20:40.680 Heatbugs[1157:6807] +[HeatbugsModel allocIVars:]: unrecognized selector sent to class 0xa3b0
2009-11-17 14:20:40.682 Heatbugs[1157:6807] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '+[HeatbugsModel allocIVars:]: unrecognized selector sent to class 0xa3b0'

*** Call stack at first throw:
(
0 CoreFoundation 0x95a1358a __raiseError + 410
1 libobjc.A.dylib 0x93460f49 objc_exception_throw + 56

2 CoreFoundation 0x95a5fa9b +[NSObject(NSObject) doesNotRecognizeSelector:] + 187

3 CoreFoundation 0x959bb026 ___forwarding___ + 950
4 CoreFoundation 0x959babf2 _CF_forwarding_prep_0 + 50
5 Swarm 0x000826bb +[Grid2d createBegin:] + 59

6 Swarm 0x00080b3c +[Discrete2d create:setSizeX:Y:] + 55
7 Swarm 0x0008267a +[Grid2d create:setSizeX:Y:] + 73
8 Heatbugs 0x00006e57 +[HeatbugsWorld createBegin:withModel:andSize:] + 55

9 Heatbugs 0x00003cf2 +[HeatbugsModel heatbugModelWithAZone:] + 338

10 Swarm 0x0001e726 +[CreateDrop_s create:] + 41
11 Heatbugs 0x00003221 -[HeatbugsGUI buildObjects] + 145
12 Swarm 0x000860e6 -[OpenStepSwarmController newSimulation:] + 211

13 Foundation 0x98c90964 -[NSThread main] + 45
14 Foundation 0x98c90914 __NSThread__main__ + 1499
15 libSystem.B.dylib 0x94800f39 _pthread_start + 345

16 libSystem.B.dylib 0x94800dbe thread_start + 34
)

1. Scott - based on what you said regarding zones - quite correctly - even a [HeatbugsWorld alloc] would crash - so I've removed all such methods and functions, but now I need to find a way of encapsulating swarm-framework implementation details from the user-app - mostly just to make sure that I can do it - and that I have a good understanding of how it all works.

Yep, don't do it. Use the +create methods like everybody else.

2. I'm also a little confused with protocols and classes that share the same name - such as Grid2d - is that how things should be done? Is that good practice - should I be doing it? :)

Don't say an object conforms to a protocol, like Grid2D unless it actually does, and your class doesn't. If you want to add functionality then you should subclass Grid2D, that's what subclassing is for...

3. Finally, notice that the [Grid2d create:setSizeX:Y:] takes no Zone info, could that be related to my problem? I did try [[Grid2d createBegin:z] ...] but had no luck there either.

That means it uses the default global zone. You really don't need to get involved in using zones, just let the framework use the default.

4. Sorry for the unlimited supply of newb-spam.

Nima

_______________________________________________
swarm-hackers mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/swarm-hackers

_______________________________________________
swarm-hackers mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/swarm-hackers

--
Nima Talebi
web: http://ai.autonomy.net.au/People/Nima
gpg: B51D 1F18 D8E2 B702 B027 23A4 E06B DAC1 BE70 ADC0

--
Nima Talebi
web: http://ai.autonomy.net.au/People/Nima
gpg: B51D 1F18 D8E2 B702 B027 23A4 E06B DAC1 BE70 ADC0

--
Nima Talebi
web: http://ai.autonomy.net.au/People/Nima
gpg: B51D 1F18 D8E2 B702 B027 23A4 E06B DAC1 BE70 ADC0

--
Nima Talebi
web: http://ai.autonomy.net.au/People/Nima
gpg: B51D 1F18 D8E2 B702 B027 23A4 E06B DAC1 BE70 ADC0

--
Nima Talebi
web: http://ai.autonomy.net.au/People/Nima
gpg: B51D 1F18 D8E2 B702 B027 23A4 E06B DAC1 BE70 ADC0

_______________________________________________
swarm-hackers mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/swarm-hackers

_______________________________________________
swarm-hackers mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/swarm-hackers

--
Nima Talebi
web: http://ai.autonomy.net.au/People/Nima
gpg: B51D 1F18 D8E2 B702 B027 23A4 E06B DAC1 BE70 ADC0

_______________________________________________
swarm-hackers mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/swarm-hackers

_______________________________________________
swarm-hackers mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/swarm-hackers

--
Nima Talebi
web: http://ai.autonomy.net.au/People/Nima
gpg: B51D 1F18 D8E2 B702 B027 23A4 E06B DAC1 BE70 ADC0

From:	Nima Talebi
Subject:	Re: [swarm-hackers] Still learning the framework...
Date:	Thu, 19 Nov 2009 19:51:39 +1100