MathGroup Archive 2008

[Date Index] [Thread Index] [Author Index]

Search the Archive

RE: Re: Dynamic: feature? No, in my opinion is UpValues feature

  • To: mathgroup at
  • Subject: [mg88088] RE: [mg88068] Re: Dynamic: feature? No, in my opinion is UpValues feature
  • From: "Jose Luis Gomez" <jose.luis.gomez at>
  • Date: Thu, 24 Apr 2008 05:57:08 -0400 (EDT)
  • References: <fukem6$s0m$> <>

Dear Chris and Jean-Marc

I believe the behavior that you report is Not a Dynamic feature, I think it
is an UpValues feature, and I am Not surprised it happened, let me explain.

(If there is in this forum any expert in DownValues, OwnValues and UpValues,
please correct me if I make any mistake in the following:)

First a simpler example:

If I write the following two different rules for the same expression foo[a],
which one will Mathematica obey?

foo /: foo[a]=400;
a /: foo[a]=12;

The answer is that Mathematica will always say foo[a] is 12, it does Not
matter which definition was evaluated before, because the rule
a/:foo[a]=12 is an UpValue (definition assigned to an argument, similar to
some aspects of object oriented programming) while
foo /: foo[a]=400 is a DownValue (definition assigned to a Head, this are
the "normal" definitions)

And Mathematica will always try UpValues first, and if there is no UpValue
that can be applied, then it will try DownValues.

The reason for this behavior is that we can create specific rules with
UpValues and general rules with DownValues that coexist. For example the
following command will create a specific rule for the addition of "a" plus
anything, without disturbing the behavior of addition in other situations:
a /: a + x_ := myplus[a, x]
This specific rule will always be used before the general rules of addition
when the addition includes a. For example evaluate x+y+a+z and you will
obtain myplus[a,x+y+z]. On the other hand, if you evaluate 3+4 you will
obtain 7, no problem because you did not overwrite the general rules
addition, you just added a specific rule for a special case, which coexist
with the general rules.

However, in the example above, the rule foo /: foo[a]=400 will never be
used, because the rule a /: foo[a]=12 will always "win". Then the code above
(definitions of foo) is in some sense bad programming, yet the output is

Now the case that we are interested, What do you think it must happen if you
have the following definitions for goo? What do you think Mathematica should
do in this case?

a /: goo[a,b]=400;
b /: goo[a,b]=12;

First, we can say that this definitions of goo are at least as bad
programming as the example above with foo, because two different rules
should apply to the same expression. Maybe you were expecting that the last
rule evaluated will replace the first rule, but this does Not happen because
the rules are assigned to different objects, a and b.

You can verify that the two rules exist at the same time by evaluating
And evaluating
So, the second rule does not overwrite the first rule, the two conflicting
rules coexist, BECAUSE they are assigned to different objects, "a" and "b".
In order to have the second (last) rule to overwrite the first rule both
rules must be assigned to the same object, for example "a".

I think this bad programming (two different rules of the same hierarchy that
should be applied to the same expression coexist), therefore we can expect
the behavior of Mathematica to be unpredictable. If the two conflicting
rules coexist, which one should Mathematica obey?

I am Not surprise that Mathematica behavior is different if in different
situations, for example, if one rule is evaluated first or second. Also it
could happen that Mathematica 5.2 and Mathematica 6.0 could have (I do Not
know if they do) different behavior in this bad programming example (goo).

But those are my thoughts, Is there in the forum any expert in DownValues,
OwnValues and UpValues that can tell us if my ideas are correct?


-----Mensaje original-----
De: Jean-Marc Gulliet [mailto:jeanmarc.gulliet at]
Enviado el: Mi=E9rcoles, 23 de Abril de 2008 03:10 a.m.
Para: mathgroup at
Asunto: [mg88068] Re: Dynamic: feature?

Chris Osborn wrote:

> I have a cell containing this:
> Dynamic[f[a, b]]
> Then I do this:
> a /: f[a, b] = 12
> and the dynamic cell updates to 12, as I would expect.
> When I do this:
> b /: f[a, b] = 45
> The dynamic cell does *not* update for some reason.
> It seems as though it does not realize an update has occurred when it
> is associated with b.
> Does anyone know why this is?
> Thanks in advance,
> Chris

Weird. I witness the same behavior if the cells are evaluated in the
given order. However, ff one change the order of the assignments (i.e. b 
first, then a) Dynamic[] works as expected. Evaluating the following
expressions in that order,

     Dynamic[f[a, b]]
     (* The first output cell is: f[a, b] *)

     b /: f[a, b] = 45
     (* The first output cell is now: 45 *)

     a /: f[a, b] = 12
     (* The first output cell is now: 12 *)

     $Version => "6.0 for Mac OS X x86 (64-bit) (February 7, 2008)"

I have also recorded the sessions in a PDF file. See

-- Jean-Marc

  • Prev by Date: Re: Print[Plot] vs Print[text,Plot]? (*now Do and Table*)
  • Next by Date: Re: Re: Player Pro and Packages
  • Previous by thread: Re: Dynamic: feature?
  • Next by thread: Re: Dynamic: feature?