Why Euler's number e = 2.71828... is not a built-in constant in MATLAB?
494 ビュー (過去 30 日間)
I understand that we can produce that number in MATLAB by evaluating exp(1), or possibly using exp(sym(1)) for the exact representation. But e is a very common constant in mathematics and it is as important as pi to some scholars, so after all these many versions of MATLAB, why haven't they recognize this valuable constant yet and show some appreciation by defining it as an individual constant rather than having to use the exp function for that?
回答 (2 件)
John D'Errico 2020 年 6 月 18 日
編集済み: John D'Errico 2020 年 6 月 18 日
Let me add this as an answer, because there are very good reasons to leave e as not a named constant, instead of naming it. Yes, they could have given you e, as well as pi and i. To be honest, there is just as good of an argument to have created many such named constants. For example, phi, the golden ratio. phi appears in zillions of places in mathematics. Luckily, phi is easy to compute, as
phi = (1 + sqrt(5))/2
in case you ever need it. Or you could compute it in this form equally useful form:
phi = (sqrt(5) - 1)/2
which happens to be just the inverse of the first.
But then there is the Euler-Mascheroni constant, often called the Euler gamma, or just gamma by some. And we already have a hugely valuable function named gamma, which computes the gamma function. I use gamma a LOT as a function. But some people would want to see the Euler gamma as a constant too.
You can actually find this in the symbolic toolbox as eulergamma.
Note that it exists as a function with a long name, but it is there if you need it. And some people would have great arguments to include Avogadro's number, the Planck constant, or the speed of light. So there are some named constants. But really only the two of them. If it bothers you, you could theoretically write a function for e, but in fact, I strongly recommend that you do not do so in the case of e!
It would not have cost a lot, or so it would seem. It would have created some possible places for confusion as the comments suggest, because e is used by itself as an indicator of scientific notation.
If for some reason, you wanted the number, you can always compute it directly as exp(1). So this is even easier than computing the golden ratio constant. But let me ask you this: Why do you think you want it? Why do you think you want the number e in MATLAB?
Really, there is only one reason why you might want to have e laying around. That is to use it in the form e^x. There is a fundamental problem in that idea though, because it is both more efficient and more accurate to use the exp function directly. And exp(x) is used a LOT in mathematics. If the creators of MATLAB wanted to encourage people to compute e^x, they would have provided you with the constant e. But they really don't want to do that.
So you have the function exp. In fact, this is a commonly provided function in almost every computer language you will ever learn. Everything from spreadsheets to fortran to languages like MATLAB and Python. They will have a function probably called exp. It does exactly what you expect. It computes exp(x), and is highly optimized to compute exactly that function to within machine precision.
If you were to start writing it in the form of e^x, then this would put more load on less efficient libraries, that are set up to raise some arbitrary number to a power. In fact, we can even test this out:
E = exp(1)
>> exp(2.5) - E^2.5
Interesting, no? It looks like exp(2.5) and E^2.5 produce slightly different results. Which is closer to the true value? Remember that E is a number pretty much as close as we can produce in MATLAB, to double precision accuracy. It won't help if you provided 20 significant digits for e, as MATLAB can store only 52 binary bits in the end anyway.
% What MATLAB produces using exp:
% If you use E^2.5,
As you can see, they differ down in the digits where one goes ...034732, and the alternative goes ...034767. But which is closer to the truth? We can test that out using VPA and the symbolic toolbox.
Here we see the correct value of exp(2.5) goes ...034734.
Essentially, we got an extra decimal digit of accuracy, by using the function exp. And it would not have helped if we defined E differently. We still get the wrong answer. Here, for example, I might use the symbolic toolbox to create E. In the end, it will be a double precision number, stored internally using an IEEE arithmetic floating point format.
E = double(exp(sym(1)))
>> exp(2.5) - E^2.5
Again, we get a result that is not as accurate as just using exp(2.5).
Thus in terms of accuracy, you want to use the function exp. But there are always two things we care about in computing, accuracy and speed. So how about speed? Here, remember that E is the constant we have created. It is a double precision number.
X = rand(1000);
>> timeit(@() exp(X))
>> timeit(@() E.^X)
Interesting, no? It is actually more than 4 times as fast to compute exp(X) as it was to compute E.^X. What are the odds someone who was doing some truly heavy duty computing would be upset if they saw such a differential in time? Honestly, they would have a fit.
Finally, how about consistency? Suppose The MathWorks decided to do as you wish, and they provided a named constant for e? I don't totally care what short name they chose. Think about what will happen. Now, every time someone tries to compute exp(x) versus e.^x, they might get subtly different results. Different down in the least significant bits, but DIFFERENT! Can you imagine the number of headaches they would have, trying to deal with this? The number of bug reports they would get?
So let me ask you to NOT define your own constant for E. You could do so, as some have suggested. But you will be happier in the end if you don't. You think you want it, but sometimes, what you think you want is an illusion. Just use the function exp, as people all around the world have happily done for many years. There are even several good reasons to do so.