Function mhyper acts quirky in M14 and M15

[ptc-4573512]

The mhyper function seems to be acting strange in that it returns zero when the function is called with variables for the inputs and the last input is greater than about 70. I have attached an example worksheet that illustrates this.

I am using Mathcad 14.0 M020 (14.0.2.5), and a coworker using Mathcad 15 got the same result.

Is there a correction or work around for this?

[Werner_E]

That looks like a bad bug. I can only confirm that I experience the same strange result with the current MC15 M030,

After openeing the sheet I see this

When I press Ctrl-F9 to recalculate the sheet, the first value changes to zero, too.

Guess you should open a support case and report that bug.

EDIT: It seems that its a rather old bug: http://communities.ptc.com/message/130717#130717

[Werner_E]

The same bug in Prime 3, just a but different. Instead of zero we get an error here. The error message is "Unknown error: floating_point_exception."

First calculation after loading the worksheet

After reacalculation

[AlanStevens]

If you want a reliable function form, you could always just solve the ode:

That said, I haven't investigated the limitations of this approach!

Alan

[ptc-4573512]

Thanks for the responses.

In my case, the xend is less than zero so I had to use a tweak. See below.

I too am not sure of the limitations and robustness of the ODE solution. Pearson (http://people.maths.ox.ac.uk/porterm/research/pearson_final.pdf) indicates that it may not be accurate over the full range of parameters.

[AlanStevens]

That works, though simpler just to make initial x-value negative:

Alan

[AlanStevens]

Here are a few comparisons against Pearson's results. Mathcad's ode solver seems to be accurate to about 4 or 5 significant figures here.

Alan

[Werner_E]

Mathcad's ode solver seems to be accurate to about 4 or 5 significant figures here.

Which you can significantly improve by setting TOL to a lower value than the default 10^-3.

[AlanStevens]

Werner Exinger wrote:

Mathcad's ode solver seems to be accurate to about 4 or 5 significant figures here.

Which you can significantly improve by setting TOL to a lower value than the default 10^-3.

Good thinking Werner! With TOL at 10^-12 you get around 9 or 10 significant figures.

Alan

[Werner_E]

Is there a correction or work around for this?

While I think that Alan's solution of just solving the ODE is the better approach, here is another "workaround". I don't like workarounds where I don't understand why they work, though. The calculations seems to work if you evaluate them at first symbolically and then (inline) numerically - crazy!

I don't think that it would be possible to turn this trick into a new function as we can't simultate the numeric eval inside a program.

EDIT: Played with assignments and found soemthing strange. You won't need symbolic evaluation if you assign the result to a variable

And to make the crazyness complete, you won't even need any inline evaluation:

As my tests have shown, local assignments don't work that way. So if you use mhyper() in a program you still will encounter wrong results.

[ptc-4573512]

It is crazy.

Thanks for the help.

It would be nice if mhyper worked more nicely or at least the documentation explained limitations.

[Werner_E]

I would call this behaviour a bug anyway. Mathcad should never yield a wrong result (0) but rather throw an error which could be caught by an onerror statement. So either throw an error as to sort of numeric limitations or yield a correct result, no matter if the expression is called after some other evaluations or not, no matter if the call is assigned a variable and no matter if the parameters are variables or equivalent constants.

[HarveyHensley]

I don't get this problem in MC15 M020.