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

Question

Kareem Elgindy 2020-6-17

0
链接

此问题的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/549723-why-euler-s-number-e-2-71828-is-not-a-built-in-constant-in-matlab

评论： Paul 2023-7-10

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 个评论
显示 22更早的评论隐藏 22更早的评论

Matt J 2023-7-6

编辑：Matt J 2023-7-6

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 2023-7-7

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.

请先登录，再进行评论。

请先登录，再回答此问题。

Answer 1

John D'Errico 2020-6-18

10
链接

此回答的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/549723-why-euler-s-number-e-2-71828-is-not-a-built-in-constant-in-matlab#answer_453183

编辑：John D'Errico 2020-6-18

在 MATLAB Online 中打开

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.

https://en.wikipedia.org/wiki/Euler–Mascheroni_constant

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 个评论
显示 26更早的评论隐藏 26更早的评论

Kareem Elgindy 2020-6-18

编辑：Kareem Elgindy 2020-6-18

在 MATLAB Online 中打开

Dear John,

Your detailed answer, the time you took to write it, and the effort you made to explain and code examples to support your viewpoint is very much appreciated. However, I have to disagree with you in probably all the points you mentioned. Here is why:

1. Your first argument is based on the fact that all the constants you mentioned like the golden ratio, Euler-Mascheroni, Avogadro's number, the Planck constant, and the speed of light are easy to compute, so no urgent need to define them as I understood from your answer. As you wrote, the golden ratio,

phi = (1 + sqrt(5))/2,

so no need to define it, right? If we follow your argument and apply it on all constants, you will soon realize that your own argument actually contradicts the necessity to define pi as a built-in constant. Notice that all trigonometric functions in MATLAB are well defined, so one can calculate pi as 4*atan(1). Let us check together:

>> format long; format compact
>> pi, 4*atan(1)
ans =
   3.141592653589793
ans =
   3.141592653589793
>> pi == 4*atan(1)
ans =
  logical
   1
>> vpa(pi,50), vpa(4*atan(1),50)
ans =
3.1415926535897932384626433832795028841971693993751
ans =
3.1415926535897932384626433832795028841971693993751   

Notice that one could also try to use the same algorithm used by MATLAB to compute pi to any desired degree of accuracy and speed. The point is: either they define important constants all together, or don't, as they could easily be calculated using a huge library of valuable built-in functions already written by expert programmers.

2. You gave an example showing that exp(2.5) and E^2.5 produce slightly different results, which is absolutely true. However, one can easily refute this argument by simply creating a MATLAB function called E, or en, or whatever, that calculates Euler's number using the very same method the usual exp(1) is calculated in MATLAB as a built-in function; thus sharing the same accuracy and speed. The user-defined function called en that I created in File Exchange produces correct value for 16 significant digits; however, this function can be easily updated to use the very same algorithm used by MATLAB to calculate it without any difficulty and with the convenience of now having Euler's number well defined in MATLAB the same as pi. MATLAB Development Team can use the very same algorithm they are currently using to define E, for example. So again, and back to the former point: "either they define all important constants used frequently in common scientific areas and applications, or not". I'm one of those researchers who personally view E as important as pi in applications, and I hope this matter will be considered seriously in future releases of MATLAB.

Once again I thank you John for your great efforts and time spent to add your contribution; I deeply appreciate it.

John D'Errico 2020-6-18

编辑：John D'Errico 2020-6-18

在 MATLAB Online 中打开

Sorry, but I'll simply need to disagree with you. You are wrong, and in many respects.

The Euler-Masheroni constant is NOT something easy to compute. It is typically defined in terms of a limit of the difference between the harmonic series and the natural logarithm, as as an integral. I suppose you can get it from MATLAB in the form of the digamma (polygamma) function.

-psi(1)
ans =
         0.577215664901532

But you would need to know where to look for it.

And while 4*atan(1) happens to give the same value for pi as is stored in pi itself, that is not true of e. In fact, as I carefully show, there is NO value we can store for E ~ exp(1) that is as good as using the function exp to compute a general exponential.

You would also need to know where to look for pi in the form 4*atan(1). Most students don't. But it is not difficult to teach then to use exp. And you will find an exp function in everything from a spreadsheet to basic to Fortran to Python. exp is pretty much a standard function in all tools I have ever used.

As for pi being necessary, I think students the world around would expect to find pi in MATLAB. Homework question number 2 or 3 will probably require pi anyway. And pi has surely been part of MATLAB since version 1 came out about a million years ago. I'd bet a sum of money they had the variable pi in version 0.1 of MATLAB when they put together the beta version. I can ask Cleve if you feel it important though.

