Deprecate Euler number e in favor of ℯ (U+212F)

[nalimilan]

This reduces confusion with variables called e, and ℯ is
the Unicode character for "natural exponent". It also
makes this constant more similar to others, which have
both a "special letter" and longer ASCII form.

Cf. #10607

Reference : http:https://en.wikipedia.org/wiki/Numerals_in_Unicode#Characters_for_mathematical_constants

(Shortest branch name ever!)

[kmsquire]

Would be nice if, e.g., \e<tab> completed to ℯ

[nalimilan]

Yeah, but I'm not sure how to do that.

[nalimilan]

With this commit, it looks like the deprecation warning is printed every time, not only on the first call. What am I doing wrong?

[jverzani]

As someone who has been teaching students to use Julia as a first language, I hope this doesn't go through. It is a much greater hurdle for a beginner to either define e=exp(1) or learn to type \e<tab> than for an experienced user to reckon with the difference between Main.e and Base.e, should they wish to redefine e.

[Keno]

There's still eu. Would that work?

[joa-quim]

Me too, please don't do this. I don't even know how to write the manuscript 'e'. Honestly I've seen about the Unicode variables but for me they are a 'nice curious thing' that I never really cared about and should never made mandatory in any case.

[tkelman]

e as a MathConst is kind of a party trick that I personally rarely need. I don't see why it needs to claim single-character name space - every time I use Mathematica, I'm always annoyed I can't name a variable N. I'd even prefer being explicit with MathConst{:e}() for this.

[kmsquire]

There's nothing preventing anyone from using e as a variable:

julia> e = 12345
12345

julia> e^2
152399025

julia> eu^2
7.38905609893065

Of course, if you try to use it both as e and a variable, you get a nice little warning:

julia> e
e = 2.7182818284590...

julia> e = pi
Warning: imported binding for e overwritten in module Main
π = 3.1415926535897...

julia> e
π = 3.1415926535897...

[tkelman]

Out of packages I have installed, LibExpat, Dates, ImmutableArrays, Graphs, StatsBase, DataArrays, WinRPM prior to JuliaPackaging/WinRPM.jl@41c6532, GZip, BloomFilters, Tk, HDF5, BinDeps, DataFrames, an old version of FactCheck, Distributions, Winston, IJulia, Gadfly, and Debug all use catch e somewhere. I forget the exact details, but the fact that some of the functions in WinRPM were being called inside a BinDeps macro meant some funny things happened with scope and/or error handling, and the value of e in the catch block wound up as the MathConst instead of the caught exception.

[johnmyleswhite]

Perhaps there be a MathConsts module that isn't imported by default, but can easily switched on? I see the appeal of having instant access to e and pi, but am increasingly onboard with trying to shrink the number of names claimed by Base.

[hayd]

Would be nice if, e.g., \e<tab> completed to ℯ

Kind of off topic, but it would be great if there was a way to force tab complete to show all possible completions (starting with e), e.g. \e<shift+tab>. It's frustrating when you know how a unicode starts... and you tab expecting to see options only to have a shorter char competed.

[kmsquire]

@hayd, in the console REPL, at least, you can hit <tab> twice, and that list will appear. Not sure about other interfaces, though.

[hayd]

@kmsquire I don't think that's the case if it's already a complete unicode name. Silly example (I can't recall the more annoying case I was dealing with recently, where this occured much earlier), I'm trying to tab complete to equivDD, but

julia> \equ         # This at least shows the options
\equalleftarrow \equalparallel   \equiv           \equivDD
julia> \equi<TAB>   # becomes (without showing options, suppose I start here)
julia> \equiv<TAB>  # becomes
julia> ≡            # I wanted \equivDD :(

Or, more annoyingly, I know it starts with c...

julia> \c<TAB>   # no options
julia> ̧

[JeffBezanson]

@tkelman that kind of sounds like a bug, either in the macro expander or one of the macros themselves. Saying that a certain piece of code --- even Base --- should avoid a certain variable name should not be necessary for sane scoping.

e has never gotten in my way, but there are still some things to be said for not exporting a 1-letter variable.

[ViralBShah]

I would be OK with MathConsts not being imported by default. Also OK with eu as the name.

[nalimilan]

Updated with the \e[tab] replacement rule. IMHO that's as a good compromise, very similar to what we have for pi and all other constants, which don't have the privilege a single ASCII letter symbol just for them. My take is that somebody who used e for an exception in a scope where the variable is not defined (e.g. after copy/paste) will be more more confused by seeing an error message about 2.71... than users of the constant will be be typing eu or \e[tab].

I've been able to fix the problem of repeated deprecation warnings for most cases, except when calling Float64 (and other constructors) from inside a function. It works fine from the REPL, though. I'm defining both call and convert, but no luck. Any ideas?

[mschauer]

Are there actually sources for the wiki claim that "U+212F ℯ script small e" is somehow related to "natural exponent"? This would contradict ISO 80000-2.

[nalimilan]

