Referring to arguments of a function by order in which they appear

Questions
1

I have an application in which I need to pass arguments to a function in non-list form (I know functions can take arguments in list form, but there is a bug that makes this not work in my case, we don’t have to get into it), but then I need to recreate the lists from the arguments. So for example, if

f[a1_,a2_]:=a1+a2

I would like to define, inside f a list={a1,a2] and then redefine

f[a1_,a2_]:=list[[1]]+list[[2]]

I would like to refer to a1 as first argument of f, a2 as second argument instead of by their names, because I have a much more complicated function in my real case and I want to automate list by using such Mathematica constructs as Table and Array. So how to do this?

2

I’m not at all sure what you’re trying to do, but here are some thoughts to get you started:

f1[args__] := {args}[[1]] + {args}[[2]];
f1[1, 2]
(* 3 *)

f2 = #1 + #2 &;
f2[1, 2]
(* 3 *)

Or, you can just overload your function:

f3[list : {_, _}] := list[[1]] + list[[2]];
f3[a1_, a2_] := f3[{a1, a2}];
f3[1, 2]
(* 3 *)

Or you can change the way you apply your function:

f4[a1_, a2_] := a1 + a2;
f4 @@ {1, 2}
(* 3 *)

But I don’t understand why you think using Table and Array is creating some sort of impedance, so I don’t have confidence in any of these approaches.

3

Thanks Eric for your help. I don’t think I expressed what I need well, so your examples probably won’t work. Here is a better explanation referring to the included notebook:
The first evaluation cell has no problem because f1 and f2 are symbolically defined.

The second evaluation cell also has no problem because f1 and f2 are able to be symbolically evaluated in eqnlist, before being passed to NDSolve, by taking a symbolic Derivative of f.

The 3rd cell has a problem because I insist that the Derivative not be evaluated unless one of the arguments to f is a real number (instead of a symbol), which is the case once NDSolve gets going, but not initially. Though in this case f1 and f2 can be symbolically evaluated, in my real case they can’t. If they are numerically evaluated before being passed to NDSOlve, then NDSolve will not get a list of symbolic equations. So they need to delay evaluation till NDSolve gets going
(The real f is a conditional eigenvalue of a complicated large rank matrix that also depends on solving another ODE).

In the fourth cell, I show that as long as there is no list in the arguments of f, there is no problem with the same insistence on not evaluating eqnlist and keeping it symbolic so NDSolve is happy.

In the fifth cell, I try to convert the list to a sequence before passing to f, and then convert back to a list inside of f (It looks silly in this example, but in the real application keeping list structures is essential, there are many lists, they get passed on to other functions, and it becomes an unwieldy mess without them), but it doesn’t work (I need to do the Extract while stripping the “Real” qualifier, I don’t know how to do that yet)

Open in Wolfram Cloud ↗
4

In your third cell, why don’t you just do the following?

f[a : {_Real, _}] := 0.5 (1 - a[[2]]) a[[1]]^2 + (1 - a[[1]]) a[[2]]^2 + a[[1]] a[[2]]
5

Oh, nevermind. It seems you’re saying that you want to be able to assert that a symbol should be assumed to be Real. Is that the root of the problem?

6

The only reason I want at least one of the elements of the list of arguments passed to f to be real, is a hack. I want to pass NDSolve a list of symbolic equations. Since f in my actual problem can’t be symbolically evaluated, the Real qualifier prevents evaluation when the derivatives are taken (the ones with respect to the arguments of f, not the ones with respect to t), to produce acceptable (to NDSolve) symbolic equations. Once NDSolve gets going, it replaces the arguments by real numbers, and then f can be evaluated. This can be seen to work in the fourth cell, which does not have a list of arguments passed to f. But I need to have a bunch of lists passed to f in my real (meaning actual, not as in real vs complex vs symbolic) example.

Perhaps this could be done with Hold and Release as well (instead of the Real hack) but I have been so far unsuccessful in achieving that.

7

