# Why Euler's number e = 2.71828... is not a built-in constant in MATLAB?

280 visualizzazioni (ultimi 30 giorni)
Kareem Elgindy il 17 Giu 2020
Commentato: Paul il 10 Lug 2023
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?
Below is a conversation between me and MATLAB illustrating why MATLAB developers have ZERO common sense... Enjoy the conversation dear fellows and no regret for MATLAB staff...
Me: Hello MATLAB, how is things?
MATLAB: All good! How can I serve you today sir?
Me: Yes, please. Could you give me the value of Euler's number? You know... it's a very popular and fundamental constant in mathematics.
MATLAB: Sure, but wait until I call the exponential function and ask it to evaluate it for me...
Me: Why would you call the exponential function bro??? Isn't Euler's number always constant and its value is well known for thousands of digits?
MATLAB: You will never know sir... Maybe its value will change in the future, so we continuously check its value with the exponential function every time I'm turned on...
Me: You do WHAT!!!
MATLAB: Well... This is a normal procedure sir and I have to do this every time you turn me on...
Me: Stop right there and don't tell me more please...
MATLAB: No, wait sir... I agree with you that this is perhaps one of the most cloddish things that was ever made in the history of programming, but what can I do sir? The guys who developed me actually believe that this is ingenius.
Me: Ooooh oooh ooooh.... reeeeeally!!! Now ain't that something...
MATLAB: They say sir that this is for your security plus there are no applications for that number sir, so why should they care? Even Euler himself, if resurrected again, would fail to find a single application for that number sir. Probably Jacob Bernoulli, the first to discover this number in 1683, would fail also sir, so why should we bother sir? Though it's a mathematical constant and deeply appreciated by the mathematicians around the world for centuries, we don't respect that number sir and find it useless.
Me: Who decides on the importance of Euler's number as a mathematical quantity? Mathematicians or the guys who develop you?
MATLAB: The guys who develop me sir; right?!?!?!?!?
Me: Bro I was obsessed with you in the past and I was truly a big fan of you for more than a decade. But, with the mentality I saw here from the guys who develop you, I believe you will beset with fundamental issues for a long time to come bro... No wonder why Python have beaten you in many directions and became the most popular programming language in the world. Time to move to Python you closed minded and thanks for helping me in my research works in the past decade!!! Good bye for good.
MATLAB: Wait sir... Don't leave please... As a way to compensate for the absence of Euler's number, we offer the 2 symbols i and j sir to represent the complex unity, so the extra symbol is a good compensation for Euler's number...
Me: What did you just say?
MATLAB: Say what?
Me: You provide 2 symbols to represent the same mathematical complex unity quantity, but you have none for Euler's number???
MATLAB: Yeeeeeeeap... you got it.
Me: You can't be serious!
MATLAB: I swear sir by the name of the machine I'm installed in that this is true; I'm not making that up.
Me: But why 2 symbols for the same constant; pick up one for God sake!
MATLAB: Well... There is a wisdom sir for picking 2 symbols for the same constant not just 1.
Me: What is it?
MATLAB: Have you seen the movie "The Man in the Iron Mask" written by Alexandre Dumas and Randall Wallace or read the novel "The Three Musketeers," by the nineteenth century French author Alexandre Dumas sir?
Me: I only saw the movie. But why???
MATLAB: Then you must have heard the motto the movie heros lived by in their glorious youth, "One for all, all for one".
Me: Yes, I did...
MATLAB: We sir were very impressed by this motto, so we came up with a new one.
Me: Impress me!
MATLAB: "i for j, j for i".
Me: You're killing me...
MATLAB: Wait sir, there is more...
Me: More what?????
MATLAB: Many experts around the world project that the number of letters to represent the complex unity in MATLAB may reach 52 letters sir by the end of 2050, so that you can use any English letter (capital or small) to represent the complex unity. How about this sir? Ain't this ingenious also? Sir ?!!?!?!?!?
Me: And this is when common sense was blown up by a nuclear weapon... This circus is over...
##### 24 CommentiMostra 22 commenti meno recentiNascondi 22 commenti meno recenti
Matt J il 6 Lug 2023
Modificato: Matt J il 6 Lug 2023
But e is a very common constant in mathematics and it is as important as pi... As a way to compensate for the absence of Euler's number, we offer the 2 symbols i and j
Note, pi, i, and j are also not builtin Matlab constants. They are function-generated as well:
>> pi(1)
Error using pi
Too many input arguments.
>> i(1)
Error using i
Too many input arguments.
>> j(1)
Error using j
Too many input arguments.
Steven Lord il 7 Lug 2023
Me: You provide 2 symbols to represent the same mathematical complex unity quantity
That's correct. MATLAB allows users to use either i or j in constructing complex numbers. You see Cleve Moler, the chief scientist and co-founder of MathWorks and the original author of MATLAB is a mathematician and the standard way to write sqrt(-1) in mathematics is i. But Jack Little, president and co-founder of MathWorks, has a background in electrical engineering. [See the section titled "Jack Little" in that post on Cleve's blog.] MathWorks products are quite heavily used in various engineering fields, and in engineering fields where i means something else the square root of -1 is commonly denoted as j.
From Wikipedia: "In contexts in which use of the letter i is ambiguous or problematic, the letter j is sometimes used instead. For example, in electrical engineering and control systems engineering, the imaginary unit is normally denoted by j instead of i, because i is commonly used to denote electric current."
So this isn't a MathWorks convention, it's a math and engineering convention.

