Re: Re: Re: Types in Mathematica, a practical example

```Sseziwa Mukasa wrote:

>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.
>
Sisyphean it is .
http://www.worldwidewords.org/weirdwords/ww-sis1.htm :-)

>  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
>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
>
>
>

--
Pratik Desai

...Moderation, as well as Regularity of Thinking, so much to be wished for in the Heads of those who imagine they come into the World only to watch and govern it?s Motion
Gulliver's Travels
by Jonathan Swift

```

• Prev by Date: Re: FixedPoint stops "when elements no longer change"?
• Next by Date: Re: Re: Re: Types in Mathematica
• Previous by thread: Re: Re: Types in Mathematica, a practical example
• Next by thread: Re: Types in Mathematica, a practical example