Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2005
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2005

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

Search the Archive

Re: Re: Making a new definition of Equal work with lists as well

  • To: mathgroup at smc.vnet.net
  • Subject: [mg63395] Re: [mg63387] Re: Making a new definition of Equal work with lists as well
  • From: Sseziwa Mukasa <mukasa at jeol.com>
  • Date: Thu, 29 Dec 2005 02:57:27 -0500 (EST)
  • References: <dor2jc$alo$1@smc.vnet.net> <200512280855.DAA28663@smc.vnet.net>
  • Sender: owner-wri-mathgroup at wolfram.com

On Dec 28, 2005, at 3:55 AM, dan.bernstein at gmail.com wrote:

> Thank you, Bill and Jean-Marc, for your replies.
>
> I'm afraid I didn't give a sufficiently general example in my  
> question.
> What I would like to do is to be able to get True/False results for
> expressions as general as
>
> {CL[2,3], 5, {CL[4,5], CL[2,2]}, x} == {CL[2,3], 8, {CL[6,7], CL 
> [9,9]},
> y}
>
> that is, lists containing both CLs and other elements, and nested  
> lists
> etc.
>
> Making Equal listable wouldn't work because I would then get also a
> list (of booleans) as a result.
>
> I think defining Equal for CL[a_, b_] could have "just worked" if  
> Equal
> for lists was internally defined to AND the Equal of all matching
> pairs, something like
>
> Equal[j_ListQ, k_ListQ]:=If[Length[j]!=Length[k], False,
> And@@Table[Equal[j[[i]], k[[i]]], {i, 1, Length[j]}]
>
> And I guess I could re-define it this way, but I wonder what the
> built-in definition is, and what I stand to lose by overriding it like
> that.

I may be confused but if you want to compare such expressions with  
Equal wouldn't this return the result you want given your previous  
definition of Equal with respect to CL?

expr1=Flatten[{CL[2,3], 5, {CL[4,5], CL[2,2]}, x}];
expr2=Flatten[{CL[2,3], 8, {CL[6,7], CL[9,9]}];
And@@MapThread[Equal,{expr1,expr2}]

I know it's not an object oriented approach but I'm not sure what  
advantage such an approach would bring in this case.  When working  
with an object oriented approach the expressions CL[_,_], {CL[_,_]},  
{{CL[_,_]}} are all of different types and any comparison functions  
(methods) would have to be defined on each type individually which  
seems like a lot of work.

I personally am loathe to override the behavior of predefined  
functions, especially their behavior with respect to lists because  
such a global modification could introduce surprising behavior in  
other areas, especially when working with two unrelated notebooks  
simultaneously.  The only time I feel comfortable doing so is when I  
know some fact to be globally true with respect to a expression, such  
as knowing that multiplication is not commutative for a class of  
expressions (I'm trying to avoid object oriented terminology but  
sometimes it cannot be avoided).

Regards,

Ssezi


  • Prev by Date: Can I assign a style to a GridBox row?
  • Next by Date: "Null" appearing in exported gif
  • Previous by thread: Re: Making a new definition of Equal work with lists as well
  • Next by thread: Re: Making a new definition of Equal work with lists as well