You may see that the trace() (that always returns 1) is eliminated from the expression, thus making this kind of use impossible. I may use line() to overcome it, but doing this is less convenient (takes more restructuring) than this technique.

So I ask Andrey, if possible, please disable optimizing out the trace() call. (Yes, I understand that passing a complex expression as an argument to F() may result in side effects, but this is up to user who wants to trace things.)

I also don't think so; vectorize() was used only to make multiple calls to the function to demonstrate that the output doesn't contain the multiple traces.



Thank you. Well, I know the solutions (I cited one of them above); I included the tooltip to demonstrate the elimination in the resulting internal representation of the function; I only asked for a new possibility - to avoid the exclusion of trace() while processing the function definition on the grounds that SMath knows that its result is always 1. trace() is a debug function; it's not wise to eliminate debugging facilities (it's not C++, where I may use conditionals to control inclusion of debugging facilities).

Edited by user 30 March 2016 03:17:15(UTC)  | Reason: Not specified

By the way: it would be awesome, if trace() woudn't return 1, but instead returned its argument itself (unchanged, unlike eval()). This way, we could simplify everything.
Consider this:

F(x;y):=x*y

I want to trace x. So instead of what I have to do now:

F(x;y):=trace(eval(x))*x*y

I would do simply

F(x;y):=trace(x)*y

This way, the very problem of trace() elimination could be solved, because its return would not be constant, but depend on its (last?) argument.
And by the way: eval() in trace won't work nicely in case of vectorize(), because it will trace the vector value of argument, not the individual params (thus, for instance, will be unhelpful if I want to find which specific input gives error and stops execution).