[cells-devel] kickstart (fixed)

[Ken Tilton]

OK, I will look at this tomorrow, working on getting out Cells3 and
Celtk tonight. Some notes below...

On 3/15/06, momerath <michael at guildsoftware.com> wrote:
> Wow that was weird:)  I used the google toolbar spellchecker right
> before sending, and it acted a bit odd, so I checked the sent copy and
> saw that it had left all the spellchecker formatting in the message!
> Here it is as plain text. There are still some extraneous spaces, but
> I don't think they'll make it hard to read, so...
>
> Thanks for getting back to me.  I was beginning to wonder which of the
> 5 ways to interpret the silence :) I think it must be in the genes: (
> http://en.wikipedia.org/wiki/Warnock's_Dilemma)
>
> Anyway, here is what  I've got:
>
> ( defmodel cargo-hold ()
>   (ship-owner capacity
>    ;; a set of cargo-types
>    (types :cell t : initarg :types
>           : initform nil)

A while ago I changed the default on :cell from nil to t since I found
I almost never said :cell nil. You cannot setf a cell unless it is
initialzed to be an input (c-input or c-in), so at least add :cell nil
to the non-cell slots.

>    ;; cargo-type -> quantity
>    (quantities :cell t : initarg :quantities
>                : initform (make-hash-table))))

Note that this cell is initialized with a non-cell value. That's OK,
but nothing will get triggered as you /mutate/ the hashtable contents.
So you either do not want this to be a Cell, or you need to use
something like a list and then specify 'equal as the "changed" test (I
use that so rarely I will have to look it up for you when I have
time!).

>
> ( defmodel cargo ()
>   ;; a type-id, name and the number of
>   ;; cargo-hold units it takes up (1-3)
>   (type name volume
>    ;; the character-id of the owner of
>    ;; the cargo-hold unless cargo is spaced
>    (holder :cell t : initarg :holder
>            : initform (c-in nil) : accessor holder)

Holder? What is that? if the comment above applies, I still do not get it.

>
>    ( auth-list :cell t : initarg : auth-list
>               : initform nil : accessor  auth-list)
>    (recipient :cell t : initarg :recipient
>               : initform nil : accessor recipient)
>    (stolen :cell t : initarg :stolen
>            : initform (c? (when (member (^holder)
>                                        (^ auth-list))
>                            t))

You could just say (member ....). And I think you meant (not (member...))

>            : accessor stolen)
>    (spaced :cell t : initarg :spaced
>            : initform (c? (when holder t))
>            : accessor spaced)

You could just say (c? (^holder)) since this is not scheme. And if it
really is always this simple (maybe not?), then you could just as
easily say:

(defun spaced (x) (holder x))

ie, Do not use Cells unnecessarily. But I am guessing this will get
more complicated, if so never mind. :)

>    (delivered :cell t : initarg :delivered
>               : initform (c? (when ( eql (^holder)
>                                        (^recipient))
>                               t))

Again, this is not Scheme. But maybe you find that more readable?

>               : accessor delivered)))
>
>
> The first thing you'll probably notice is that there is no mechanism
> for the cargo-holds to actually "contain" cargo objects.  I know I
> could do as the "summer" example of the cell-basics doc does, and push
> them onto a list,

My first question will be, What is "them"? ie, How exactly do things
happen in this game? Maybe a player types "Allocate <qty> <cargo> to
<ship> in hold <hold>" and then away we go? Anyway, let me address
this point:

> and recalculate based on the whole list every time
> it changes, but  I was hoping for something more elegant and
> efficient.

I understand. It is a common problem. A stock changes price, and an
index must be recalculated. Why recalculate the whole index when a
little Algebra can let the price change even if weighted be used to
compute a delta in the index.

(a) We can definitely make this more elegant (possibly using synapses) but...
(b) Let's defer this optimization a while since it is an advanced topic

>  Only one entry in the quantities hash needs to change when
> an item is added for instance.  I thought of having in and out slots
> (set the slot to a cargo object to add or remove; the other slots do
> their thing and then clear the in/out slot), but that seems ugly and I
> wasn't even sure how to pull it off.

That is how another Cells user handled such a problem. You can make
the slot clear itself after processing by specifying:

     (in :cell :ephemeral ....)

But I have a feeling you will want instead to simply push a new
"allocation" instance onto a list of allocations of the cargo and
handle the update of the hold by having an observer forward the new
info to the concerned ship via SETF, at which point the holds of the
ship can check to see if it was for them. Or the observer can go
straight to the hold. We'll work something out clean as well as
efficient. For now please try a pure declarative approach. the
computation of the stock index simply recalculated the whole index on
every relevant trade and was able to keep up with realtime, realworld
trading.


>
> And then there is the whole thing with cargo-sets which is closer to
> what I'd like to do with Cells on the larger scale.  Basically what I
> want is to have a large number of sets and their unions/intersections
> efficiently accessible anywhere in my code- stuff like "all characters
> of faction X in sector Y carrying at least one Z in their cargo hold.

That sounds like an adhoc query. :) But I think you are talking about
groups known beforehand. I have some tricks in mind for that. One has
Cells recompute certain gross cross-sections as things happen, then
queries can look at relatively few instances, still doing some of the
work but not so much as to kill performance. The key is granularity
and having the right partial aggregates computed by Cells.

>
> I hope this makes my level of understanding more clear.  I think I'm
> probably more prepared for the paradigm shift than most, owing, no
> doubt, to my long infatuation with Ted Nelson's  ZigZag.

Off to Google I go. :)

ken