Did you have a particular kind of f(x) in mind?

I don't mean so that we could just show a 2D plotting call, because I know that you know how to do that well. I mean so that we could check against any FunctionAdvisor attempt.

@NIMA112 You have non-function-call terms with omega, such as,

    omega * (x + xi)

and,

    omega * abs(x - xi)

as well as terms with function calls, such as,

    cos(omega(y + eta))

and,

    D(omega)(y + y__0)

What did you intend for all of those to mean, taken together?

Try attaching a renamed version of the worksheet .mw file, without the "&" character.

@jasser 

Do you want all possible sums >=  maxsum, or all the combinations whose sum = maxsum?

I only ask because you haven't commented on that aspect in what mmcdara has shown, checking against the strict equality (so that all the returned lists have sum=N).

Also, how many elements might be in your "longer lists"? And how fast do you need it?

Do you need the results separate, for the various odd q values? Or is it ok to do them all at once?

@C_R In the above, the Equation Label is acting similarly to the case where the input was written literally, as opposed to the case of being the value of an assigned name.

That might be the correct behavior of evaluation for the Equation Label's insertion. When I say "correct" I mean that having an inserted Eq.Label behave like an assigned name might have other kinds of problems. Certainly Eq.Labels have had evauation issues -- and tweaks/fixes -- over the years. I would believe it if a kernel expert told me that Equation Labels ought to act exactly like literal input.

The second and third add examples in my worksheet above both throw the same error if the sequence has four or more elements. In that case they both still don't work similarly to the case of an assigned variable. Using a list still handles that case fine. add_seq_ex2b.mw

So examples 2&3 don't act like examples 1&4, whether the sequence has three elements or more. That aspect, which was my main point, remains just the same as before.

I originally chose a sequence of three elements simply because the call to add using the literal sequence as arguments (third example above) happens to (kinda, sort of) match an esoteric add call with a skip/step value, and so produces no error message. The absence of an emitted error means that a user is less likely to notice the wrong&unintended result.

ps. I deliberately put in the Equation Label example because I know that you use such.

@C_R I'll make another comparison, if I may.

The last three calls below (ie. wrapping in a list) form an approach that works consistently, and has no unexpected "gotcha" pitfalls.

That approach, to pass in a list, also happens to guard against your case of a single scalar (product, say).

Download add_seq_ex2.mw

@C_R I'll split this response in a few parts:

1) In Section 3.1.1 of the Programming Guide there is some discussion of expression sequences. It shows a few things that can't be done with a vanilla procedure and passing expression sequences as arguments. And it also shows that (automatic simplification) flattening of expression sequences brings a few other, related limitations. Here are a few notes: seq_flat_ex01.mw

Difficulties in trying to pass expression sequences as arguments to procedure calls is a mistake on which some people stumble. (I have seen many, over the decades. Including some on this site, or elsewhere.)

2) There's another common issue with bare expression sequences, which is that one cannot normally construct an expression sequence of a single scalar and have it remain as an exprseq type/DAG/structure. You appear to have run afoul of this. And it's a common issue, as people learn and program in Maple. So, if your expression sequences might be constructed from just one element then you need to put in a check and handling for that case. Having `seq` or some constructor return a single scalar is thus a special case.

And very often one's code needs separate handling for the special case(s), and forgetting that can lead to unexpected errors or mistakes or wrong results. This is a fundamental issue with dealing with expression sequences.

3) Now, the Programming Guide doesn't moralize very much, or even provide much in the way of coding guidelines and notes on good programming practices. And there are things you can do in Maple that no Manual will inform you are in fact slightly dodgy.

And because of 1) and 2) handling and manipulating bare expression sequences is error prone. Those aspects can catch people off guard. In my not-so-humble opinion users are better off with lists than expression sequences in many situations.

4) It's very nice and convenient that Maple 2015 saw the new functionality to be able pass a list or Matrix/Vector to add and get the result without need for using an indexing variable. The single argument call add(M) is great, for list/set/rtable.

But the ability to call add(S) for S an expression sequence is dubious design. Users don't need more encouragement to pass expression sequences as arguments. Having a few more weird commands that allow it doesn't help, overall.

And since construction&deconstruction of list [S] from expression sequence S is decently efficient then there is no good reason for add to be able to work directly on expression sequences. And that functionality does contribute to functional ambiguity. It contributes to overall functional ambiguity. It contributes to functional inconsistency.

There are a few more bits that people ought not have to understand or muddle through. For example, in Maple 2015->2021 the second of these examples threw an error about an invalid second argument to add. In Maple 2022->2024 the result is just 3. Neither of those is easily comprehensible in light of the first example.

S:=3,4,5;
                                 S := 3, 4, 5

> add(S);
                                      12

> add(3,4,5);
                                      3

But lack of consistency and comprehensibility seem secondary, to me, relative to the earlier points against it; I don't see why it'd be a good idea altogether to have add act on an expression sequence.

I have no big objection to having add (and mul) act on the operands of a single scalar argument. What I don't care for is their functionality to accept expression sequences.

5) I don't recall your mentioning units before, in the context of this discussion. You haven't provided a full and explicit example, so I don't how it went awry.

@C_R 

The problem of expression sequences devolving into the special case of a scalar, and then unexpected behavior ensuing, is quite common. It is not rare. It is a basic level mistake, often encountered when people are relatively new to Maple. The problem is not at all restricted to add. It happens with lots of other code, and it happens often at a beginner level.

A much better solution is to adopt the general programming habit of not having bare expressions sequences floating around, or at least to get into the better habit of not passing them around in procedure calls. (There are a few exceptions, such as the prefix form of `*`(...), but those are relatively rare.)

