Re: Assigning part of indexed object
- To: mathgroup at smc.vnet.net
- Subject: [mg119844] Re: Assigning part of indexed object
- From: Leonid Shifrin <lshifr at gmail.com>
- Date: Sat, 25 Jun 2011 05:28:10 -0400 (EDT)
- References: <itsjn7$8u7$1@smc.vnet.net>
Hi Fabrice,
My guess is that the reasons are efficiency and immutability of expressions
in Mtahematica. By restricting Set
to variables or array elements, one can connect it directly to the internal
memory layout for that element. Note
that all proposed solutions are based on ReplacePart, which copies the
entire list to modify a single element.
OTOH, constructs like indexed variables are serviced by hash-tables
internally. Even if the value stored
in the hash table is a pointer to some array, that array will likely be
immutable. Whether it would be a
good idea to make it mutable I don't know, but the general ideology is that
expressions are immutable
in Mathematica. In other words, I don't think that the case of indexed
variables was overlooked when
designing Set - my guess is that the restriction to symbols is quite
intentional.
Regarding the "fix", I'd consider this not a fix but a recipe for disaster,
because modifying Set in such
a fashion is dangerous, not to mention that it will often be completely
unacceptable performance-wise. Let us say
you store a large array in a symbol and use a For loop with array indexing.
Suddenly all your array element assignments
become O(n) time, where n is the list size, or even worse for higher
dimensional tensors, not to mention increased
memory consumption. Here is an illustration:
In[18]:= a = Range[10000];
In[19]:= Unprotect[Set];
Set[sym_[[part_]], val_] := sym = ReplacePart[sym, part -> val];
Protect[Set];
In[27]:= Do[a[[i]] = a[[i]]^2, {i, Length[a]}] // Timing
Out[27]= {1.156, Null}
In[28]:= Unprotect[Set];
Clear[Set];
Protect[Set];
In[31]:= Do[a[[i]] = a[[i]]^2, {i, Length[a]}] // Timing
Out[31]= {0.047, Null}
You may do this for yourself if you wish (although I'd avoid even that),
but I'd strongly
advise against such modifications in production code or any code someone
else will be using. Set is one of the
most fundamental operations, and its modifications may have very far-
reaching and hard to predict consequences.
It may, for example, corrupt the system in very subtle ways, which you may
never be able to identify.
Unfortunately, the standard mechanism of "soft" system symbols overloading
via UpValues does not
quite work with Set (or at least I don't know of a way to make it work)
because Set holds its argument and UpValues
can only be defined for tags not deeper than level 1 in an expression. In
this post:
http://stackoverflow.com/questions/5886066/overloading-seta-b-a-b/5886322#5886322
I demonstrated a method, which I also don't like, but which is at least
safer because it tests for a
specific data type. Generally, the still safer way is to create your own
data type and introduce your own
assignment operator(s) - in this way, you don't have to modify Set at all.
Regards,
Leonid
On Fri, Jun 24, 2011 at 3:46 PM, Fabrice P. Laussy <
fabrice.laussy at n0spam-gmail.com> wrote:
> Dear all,
>
> Thanks for the solution. Supplemented with Oleksandr Rasputinov's fix:
>
> > Unprotect[Set];
> > Set[sym_[[part_]], val_] := sym = ReplacePart[sym, part -> val];
> > Protect[Set];
>
> it works splendidly.
>
> In "some elements of Mathematica Design (1992)" [http://goo.gl/nm1tT],
> Stephan Wolfram makes a point where one should resist the temptation to
> design functions to do things that look natural for them to do, as they
> could break dramatically later on.
>
> Here we have a clear case where Set seems it ought to work as redesigned by
> Oleksandr. Is there any reason for this not being the default behaviour?
>
>