Re: Suggestions for Maintaining "Object" State?
- To: mathgroup at smc.vnet.net
- Subject: [mg78474] Re: Suggestions for Maintaining "Object" State?
- From: Hannes Kessler <HannesKessler at hushmail.com>
- Date: Mon, 2 Jul 2007 07:00:00 -0400 (EDT)
- References: <f5vsk1$l46$1@smc.vnet.net><f62kka$bv1$1@smc.vnet.net>
Hello Carey,
a comment regarding your ice example: In case you always have a
single ice object with its temperature and other attributes I would
attach the properties and functions directly to the ice object instead
of creating a "cookie" (thisIce) either straightforward with Unique as
in David Baleys contribution or with the module approach as in my
previous sphere example. Only if you think of several ice objects with
different states the cookie approach is appropriate.
On the other hand, if you consider several aggregate states of perhaps
several materials, the "cookie" approach is a good idea:
solidQ[_]:=False;
liquidQ[_]:=False;
material[initialTemp_, initialMass_, AggregateState->type:("solid" |
"liquid"), Material->name:("H2O"|"mercury"|...)]:=
Module[{thisMaterial},
Switch[type,
"liquid", liquidQ[thisMaterial]=True,
"solid", solidQ[thisMaterial]=True];
material[thisMaterial] = name;
...
thisMaterial];
The advantage is, you can define different functions for different
aggregate states and materials:
f[mat_?solidQ]:=Module[{...}, ...]; (*do something with a solid*)
f[mat_?liquidQ]:=Module[{...}, ...]; (*do something with a liquid*)
g[mat_]/;material[mat]=="H2O":=Module[{...}, ...]; (*do something with
frozen or liquid water*)
g[mat_]/;material[mat]=="mercury":=Module[{...}, ...]; (*do something
with frozen or liquid mercury*)
Regarding the other points I agree with David Baley, particularly with
his advice to take care of cleanup and his useful tip to use \[Breve]
(type it in the frontend as esc-bv-esc).
Regards,
Hannes
On 30 Jun., 12:13, "Carey Sublette" <carey... at earthling.net> wrote:
> Thanks to all for replying!
>
> I have combined the replies so that I can take care of responding with one
> go.
>
>
>
> "dh" <d... at metrohm.ch> wrote in messagenews:f602rb$sh9$1 at smc.vnet.net...
>
> > Hi Carey,
>
> > you could try to put all the states into a function. E.g.:
>
> > assume 2 objects a and b:
>
> > a={1,2};
>
> > b={4,3,2,1};
>
> > states[a]=a;
>
> > states[b]=b;
>
> > states[x] will then return the state of x.
>
> > hope this helps, Daniel
>
> Thanks Daniel, this got me part of the way there. Hannes, below, gave built
> on this idea for a more complete solution approach.
>
> > In version 6 there is a very interesting tutorial that you can see by
> > typing
> > tutorial/AdvancedDynamicFunctionality into the Documentation Center
> > window.
> > Local variables defined within DynamicModule have their states preserved,
> > because they are stored (in a hidden way) in the output cell created by
> > DynamicModule. Although I haven't yet used this behaviour to do
> > simulations
> > of the sort that you describe, it looks to me as if DynamicModule may well
> > give you the functionality you want.
>
> > Steve Luttrell
> > West Malvern, UK
>
> Hi Steve: I looked into this, but it only seems designed to support UI
> functions. It holds evaluations, permanently it seems, if there is no UI
> component present, and since the state is kept in the front end, not the
> kernel, it suggests performance would be not so great. I fiddled with it
> awhile, but could not get it to do anything useful.
>
> "Hannes Kessler" <HannesKess... at hushmail.com> wrote in message
>
> news:f62kka$bv1$1 at smc.vnet.net...
>
> > Hello Carey,
>
> > one possibility you could use is an object-oriented approach what you
> > perhaps have in mind with "using UpValues or Tags to assign object
> > state to symbols". Here are two links where you can download packages
> > and examples:
>
> >http://library.wolfram.com/infocenter/Conferences/5773/
> >http://library.wolfram.com/infocenter/Articles/3243/
>
> Thanks Hannes:!
>
> You fleshed out the ideas I was working towards! The techniques you showed
> work great!
>
> Roman Maeder's package looks impressive. It is a bit much to bit off right
> now, but I'll have to study it.
>
> For what it worth, here is the toy problem I implemented using this
> approach. It has an "ice" object that keeps track of its enthalpy, and can
> be examined for its temperature and fraction that is melted.
> In[142]:= ice[mP] = 273;
> ice[CpL] = 4.18;
> ice[CpS] = 2.114;
> ice[heatOfFusion] = 334;
> ice[hMelt] = ice[mP]*ice[CpS];
> ice[hAllMelt] = ice[hMelt] + ice[heatOfFusion];
> ice[initialTemp_, initialMass_] := Module[{thisIce},
> mass[thisIce] = initialMass;
> H[thisIce] = (initialTemp + ice[mP])*ice[CpS]*initialMass // N;
> thisIce
> ]
> In[149]:=
> changeEnergy[i_, heatJ_] := H[i] = H[i] + heatJ;
> getState[i_] := (h = H[i]/mass[i];
> If[h <= ice[hMelt], {(h/ice[CpS]) - ice[mP], 0},
> If[h >= ice[hAllMelt], {ice[mP] + (h - ice[hAllMelt] )/ice[CpL],
> 1}, {ice[mP], (h - ice[hMelt])/ice[heatOfFusion]}]]);
>
> In[151]:= iceCube = ice[-50, 1]
> H[iceCube]
> mass[iceCube]
> getState[iceCube]
> changeEnergy[iceCube, 200];
> H[iceCube]
> getState[iceCube]
> Out[151]= thisIce$4308
> Out[152]= 471.422
> Out[153]= 1
> Out[154]= {-50., 0}
> Out[156]= 671.422
> Out[157]= {273, 0.282335}