MaplePrimes - comments on Post, One more argument for long double

MaplePrimes - comments on Post, One more argument for long double http://www.mapleprimes.com/posts/130249-One-More-Argument-For-Long-Double en-us 2026 Maplesoft, A Division of Waterloo Maple Inc. Maplesoft Document System Wed, 10 Jun 2026 21:00:13 GMT Wed, 10 Jun 2026 21:00:13 GMT The latest comments added to the Post, One more argument for long double http://www.mapleprimes.com/images/mapleprimeswhite.jpg MaplePrimes - comments on Post, One more argument for long double http://www.mapleprimes.com/posts/130249-One-More-Argument-For-Long-Double DBL_MIN, DBL_MAX http://www.mapleprimes.com/posts/130249-One-More-Argument-For-Long-Double?ref=Feed:MaplePrimes:One more argument for long double:Comments#comment130254 <pre>I do not understand your sheet in detail, but before the final section you say the error comes by LDBL_MIN, LDBL_MAX</pre> <pre>Note, that evalhf is not even IEEE compliant. Using Digits:=18 and Maple 15: </pre> <pre>DBL_MIN; evalhf(%);                                                -307                          1.00000010000000001 10     DBL_MAX; evalhf(%);                                                307                           9.9999999000000002 10    The first is 5060056838688399/9007199254740992*pow(2,-1019), and the last 5010420849918223/9007199254740992*pow(2,+1024) But DBL_EPSILON is correct (have not checked other constants. I think there have been posts by 'acer' about that.</pre> The latest comments added to the Post, One more argument for long double 130254 Wed, 01 Feb 2012 23:39:28 Z Axel Vogt Axel Vogt of course, DBL_MIN, DBL_MAX http://www.mapleprimes.com/posts/130249-One-More-Argument-For-Long-Double?ref=Feed:MaplePrimes:One more argument for long double:Comments#comment130260 <a href="http://www.mapleprimes.com/posts/130249-One-More-Argument-For-Long-Double#comment130254">@Axel Vogt</a> , oh, of course <pre>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.</pre> The latest comments added to the Post, One more argument for long double 130260 Thu, 02 Feb 2012 03:48:54 Z icegood icegood More or less (but vaguely) I understand http://www.mapleprimes.com/posts/130249-One-More-Argument-For-Long-Double?ref=Feed:MaplePrimes:One more argument for long double:Comments#comment130293 <pre>More or less (but vaguely) I understand: NonEvalhfCacheWithRemember is a kind of test-evaluation for evalhf. I do not have a feeling, where those problem may come from the code or how to improve it, since I guess your FMain is an example (otherwise you would have treated the 2 occurrencies of LerchPhi in a different way. And for that example I would have tried with 'option hfloat'. I guess it is part of your efforts to use evalhf for non-evalhf'able functions in a seemingless way? Edited (about 1 hour later) for the following: I think the 'correct' value for lpu=200,lpv=100,lpw=1 is -.130870138625117831910143506853e-7 For that I used Digits=30, took the 'body' in your FMain to get the final expression, converted to rational and evaluated the input with Digits=300 (and the usual LerchPhi without the construction) So there is a cancellation problem in both evalf and evalhf, if the digits are too low (may be towards your guess on rationals and differences). </pre> The latest comments added to the Post, One more argument for long double 130293 Fri, 03 Feb 2012 00:11:31 Z Axel Vogt Axel Vogt Problem is other one http://www.mapleprimes.com/posts/130249-One-More-Argument-For-Long-Double?ref=Feed:MaplePrimes:One more argument for long double:Comments#comment130305 <a href="http://www.mapleprimes.com/posts/130249-One-More-Argument-For-Long-Double#comment130293">@Axel Vogt</a>  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. The latest comments added to the Post, One more argument for long double 130305 Fri, 03 Feb 2012 15:46:39 Z icegood icegood now i got it http://www.mapleprimes.com/posts/130249-One-More-Argument-For-Long-Double?ref=Feed:MaplePrimes:One more argument for long double:Comments#comment130310 <a href="http://www.mapleprimes.com/posts/130249-One-More-Argument-For-Long-Double#comment130305">@icegood</a>  Now I got it. So besides the precision problem with evalhf you would appreciate a fast numerical LerchPhi? And if it is so: what are the (typical) ranges for the 3 inputs? The latest comments added to the Post, One more argument for long double 130310 Fri, 03 Feb 2012 19:14:47 Z Axel Vogt Axel Vogt @Axel Vogt  So besides the precision http://www.mapleprimes.com/posts/130249-One-More-Argument-For-Long-Double?ref=Feed:MaplePrimes:One more argument for long double:Comments#comment130312 <a href="http://www.mapleprimes.com/posts/130249-One-More-Argument-For-Long-Double#comment130310">@Axel Vogt</a>  <blockquote> So besides the precision problem with evalhf you would appreciate a fast numerical LerchPhi? </blockquote> Yes <blockquote> And if it is so: what are the (typical) ranges for the 3 inputs? </blockquote> 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. The latest comments added to the Post, One more argument for long double 130312 Fri, 03 Feb 2012 20:37:48 Z icegood icegood