Re: What Happens to Garbage in Mathematica?
- To: mathgroup at smc.vnet.net
- Subject: [mg44042] Re: What Happens to Garbage in Mathematica?
- From: "Steven T. Hatton" <hattons at globalsymmetry.com>
- Date: Sun, 19 Oct 2003 01:10:35 -0400 (EDT)
- References: <bm84s2$fug$1@smc.vnet.net> <bmg0nf$e9t$1@smc.vnet.net> <bmj2j5$pqs$1@smc.vnet.net> <bmqqao$rjs$1@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
Olaf Rogalsky wrote:
> Disclaimer: The following statements of mine don't realy express wisdom,
> but
> my partial piece of knowledge, which is an other word for opinion. If
> anyone of you has deeper insight, I would be delighted if you can
> enlighten me, too.
>
> "Steven T. Hatton" wrote:
>> [...] Currently, the only way I know to change
>> the location of a primitive is to create a new one, and assign it to the
>> original variable.
>
> Yes, that is the way how functional programming languages work.
[...]
>. If one then evaluates "i=2", a new
> binding between "i" and an *other*, *new* variable, which holds the value
> "2" will be established.
>
> Note 1: Out[1] still references the first variable, and therefore the
> allocated
> memory for the first variable is not freed.
There are times when strange things happen after changing the internals of a
function which seem to indicate a variable other than the intended one is
being accessed. If I kill the kernel and reevaluate the function, it then
works. I don't have a specific example, but it is not all that uncommon,
especially if I fail to clear all variable in use. The goes beyond simply
reading a variable I expect to be in scope, but neglected to clear.
> Note 2: Most functional languages are not puristic, which means, that they
> have
> some way to reassign a variable. But I don't know, if Mathematica
> has.
>
This has an interesting consequence which, if I'm understanding things
correctly, is relevant to my current situation. I am trying to create a
generic way of producing graphical representations of coordinate mapping
wherein the coordinate curve frequencies are lower than the point density
along the curves. IOW, I'm trying to smoothe out the curves.
I originally thought it would be a good idea to share the points between
curves where they intersect. There may still be advantages to doing so,
but they don't include memory conservation. If I have the following:
p1={0,0,0};
p2={1,1,1};
p3={2,2,2};
p4={2,0,0};
p5={0,2,2};
Show[Graphics3D[
Join[{Red,PointSize[0.02],Line[{p1,p2,p3}],Line[{p4,p2,p5}]},
Point/@{p1,p2,p3,p4,p5}]]]
There will be memory allocated for each usage of the coordinate values. For
example, mathematically, p2 is shared by both lines, but the values are
reproduced for each primitive. Is this the way you understand the
situation?
> This is the first rule, constisting of "pattern :> replacement". The
> pattern matches any occurance of Polygon[<anything>], and gives this
> subexpression the name "poly". Since the only valid agrument to the
> Polygon function is a list of coordinates, for every math "poly" will be
> (temporary) bound to Polygon[<list of coordinates>].
[...]
This seems to mean shape could be a list of different primitives, and all
would be transformed by the appropreate rule. Is this correct?
>
>> function (transformation rule?). It pulls the points out of the shape
>> and transforms them using the rotation matrix. It would seem it places
>> the
>> results in a list with a head of the same type as the shape. What it
>> clearly doesn't do is modify the 'members' or elements of the original
>
> Yes, it returns a new copy. Again, consider the following code snipped:
> "a=1; b=a; a=2". The first "=" does not assign "a" to the value "1", but
> bounds "a" to a newly created variable which holds "1". The second "="
> bounds "b" to the same (identical) variable as "a". The third "="
> establishes a new binding for "a" to a new variable, which holds "2". The
> old variable of "a" is unchanged and "b" still is bound to that variable.
"a" is an identifier, which has a location in memory containing the
character code for 'a', as well as either the value assigned to it, or the
address of a memory location holding the value. From what you said, I have
conclude that if I have the following:
reallyLongVariableName=1;
a=reallyLongVariableName;
reallyLongVariableName=2;
b=reallyLongVariableName;
reallyLongVariableName=3;
c=reallyLongVariableName;,
a,b and c will reference a place in memory holding the string
"reallyLongVariableName", as well as the values 1,2 and 3 respectively. Is
this correct?
>>
>> It would seem that if I were to assign the return value of RotateShape[]
>> to lna like this: lna = RotateShape[ln, 2, 2, 2], I would create a dirty
>> chunk of memory which will require housekeeping before it can be reused.
>
> I don't understand you here.
If I have a complex shape which is transformed by the above rotation
function, the location of the original coordinate values will not be
available until garbage collection is run. Correct?
[...]
> There is an overhead to this, but don't worry too much. Mathematica is
> an interpreted language, which does a lot of symbolic manipulations.
> E.g. in your problem, the pattern matching propably is much more expensive
> than the memory management.
I had an interesting experience while working with my own transformation
functions. I noticed that each frame of my animation took progressively
longer than the previous one, but the operations in each frame were
identical. What I discovered was the values of the rotation matrices were
remaning symbolic expression which grew more complex with each iteration
since they resulted from an application of the transfromations to the
previous frame's results. Once I put in //Ns in the apropriate places, the
frames all processed in equal (and _much_ shorter times.
>
> Olaf Rogalsky
>
Steven
--
"Philosophy is written in this grand book, The Universe. ... But the book
cannot be understood unless one first learns to comprehend the language...
in which it is written. It is written in the language of mathematics, ...;
without which wanders about in a dark labyrinth." The Lion of Gaul