@mschauer Any copy of the Unicode standard will do, e.g. http:https://unicode.org/charts///PDF/Unicode-4.1/U41-2100.pdf It's true that ISO 80000-2 uses e, but well, it also says that the imaginary unit should be written i. No idea how Unicode decided to recommend ℯ.

[simonbyrne]

+1: e is one of the less useful constants for numerical software, since its main use is e^x == exp(x).

I would also be in favour of ⅈ (u+2148) for im.

[mschauer]

@nalimilan Ok, not our problem ;-)

[simonbyrne]

This will also help with things like:

julia> 2e
5.43656365691809

julia> 2e-1
0.2

[StefanKarpinski]

Not really – that still means the same thing, regardless of whether e is defined or not.

[simonbyrne]

Yes, but now at least one will throw an error (unless the user defines e of course).

[jiahao]

Both e^x and exp(x) show up very often in the mathematical literature. Removing exp(x) would confuse a great many users.

In practice you don't save much in terms of clarity when exponentiating a long expression, since you'd have e^(very long expression) vs exp(very long expression). Consider that people routinely write expressions like these or pdf, p5.

[JeffBezanson]

As everybody probably knows, I'd rather have exp(M) compute the matrix exponential than have expm and the vectorized :shudder: version.

[simonbyrne]

As everybody probably knows, I'd rather have exp(M) compute the matrix exponential than have expm and the vectorized :shudder: version.

Obligatory reference to #5840.

[sbromberger]

FWIW, I'm in favor of being consistent here. If e is "ok", then it seems to me that denying the use of zeta (per #10607) because "people use it for local variables" is inconsistent. I would counterargue that e is more commonly used as a local variable than ζ.

Again, it's possible to work around whatever decisions are made here, but absent a policy that one can reference when deciding whether or not a specific single-character variable makes sense or not, it's confusing as heck.

It's also entirely possible that I'm missing the point.

[JeffBezanson]

I think what's happening here is that we don't want to add any more 1-letter exported names, but it's not worth breaking things to remove the few we have.

[Keno]

Do we know how many people are actually using e in their code to mean Euler's constant. I suspect it's not that many.

[JeffBezanson]

There is also a question of how strongly associated the letter is. Walk into any technical department and say "e", and it can mean only one thing. Most single letters have marginal meanings by comparison, I think even the φ and γ that we already have in Base.

[sbromberger]

There is also a question of how strongly associated the letter is. Walk into any technical department and say "e", and it can mean only one thing. Most single letters have marginal meanings by comparison, I think even the φ and γ that we already have in Base.

OK, but then what about ζ? Heck, even the function declared in Base is named "zeta". My original proposal was to give it the corresponding unicode Greek letter.

Again, I think it's more important at this point to be consistent. I'm not in favor of saying "we don't want to break things" in a language this new. IMO, consistency is more important than stability at this point in Julia's development.

[JeffBezanson]

I'd say ζ is really not as universal as e. There is also Γ to consider for gamma.

I'm not sure why we have φ and γ. We were probably just having fun with unicode and MathConst. Surely those are used even more rarely than e.

[Keno]

As a quick datapoint from my entirely unscientific survey of all the packages I have installed, there were about 120 uses (multiple uses in the same function/file not counted) of e as local variables, 7 global redefinitions of e in a module to be something else, 5 constructs of the form e = exp(...) and 3 actual uses of e as Euler's constant. As such I would argue that looking at a random piece of code you can not conclude that e is Euler's constant. Using eu or even the unicode name would make that abundently clear. Further, if I remember the number of times I've accidentally written:

try
foo()
catch
println(log,"An error occurred: ", e)
end

Only to get in my log file "An error occurred: 2.7182818284590...", being confused for a moment and then realizing what happened, I just don't think reserving the one character name is worth it. In the try/catch example above, Lint.jl would probably have flagged (or could have) the undefined use of e if it weren't defined in Base.

[nalimilan]

@Keno Thanks for actually doing that survey!

[JeffBezanson]

Yes, that is interesting. I think this is more a command line thing than a package thing. Most real code will not use e anyway, but exp. If we get rid of it, we might as well remove φ and γ. That would leave I and π as the only 1-letter Base exports.

[tkelman]

I like the suggestion above of putting these in a MathConsts module. Or maybe there's a slightly nicer module name than that.

[sbromberger]

Without wanting to bikeshed the name, +1 to the MathConsts module idea.

[mlubin]

FWIW, I most commonly use e to refer to an edge in a graph. I never use it as exp.

[nalimilan]

Since it doesn't seem this is going to be merged, could somebody knowledgeable review the docs I wrote in beea5bc and confirm they are good to merge separately?

[tkelman]

I haven't messed with @deprecate too much, but that looks okay to me

[Keno]

I still feel strongly that this should be merged. We should think of this is deprecating e in favor of eu (while adding a nice unicode alias like we have to the others).

[nalimilan]

@tkelman Thanks, pushed as bfd9335

I'm all for reviving the discussion on the PR itself, though. :-)

[fredrikekre]

superseeded by #23427

[nalimilan]

The posthumous victory of an old and forgotten PR!