It differs from Python's NumPy's:
exp(-0.305175781250000000) == 0.736993813311010992...
np.exp(-0.305175781250000000) == 0.736993813311010881...
yet for most inputs on the case I first checked, they are identical:
exp(-0.476837158203125000) == 0.6207436040675000654687210044357925653457641601562500000
np.exp(-0.476837158203125000) == 0.6207436040675000654687210044357925653457641601562500000
Yet, checking on another linear sweep, -10:.002:10-.002 == np.arange(-10, 10, .002) , none of the values exactly match, instead the difference grows exponentially, and signed relative difference, (a-b)/a, linearly vs linear sweep of exp. np.exp C source is fairly complicated and involves beyond-mathematical adjustments (e.g. denormal handling). I'm unsure what to make of the systematic error for a general sweep, and exact equality for a selective sweep, for formula equality.
Is MATLAB's exp implementation known?
(This is not an XY problem. My question is exactly as stated.)
High precision applications that are not ready for floating point errors are generally called "low precision applications". If your code is sensitive to this, you are screwed.
In fact, if you compute the smallest change that a double precision number can represent at the scale of your number, i.e. eps(0.736993813311010992), the result is 1.11022302462516e-16, which is exactly 0.736993813311010992-0.736993813311010881, so you are 1 bit away between the two answers. Note that the real answer is 0.73699381331101091470592957743439, so neither of them, its between them.
You can't have a bit-per-bit equal floating point computation in several languages. This is an impossible task to achieve. Any of the following may produce a change of 1 bit in a floating point result within the same programming language: library version, compiler version, processor brand, processor firmware, OS, etc
Any numerical software that requires high precision must be aware of this systematic errors.