My case relates to every expressions, not only rtables. And expressions assumed to fully calculable (because they are under global scope). Actually i've written workaround:

ReassumeVars:=proc(allconditions)
  local li, var, condition;
  global DummyVar;
  #
  for condition in allconditions do
    var:=op(1, condition[1]);
    for li in anames('user') do
      if type([eval(li)], list(symbol)) and evalb(li<>var) then
        assign(li, subs(var=DummyVar, li));
      end if;
    end do;
    assign(evaln(var), evaln(var));
    assume(condition[]);
    for li in anames('user') do
      if type([eval(li)], list(symbol)) and has(li, DummyVar) then
        assign(li, subs(DummyVar=var, li));
      end if;
    end do;
  end do;
end proc:

with input [[a<=amax, a>=amin], [b is real]] or whatever. Should work.

@Axel Vogt 

Found maybe not so fast way but rather universal and easy to implement way for calculation of  LerchPhi(z,a,v) for |z|<1, a>=1 - integer, v>1 (two areas 0<v<0.5 and 0.5<v<1.0 should be proceeded in two, i suspect, independed ways, tried to do smth for v<0.5 via asymptotic function but didn't succeed). With bigger 'a' differences in  timings become even more drammatic.lp2.mw

And yes, lpw>1 is "more is better". Not lpv, that just simply >0. lpv<1 has other sense than lpv>1 but it still interest . It returns for sigma to be just >-1. Values of sigma<-0.5 are need totally different approach because of infinity in phi=pi. While i just wonder why for 0>sigma>-0.5 L returns complex numbers...It's clear: phi_cutoff isn't correct.

More about functions: -2+x*cos(phi)+x rather decreases at [0, pi] from -2+2*x to -2. (x>0) . Yeah, all of that looks to be overcomable.

@Axel Vogt 

Just have nothing to say. So, LerchPhi is far away to be optimized - it's just signal for developers. All i need in my task is to calculate also LerchPhi(y,n,b) for integer n up to 3, which naturally arose after differentiating that stuff by 3rd parameter. As i understand those weights are universal (given by Beyer in 1987?), so question is just in changing K. To do this i need more information: is that Gauss-Legendre applicable well for monotonous functions only? Is that why you need to find maximum first?

@Axel Vogt 

So besides the precision problem with evalhf you
would appreciate a fast numerical LerchPhi?

Yes

And if it is so: what are the (typical) ranges for
the 3 inputs?

Physical sense have values lpv>0, lpw>1. Last one principally "more is better". I planned to analyze up to 1000. For lpu  - it's just >0 and will be what will be. I mean, question there is not about "typical" values, it's rather about "what happens in those big values" i.e. it's just research scope.

@Axel Vogt 

Forget for one minute about all that callback stuff. I'm totally satisfied with round-off value, i don't need exact otherwise calculation will be too slow because LerchPhi is slow itself.

For exact value in this example you can apply

MakeExactEvalfProc:=proc(p::procedure)
  local lv:=convert(eval(p),list), arrdim:=eval(op(2,op(2,(op(2,lv[1]))))),arrname:=eval(op(op(2,eval(p))));
  lv := eval(subsop(1 = 'arrname = 'Array'(1 .. arrdim)', lv));
  lv:=`codegen/makeproc`(lv,locals=[arrname],parameters=[op(1,eval(p))]);
  return eval(lv);
end proc:

on FMain as parameter. Sorry that you waste your time on this.

-------------------

Let's consider much simpler example:

p:=proc(x) local larr; larr:=Array(1..3); larr[1]:=x; larr[2]:=larr[1]*larr[1]; larr[3]:=larr[2]/x; end proc;

Even with Digits=10 evalf(p(10^180)) returns correct value 10^180 while

evalhf(p(10^180)) returns Float(infinity). And with former example i showed that  it's not enough to have double precision for practical functions while software floats are great in that sense that they not seem to have bounds for exponenta, i.e. Digits applicable for mantissa only.

@Axel Vogt , oh, of course

DBL_MIN, DBL_MAX because we have double calculation for now. Thank you. 

About sheet... It's, of course, rather a piece of main sheet. Purpose - fastest calculation of FMain.
So, keys to do so
1) All calculations are in evalhf environment
2) For noncalculable in evalhf functions create callback to evalf to calculate them too. 
3) Precision of eval/evalf environment could variate to do best fit in precision/time of calculation (eval_callback_toler variable)
4) If arguments are close enought to calculated before - function value simply retrieved from cache.
For now it's simply=7 (map(proc() evalf[7](args); end proc, func))
5) All variables in FMain, created in symbolical stage when this FMain was formed, are packed in hfarray
 (it seems to be little bit faster than packing them into simply array, what `codegen/packlocals` do).

And main drawback are round-offs... And if i satisfied with eval environment (so far, 
if you know method to create NonEvalhfCacheWithRemember even faster, i would appreciate;
my simple profiler shows that in this case of LerchPhi NonEvalhfCacheWithRemember takes 30% more to 
cache/retrieve values),
there are still many nuances in evalhf itself, includding those overflows...With long double situation should be
only little bit slower but defenetly better. Without them... I actually  don't know how to calculate this one in
fast way and prevent at least those unnecessarry errors. I completly understand why calculation take such strategy.
I beleive that  'codegen/optimize' within other things just minimizes division operations => 
both numerator and denominator become big out of DBL_MAX.

Bad example. It's simply reccursive assignment. Have smth else. Still don't know :(

nice tip! To memorizzz!

nice tip! To memorizzz!

It's OK, i actually don't need do smth with params, but rather with locals i.e. those symbols that codegen/optimize create (_t1, _t2, ...). And if idea with array could avoid that problem i'll consider how to apply codegen/packlocals. It should help.

It's OK, i actually don't need do smth with params, but rather with locals i.e. those symbols that codegen/optimize create (_t1, _t2, ...). And if idea with array could avoid that problem i'll consider how to apply codegen/packlocals. It should help.

@Xilyte 

See ?backslash for more escaped symbols. Most of them (includding \t i.e. 09h in ascii) same as in pure "c" language.

@Xilyte 

See ?backslash for more escaped symbols. Most of them (includding \t i.e. 09h in ascii) same as in pure "c" language.

hasn't parsed plot structure itself till today. Cool stuff :)