They’re doubles. vpa() is simply choosing to display non-significant digits beyond the floating point relative accuracy, where printf() and disp() truncate or zero them out.
You’re only getting your original four digits back out because the literal you chose to initialize num with just happens to be the exact decimal expansion of a binary double value, because it was copy and pasted from the output of the expansion of an actual double value from the other question. It won’t work for other nearby values, as you show in your “BONUS” addendum.
More precisely, all numeric literals in Matlab produce values of type double. They get converted to the binary double value that is nearest to the decimal value they represent. In effect, digits in a literal beyond the limit of precision of the double type are silently dropped. When you copy and paste the output of vpa to create a new variable, as the other question’s poster did with the e = ... statement, you’re initializing a value from a literal, instead of dealing directly with the result of a previous expression.
The differences here are just in output formatting. I think what’s going on is that vpa() is taking that double precision binary double and treating it as an exact value. For a given binary mantissa-exponent value, you can calculate the decimal equivalent to arbitrarily many decimal places. If you have a limited precision (“width”) in the binary value, as you do with any fixed-size data type, only so many of those decimal digits are significant. printf() and Matlab’s default display handle this by truncating the output or displaying non-significant digits as 0. vpa() is ignoring the limits of precision and continuing to calculate as many decimal places as you request.
Those additional digits are bogus, in the sense that if they were replaced by other values to produce a nearby decimal value, they would all get “rounded” to the same binary double value.
Here’s a way to show it. These values of x are all the same when stored in doubles, and will all be represented the same by vpa().
x = [
2.7182818284590455348848081484902650117874145507812500
2.7182818284590455348848081484902650117874145507819999
2.7182818284590455348848
2.71828182845904553488485555555555555555555555555555
exp(1)
]
unique(x)
Here’s another way of demonstrating it. Here are two doubles that are very close to each other.
x0 = exp(1)
x1 = x0 + eps(x0)
vpa(x0) and vpa(x1) should produce outputs that differ a lot past the 16th digit. However, you shouldn’t be able to create a double value x such that vpa(x) produces a decimal representation that falls between vpa(x0) and vpa(x1).
(UPDATE: Amro points out that you can use fprintf('%bx\n', x) to display an exact representation of the underlying binary value in hex format. You can use this to confirm the literals map to the same double.)
I suspect vpa() behaves this way because it treats its inputs as exact values, and polymorphically supports other Matlab types from the Symbolic Toolbox that have more precision than doubles. Those values will need to be initialized by means other than numeric literals, which is why sym() takes a string as an input and vpa(exp(1)) differs from vpa(sym('exp(1)')).
Make sense? Sorry for the long-windedness.
(Note I don’t have the Symbolic Toolbox so I can’t test vpa() myself.)