Integral not evaluated with float integrand

[rmix22-disabled]

Found another bug presumeably with Mupad.

Even very simply integrals with at least one variable limit dont' get evaluated.

See attached picture.

Assuming the limit or the variable x as real does not help.

Using MC_14_M030.

RMix

[RichardJ]

That's bug alright. A rather lame one, because if you change the 2 in your first example to an undefined variable name such as xxx the integral evaluates just fine. So it can evaluate the integral with no problem, it just can't substitute a floating point number afterward.

Richard

[TomGutman]

The use of a number with a decimal point in an expression forces float (numeric) evaluation (part of the specifications for the symbolic processor). With variable limits, such a numeric evaluation cannot be done, and it leaves the original integral expression.
__________________
� � � � Tom Gutman

[RichardJ]

On 2/17/2010 8:26:36 PM, Tom_Gutman wrote:
>The use of a number with a
>decimal point in an expression
>forces float (numeric)
>evaluation (part of the
>specifications for the
>symbolic processor). With
>variable limits, such a
>numeric evaluation cannot be
>done

Why?

Richard

[TomGutman]

>>Why?<<

Because the result depends on the (unknown) value of the limit.
__________________
� � � � Tom Gutman

[AlvaroDíaz]

I'm sure that mupad gives the correct answer for explicit decimal-point numbers; this is the mixed symbolic/numeric algebra. I assume that it's a true mathcad bug, in the interface mupad-mathcad (actually, a mupad package and a mathcad dll).

Regards. Alvaro.

[rmix22-disabled]

On 2/18/2010 3:27:53 AM, adiaz wrote:
>I'm sure that mupad gives the
>correct answer for explicit
>decimal-point numbers; this is
>the mixed symbolic/numeric
>algebra. I assume that it's a
>true mathcad bug, in the
>interface mupad-mathcad
>(actually, a mupad package and
>a mathcad dll).
>Regards. Alvaro.



At least MC 11 does NOT have that problem. So its likely a Mupad-only bug - and I would really call it a bug anyway.

[AlvaroDíaz]

On 2/18/2010 5:33:16 AM, rmix22 wrote:

>At least MC 11 does NOT have that
>problem. So its likely a Mupad-only bug

I can't post the screen-dump -because don't copy it- but I do the integral into a mupad Version 4 and works like maple.

>- and I would really call it a bug anyway.

Yes, it is a bug, point is where. I think that it is in mathcad v 14, not v 11 or mupad.

Regards. Alvaro.

[Al2000]

>On 2/18/2010 3:27:53 AM, adiaz wrote:
...
>At least MC 11 does NOT have that
>problem. So its likely a Mupad-only bug
>- and I would really call it a bug
>anyway.

Neither MC 2001



Saludos,

Al

[RichardJ]

On 2/17/2010 10:00:47 PM, Tom_Gutman wrote:
>>>Why?<<
>
>Because the result depends on
>the (unknown) value of the
>limit.

But it can solve the integral symbolically, then follow with numerical evaluation. Using a floating point number should not force it to do only numerical evaluation.

Richard

[TomGutman]

>>But it can solve the integral symbolically, then follow with numerical evaluation.<<

Yes, it could. But there is nothing that requires it to do so.
__________________
� � � � Tom Gutman

[rmix22-disabled]

On 2/18/2010 12:48:37 PM, Tom_Gutman wrote:

>>>But it can solve the integral symbolically, then follow with numerical evaluation.

>Yes, it could. But there is
>nothing that requires it to do
>so.

Nothing, but the user waiting for a useable answer. Indeed I strongly insist that MC should behave better in that sense.
Especially when using a numeric system like MC you invoke the symbolic processor on purpose and it should not be forced to that fully numeric evaluation simply because you use a float in your expression. The example I posted was drastically simplified. The real problem had quite some nasty float numbers in it and still a solution was wanted (and MC was theoretically able to serve it). It was quite a stupid an tedious task to convert all the floats to fractions to make MC do the work.
So either MC/Mupad should work the way Richard sketched in his posting or the switch to numeric mode should not be an automatic one by using a float number. Doesn't do the modifier "float" the job anyway?
Infact I would suppose and expect a symbolic processor to evaluate 0.4 to 2/5 (if not otherwise told) and not to be switched to numeric mode by that float.

RMix

[TomGutman]

>>Infact I would suppose and expect a symbolic processor to evaluate 0.4 to 2/5 (if not otherwise told) and not to be switched to numeric mode by that float.<<

And with respect to Mathcad you suppose wrong. This is a design decision, made long ago when symbolics were introduced (possibly a part of live symbolics). You may disagree with the wisdom of that design, but that is the documented design and your disagreemant does not make it a bug. The program is required to adhere to the published specifications, not your opinion on how it should work. If you find the product to be missing a feature that you might like, or to have made design choices that you disagree with, that is properly discussed in the feature suggestion forum, not the bugs forum.
__________________
� � � � Tom Gutman

[RichardJ]

On 2/18/2010 10:36:18 PM, Tom_Gutman wrote:
>>>Infact I would suppose and expect a symbolic processor to evaluate 0.4 to 2/5 (if not otherwise told) and not to be switched to numeric mode by that float.<<
>
>And with respect to Mathcad
>you suppose wrong. This is a
>design decision, made long ago
>when symbolics were introduced
>(possibly a part of live
>symbolics).

If you mean changing 0.4 to 2/5 that is certainly true (and such a change wouldn't be necessary for symbolic evaluation anyway), but the Maple engine handles this integral just fine (i.e. it solves the integral symbolically, then numerically evaluates).

Richard

[rmix22-disabled]

On 2/18/2010 10:36:18 PM, Tom_Gutman wrote:
>>>Infact I would suppose and expect a symbolic processor to evaluate 0.4 to 2/5 (if not otherwise told) and not to be switched to numeric mode by that float.<<
>
>And with respect to Mathcad
>you suppose wrong. This is a
>design decision, made long ago
>when symbolics were introduced

That may be true but in case of the integral, which was the initial subject, it rather seems to be a mattter of how the new symbol engine handles the forced numeric mode. The integrals are correctly shown (in the sense of evaluting as expected) in version 11! To me thats more of a bug than a simple annoyance that this does not work in version 14.

Concerning my proposal of changing the way the engine is forced to symbolic mode I agree with that being a change of documented design and therefore beeing subject of feature suggestion. It was made here because it would solve the problem with the inital integral (and because I quite often was displeased with that behaviour). I strongly feel that the switch to numerics in the symbolic engine should not be that automatic.

Considering my 0.4 to 2/5 statement, this was done as most symbolic engines would do this unless told to approx, therefore I said i would have expected it. It's not really a strong feature suggestion because it could be quite cumbersome too in other programs, to have "exact" fractions in lieu of floats. In other programs there usually is the possibility to force an approx mode but in Mathcad you have no opportunity to force an exact mode if you have floats in your expressions. Together with the changed way of evaluating the integral thats a bad combination, I think.

RMix