Do you know Napier’s constant *e*? The *e* is also known as the base of the natural logarithm. In the Challenge of the Month – July 2015, I suggested following challenge:

**Community Suggestion (By Nonki)**

- Calculate Napier's constant
*e*(the base of the natural logarithm).

This idea is from that Small Basic doesn’t have the property Math.E like Visual Basic (But, LitDev Extension has LDMath.E property).

I made three programs for this challenge.

This is the first program: CML298

- This program uses following equation to calculate
*e*.

- This program causes run time error.
- This program can calculate
*e*correctly to 27 places of decimals (accurate as possible for Small Basic).

0!=1 e=1 1!=1 e=2 2!=2 e=2.5 3!=6 e=2.6666666666666666666666666667 : : 24!=620448401733239439360000 e=2.7182818284590452353602874043 25!=15511210043330985984000000 e=2.7182818284590452353602874688 26!=403291461126605635584000000 e=2.7182818284590452353602874713 27!=10888869450418352160768000000 e=2.7182818284590452353602874714 Unhandled Exception: System.OverflowException: Value was either too large or too small for a Decimal. at System.Decimal.FCallMultiply(Decimal& d1, Decimal& d2) at _SmallBasicProgram._Main()

The second one is: DNP836.

- This program uses following equation to calculate
*e*.

- This program can calculate
*e*correctly to 13 places of decimals. - The calculation is done by bisection method with Math.NaturalLog operation.

Math.NaturalLog(2.5)=0.916290731874155 Math.NaturalLog(2.75)=1.01160091167848 Math.NaturalLog(2.625)=0.965080896043587 : : Math.NaturalLog(2.7182818284586574009153991937)=0.999999999999858 Math.NaturalLog(2.7182818284588847745908424258)=0.999999999999941 Math.NaturalLog(2.7182818284589984614285640418)=0.999999999999983 Math.NaturalLog(2.7182818284590553048474248498)=1 e=2.7182818284590553048474248498 Press any key to continue...

This is the third one: RMF924.

- This program uses following equation to calculate
*e*.

- This program can calculate
*e*correctly to 14 places of decimals. - If
*n*is larger than about 7.2E16, the result becomes 1.

n=1 1+1/n=2 e=2 n=16 1+1/n=1.0625 e=2.6379284973666 n=256 1+1/n=1.00390625 e=2.71299162425343 n=4096 1+1/n=1.000244140625 e=2.71795008118967 : : n=17592186044416 1+1/n=1.000000000000056843418860808 e=2.71828182845897 n=281474976710656 1+1/n=1.0000000000000035527136788005 e=2.71828182845904 n=4503599627370496 1+1/n=1.000000000000000222044604925 e=2.71828182845904 n=72057594037927936 1+1/n=1.0000000000000000138777878078 e=1 n=1152921504606846976 1+1/n=1.000000000000000000867361738 e=1 n=18446744073709551616 1+1/n=1.0000000000000000000542101086 e=1 : : n=1208925819614629174706176 1+1/n=1.0000000000000000000000008272 e=1 n=19342813113834066795298816 1+1/n=1.0000000000000000000000000517 e=1 n=309485009821345068724781056 1+1/n=1.0000000000000000000000000032 e=1 n=4951760157141521099596496896 1+1/n=1.0000000000000000000000000002 e=1 Unhandled Exception: System.OverflowException: Value was either too large or too small for a Decimal. at System.Decimal.FCallMultiply(Decimal& d1, Decimal& d2) at _SmallBasicProgram._Main()

What are the disadvantages of not having the E property?

What are the advantages (toward the Small Basic goal of Simplicity) of not having it?

I'm trying to weigh whether this should be a feature request, or something that's better left for the LitDev Extension and equations like this to calculate E and get to the same result.

Thanks!

Advantages are one less and not very hard to recreate SB operation.

Disadvantage 1 extra constant to set in a program E = 2.71828182845904523536028747135266249775724709369995

How accurate does it need to be? as adding 1 to E in SB returns only 14 decimal places.

They reckon it's an important constant. PI is an important constant and it's included.

To help contain simplicity maybe a limit could be put forward on "The maximum number of Members any SB object should contain".

I think the GraphicsWindow object has about 40 and Math about 22.

An approx. limit of members may help define simplicity. But the definition could be in context to the object.

e.g. 40 Math objects could be more confusing than 40 GW objects.

I think 1 more important constant to Math object would be useful and represent quality.

Why wasn't it added initially?

I think the demand for pi is higher.

Jibba Jabba, I agree with your ideas.

By the way, Small Basic can show only 14 decimal places in a variable such as

E = 2.71828182845904

when the variable is substituted with a literal number.

I don't know why that is 14 decimal places while Decimal type of .NET framework can contain 28 decimal places and Small Basic variables are implemented as Decimal type variables internally.