[Date Index]
[Thread Index]
[Author Index]
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.
Regards,
Ssezi
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**
| |