Accedi per commentare.

### Risposte (2)

John D'Errico il 18 Giu 2020
Modificato: John D'Errico il 18 Giu 2020
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
phi =
1.61803398874989
in case you ever need it. Or you could compute it in this form equally useful form:
phi = (sqrt(5) - 1)/2
phi =
0.618033988749895
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.
vpa(eulergamma)
ans =
0.5772156649015328606065120900824
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)
E =
2.71828182845905
>> exp(2.5)
ans =
12.1824939607035
>> exp(2.5) - E^2.5
ans =
-3.5527136788005e-15
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:
sprintf('%0.55f',exp(2.5))
ans =
'12.1824939607034732347301542176865041255950927734375000000'
% If you use E^2.5,
sprintf('%0.55f',E^2.5)
ans =
'12.1824939607034767874438330181874334812164306640625000000'
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.
vpa(exp(sym(2.5)))
ans =
12.182493960703473438070175951168
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)))
E =
2.71828182845905
>> exp(2.5) - E^2.5
ans =
1.77635683940025e-15
>> sprintf('%0.55f',E^2.5)
ans =
'12.1824939607034714583733148174360394477844238281250000000'
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))
ans =
0.0015833418125
>> timeit(@() E.^X)
ans =
0.0068411758125
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.
##### 28 CommentiMostra 26 commenti meno recentiNascondi 26 commenti meno recenti
Kareem Elgindy il 27 Giu 2020
Modificato: Kareem Elgindy il 27 Giu 2020
Hi David,
This is a nice remark. When we invoke exp(1) and en in MATLAB we get
>> exp(1)
ans =
2.718281828459046
>> en
ans =
2.718281828459045
You referred to the value of exp(1) here as being `a more precise expression to 15 decimal places'. Surprisingly, it isn't! To verify this matter, let us check using multiple resources:
1. If you check Wikipedia at https://en.wikipedia.org/wiki/E_(mathematical_constant), you'll see there that, and I'm quoting, 'The numerical value of e truncated to 50 decimal places is 2.71828182845904523536028747135266249775724709369995...'
2. If you are interested to see the digits representation of Euler's number to 10,000 digits, see https://www.math.utah.edu/~pa/math/e.html.
3. I used MATHEMATICA to display the digits of Euler's number to 21 digits precision and here's what I discovered
4. If we display Euler's number to 16 accurate significant digits using MATLAB symbolic toolbox we get
>> vpa(exp(sym(1)),16)
ans =
2.718281828459045
which is the same value obtained by en. From the above arguments, you can understand now that it's in fact more accurate to use en instead of exp(1) in double-precision floating point systems. You can add this as another advantage of using en.
Best wishes,
Dr. Kareem
David Goodmanson il 27 Giu 2020
Modificato: David Goodmanson il 27 Giu 2020
Hi Kareem,
you are correct. I rather expected that vpa(exp(1),25) would give the right result and was going with that, but
vpa(exp(1),25)
ans = 2.718281828459045534884808
^
whereas
vpa(exp(sym(1)),25)
ans = 2.718281828459045235360287
is correct.

Accedi per commentare.

Jan il 5 Lug 2023
What an epic discussion. Some levels less sophisticated:
I needed exp(1) in a line of code called very frequently. exp() is an expensive function, such that a locally defined constant is efficient:
N = 1e6;
tic
for k = 1:N
A = (20 * exp(1) + 63) / (100 * exp(1) - 50);
end
toc
Elapsed time is 0.017215 seconds.
tic
for k = 1:N
B = (20 * en + 63) / (100 * en - 50);
end
toc
Elapsed time is 6.074733 seconds.
tic
exp1 = exp(1);
for k = 1:N
B = (20 * exp1 + 63) / (100 * exp1 - 50);
end
toc
Elapsed time is 0.006386 seconds.
function y = en(x)
if nargin ~= 0
y = exp(x);
else
y = exp(1);
end
end
##### 14 CommentiMostra 12 commenti meno recentiNascondi 12 commenti meno recenti
Walter Roberson il 10 Lug 2023
I had reported to Mathworks some inconsistencies in the handling of symbolic π . Minor issues that I thought would be easily fixed. Instead Mathworks choose to make sym('pi') into just a plain variable that did not indicate the constant, breaking years of common use. I'm still a bit bummed out about it. I feel it is ineligent and error-prone to count on sym(pi) recognizing that the input value is "close enough" to π and converting that to the constant
sympref('floatingpoint', false)
ans = logical
1
X = pi - 1e-14;
X - pi
ans = -1.0214e-14
sym(X)
ans =
π
delta = (1:100)*1e-15;
X = sym(pi - delta);
maxdelta = 6.9000e-14
so anything closer than roughly 69e-15 to pi is counted as-if it is π
maxdelta / eps(pi)
ans = 155.3742
which is roughly 155 times eps -- it is not a matter of "aliasing", Mathworks has deliberately permitted "slop" to be considered "close enough" to match.
Paul il 10 Lug 2023
Having the symbolic variable sym('pi') display as π does have its uses and is consistent with how other symbolic variables are displayed as shown in this comment and this comment. If a change really is warranted in how sym('pi') is displayed, maybe it should be a sympref.

Accedi per commentare.

### Categorie

Scopri di più su Mathematics in Help Center e File Exchange

### Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by