Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected behavior of limits #596

Open
JorgeLLH opened this issue Sep 23, 2022 · 0 comments
Open

Unexpected behavior of limits #596

JorgeLLH opened this issue Sep 23, 2022 · 0 comments
Labels
Bug A serious math/runtime error Not now Means even though we count it as an issue, we won't solve it in the near future

Comments

@JorgeLLH
Copy link

JorgeLLH commented Sep 23, 2022

The version I use: AngouriMath.FSharp 1.3.0<!--
Unexpected behaviour or bug: <!--
The following limit:
let a_limit = Core.parser("limit(1/(ln(x+(x*x+1)^0.5))-(1/ln(x+1)), x, 0)";;
(a_limit.Evaled).EvalNumerical() |> double;;

Results in:
val it : double = nan

Actual answer should be -1/2

Another limit (related to the Gamma function, upper limit of the integral)
let upper_lim_Gamma=Core.parsed("limit((x^(5-1))*(e)^(-x), x, +oo)");;
(upper_lim_Gamma.Evaled).EvalNumerical() |> double;;

Results in:
val it : double = nan

Actual value should be 0.

Smaller values 20 instead of infinity for example result in correct values.

Another limit (answer is 1/e) giving an error:
let limit_b = Core.parsed("limit(((x!)/x^x)^(1/x), x, +oo)");;
(limit_b.Evaled).EvalNumerical() |> double;;
AngouriMath.Core.Exceptions.CannotEvalException: Result cannot be represented as a simple number! Use EvaluableNumerical to check beforehand.
at AngouriMath.Entity.EvalNumerical()
at <StartupCode$FSI_0027>.$FSI_0027.main@()
Stopped due to error

Smaller values produce the expected behavior:
let limit_b = Core.parsed("limit(((x!)/x^x)^(1/x), x, 4)");;
(limit_b.Evaled).EvalNumerical() |> double;;
val it : double = 0.5533409599

Thanks for your time!
-->

@WhiteBlackGoose WhiteBlackGoose added Bug A serious math/runtime error Not now Means even though we count it as an issue, we won't solve it in the near future labels Sep 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug A serious math/runtime error Not now Means even though we count it as an issue, we won't solve it in the near future
Projects
None yet
Development

No branches or pull requests

2 participants