MathGroup Archive 2005

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

Search the Archive

Re: Re: Types in Mathematica, a practical example

On Dec 6, 2005, at 12:03 AM, Andrzej Kozlowski wrote:

> It seems to me that you are looking here at Mathematica from the
> wrong view point. Although Mathematica is not a strict "functional"
> language, it is "functional" at least in the sense that it is
> "functions" and not "objects" that play the central role (I am being
> deliberately vague here but I have run out of patience with long
> discussions of programming languages and  general design issues.).

Amen, but apparently I have a masochistic streak that makes me  
persevere in this sisyphean discussion.  At any rate I thought about  
the problem a bit further, I am not sure why, and your point above is  
related to my thoughts.  If one insists on seeing all programming in  
an "object oriented" manner there is an argument that could be made  
for understanding how to make a Symbol x have some desired properties  
corresponding to behavior according to a type.  The first thing one  
must do is forget the Java/C++ model of objects, where objects are  
defined as record structures which can contain associated methods.   
Instead the appropriate model is Smalltalk, where the definition of a  
method on a variable defines the behaviors of the class to which that  
variable belongs.

> In
> this case the issue is with the function Plus and not with the nature
> or "type" of x etc. Plus has the attribute Listable, which is
> responsible for the behaviour you see

Agreed, so the "object oriented" approach would be to redefine the  
Plus method on x to get the behavior we desire.  We can consider the  
regular Plus method to be inherited from the type which roots the  
Mathematica type system: expression.  The larger problem is the  
evaluator; the Listable attribute gets applied before any definitions  
of Plus are used and removing the Listable attribute would apply to  
all definitions of Plus not just the Plus for x.  Having spent too  
much time thinking about this already I'm not really sure how to work  
around that problem, it seems to me one would need to redefine Plus  
in such a way that all instances of Plus not involving x behave as a  
Listable expression which is a nontrivial task.

A simpler alternative is to create your own method not named Plus  
with the properties you desire: objects of type undefined2DArray  
should return as a symbol and other objects should be evaluated.   
There are still some issues with the evaluator but

mySubtract[undefined2DArray[x_], a_] := HoldForm[mySubtract[x, a]]
mySubtract[x_, a_] := x - a
mySubtract[undefined2DArray[x], a]
ReleaseHold[mySubtract[undefined2DArray[x], a] /. x -> a]

gets most of the way there but is admittedly unwieldy to use because  
of the Holds.

> the natural way to deal with your problem is by
> temporarily blocking the Listable attribute like this:
> In[10]:=
> a = {{1, 2}, {3, 4}};
> In[11]:=
> Block[{Plus}, x - a /. x -> a]
> Out[11]=
> {{0, 0}, {0, 0}}

Of course, but I think the idea in this thread is to deal with the  
idea of types and their implementation in Mathematica.  The evaluator  
does not easily fit into a model of types.  I think what should be  
clear though is that unless there is a very good argument for  
developing the infrastructure necessary to redefine the behavior of  
Mathematica expressions globally, development of a type system  
infrastructure is probably far more work than it's worth.



  • Prev by Date: Re: Types in Mathematica, a practical example
  • Next by Date: Re: Can you solve my gravity-maths problem in Mathematica?
  • Previous by thread: Re: Types in Mathematica, a practical example
  • Next by thread: Re: Re: Re: Types in Mathematica, a practical example