@Markiyan Hirnyk
e2 - don't get it. And trying for me is little bit hard because input expression in general case not known. I noticed that sometimes i need radical, simetimes need power, but most of them i need size. And symbolic just to do for 'size' things be little bit easier...

So complicated :(. OK, what about then shortest form of writing if i want point out order? Let say, radical, symbolic and size at end.
I mean simplify(simplify(simplify(expr, radical), symbolic), size) too long...

So complicated :(. OK, what about then shortest form of writing if i want point out order? Let say, radical, symbolic and size at end.
I mean simplify(simplify(simplify(expr, radical), symbolic), size) too long...

ex.mw

Nice! All i need

Nice! All i need

See solution via ToInert/FromInert pair. But... such power should ignored anyway in subs in future versions.

If someone need too:

FromInert(eval(ToInert(eval(pp)), [_Inert_POWER=proc() local res; if evalb(args[2]=ToInert(1.0)) then
res:=args[1]; else res:=_Inert_POWER(args) end if; return res; end proc]));

@Pseudomodo
Totally agree with timings.  Those remember/caching goes god know where. Anyway, int itself will not be faster,  of course, but message is, that you can directly compile other non-int part. And timings then should be average ones for every procedure with respect to different orders (and restart of course within every order change). But i thought it's unesrtood.

About lexical scoping: the idea is to minimize lexical scoping itsef (i didn't say that it becomes 0 at all). For relatively long H it will be essential. You understand that say string x86 instructions (movs, and so on) are muuch slower than even fpu instructions. Besides no operators grabbing will be present (while operands will be present in both cases).

Really nothing special... Now i understand. Moreover it becomes clear for me why you can use in body of that proc u as [args] and manipulate them. Nice trick anyway.

Really nothing special... Now i understand. Moreover it becomes clear for me why you can use in body of that proc u as [args] and manipulate them. Nice trick anyway.

All i need op(0,expr). Thanks

All i need op(0,expr). Thanks

@epostma 

Today checked again. Everything is OK. Smth wrong happens to me yesterday :(

let say H:=int(exp(x^6),x=0..b);

will not work :(  Even prep2trans doesn't help. Besides t for compiled H is not evalhf-able and eval for t is not so easy to encapsulate. See parallel branch.

let say H:=int(exp(x^6),x=0..b);

will not work :(  Even prep2trans doesn't help. Besides t for compiled H is not evalhf-able and eval for t is not so easy to encapsulate. See parallel branch.