Anyway, we can argue in either direction about the need for other defined constants in MATLAB. Honestly, I don't give a damn either way, except that if the MathWorks were to create too may defined constants, then it would possibly invalidate all sorts of code people have written over the years. And that IS important. For example, suppose the Mathworks were to suddenly introduce a variable with the name en? At that point, ALL legacy code that employs a variable named en that is something else will now potentially start to see bugs. People will suddenly need to worry if they have variables named phi, en, etc. As it is, we can see problems when people create variables with the name eps. Other named constants, like realmax or realmin seem not to be much of a problem. I've never really seen people trying to trample upon inf or NaN. But I seriously doubt the MathWorks wants to introduce new named constants.

So the solution the MathWorks uses is to totally minimize the named constants they provide. When they do provide something, they give it a name liike eulergamma, that won't get stepped upon very easily. If you want some named constant, feel free to create it yourself. Be careful to make it as accurate as possible, but that is your problem entirely. If MathWorks were to provide a golden ratio constant, I would argue for a name like goldenRatio, something that will be not a problem. A lot of people use phi as a variable name for other things.

The real problem is as I said: e as a named constant in MATLAB will have only one common purpose - to compute e^x for those who don't wish to learn to type exp(x). You have shown nothing that counters my claim.

We CANNOT create a function in MATLAB that will return a double precision number E, that in turn can then be used to compute E^X as fast and as accurately as exp(X) does the same thing. I showed that. REREAD MY ANSWER.

One thing that MathWorks seriously does NOT wish to do is create a variable E, such that E.^X does not give identically the same result as exp(X), ALWAYS. Were this to happen, can you imagine the huge number of furious bug reports they would get?

I even show that if you store the symbolic value of e as a double precision number, you still get the wrong result. This is not something the MATLAB development team can do. They have no magical powers in this respect, because exp(X) actually gives better, faster, and more accurate results. I can imagine the laughter at Mathworks if asked to include functionality in MATLAB that is less accurate, slower, and inconsistent? The first person who tried to do that would be given some job coaching.

Sorry. Just learn to use exp as a function. Or feel free to create your own named constant and use it as you wish. But don't expect things to be fast. Don't expect it to be as accurate. And, really, why do you want something slower and less accurate anyway?

Steven Lord 2020-6-18

编辑：Steven Lord 2020-6-18

在 MATLAB Online 中打开

Commenting on a couple points John D'Errico brought up:

So you have the function exp. In fact, this is a commonly provided function in almost every computer language you will ever learn.

In fact, the IEEE standard for double precision (IEEE 754) lists exp as a recommended operation. [To be fair it also recommends exp2 and exp10. We have exp2 as pow2 with one input but we don't have exp10. We also don't always throw the exceptions the IEEE spec suggests, since we have complex numbers available.]

As for pi being necessary, I think students the world around would expect to find pi in MATLAB. Homework question number 2 or 3 will probably require pi anyway. And pi has surely been part of MATLAB since version 1 came out about a million years ago. I'd bet a sum of money they had the variable pi in version 0.1 of MATLAB when they put together the beta version. I can ask Cleve if you feel it important though.

One difference between pi and e (just IMO) is that pi is often used "in isolation" as just a number. The most common use case for e is as the base for a power operation e^something. If pi were only ever used in the context of sin(pi*something) we'd probably only provide a sinpi function.

