Dear John, Thanks for your answer. Now the file that I shared with you yesterday for

N[termn6 /. {Subscript[T, 1] -> 5.020, Subscript[n, 1] -> 1020, Subscript[c, 1] -> 1.420, Subscript[T, 2] -> 5.020, Subscript[n, 2] -> 1020, Subscript[c, 2] -> 1.420, Subscript[T, 3] -> 5.020, Subscript[n, 3] -> 1020, Subscript[c, 3] -> 1.420, Subscript[T, 4] -> 5.020, Subscript[n, 4] -> 1020, Subscript[c, 4] -> 1.420, Subscript[T, 5] -> 5.020, Subscript[n, 5] -> 1020, Subscript[c, 5] -> 1.420, Subscript[T, 6] -> 5.020, Subscript[n, 6] -> 1020, Subscript[c, 6] -> 1.420, k -> 0.01`20}]

its no more giving 0.999993 but 4.76145665529708310^546 today*

What might have changed in a day? All the results are from mathematica 11.3. I trust 0.999993 because its more of an answer that one would expect physically as it enters into a probability distribution function. Sharing today's file again. Daniel please see to it too termn6 is giving the same unphysical answer today as termn5 (today & yesterday).

Daniel & John, I would be more than grateful if I can retreive my old results (at least for termn6 of yesterday). Thanks, Pallavi

I, like Daniel, see similar results from controlled and machine precision. Why do you trust the old laptop's results?

Dear John, Thanks for the reply. I tried what you suggested but that didn't help when {p=5} in the sum from p=1 to p=5 (it just removed the error messages), bit it just works fine when the upper limit is changed to p=6. Sharing the mathematica notebook. So the problem remains and it may pop up again in a corresponding higher order calculation.

It would be easier for us to help if you posted code we could copy rather than an image.

I suggest using controlled precision: replace each machine number (numbers with a decimal point, like 1.5) with a controlled precision number like 1.5`20.

I believe I may too have similar kind of problem in Mathematica 11.3.

In my students' old laptop the same input gives a different correct (the one to be expected) result

Can you please suggest a fix?

Thanks. Pallavi

The purpose of machine numbers is to give you access to the underlying machine arithmetic. Most machines are optimized for double arithmetic, so this gives you access to efficiency. Underflowing to zero is part of machine arithmetic, so trapping underflow and substituting a different kind of number was a troublesome violation of the basic design.

Using machine numbers inappropriately has always been a problem in Mathematica, as in other computing contexts. You're on shaky ground when you use machine numbers as input to symbolic machinery like Solve or Integrate, and the usual numeric hazards are also present. Fortunately, these are easily avoided. For symbolic calculation, use exact numbers, like 3/2 in place of 1.5. For safer, more rigorous numerics, use controlled precision like 1.5`10 .

You're in control here. Underflowing to zero improves that control: rather than arbitrarily switching the arithmetic domain, it keeps your calculation in the machine domain when that's the way you've formulated your problem.

Dear Oleksandr,

I am sure your solution is very clever. But my problem is that I am not able to reproduce something like that the next time I have a similar problem.

I am not a mathematician but a biologist who work with applied mathematics. For 20+ years Mathematica has helped me to develop mathematical models to population biological questions and apply them to data.

I am extremely sad that it now will be more difficult for me take advantage of the coming new developments in Mathematica. I will be forced to live in a V11.2 world.

Please rethink this decision and get back to the philosophy of providing a simple to use software for users who are not mathematicians but use mathematics to solve applied problems.

Christian

Why limit NMaximize to machine precision? You might want to try the option WorkingPrecision. Like

         NMaximize[Cos[x^2 - 3 y] + Sin[x^2 + y^2], {x, y},WorkingPrecision -> 20]

.