So, which of these 5 examples is closest to what you actually want? You’re demonstrating things that work, but apparently they aren’t good enough. So what is your actual situation and what is it that you’re actually trying to get to work?

8

The third cell would be ideal since it keeps the list structure. The fifth cell tries to get rid of the list structure (in reality I would also Flatten some Joined lists, some of which are also 2 dimentional, nested lists, to create args, I didn’t bother showing that in this example), but it’s far from ideal and also a hack, to compensate for the bug that Derivative can’t handle qualifiers in lists. The other examples that actually work, either do not have lists (in arguments to f), or have functions that can be evaluated symbolically (and their derivatives too), which is not my case in the actual application. And I haven’t gotten the fifth cell to work yet, though maybe it is close?

9

Okay, maybe this is what you’re after. I changed variable names to help myself keep track of what’s going on.

avInit = {1, 1};
avFns = Array[av, 2];
avFnsApplied = Through[avFns[t]]; (* {av[1][t], av[2][t]} *)

avProtoList[a_List] := 0.5 (1 - a[[2]]) a[[1]]^2 + (1 - a[[1]]) a[[2]]^2 + a[[1]]  a[[2]];
avProto[args___] := avProtoList[{args}];

g1 = Derivative[1, 0][avProto];
g2 = Derivative[0, 1][avProto];

eqnlist = {
  Derivative[1][av[1]][t] == avProtoList[avFnsApplied], 
  Derivative[1][av[2]][t] == avProtoList[avFnsApplied], 
  av[1][0] == avInit[[1]], 
  av[2][0] == avInit[[2]]};
solDEsuper = NDSolve[eqnlist, avFnsApplied, {t, 0, 1.4}]

I didn’t try to check that the result is correct. I just tried to do a formal transformation into what I think you’re asking for.

10

Not quite. Maybe somehow include g1 and g2 in the eqnlist. As it is now, the equation does not have the Derivatives (with respect to the list arguments, not time), and also eqnlist has done the evaluation symbolically of f, instead of keeping it unevaluated.

11

Ugh. Got wrapped around the axle in my translation. What about this?

eqnlist = {
  Derivative[1][av[1]][t] == g1 @@ avFnsApplied,
  Derivative[1][av[2]][t] == g2 @@ avFnsApplied,
  av[1][0] == avInit[[1]],
  av[2][0] == avInit[[2]]}
12

But you get the idea, right? One function to deal with lists and another to deal with sequences.

13

