Re: Re: Problem with evaluation of delayed rules
- To: mathgroup at smc.vnet.net
- Subject: [mg21731] Re: [mg21678] Re: Problem with evaluation of delayed rules
- From: Hartmut Wolf <hwolf at debis.com>
- Date: Wed, 26 Jan 2000 03:45:32 -0500 (EST)
- Organization: debis Systemhaus
- References: <85mkef$1og@smc.vnet.net> <200001220752.CAA11559@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
Eckhard Hennig schrieb:
>
> Thanks to everyone who responded to my message regarding evaluation of
> delayed rules in held expressions. Unfortunately, none of the proposed
> solutions fully meets my requirements, either because Condition 1 (no
> specific solution for "If") was not taken into account or because it doesn't
> work for my particular application. What I posted was just a simple example,
> and the actual problem is indeed a bit more complicated:
>
> Let "equations" denote a list of mathematical expressions involving "If"
> statements (or other control statements with HoldXXX attribute). In
> "equations", I want to apply the following substitutions. All delayed rules
> must be evaluated as soon as they apply because the variable "mnavar" (a
> list of symbols) is local to a Block.
>
> equations /.
> { Derivative[_][_][x_ /; x =!= $TimeVariable] -> 0,
> Derivative[k_][Voltage[a_, b_, _]][$TimeVariable]
> | Derivative[k_][Voltage[a_, b_, _]] :>
> D[mnavar[[a]] - mnavar[[b]], {$TimeVariable, k}],
> Voltage[a_, b_, _] :> mnavar[[a]] - mnavar[[b]],
> Derivative[k_][Current[__, i_]][$TimeVariable]
> | Derivative[k_][Current[__, i_]] :>
> D[BranchCurrentIdentifier[i], {$TimeVariable, k}],
> Current[__, i_] :> BranchCurrentIdentifier[i] }
>
> Several responses to my original message suggested using a "Cases" statement
> to build up a list of evaluated replacement rules dynamically and then apply
> this list to the expression. This solution has two disadvantages: it needs
> more memory and it does not work for more than one delayed rule at a time,
> thus requiring repeated application of the "Cases" approach for each of the
> above rules. In my application, these drawbacks are not acceptable because
> the "equations" may be very large, so that memory efficiency and performance
> is an important issue.
>
> Any other solutions that don't involve specific solutions for the "If"
> statement or degrade performance?
>
Dear Eckhard,
I didn't answer to your first posting, since I had not had understood.
But, ... perhaps the following might help you:
symbols = {a, b, c, d};
expr = If[x > 0, Difference[1, 2], Difference[3, 4]];
upeval /: f_[x___, eval[y_], z___] /; f =!= RuleDelayed := f[x,
Evaluate[y], z]
In[]:= expr /. Difference[x_, y_] :> upeval[symbols[[x]] - symbols[[y]]]
Out[]= If[x > 0, a - b, c - d]
Discussion: the helper function upeval (Up Evaluate) forces the
evaluation of the substituted rhs of RuleDelayed within If or any
function with HoldAll, HoldFirst or HoldRest Attributes, so it should
also work with Which, Switch and any other flow control expression. Of
course it should not evaluate within RuleDelayed itself!
This works because upvalues are evaluated in any case except with
HoldAllComplete attributes!
Yet the first -- and the most natural idea, I think -- is the solution
of Andrzej Kozlowski which essentially is (with a slight technical
correction)
In[13]:=
expr /. Block[{x, y}, Difference[x_, y_] :>
Evaluate[symbols[[x]] - symbols[[y]]]]
Out[13]=
If[x > 0, {a, b, c, d}[[1]] - {a, b, c, d}[[2]],
{a, b, c, d}[[3]] - {a, b, c, d}[[4]]]
Your objections agains use of memory for that solution appear as a
delusion, see:
In[19]:= MemoryInUse[]
Out[19]= 1171872 >>> Windows NT Task-Manager: 76128K
In[20]:= symbols = Array[z, {100000}];
In[21]:= MemoryInUse[]
Out[21]= 5594632 >>> Windows NT Task-Manager: 80472K
In[22]:=
expr /. Block[{x, y},
Difference[x_, y_] :> Evaluate[symbols[[x]] - symbols[[y]]]];
In[23]:= MemoryInUse[]
Out[23]= 5597840 >>> Windows NT Task-Manager: 80472K
However you must avoid that expression to be output (as Andrzej has
already stated).
Kind regards, Hartmut
- References:
- Re: Problem with evaluation of delayed rules
- From: Eckhard Hennig <hennig@itwm.uni-kl.de>
- Re: Problem with evaluation of delayed rules