And pi wasn't in Cleve's original MATLAB (you can see in the User's Guide that in one of the examples he computes it using atan) but it was in PC-MATLAB 1.0 (or at least 1.3, since Cleve mentioned that was the earliest disc he could find. See the Contents section here.)

For example, suppose the Mathworks were to suddenly introduce a variable with the name en? At that point, ALL legacy code that employs a variable named en that is something else will now potentially start to see bugs.

Actually, it's likely the opposite. Remember that variables are higher precedence than functions. If we introduced a function named en and people had:

en = 42;

in their code, they wouldn't be able to call the en function until or unless that variable no longer existed. See:

sum = 0;
sum = sum + ...
% now try to call the sum function
y = sum(x) % likely error or unexpected result

If we made en a keyword like if, for, and while that could break code. But we don't introduce new keywords that often (arguments is I believe the most recent one) and context does matter (methods is only a keyword inside a classdef file.) As precedent, pi isn't a keyword.

James Tursa 2020-6-18

在 MATLAB Online 中打开

A quick follow up about pi. It is often used in "isolation" as John and Steven mention, but it is also often used as part of arguments to periodic trig functions. These trig functions apparently have special code to effectively do the mod 2pi argument reduction to high precision (more than double). It might be nice if MATLAB provided this "high precision mod 2pi" capability as a standalone function, so that users could match what the trig functions do in their own code. E.g.,

>> x = 1e17;
>> sin(x)
ans =
  -0.464530104835373
>> sin(mod(x,2*pi))  % Naive mod 2pi fails to match MATLAB
ans =
     0
>> mod2pi = @(x) atan2(sin(x),cos(x))
mod2pi =
  function_handle with value:
    @(x)atan2(sin(x),cos(x))
>> sin(mod2pi(x))  % Our own mod 2pi function matches MATLAB
ans =
  -0.464530104835373
>> sin(vpa(x))  % vpa matches also
ans =
-0.46453010483537269615452411397506
>> double(ans)
ans =
  -0.464530104835373
  
>> mod(x,2*pi) % range is too great for mod function
ans =
     0
>> mod2pi(x) % but not custom function
ans =
  -2.658488737094681

So, I can mimic what the trig functions are doing in the background with argument reduction with my own mod2pi function, but it costs me three trig function calls to do it.

John D'Errico 2020-6-18

在 MATLAB Online 中打开

I can understand wanting things to be different, to meet your expectations of how mathematics is usually written. But MATLAB is not really a WYSIWYG tool. Instead, it is much more of a text based language. It is optimized for efficiency in usage. We want things to run as fast as possible, to be as accurate as possible. Otherwise we would use a different tool.

For example, long ago, I was using MathCAD for a little while. I'm not even sure that tool is still around. But I recall spending time working with the tool, trying to use it for some computations. I even spent time working with the developers, trying to get them to deal with and repair numerical issues. I gave up, because it seemed at least in the early days that they were more worried about how things looked than how they worked. Again, I have no idea if the tool is still around, and I am sure it has improved since then if it still is.

So yes, the interface is important. But typing in exp(x) compared to perhaps E^x, e^x, or en^x is small potatoes. And if the cost in that computation is it becomes significantly slower or even the slightest less accurate, that is a real cost, a serious one.

X = rand(10000);
>> timeit(@() E.^X)
ans =
           0.7209758528125
>> timeit(@() exp(X))
ans =
           0.2000676988125

And that is a MASSIVE difference in time.

Kareem Elgindy 2020-6-19

在 MATLAB Online 中打开

Being my first time to post a question on this forum and receive this amount of feedback from various participants has been indeed a very exciting experience to me. This would encourage me to more and more rely on this forum to get nice feedbacks about MATLAB. I’d like to add and clarify a few points in the following:

When I initially created this post, it was never my intention to replace the exponential function exp(x) with Euler’s number E, or en, etc., for values of x ~= 1. In fact, what I thought of was to use a simple notation like E to call Euler’s number rather than having to type exp(1), which as a mathematician I didn’t like much 😊. What I initially was thinking of was to use a symbol like E, for example, to do simple arithmetic operations on Euler’s number, operations like addition, subtraction, multiplication, and division. I also prefer to type E rather than typing exp(1) to invoke Euler’s number via MATLAB Command Window. If we define a function called E to provide Euler’s number, we can write something like (20*E+63)/(100*E-50) rather than writing (20*exp(1)+63)/(100*exp(1)-50), which doesn’t look much appealing to me as a mathematician. Of course, it would be of greater appealing if I could write (20*e+63)/(100*e-50), which is not possible as e is booked for 10. We can verify that this is fine through the following code:

>> format long; format compact;
E = 2.718281828459045;
(20*E+63)/(100*E-50)
ans =
   0.529083523398424
(20*exp(1)+63)/(100*exp(1)-50)
ans =
   0.529083523398423
% Using the exact representation of exp(1):
vpa((20*exp(sym(1))+63)/(100*exp(sym(1))-50),16)
ans =
0.5290835233984236

When I created a file and called it E, and put it in MATLAB path, I was curious to learn about the speed of execution, so here is what I had:

>> tic, (20*exp(1)+63)/(100*exp(1)-50), toc
ans =
   0.529083523398423
Elapsed time is 0.000561 seconds.
tic, (20*E+63)/(100*E-50), toc 
ans =
   0.529083523398424
Elapsed time is 0.000346 seconds.

So, calling E was faster than calling exp(1). Of course, this must be true. When I call E I’m calling a constant value already stored, but when I call exp(1) MATLAB would have to calculate the exp function at x=1, which is slower and inconvenient in practice. Why should we evaluate a function at x=1 when its value is already common and known to almost everyone? This is an important subject that I invite MATLAB Development Team to investigate in the future.

For more accuracy on arithmetic computations involving Euler’s number one can use the same algorithm used by MATLAB for computing exp(1). How MATLAB computes exp(1)? In fact, I don’t know.

E^x should never replace exp(x), for x~=1. This never crossed my mind when I created this post.

Generally speaking, any constant when raised to some general power would produce an error in a floating-point system. Consider pi for example and compare it with its exact value when raised to some general power:

>> double(pi^(10+1/10) - sym(pi)^(10+1/10))
ans =
    -7.903172385091404e-11
    

So, it’s not unusual to see a difference between E^x and exp(x), for x~=1. I do support to use exp(x) instead of E^x for general values of x, but I don’t support to write exp(1) instead of E for simple arithmetic operations that only involves E not E^x, for general x values.

I taught MATLAB training courses for like 10 years now, and each time I teach I receive a few questions from students asking me what is the built-in constant notation for Euler’s number, and they would never become satisfied when I say we use the exponential function exp(1).

When @John mentioned a list of constants to support his viewpoint, and gave an example on the golden ratio phi = (1 + sqrt(5))/2, I had a feeling from what I read that all the constants he mentioned were easy to compute according to my understanding of what he wrote. I did not make a research on this list but instead I was referring to his examples. So it turns out that one or two, etc. of this list were not easy to compute… this was not the point anyway. The point is, and let me rephrase it given the previous argument: “either MATLAB defines important constants all together, or don't, as some of these constants could easily be calculated using a huge library of valuable built-in functions already written by expert programmers.”

When @John wrote “suppose the Mathworks were to suddenly introduce a variable with the name en? At that point, ALL legacy code that employs a variable named en that is something else will now potentially start to see bugs.” Correct… But would that mean that MATLAB should now never introduce new built-in functions to avoid conflict with legacy codes! I have to disagree with this opinion. MATLAB should continuously introduce new built-in functions to help researchers do their works with minimal programming efforts. The choice of new names must of course be reasonable and undergoes several checks and smart investigation and revisions before they could be introduced in future releases. Choosing just any new name randomly is a mistake that should be avoided.

@John: “If you want some named constant, feel free to create it yourself.” Good advice from you. I did 😊. See https://www.mathworks.com/matlabcentral/fileexchange/77046-euler-s-number.

@John: “e as a named constant in MATLAB will have only one common purpose - to compute e^x”. I largely agree with you on this point. Most well-known applications involving e would include e raised to some power x~=1. But for theoretical purposes this is not a restriction. As I mentioned before, one may do the 4 standard arithmetic operations on e (addition, subtraction, multiplication, and division) conveniently using a nice notation like E, or en, rather than exp(1). Imagine we had a differential equation and we want to solve it, then plot its solution at a large set of data points. Say, the solution of the differential equation was something like exp(1)*sin(x)/10, and we want to plot its values against x=linspace(0,2*pi,10000). Here is what I found when I compared the speed of coding using exp(1) and the simple function en that I created; see https://www.mathworks.com/matlabcentral/fileexchange/77046-euler-s-number:

    >> x=linspace(0,2*pi,10000); tic,plot(x,exp(1)*sin(x)/10),toc
Elapsed time is 0.005998 seconds.
x=linspace(0,2*pi,10000); tic,plot(x,en*sin(x)/10),toc
Elapsed time is 0.003541 seconds.

So, oops… en wins the race! There are numerous examples I can give showing that the use of en would be much faster than using exp(1), as long as en is not raised to general powers. This deserves attention from MATLAB Development Team… hopefully they won’t laugh at it.

@Bjorn: Apparently my second point was misunderstood. My intention, and probably I didn’t phrase my words well enough when I wrote that point, is that calculating Euler's number using the very same method the usual exp(1) is calculated in MATLAB as a built-in function would produce the same accuracy and speed when exp(1) is involved in an operation. I did not intend when I mentioned these words to use E^x though for the reasons stated above. I meant usual arithmetic operations like addition, subtraction, multiplication, and division. Perhaps what caused the confusion was that I started my second point with a sentence that included exp(2.5) and E^2.5. So, I hope now my argument is clearer. To confirm, it never even crossed my mind to replace exp(x) with E^x for x~=1… never since the moment I was born and forever till the moment I die 😊.

@Steven Lord: “As for pi being necessary, I think students the world around would expect to find pi in MATLAB.” Time for MATLAB Team to think of us as researchers as well. I, as an applied and computational mathematician, need valuable constants to be defined as well. Things like Euler’s number, or the golden ratio, and others would be great to have them all defined in MATLAB. I recall I developed an optimization method during my master studies and the work was published in Applied Mathematics and Computation. In this work I used the golden ratio to locate a minimizer of a function, but unfortunately this significant constant was not defined in FORTRAN—I did the work using FORTRAN back then-- so I had to calculate it and store it in the code. Having a list of important constants arising in various areas well defined in MATLAB can indeed be very convenient and efficient also, because now we can simply invoke them quickly as stored constant values without having to compute them.

@Steven Lord: “I can ask Cleve if you feel it important though.” Thank you. No need for this. The subject is not about pi; it’s about other important constants that require further attention from MATLAB Development Team. I would be curious though if you could ask Cleve about why Euler’s number and other important constants were never introduced in MATLAB until now, and whether there is any intention to consider this subject in the future.

To conclude, I’d generally say the following:

Invoking E to work with is faster than having to calculate exp at x=1.
I never thought of using E^x instead of exp(x) for x~=1. Not for a single moment. My 2ndpoint I mentioned before was unfortunately misunderstood. But I hope now it’s understood.
Apparently most, if not all, real-life applications would involve exp(x), for some general power of x~=1. This could be a major reason for neglecting the idea of defining E for exp(1). However, one may still find at least theoretical problems that would involve only E, so using E would be more convenient and faster; see my earlier example on this matter.
This is a fantastic forum… you made me love MATLAB more and more through your feedbacks and contributions. I used to be an expert of FORTRAN till I started to learn about MATLAB in 2010. I dropped FORTRAN the moment I discovered the beauty of this piece of art called MATLAB. One of the reasons that MATLAB is proud of is having a huge library of built-in functions. This is one of the greatest reasons that attracted me towards this giant software. I hope MATLAB Development Team would someday in the future listen to researchers like me and start defining valuable constants that are common in scientific disciplines and applications to add more and more power to its arsenal of built-in functions and constants.

Best wishes,

Dr. Kareem

David Goodmanson 2020-6-20

编辑：David Goodmanson 2020-6-20

在 MATLAB Online 中打开

Hello Kareem,

When I made the original suggestion, I was thinking of the 'en' function as something for one's personal toolbox, where you can do anything that seems advantageous. One of the benefits of Matlab. Overall, though, I think there are enough reasons why Matlab will likely not adapt this. But at least you can address objections with regard to speed:

function y = en(x)
if nargin ~= 0
 y = exp(x);
else
 y = exp(1);
end
end
en                       % obtain e
  ans =  2.7183
en^2                     % powers of e 
  ans = 7.3891
en(1:.001:10)          % for speed with a large array

I'm happy enough to use exp(1) instead of an explicit 16 digit number since things are fast enough anyway.

I do think 'en' is a far better choice than E, for a couple of reasons. For the first reason, you have provided the perfect example:

(20*E+63)/(100*E-50)

Here it is way, way too easy to confuse E+63 with the scientific notation 1E+63, same for E-50. The other reason is that with 'en' you don't have to use the caps key. Which means that you won't accidentally hit the ##$%^&@*$! caps lock key and have to backspace out a bunch of stuff, which I do at least once a day..

Kareem Elgindy 2020-6-20

编辑：Kareem Elgindy 2020-6-20

在 MATLAB Online 中打开

@David Goodmanson: Thank you for your continuous feedbacks. Your language is extremely polite. You start by addressing people with their names and you never tend to use offensive/mocking words to offend anyone. Thumbs up to you David. I also agree with you that 'en' is a far better choice than E. About the code you described I think it's slower than calling exp(1) because it includes 2 calls to evaluate exp(1): one for en and 1 for exp(1). What I was thinking of was to create a file named say en and use the same technique exercised by MATLAB. Say MATLAB calculates exp(1) using a method called Method A. One can create the file as follows:

function x = en
% Insert Method A below.
end

So now you calculate en using 1 call (in case more accuracy is needed).

@Stephen Cobeldick: Try to put the function exp and en in the same directory and see how it goes. Let MATLAB define en as a built-in function and see how it goes. I don't have to prove it to you that en would work faster. Calling a constant value with a stored value is logically and truly faster than calling a function that involves calculations. This is ABCD common sense! No rational and sensible man on earth can refute this fact even if it hurts some people. Facts do hurt in many cases. I can see one here.

Kareem Elgindy 2020-6-20

编辑：Kareem Elgindy 2020-6-20

在 MATLAB Online 中打开

@Stephen Cobeldick: As a follow up to my last clarification, you should understand that your example is wrong and in many aspects:

You are trying to show that a function that requires calculations is faster in practice than a function defined by a stored value!
When you presented your code you made a huge mistake. You didn't account for function precedence order that MATLAB exercises when it searches/calls a function. Calling a built-in function would generally be faster than calling a user-defined function in large loops, even if the user-defined function was fater than the built-in function-- the reason is simple: MATLAB looks for the built-in function first. So by the time the large loop ends the execution of the operation that requires the built-in function would be relatively smaller than the one for the user-defined function. That's because of the function precedence exercised by MATLAB which is biased to built-in functions I suppose. To verify this point further, I know that variables is probably one of the first things, if not the first, that MATLAB looks for when calling a certain name in the MATLAB Command Window. Before assuming that a name matches a function, MATLAB checks for a variable with that name in the current workspace. So suppose I assign en to a variable called y. Let's check the timing again using your own example:

>> y = en;
>> N = 1e6;
>> tic
for k = 1:N
A = (20*exp(1)+63)/(100*exp(1)-50);
end
toc
tic
for k = 1:N
B = (20*y+63)/(100*y-50);
end
toc
Elapsed time is 0.011791 seconds.
Elapsed time is 0.006986 seconds.

So defining en as a built-in function in MATLAB would kill the function precedence bias and show the true performance of both codes. Any reasonable and fair person would agree with me on this fact.

Stephen23 2020-6-20

编辑：Stephen23 2020-6-23

"You are trying to show that a function that requires calculations is faster in practice than a function defined by a stored value!"

Because sometimes they are.

All other things being equal, I agree completely that a stored value will likely be faster than a calculation. But your timing tests compare inbuilt exp with your own JIT-compiled function, and that is definitely not keeping "all other things equal". A function compiled by the JIT engine is not the same as a precompiled function: for a start it has to be compiled on the fly, and that takes time.

You provided a test comparing apples with oranges, and claimed that the test proved that "So, calling E was faster than calling exp(1). Of course, this must be true." But it isn't. The correct test would be to compare an inbuilt function (with a constant) vs. an inbuilt function (with a calculation), or perhaps two user functions that would both be compiled by the JIT engine. But that is not the test that you presented here: you compared a JIT-compiled function vs an inbuilt function, and clearly their runtimes are not so simple to compare.

The only point I made in my previous comment was that the timings less than 1/10 second are unreliable, exactly as the documentation states. I did not make any statements about what those functions are doing.

"When you presented your code you made a huge mistake. You didn't account for function precedence order that MATLAB exercises when it searches/calls a function"

The function precedence order depends significantly upon the folder where the file is saved (information that I actually did not give in my last comment). The MATLAB documentation describes the function precedence order here:

https://www.mathworks.com/help/matlab/matlab_prog/function-precedence-order.html

The relevant categories given on that page are:

"1. Variables"

...

"10. Functions in the current folder"

"11. Functions elsewhere on the path, in order of appearance... Built-in function ..."

I saved your en file in the current folder (category 10), so it actually had a higher precendence than the builtin exp function (category 11). The word "built" is only used once on that entire page, in category 11.

"Calling a built-in function would generally be faster than calling a user-defined function in large loops, even if the user-defined function was fater than the built-in function-- the reason is simple: MATLAB looks for the built-in function first."

Actually MATLAB follows the function precedence order given in the documentation that I linked to above: a user-defined function saved in the current directory (or a private directory, etc.) will be found before a built-in function that is anywhere else on the Search Path. And of course this will not make any difference to the runtime of the function, just a very tiny difference to the time it takes MATLAB to find the function, which once compiled by the JIT engine is likely not repeated for each function call.

Steven Lord 2020-6-20

In theory, having a function that doesn't need to do any calculations and just return a constant value will be faster than one that needs to do calculations.

In practice, neither is going to be the bottleneck in your code. If it is, I suspect getting that value is all your code is doing.

You could submit this enhancement request to Technical Support using the telephone icon in the upper-right corner of this page. But I'll be honest with you. I know how much it costs to add even the most basic built-in function to MATLAB. That cost is higher than you think it is. [As one example, exp is supported for use with MATLAB Coder and GPU Coder. For parity in functionality, e would need to be supported in code generation as well. That would require at the least testing it in code generation to ensure it works.] Would the benefit of this change (letting users type e instead of exp(1) in their code) outweight the cost to implement and maintain this function? In my opinion, it would not.

You asked a reasonable question, and I think it spawned some interesting discussion, but I'm doubtful that enhancement request would be actioned. Of course there's nothing wrong with writing your own e.m function that returns that constant value. Would it be as fast as if that function were built into MATLAB? Probably not. Would you notice the difference? Probably not.

Kareem Elgindy 2020-6-23

在 MATLAB Online 中打开

@Paul: Hello Paul and many thanks for sharing your comment with us in this forum. You asked two important questions. As for the first question, think of any mathematical model in which one or more of its terms, or perhaps the solution to the model involves an expression like sin(exp(1)*x)+3*exp(1), and we need to compute this expression for a certain range of x-values. Why should we ask MATLAB to calculate the exponential function twice at x=1, when we could easily define exp(1) as a constant, say en, and type sin(en*x)+3*en. This would be faster and computationally cost efficient indeed. Consider the following example:

>> format long; format compact
x=linspace(1,2,4); sin(exp(1)*x)+3*exp(1)
ans =
   8.565626775880046   7.690599490173445   7.171347209837022   7.405799017154221
>> sin(en*x)+3*en
ans =
   8.565626775880045   7.690599490173443   7.171347209837021   7.405799017154219
>> vpa(sin(exp(sym(1))*x)+3*exp(sym(1)),16)
ans =
[ 8.565626775880044, 7.690599490173443, 7.171347209837021, 7.405799017154219]

Of course, if one needs more accuracy than possibly 15 or 16 significant digits, we can then ask MATLAB to evaluate the exp function at x=1—it’s funny though to see that en gave a better accuracy than exp(1) in the above example. So exp was called and computed twice at x=1, at least theoretically took longer for execution, and yet gave a poorer result. On the other hand, en included ZERO computations and gave a better result!

As for your second question, I, as an applied and computational mathematician, never used more than 16 significant digits in all my previous works (which includes solving ODEs, PDES, integral equations, integro-differential equations, nonlinear optimization, and optimal control theory) except when I wanted to compare my approximations with the exact values of the solution—I personally prefer to use MATHEMATICA to do symbolic computations than MATLAB though.

Kareem Elgindy 2020-6-23

@Steven Lord: Thank you for sharing your comments. I'm happy that we share the common viewpoint that a function that doesn't need to do any calculations and just return a constant value will be faster than one that needs to do calculations, at least theoretically. I believe though that if we play a fair game and we neutralize all other factors that could influence the speed of execution of both files, then definitely en wins in speed. For double-precision floating point arithmetic widely common for numerical computations, en is sufficient and very practical to my research needs.

I believe it remains important to ask: why should we evaluate exp at x=1 when e is a very known value? In almost all algorithms I developed in my career so far, I frequently use constant parameter inputs defined as double-precision numbers, i.e. are represented by 16 significant digits. In double-precision floating-point systems, this is typically the case. So why should we ask MATLAB to compute exp at x=1 when we can use its 16 significant digits representation instead. This would be faster and computationally more efficient. How about other important constants like the golden ratio which does not occur redundant with other functions? Why should we calculate them when their values are very known values? One of the reasons MATLAB Developers are proud of is that they have a huge library of functions that can help programmers and users to do certain tasks with minimal programming efforts, but they fail to have even a decent library for important mathematical constants. If they define these constants, we could use them directly in our works without having to calculate them using other functions or formulas.

Your suggestion to submit this enhancement request to Technical Support shows that you are an open minded person and I'm so glad that I'm having this conversation with you. Thanks also for your sincere information about the cost and your expert feedback.

Kareem Elgindy 2020-6-27

编辑：Kareem Elgindy 2020-6-27

在 MATLAB Online 中打开

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:

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...'
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 .
I used MATHEMATICA to display the digits of Euler's number to 21 digits precision and here's what I discovered
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.

Hope this answers your question.

Best wishes,

Dr. Kareem

David Goodmanson 2020-6-27

编辑：David Goodmanson 2020-6-27

在 MATLAB Online 中打开

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.

请先登录，再进行评论。

Answer 2

Jan 2023-7-5

0
链接

此回答的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/549723-why-euler-s-number-e-2-71828-is-not-a-built-in-constant-in-matlab#answer_1267873

在 MATLAB Online 中打开

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 个评论
显示 12更早的评论隐藏 12更早的评论

James Tursa 2023-7-5

编辑：James Tursa 2023-7-6

在 MATLAB Online 中打开

Observations on exp(1) ...

Online MATLAB:

exp(1) - double(exp(sym(1)))
ans = 0

MATLAB R2021a PCWIN:

>> exp(1) - double(exp(sym(1)))
ans =
4.4409e-16

Of course you don't expect that whatever method is used in the background for exp( ) to always produce the closest approximation for every possible input value, so no real issue with the discrepancy above. It is just interesting that my PC version of MATLAB doesn't produce the closest double precision value to e using exp(1). It would in fact be more consistent to just hard code this particular value directly if you are using it in such arithmetic expressions as above, e.g.,

exp1 = 2.718281828459045;
exp1 - double(exp(sym(1)))
ans = 0

*** EDIT ***

A quick follow up. Neither of these values for e gets recognized by the sym engine for what they are. E.g.,

MATLAB Online:

exp1 = exp(1)

exp1 = 2.7183

e = 2.718281828459045

e = 2.7183

num2hex(exp1)

ans = '4005bf0a8b145769'

num2hex(e)

ans = '4005bf0a8b145769'

sym(exp1) % <-- doesn't recognize this as exp(1)

ans =

sym(e)

ans =

MATLAB R2021a PCWIN:

>> exp1 = exp(1)
exp1 =
2.718281828459046
>> e = 2.718281828459045
e =
2.718281828459045
>> num2hex(exp1)
ans =
'4005bf0a8b14576a'        <-- one bit different from below
>> num2hex(e)
ans =
'4005bf0a8b145769'        <-- one bit different from above
>> sym(exp1)
ans =
3060513257434037/1125899906842624    <-- doesn't recognize exp1 as exp(1)
>> sym(e)
ans =
6121026514868073/2251799813685248    <-- doesn't recognize e as exp(1)
>> sym(pi)
ans =
pi                                   <-- but it does recognize pi

James Tursa 2023-7-6

编辑：James Tursa 2023-7-6

在 MATLAB Online 中打开

@Paul If I understand your latest comment correctly, I think you are misinterpreting what sym(pi) is doing. In this form, the pi( ) function is called first and returns a double precision value. This double precision value is then passed on to the sym( ) function. The sym( ) function then examines the passed in value to determine if it can discern your intent (looking for modest rational values or rational values times π). This all happens inside the sym( ) function and it has no clue how this floating point number was initially generated. This is not a result of the parser seeing the sym(pi) form and somehow constructing a symbolic π variable because it saw the letters pi and discerned your intent. After all, how could the parser know that the pi( ) function hasn't been changed and doesn't actually return the π value? So starting with p=pi first makes no difference in how this value gets passed into sym( ). The result depends on the value, not on the syntax used to generate the value. To illustrate:

sym(pi)

ans =

π

pi = 5

sym(pi)

ans =

5

sym(acos(-1))

ans =

π

sym(atan(1))

ans =

Also this comment you made:

"If sym(exp(1)) returned the symbolic constant e, then there may be problem if, by intent or not, the input to sym is a double that is equal in value to exp(1) but not intended to be e."

In fact, that is exactly what happens with pi. The intent is discerned based solely on the value passed in, not on something the parser recognized in the calling syntax. So your comment applies to the exact situation we have with pi currently, but I don't see any significant issue with that.

I have never had the need for the sym( ) function to recognize any forms of (p/q)*exp(r/s) etc., so it doesn't really bother me that this isn't part of sym( ) capability. The only reason I included that in this thread is because I was curious if either of the "close" numbers to e would be recognized by the sym( ) function.

@Steven Lord Something weird happened FYI. When I first ran the code above, the sym(pi) generated 3.1415. I had to run the code a second time to get the π result. But I can't reproduce this. Very strange ...

Walter Roberson 2023-7-10

在 MATLAB Online 中打开

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);
mask = find(X == sym(pi));
maxdelta = delta(max(mask))
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 2023-7-10

@Steven Lord

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.

请先登录，再进行评论。

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

24 个评论
显示 22更早的评论隐藏 22更早的评论

回答（2 个）

28 个评论
显示 26更早的评论隐藏 26更早的评论

14 个评论
显示 12更早的评论隐藏 12更早的评论

另请参阅

类别

标签

产品

Community Treasure Hunt

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

24 个评论 显示 22更早的评论隐藏 22更早的评论

回答（2 个）

28 个评论 显示 26更早的评论隐藏 26更早的评论

14 个评论 显示 12更早的评论隐藏 12更早的评论

另请参阅

类别

标签

产品

Community Treasure Hunt

24 个评论
显示 22更早的评论隐藏 22更早的评论

28 个评论
显示 26更早的评论隐藏 26更早的评论

14 个评论
显示 12更早的评论隐藏 12更早的评论