So close! It works, but unfortunately eqnlist has evaluated the derivative of f symbolically. Recall that in the actual case this cannot be done, since f can only be evaluated numerically. If I recall, what happens if I don’t use the “Real” hack (which gives me a "non-numerical derivative at t=0 when I have lists, but works without lists), which is also what will happen if I use your solution in the actual case, is that it keeps trying to evaluate Eqnlist symbolically, never even getting to evaluate NDSolve and just doesn’t give me output.

14

Okay, then I need more information. I can’t tell the difference between this and what you had previously that I thought you said was good.

Is there anyway you can simplify the problem? Like just give a simple function whose derivative is just dead simple to look at and immediately recognize and then provide an actual correct solution that I can use as a test case?

I feel like we’re getting lost in implementation details, and I haven’t actually figured out what you really want.

Also, some commentary with your examples would be helpful. I’m not sure what’s working as desired and what’s not. You seem to set up an example just to indicate that it’s not what you want, but it seems to work, so I don’t know what the problem is.

Or maybe work backward. Hand-roll the entire NDSolve expression. Just provide the literal inputs that you want that work for NDSolve. Then show me what you have as inputs to this whole process. From there, maybe I can figure out how to get from your inputs to the final NDSolve expression.

15

I am willing to pay you $200 to solve this problem. OK, so we need two things:

  1. Arguments to f have to be a bunch of lists (and some non-lists too)
  2. eqnlist that is given to NDSolve should not attempt to evaluate f (or its non-time derivatives) but should be in symbolic, unevaluated Derivatives form. The reason is that f (and hence its derivatives) is not possible to evaluate symbolically, only numerically.

I don’t know how to come up with a simple f that can’t be evaluated symbolically (like it is in all the examples we have produced so far). I can send you two files that have the real f (called ffoutsuper in there, you will have to scroll down to see its definition which involves eigenvalues of a high rank matrix and calls to another ODE solver, and then scroll down even further to see where NDSolve is called):
The first shows that as long as there are no lists in the arguments to f, NDSolve is happy and so am I.

The second doesn’t work because there are lists in the args to f. You can see from these 2 files that f has no hope of being evaluated symbolically (maybe there is a clever way to do it using certain symmetries, but I will have cases in the future where these symmetries are not present that might make f be evaluatable symbolically)

nestedlevels4.3.nb (575 KB)
nestedlevels4.5.nb (604 KB)

16

I’m sorry, this isn’t helping me. Please, please just give me literal concrete expressions that I can work with. I know it’s obvious to you, but I’m not grokking. So, like in your original example, is the following even correct?

NDSolve[
  {Derivative[1][av[1]][t] == 1.*av[1][t]*(1 - av[2][t]) + av[2][t] - av[2][t]^2, 
   Derivative[1][av[2]][t] == av[1][t] - 0.5*av[1][t]^2 + 2*(1 - av[1][t])*av[2][t], 
   av[1][0] == 1., av[2][0] == 1.}, 
  {av[1][t], av[2][t]}, 
  {t, 0, 1.4}]

Does that produce the result you want? If not, show me an NDSolve expression that does produce the result you want. Then we can work backward from there. I can’t figure out if this is the right “end game” and you’re struggling to figure out how to get there, or if this is the wrong “end game” and you don’t know where things went wrong.

17

You said

The first shows that as long as there are no lists in the arguments to f, NDSolve is happy and so am I.

and

You can see from these 2 files that f has no hope of being evaluated symbolically (maybe there is a clever way to do it using certain symmetries, but I will have cases in the future where these symmetries are not present that might make f be evaluatable symbolically)

I know you think you’re being helpful, but this is just a distraction. I need to know the actual things you want to pass in to NDSolve. Just forget about the list versus non-list arguments for now. I just need to have a target to shoot for. These informal descriptions are just not helping me.

I’m like 95% sure this is doable in a very easy way, but so far I’ve failed to hit your target, and I don’t know what my errors are. Don’t tell me in words like “evaluate f symbolically”. Just give me a concrete target that I can shoot for.

18

Hmm… I don’t know how to make it simpler. If you look at the two big files I included, the first has no lists and it works, the second has lists and it doesn’t work. The same is true for the simpler file I included originally, but in that one there is an f that can have its derivative be taken symbolically (but can be prevented from doing so by the “Real” hack). In the more complex files, in both cases there is an f that is not able to have its derivatives be taken symbolically. The code snippet you posted:

NDSolve[
  {Derivative[1][av[1]][t] == 1.*av[1][t]*(1 - av[2][t]) + av[2][t] - av[2][t]^2, 
   Derivative[1][av[2]][t] == av[1][t] - 0.5*av[1][t]^2 + 2*(1 - av[1][t])*av[2][t], 
   av[1][0] == 1., av[2][0] == 1.}, 
  {av[1][t], av[2][t]}, 
  {t, 0, 1.4}]

has explicit expressions for the equations in eqnlist (effectively evaluating derivatives of f), so it it NOT what is needed.

19

so it it NOT what is needed.

Excellent! That’s progress. So, what is needed?

Clearly we’re having a communication issue. You think you’ve provided me with enough info, but I don’t understand. Why can’t you literally just manually change the thing that doesn’t work to the thing that does work and show me that? If you do that, I can almost guarantee that I can show you how to get there.

20

Now you’re just being funny, or sarcastic? I guess I need to think of a simple example of a function that can’t be evaluated symbolically for you to “grok” what is going on. The example in those two files (nestedlevels4.3 and nestedlevels4.5 was too complicated apparently). This is probably just as frustrating for you as it is for me.