I tried hard to convey an explanation earlier, but above you've just written the opposite conclusion and ascribed the earlier responses as justification of that misguided view.

Passing an expression sequence to add, and then being surprised when the scalar case is overlooked by the calling code, is user-error. It's an important case of user-error because left unchecked it will get the programmer into problems in many other situations not restricted to add.

The notion that add's functionality to act on operands of a scalar expression ought to be removed, just because you were caught off guard by uncareful use of expression sequences, is wrong.

The functionalities being discussed, for expression sequences and scalars, were introduced in the same release, just after Maple 18, IIRC. Yes, taken together those functionalities can lead to more mistakes. But if one of them had to be removed then it ought to be the handling of a bare expression sequence, because that is the one which mirrors suboptimal Maple programming more generally.

ps. I'm holding back above. Using bare expression sequences in one's code is an inferior Maple programming practice. Introducing the ensuing programming dangers, which are unnecessary and easily avoiding without large inefficiency, is a foolish approach.

ps. You've responded with, "After your comments, it seems even more likely that applying add to a scalar expression is dispensable and potentially `dangerous`." Now, three people responded so far to your Question, and all three of them suggested the call add([A]) instead of add(A), when A is an expression sequence. That's an endorsement for the idea of passing a list instead of a bare expression sequence. What's "dangerous" is the habit of passing expression sequences in procedure calls (they usually get flattened, which catches people off guard, and is easily avoidable, etc), rather than add's treatment of the operands of a scalar.

@jalal That was not clear to me from the original Question. Thanks.

You can apply handler procedure F to either the M or the Sol entries in your Tabulate calls. Below, I do it for both. It's your choice.

Systmes_Idea_ac2.mw

Systmes_Idea_ac2.mw

It's now a Post, rather than a Question. (I changed your link)

Your sentence, "The function “add” (a built-in function with special evaluation rules) is intended to be used on sequences" is charged with fuzzy inaccuracy.

It happens that add can work on an expression sequence. But it is not "intended" that such is any kind of preferred usage. Passing expression sequences as arguments to procedure calls is a more generally ruinous habit, and would lead to far more mistakes.

Don't get into the habit of invoking add(S) where S is an expression sequence, when you could instead use the sane add([S]) call. Much more of the time you'll run into trouble elsewhere when you mistakenly try and pass sequences to procedure calls and they get flattened.

nb. If S is an expression sequence then it is uniquified in Maple's stored memory, and construction of the list [S] only increases internal memory use of the thin wrapper of the list structure -- it does not double the memory use. So constructing [S] from S is not very memory-inefficient.

Thus there is no reason to pass a scalar to add by mistake, because you never have to pass it a bare expression sequence.

And the behavior of add to work on operands of a scalar should therefore not be problematic. It's only problematic if you follow the poor strategy of passing bare expression sequences to add.

Someone else might want the behaviour of add's adding operands of a scalar expression, and mistakes than ensue because someone else ill-advisedly passes bare expression sequences to add is not a decent justification for removing the former functionality.

That's my opinion, but I've supplied a rationale for it. I think that add's acceptance of bare expression sequences is more of a design mistake than is add's handling of scalar expression's operands.

@C_R I'm not sure that ::evaln procedure parameter spec would always act as you were expecting. There are a few Constants names that would require other handling; assuming that you are just trying to avoid having to always enter the single left-quotes and so manually form the actual names yourself.

convert(..,name) might be more along the lines of what you wanted. (The ::uneval is optional...)

Download getdef_ex.mw

@C_R I don't personally like Equation Labels (even more than I don't care for alias). But I'm glad that the system is flexible and allows for differing styles of programmatic flow.

Here below is an example of the zeal for replacing assignments with Equation Labels taken too far. It gets rid of the rhs calls. Please take it in the intended spirit of friendliness. (The world seems to need such, right now.) There's a balance somewhere, where a non-Maple reader can understand more of the presentation.

Download roman_in_subscript_example_ac2.mw

On a more serious note, I think that,
    (evalf*GetUnit)(Constant(sigma))
is somewhat nice, ie. without too many instance of "sigma". It's the only actual improvement I might have had for your example.

ps. I wish that the Mapleprimes inline worksheet renderer did a better job with Equation Labels, leaving them right-aligned as in the actual Maple GUI.

@C_R So, for this particular example an assignment can serve in lieu of alias. That's all I was trying to convey.

I made some other stylistic changes, not because I think it's better, but just for fun.
i) If one has Eq 2 E=sigma*T^4 at hand then it can be used for Eq 3.
ii) UseUnit makes the unit-combining on target, though you might not want it elsewhere.
iii) 2D Input of 2-argument eval is a choice.

Download roman_in_subscript_example_ac.mw

@Mapleliquid As I wrote before, you cannot be directly using RGB since that requires three layers, ie. here, three matrices or sets of data.

And you only have a single Matrix whose number of entries matches the number of grid points in the plot.

So (instead of RGB) I have used your single Matrix of data can be used to specify the HUE of an HSV colorspace.

Note that in my second example I used the HSVtoRGB command from the ColorTools package. That's why I scaled the 0.0..1.0 values (from FitIntensity) by 360, like degrees.

The GUI's plot renderer can attempt its own rescaling of data, but it does well/best with just the 0.0..1.0 range. But it gets into numeric difficulty if the data is scaled too far from that; I happened to use the 0..360 scaled data (which my second example needs) for both approaches, since the GUI could handle that.

So, you could the 0.0..1.0 range for the first method I showed, and the 0..0..360.0 range for only the second. Here that is:  Plot1_ac2.mw