This doesn't seem to be an issue with DOSBox, and you're probably better off asking somewhere else about problems in BASIC programming, but here's what stands out to my eye:

1y = x0 + x * (a1 + x*(a2 + x*(a3 + x*a4)))
2    ^^

I think you mistakenly used x0 instead of a0 in that expression, and x0 will have a value of zero unless assigned something else.

No, I did a typing error. I really used y = a0 + etc.

There may be an FPU emulation bug in DOSBox. The problem occurs in QuickBASIC 4.5 and 7.1, but not in QBASIC (possibly because it does not use the FPU). If you use the small program here to indicate that the system does not have an FPU (although it really does), then the problem does not occur in QuickBASIC. Also, as a workaround, the problem does not occur if you add a0 on the end of expression instead of at the beginning. I suspect the issue is in regard to FPU stack handling because of the order-of-operations aspect to the problem, but it's just a guess.

The problem does NOT appear in QuickBasic, where Horner's formula works perfectly, even when a0 is placed at the start of the formula.
I always wrote my programs in QuickBasic and never had that problem.
I had a computer running in Windows XP, but due to the fact that Microsoft did no longer support XP after April 8, I purchased a new computer running in Windows 7.
The latter no longer had the "real" DOS, and that's why I now try DOSBox. I don't understand why Horner's formula gives wrong results in DOSBox, as it is the same QuickBasic programming language. And strangely, when I restrict Horner's formula to 2 or 3 terms, the results are correct.

Jean Meeus

I was referring to QuickBASIC when run in DOSBox, not elsewhere. And in case you overlooked that part, I mentioned that there may be an FPU emulation bug in DOSBox, and I also gave two workarounds for the problem.

Could you give us the actual code you have (either attached file or just the listing) in order to replicate the problem? At first me too didn't think that the problem was dosbox related, I imagined some error in your program, but stating that it only happens when running the same code from within dosbox is interesting...

Here's the code, in case it wasn't obvious from the info given:

1a0 = 9.123
2a1 = .21
3a2 = .12
4a3 = .06
5a4 = .05
6x = .1
7y = a0 + x * (a1 + x * (a2 + x * (a3 + x * a4)))
8PRINT y

As I mentioned before, there may (emphasis on *may*) be an FPU emulation bug in DOSBox, but the Windows XP NTVDM is not a good model for correct behavior, so the issue needs to be tested on a real DOS system with an FPU. In the meantime, the NOFPU program I linked to is an effective workaround.

I tested the BASIC program in QB 4.5 and reproduced the issue. However, the issue does not occur where dosbox is built with the "dynrec core" instead of the "dynamic-x86 core". The issue also does not occur where core=normal.

The OP also made some errors in coding this short example program, including the parameter "a0".

That is odd.. I did a quick debug of the problem and saw the fpu stack being overflowed. I am not sure why the core would influence it (didn't try it myself), if it does, it might be pure luck. I will debug it in more detail later.

The problem occurs in DOSBox 0.74 and vanilla SVN with core=normal on my system, both in QuickBASIC 4.5 and 7.1; can't see any reason why it would be different for others.

I'll continue to experiment, but I should have said that core=normal and core=dynamic are producing different results. The latter an error while the former a value (I will confirm whether that value is correct). JDOSBox and other versions showing same behavior.

Edit: The normal core is producing a wrong result, "0.072265", but the dynamic core shows "-1.#IND". Rearranging the first coefficient, a workaround suggested, produces the correct result (in either core) with presumed rounding, "9.145266".

1a0 = 9.123
2a1 = .21
3a2 = .12
4a3 = .06
5a4 = .05
6x = .1
7REM y1 = x * (a1 + x * (a2 + x * (a3 + x * a4))) + a0
8y2 = a0 + x * (a1 + x * (a2 + x * (a3 + x * a4)))
9REM PRINT y1
10PRINT y2

I also found same result as above with jDOSBox under its normal and "modified normal" cores. Further tried with softfpu=true and false.

Thank you very much for investigating this.

NOFPU seems to be a valid workaround indeed.

I compiled the above program and the resulting binary produces the correct result in dosbox, "9.145266"; even though it does not when run within the quickbasic program (via the quickbasic interpreter). I wonder if the FPU instructions are not used by the quickbasic compiler/linker? Or instead that the problem is mainly quickbasic specific.

It's a quirk of QuickBASIC 4.5, possibly other versions as well, that the IDE uses the coprocessor if present in the system, but the compiler always uses x87 emulation by default. You can disable x87 emulation by including NOEM.OBJ when linking an executable.