HP-71B internal summation weakness in Math ROM

[toml_12953]

(06-05-2020 12:39 AM)Valentin Albillo Wrote:  .
Hi again, J-F:

(06-04-2020 08:18 AM)J-F Garnier Wrote:  Valentin, I strongly encourage you to use DOSBox to continue to use Emu71/DOS ! [...] Even if the performance is reduced due to the two emulation layers, Emu71 still runs at about x8 speed on my quite old core-i3 machine (Win10-64).

Thanks for your advice, J-F, I appreciate it but we've discussed this over PMs a number of times. x8 speed is simply too slow for me, I'm now using go71b which says it runs at 128x speed (probably 60x at most) and it's slow as molasses, so 8x would be simply unbearable (can you imagine, a FOR/NEXT loop counting up to 800 in a second, while anything now counts in the hundreds of thousands at the very very least ?)

Also, you told me that DOSBox doesn't support copy-paste of text and that's a big no-no for me.

Anyway, as you can't/won't issue a 64-bit compatible version of your Emu71 I've decided that I'll simply buy an old XP system and that's that. I'd have already done it were it not for this dreaded confinement but will do it eventually, end of problem.

Quote:Keeping the 15-digit value all along the expression evaluation will create consistency issues, for instance doing A=1/3 @ A+A+A would return a different result, since variables are holding the packed 12-digit forms only.

Your example has nothing to do with mine, as it consist of two separate evaluations, not one, and the first one does assign the 12-rounded result to variable A, so no surprise that A+A+A returns a 12d+12d+12d = 12d result.

What I'm saying is that a single evaluation that proceeds internally in full till it returns the result rounded to 12 digits should never round every partial subexpression while still internally computing the full expression, that's retarded and serves no purpose, even consistency. It should really evaluate the whole expression to 15 decimals internally, then return the final result rounded to 12 digits once it's fully done and no sooner, period.

If not, would you consider it acceptable that while the system is evaluating, say, the value of a sine or exponential, it would round to 12 digits each term, internal sum or multiplication or division or whatever ? Surely not, right ? You'd agree that the whole sin(x) should be evaluated using 15-digit precision wholesale. Same with my 1/3+1/3+1/3.

Quote:An emulator adds the overhead of the CPU/hardware simulation; Free42 is a native application. All depends on the performance of the emulation engine, I can't really judge the x60 ratio but it's the order of magnitude we can expect

I don't concur. A factor of 60x is just too much, no emulation should be that inefficient. Say 10x would be acceptable, if slow, but 60x ? Really ? Converting a 10 seconds running time to 10 minutes ? A 10 minutes running time to 10 hours ? That would be a horribly inefficient emulation, direct-to-garbage-bin class.

I can imagine the poor retarded emulation engine saying to itself: "What's that thingy ahead ? Oh, my, it's a byte ! ... and look, what's this other thing ? Hey, nice, another byte ! ..." and so on and so forth.

Thank you very much for your comments. By the way, I've read your supplementary manual for "Math ROM The Sequel" and have some hopefully useful comments for you, to be sent in a PM or e-mail in the next days.

Best regards.
V.

When I run either an emulation or simulation, I want it to run as identically to the original as possible, including speed. Nostalgia is why I run them in the first place and having them run hundreds or thousands of times faster than the original would ruin the feel of them. When I want speed, I run modern compilers on modern hardware.
My 2¢. YMMV.