# Ways to protect certain parts of expressions

I am currently working on a quantum mechanics problem where I try to find equations that relate different states of a many-body system. The states are described by sets of pairs of integers, like list1 = {{0,0},{0,1},{1,-1},{3,-3}}. There is a very expensive and complicated function listToPoly[li_List] that turn such lists into polynomials. It turns out that many seemingly different lists can produce the same polynomial, or that sets of lists produce sets of polynomials that are linearly dependent. I have found a way to determine some of these dependencies without using listToPoly but I would like some help implementing it.

What I want to accomplish is a way to represent these lists in a way that I can both act on them with functions that manipulate their list structure, e.g.,

func1[li_List,k_] := Transpose[{#1+k, #2}]& @@ Transpose[li]


and programmatically generate and solve the equations that represent the linear dependences. Say I have three lists:

l1 = {{0, 0}, {0, 1}}
l2 = {{0, 0}, {0, 2}}
l3 = {{0, 1}, {0, 2}}


and I find out that their corresponding polynomials p1, p2, p3 would satisfy

2*p1 - 3*p2 + p3 == 0


I would like to be able to generate such equations using the lists (I don't want to invoke listToPoly), but then I need to prevent evaluation like

2*l1 - 3*l2 + l3 = {{0, 1}, {0, -2}}


Even combining the two things, it would be nice to be able to define something like

lindep[li_List, kmax_] := Sum[(-1)^k * func1[li, k], {k, kmax}] == 0


and then evaluate

lindep[{{0,0},{0,1}}, 2]


to get

- {{1,0},{1,1}} + {{2,0},{2,1}} == 0


There are probably lots of ways to do this, like:

• Using Hold and ReleaseHold
• Adding or replacing a custom head and defining functions to act on object with that head
• Using ToString and ToExpression back and forth
• etc.

### Question

What would you guys choose? Any clear (dis)advantages to any particular method? I realize I am basically asking "how to handle custom objects", but I thought giving the context would make it easier to point me in the right direction.

• Related: (4636) – Mr.Wizard Feb 13 '15 at 20:23

I realize I am basically asking "how to handle custom objects", but I thought giving the context would make it easier to point me in the right direction.

It seems that you are. I believe the most natural way to do that in Mathematica is to use a custom head. I'll use obj for my examples.

First you might define a pattern for your custom object:

p0 = obj[{{_, _} ..}];


Then define a new func1 (I'll call fn1) referencing that pattern:

fn1[li : p0, k_] := MapAt[# + k &, li, {1, All, 1}]


And lindep:

lindep[li : p0, kmax_] := Sum[(-1)^k*fn1[li, k], {k, kmax}] == 0


We can define a Format to style obj expressions as plain lists:

Format[x : p0] := Interpretation[First @ x, x]


Finally:

lindep[obj[{{0, 0}, {0, 1}}], 2]

-{{1, 0}, {1, 1}} + {{2, 0}, {2, 1}} == 0

• Thanks, using a custom head was my hunch. Also, using Format and Interpretation this way was new to me, cool! If I only plan on using the head obj for these lists, would there be any difference between your suggestion, and not defining p0 but simply defining functions like fn1[li_obj, k_]? – Marius Ladegård Meyer Feb 13 '15 at 17:34
• @Marius Don't be too quick to Accept an answer. (But thank you.) You can use li_obj if you like and it will be somewhat faster if applied a lot, but the longer pattern will make sure the data is not malformed. Regarding Format I remembered after posting that I probably should have used MakeBoxes instead; please see: (4112299) – Mr.Wizard Feb 13 '15 at 19:39
• @Mr.Wizard First off, this solution is very helpful. In your example, have you noticed that if you assign the lindep function to a variable x = lindep[obj[{{0, 0}, {0, 1}}], 2] that ?x results in an error with infinite recursion? Are there some additional changes that can be made to fix this? – Adam Law Mar 17 '16 at 21:22
• @Adam I was not able to reproduce that problem (v10.1.0 under Windows 7) but I think it may be caused by my use of Format instead of MakeBoxes, out of laziness. See (4119830). – Mr.Wizard Mar 18 '16 at 21:19