Search All of the Math Forum:

Views expressed in these public forums are not endorsed by NCTM or The Math Forum.

Topic: Work on Basic Mathematica Stephen!
Replies: 81   Last Post: Jun 4, 2013 5:59 AM

 Search Thread: Advanced Search

 Messages: [ Previous | Next ]
 lshifr@gmail.com Posts: 531 Registered: 2/9/09
Re: Warsaw Univ. course, was Re: Work on Basic
Posted: Jun 3, 2013 11:12 PM
 Plain Text Reply

On Tue, Jun 4, 2013 at 12:45 AM, Richard Fateman
<fateman@eecs.berkeley.edu>wrote:

> On 6/3/2013 9:25 AM, Leonid Shifrin wrote:
>
> <long message>
>
> Thanks for what I consider a most agreeable contribution.
> I was not aware of your material on stackexchange, which seems
> to be rather nice.
>

Thanks, I do appreciate your opinion.

>
>
> You are right that my example regarding mutable Lists in Mathematica
> was incorrect. Actually on two grounds. The syntax was not right and
> I did not mean to say that Lists in Mathematica are not mutable, since
> they certainly are.
>
> Just that Lists have the uncomfortable property that if you access one
> element,
> all the others are re-evaluated. Here is an example, which I think is free
> of
> mis-used syntax...
>
> ( q=Table[f[i],{i,1,3}];
> f[n_]:=(Print[n];g[n]))
>
> q[[2]]
>
> evaluates to display
> 1
> 2
> 3
> g[2]
>
> Changing q by, for example, q[[2]]=hello
> does not re-evaluate the elements.
> However, referring to in again as q[[2]] does this:
> 1
> 3
> hello
>

Yes, this is indeed what happens. Arguably this is a correct behavior
(for Mathematica), because Mathematica can not tell in advance that
q will not evaluate to something else. For example, we could have q
assigned to some other symbol, and that symbol to hold the list.

In general, this is because Part does not hold its arguments. Given that
Part works on general expressions, I don't find this inconsistent.
If you don't want this behavior, one way out is to not store the values in
a list, but rather store them in some head which holds their elements,
such as Hold:

In[5]:= q1 = Map[f, Hold @@ Range[3]]

Out[5]= Hold[f[1], f[2], f[3]]

In this case, we get

In[6]:= q1[[2]]

During evaluation of In[6]:= 2

Out[6]= g[2]

Which seems to be the behavior you expected. One could
use HoldComplete in place of Hold, which would arguably
be even better since that would have prevented any non-trivial
evaluation of q1 whasoever (including e.g. search for UpValues,
not prevented by Hold).

Regards,
Leonid

>
> Thanks for pointing out the original error.
> RJF
>
>
>

Date Subject Author
5/12/13 David Park
5/13/13 psycho_dad
5/13/13 psycho_dad
5/14/13 Nasser Abbasi
5/15/13 szhorvat@gmail.com
5/16/13 szhorvat@gmail.com
5/16/13 Dr. Peter Klamser
5/17/13 Andrzej Kozlowski
5/17/13 Murray Eisenberg
5/17/13 Dr. Peter Klamser
5/18/13 Dr. Peter Klamser
5/19/13 Murray Eisenberg
5/19/13 paulmchale7@gmail.com
5/19/13 paulmchale7@gmail.com
5/23/13 szhorvat@gmail.com
5/24/13 David Park
5/20/13 Ingolf Dahl
5/20/13 David Annetts
5/22/13 mathgroup
5/23/13 Richard Fateman
5/24/13 W. Craig Carter
5/23/13 David Park
5/23/13 mathgroup
5/24/13 Richard Fateman
5/25/13 David Park
5/25/13 Richard Fateman
5/25/13 David Park
5/28/13 Alexei Boulbitch
5/28/13 Alexei Boulbitch
6/4/13 Bill Rowe
5/24/13 David Park
5/27/13 Noqsi
5/28/13 Richard Fateman
5/31/13 David Bailey
6/1/13 Richard Fateman
6/2/13 David Bailey
6/3/13 Richard Fateman
6/3/13 David Bailey
6/4/13 Andrzej Kozlowski
5/29/13 fd
5/30/13 Noqsi
5/31/13 Richard Fateman
5/31/13 Kevin J. McCann
5/31/13 Andrzej Kozlowski
6/1/13 Richard Fateman
6/1/13 Richard Fateman
6/2/13 Andrzej Kozlowski
6/3/13 Richard Fateman
6/3/13 Andrzej Kozlowski
6/1/13 Daniel Lichtblau
6/2/13 Richard Fateman
6/2/13 James Stein
6/3/13 waku
6/3/13 Daniel Lichtblau
5/27/13 Noqsi
6/2/13 David Bailey
5/28/13 fd
5/31/13 David Bailey
5/28/13 fd
6/2/13 Mark McClure
6/3/13 Richard Fateman
6/3/13 Joseph Gwinn
6/3/13 lshifr@gmail.com
6/3/13 lshifr@gmail.com

© The Math Forum at NCTM 1994-2017. All Rights Reserved.