I am currently working on sorting out some bad mistakes that I made
early in the design of the Monte Carlo simulation I work on and use.
I'm increasingly needing extensibility and flexibility so I can change
energy models and the like. Common Lisp has been very helpful for
this, but I'm increasingly thinking that there is additional
functionality that make things work even better.
ATM, I use a couple classes for my work. One is a MOVE-TABLE class
(which I subclass as necessary) that tracks the moves the MC
simulation can make, and another is a STATE class (which I also
subclass), which contains the state the system is in. Both of these
structures are pretty expensive to initialize, and I usually only have
to do the expensive part during the first run on any specific system
I'm simulating.
I have generic functions, RESET-MOVE-TABLE and RESET-STATE that I use
to do the cheap part, and do the expensive part in :AFTER methods on
INITIALIZE-INSTANCE, so they get done automatically. However, I see in
the CLHS that there's a function called REINITIALIZE-INSTANCE that
sounds like it might or might not be exactly what I want.
Also, is there any reason I oughtn't do something like this:
(defmethod stuff-i-do-often ((foo foo))
(some-stuff foo)
(some-other-stuff foo))
(defmethod initialize-instance :after ((foo foo))
(stuff-i-need-to-do-once foo)
(stuff-i-do-often foo))
and then call STUFF-I-DO-OFTEN whenever I need it? It feels "wrong"
for some reason, but I can't put my finger on why, and maybe it's a
common way of doing things.
TIA,
Pillsy
From: Ken Tilton
Subject: Re: Using MAKE-INSTANCE, INITIALIZE-INSTANCE and REINITIALIZE-INSTANCE
Date:
Message-ID: <Mf1Yi.277$vC5.154@newsfe10.lga>
Pillsy wrote:
> I am currently working on sorting out some bad mistakes that I made
> early in the design of the Monte Carlo simulation I work on and use.
> I'm increasingly needing extensibility and flexibility so I can change
> energy models and the like. Common Lisp has been very helpful for
> this, but I'm increasingly thinking that there is additional
> functionality that make things work even better.
>
> ATM, I use a couple classes for my work. One is a MOVE-TABLE class
> (which I subclass as necessary) that tracks the moves the MC
> simulation can make, and another is a STATE class (which I also
> subclass), which contains the state the system is in. Both of these
> structures are pretty expensive to initialize, and I usually only have
> to do the expensive part during the first run on any specific system
> I'm simulating.
>
> I have generic functions, RESET-MOVE-TABLE and RESET-STATE that I use
> to do the cheap part, and do the expensive part in :AFTER methods on
> INITIALIZE-INSTANCE, so they get done automatically. However, I see in
> the CLHS that there's a function called REINITIALIZE-INSTANCE that
> sounds like it might or might not be exactly what I want.
I am thinking not, but if so note that shared-initialize is where you
want to put any porcessing required for init/re-init.
>
> Also, is there any reason I oughtn't do something like this:
>
> (defmethod stuff-i-do-often ((foo foo))
> (some-stuff foo)
> (some-other-stuff foo))
>
> (defmethod initialize-instance :after ((foo foo))
> (stuff-i-need-to-do-once foo)
> (stuff-i-do-often foo))
>
> and then call STUFF-I-DO-OFTEN whenever I need it? It feels "wrong"
> for some reason, but I can't put my finger on why, and maybe it's a
> common way of doing things.
I think it feels wrong because stuff-i-do-often seems not to be part of
initialization per se, you are just putting it there "to make sure it
gets done", which is more about paranoia than clean design. My guess is
that stuff-i-do-often is in fact (the first) part of some other process,
and that you will or should have it there anyway.
Hmmm, I once saw someone reintializing some reusable state /after/ the
process that used it "so it would be ready the next time". I asked him
what would be wrong with initializing it at the beginning of the
process, he said "good point". The other way around you have to worry
about whether every exit ramp from the process includes the
reinitialization. If you want something in a certain condition at the
beginning of a process, put the code that makes it so at the beginning
of the process. Just guessing of course at what you might be up to.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Nov 6, 12:10 pm, Ken Tilton <···········@optonline.net> wrote:
> Pillsy wrote:
> > It feels "wrong" for some reason, but I can't put my finger on why,
> > and maybe it's a common way of doing things.
> I think it feels wrong because stuff-i-do-often seems not to be part of
> initialization per se, you are just putting it there "to make sure it
> gets done", which is more about paranoia than clean design. My guess is
> that stuff-i-do-often is in fact (the first) part of some other process,
> and that you will or should have it there anyway.
You may be right about this. It's also possible (and something that
had occurred to me while going through some of my recent fixing) that
the way I've decided what goes in which class may be wrong. E.g.,
maybe I should have a MODEL class (which is all the stuff that doesn't
change from run to run, or over the course of the run, like the RNA
sequence I'm looking at or the temperature) and STATE class (which
contains stuff that does change, ranging from the moves I've done so
far to which bases are paired together right now) instead.
Still, though, some of the mutable structures aren't something I
really want to allocate every time if I can avoid it; they feature
largish arrays and hash tables, and I already cons more than I'd
really like.
It's something to think about.
Cheers,
Pillsy
Pillsy <·········@gmail.com> writes:
> On Nov 6, 12:10 pm, Ken Tilton <···········@optonline.net> wrote:
>> Pillsy wrote:
>
>> > It feels "wrong" for some reason, but I can't put my finger on why,
>> > and maybe it's a common way of doing things.
>
>> I think it feels wrong because stuff-i-do-often seems not to be part of
>> initialization per se, you are just putting it there "to make sure it
>> gets done", which is more about paranoia than clean design. My guess is
>> that stuff-i-do-often is in fact (the first) part of some other process,
>> and that you will or should have it there anyway.
>
> You may be right about this. It's also possible (and something that
> had occurred to me while going through some of my recent fixing) that
> the way I've decided what goes in which class may be wrong. E.g.,
> maybe I should have a MODEL class (which is all the stuff that doesn't
> change from run to run, or over the course of the run, like the RNA
> sequence I'm looking at or the temperature) and STATE class (which
> contains stuff that does change, ranging from the moves I've done so
> far to which bases are paired together right now) instead.
>
> Still, though, some of the mutable structures aren't something I
> really want to allocate every time if I can avoid it; they feature
> largish arrays and hash tables, and I already cons more than I'd
> really like.
>
> It's something to think about.
To me this sounds a lot like
"I have a rule in mind like when I am accessing some data and they
aren't initialized they should somehow recognize this and just init
themselves then."
I have become used to do this using Kenny's Cells. Clean model and
rules concept, easy to program, reliable. For me it's really a
"Remember the times when we had to do without Cells?" story
meanwhile.
Hth.
Frank
--
Frank Goenninger
frgo(at)mac(dot)com
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."