|
|
last edited 2 years ago by TheDoctor |
1 2 3 4 5 6 7 8 | ||
Editor: TheDoctor
Time: 2022/01/31 23:12:40 GMT+0 |
||
Note: |
removed:
-From TheDoctor Mon Jan 31 23:10:25 +0000 2022
-From: TheDoctor
-Date: Mon, 31 Jan 2022 23:10:25 +0000
-Subject:
-Message-ID: <20220131231025+0000@fricas-wiki.math.uni.wroc.pl>
-
-integrate(1/(1+exp(b*x)),x=-m..%plusInfinity
Here are some integration problems.
Test1
Start here:
(1) -> integrate(x/sqrt(2*%pi)*exp(-1/2*log(x)^2),x=0..%plusInfinity)
(1) |
Test2
A simpler integration:
integrate(1/sqrt(2*%pi)*exp(-1/2*x^2),x=%minusInfinity..%plusInfinity)
(2) |
We are using the following version of FriCAS:
)version
"FriCAS 1.3.10 compiled at Wed 10 Jan 02:19:45 CET 2024"
integrate(x^n*exp(-x^2/2),x=0..%plusInfinity, "noPole")
(3) |
But FriCAS can do indefinite integral
integrate(x^n*exp(-x^2/2),x)
(4) |
so the problem is due to too weak limit.
What if the positive Integer is declare as a positiveInteger or even chosen, say, as 2:
n:PositiveInteger
integrate(x^n*exp(-x^2/2),x=0..%plusInfinity)
n is declared as being in PositiveInteger but has not been given a value.
n:PositiveInteger
is a frequent expectation of new users of FriCAS - especially if one have used other computer algebra systems, after all FriCAS is supposed to be a "strongly typed" system, right? Certainly I was surprized (and disappointed) by FriCAS limitations in this regard.
Unfortunately FriCAS does not attempt to use this type information when forming expressions - but worse - declaring the type actually interferes with the use of the variable to form expressions!
When you write
n:PositiveInteger
what this tells FriCAS is that n
will be assigned an integer
value greater than 0 - only that. After it is actually assigned
some value, then it can be used exactly like that value, but
not before.
To me, this is a tremedous waste of an opportunity in FriCAS to to deal with "domain of computation" issues such as are addressed in other untyped computer algebra systems by the use of "assumptions" such as:
assume(x,PositiveInteger);
Such knowledge can be used to considerably improve the quality and generality of the computations.
f(x | (x >=0) and (x <=1) ) == 1
f(x | (x<0) or (x > 1)) == 0
It is obvious that , while FriCAS signals error.
integrate(f(t),t=-1..2)
There are 1 exposed and 1 unexposed library operations named >= having 2 argument(s) but none was determined to be applicable. Use HyperDoc Browse,or issue )display op >= to learn more about the available operations. Perhaps package-calling the operation or using coercions on the arguments will allow you to apply the operation. Cannot find a definition or applicable library operation named >= with argument type(s) Variable(t) NonNegativeInteger
Perhaps you should use "@" to indicate the required return type,or "$" to specify which version of the function you need. FriCAS will attempt to step through and interpret the code. There are 1 exposed and 1 unexposed library operations named >= having 2 argument(s) but none was determined to be applicable. Use HyperDoc Browse, or issue )display op >= to learn more about the available operations. Perhaps package-calling the operation or using coercions on the arguments will allow you to apply the operation.
Cannot find a definition or applicable library operation named >= with argument type(s) Variable(t) NonNegativeInteger
Perhaps you should use "@" to indicate the required return type,or "$" to specify which version of the function you need.
Currently conditional expressions are not supported. Axiom used to evaluate such examples using its internal order on expressions, which gave unexpected results. From users point of view the results were wrong.