Division by 0 (zero) in an App

[Bob Frazee]

Most of the programming I've done has been with Apps. In a "hpprgm", division by 0 is flagged as "X\0". In an App, it dumps you to the home screen, and tells you nothing. It also appears, that in general, the error messages on programming mistakes are not as good on the Apps programming side, as they are on the regular programming side (hpprgm). The division by 0 anomaly has existed for a long time. I was wondering if improving App error message creation is at least being considered?

[Han]

(03-26-2017 09:48 PM)Bob Frazee Wrote:  Most of the programming I've done has been with Apps. In a "hpprgm", division by 0 is flagged as "X\0". In an App, it dumps you to the home screen, and tells you nothing. It also appears, that in general, the error messages on programming mistakes are not as good on the Apps programming side, as they are on the regular programming side (hpprgm). The division by 0 anomaly has existed for a long time. I was wondering if improving App error message creation is at least being considered?

Apps do not have any means of returning results, including error messages, unlike non-app programs. You can still debug an app by inserting DEBUG statements into your code. This will trigger the debugger to help you trace the errors.

That said, if you need to trap errors, consider IFERR blocks.

But in sum, you are right -- apps require you to be much more vigilant about making sure your code behaves as intended from the design stage.

[cyrille de brébisson]

Hello,

Note that you can test your faulty app program function by exporting it and calling it directly from the command line. At this point, it will behave like a normal program.

Do not hesitate to use the build in debuger either using debug(function) or by placing a breakpoint in your program using the debug; instruction in said program.

Cyrille

[Bob Frazee]

Hi Cyrille;
Well, I tried your above suggestion.
App Name: HeatIndex
Inside App: EXPORT Heatindex()
Go to home screen
Select: Toolbox, then App, then HeatIndex->HeatIndex
I now have HeatIndex on the command line
I hit Enter. App does not start. All it does is shift HeatIndex above the command line and displays 0.0000
It does the same thing if I use HeatIndex().
It also does the same thing if I take the divide by 0 out of the App.

Am I doing something wrong?

[Han]

(03-28-2017 11:37 PM)Bob Frazee Wrote:  Hi Cyrille;
Well, I tried your above suggestion.
App Name: HeatIndex
Inside App: EXPORT Heatindex()
Go to home screen
Select: Toolbox, then App, then HeatIndex->HeatIndex
I now have HeatIndex on the command line
I hit Enter. App does not start. All it does is shift HeatIndex above the command line and displays 0.0000
It does the same thing if I use HeatIndex().
It also does the same thing if I take the divide by 0 out of the App.

Am I doing something wrong?

Was the app designed to start using the HeatIndex() program? In other words, how do you normally start your app? Usually, apps are "run" using one of the following physical keys: Plot, PlotSetup, Num, NumSetup, Symb, SymbSetup, View, or Info. Additionally, the app can also be "run" by using the Apps key, selecting the app, and choosing "Start" from the touchscreen menu. However, each of these buttons do (possibly) different things depending on the code definition for Plot(), PlotSetup(), etc. So unless those functions directly and immediately call HeatIndex(), then of course nothing will run.

Also, when you wrote "Inside App: EXPORT HeatIndex" -- was this to mean that you added EXPORT in front of HeatIndex inside the source code file?

[cyrille de brébisson]

Hello,

What does the HeatIndex function contain?

Cyrille

[Bob Frazee]

Cyrille wrote;
"What does the HeatIndex function contain?"

Code:


//Variables... 
t;rh;
hi;hi2;tmp;

// Subroutine...
HeatIndexCalc();
EXPORT HeatIndex()
BEGIN
END;

VIEW "Start HeatIndex",START()

BEGIN
STARTVIEW(-1,1);
WHILE GETKEY<>4 DO
 REPEAT
  tmp:=INPUT(
  {{t,[0],{60,22,1}},
   {rh,[0],{60,22,2}},
   {hi,[0],{60,22,4}},
   {hi2,[0],{60,22,5}}},
   "Heat Index Input and Output",
   {"Temperature, Deg F  : ",
    "Relative Humidity, %  : ",
    "Heat Index, Deg F  :",
    "Heat Index, Deg F  :"},
   {" Air Temperature (80 to 104 °F)",
    " Relative Humidity (40 to 100 %)",
    " Heat Index from www.weatherimages.org",
    " Heat Index from www.4wx.com"},
   {t,rh,hi,hi2},{t,rh,hi,hi2});

  IF tmp==0 THEN
   STARTVIEW(-4,1);
   MSGBOX("End of Program");
   RETURN;
  END;
 UNTIL t>=80. AND t<=104. AND rh>=40. AND rh<=100.; 

 HeatIndexCalc();
END; // While

STARTVIEW(-4,1);
MSGBOX("End of Program");
END;

HeatIndexCalc()
BEGIN
// This is the 16 element equation used to convert
// dry bulb temperature (T) and relative humidity (RH)
// into the Heat Index. This equation works at
// dry bulb temperatures of 70°F and higher.
// Source: http://www.weatherimages.org/data/heatindex.html

//  Where:
//  hi = Heat Index
//  t = Temperature (° F)
//  rh = Relative Humidity (%)

tmp:=16.923;
tmp:=tmp+1.85212*10^(-1)*t;
tmp:=tmp+5.37941*rh;
tmp:=tmp-1.00254*10^(-1)*t*rh;
tmp:=tmp+9.41695*10^(-3)*t^2;
tmp:=tmp+7.28898*10^(-3)*rh^2;
tmp:=tmp+3.45372*10^(-4)*t^2*rh;
tmp:=tmp-8.14971*10^(-4)*t*rh^2;
tmp:=tmp+1.02102*10^(-5)*t^2*rh^2;
tmp:=tmp-3.8646*10^(-5)*t^3;
tmp:=tmp+2.91583*10^(-5)*rh^3;
tmp:=tmp+1.42721*10^(-6)*t^3*rh;
tmp:=tmp+1.97483*10^(-7)*t*rh^3;
tmp:=tmp-2.18429*10^(-8)*t^3*rh^2;
tmp:=tmp+8.43296*10^(-10)*t^2*rh^3;
hi:=tmp-4.81975*10^(-11)*t^3*rh^3;
hi:=ROUND(hi,0);

// Source: http://www.4wx.com/wxcalc/formulas/heatIndex.php
tmp:=-42.379;
tmp:=tmp+2.04901523*t;
tmp:=tmp+10.14333127*rh;
tmp:=tmp-.22475541*t*rh;
tmp:=tmp-6.83783*10^(-3)*t^2;
tmp:=tmp-5.481717*10^(-2)*rh^2;
tmp:=tmp+1.22874*10^(-3)*t^2*rh;
tmp:=tmp+8.5282*10^(-4)*t*rh^2;
hi2:=tmp-1.99*10^(-6)*t^2*rh^2;
hi2:=ROUND(hi2,0);
END;

[Han]

It is fairly evident that the HeatIndex() function does absolutely nothing since there is no code there (just an empty BEGIN END; block).

The actual code that starts your app is the START() function that has been _ALSO_ duplicated as a [View] menu item, listed as "Start HeatIndex".

So the function you want to export (if that is in fact what you want to do) is the START() function.

[Bob Frazee]

Han wrote;
"In other words, how do you normally start your app?"
I typically start it by either tapping on the "HeatIndex" App screen icon or highlighting the App screen icon and hitting the "Enter" key.

I presume that HeatIndex() starts the program, and even though it appears to do nothing, the BEGIN END pair has to be there, or the App will not run. If it actually does nothing, then it should execute the next instruction, which is the VIEW command. The order of this App follows the DiceSimulation() App example on p 579 of the manual.

Cyrille wrote;
"Note that you can test your faulty app program function by exporting it and calling it directly from the command line. At this point, it will behave like a normal program."
So in this case, Han is correct?, I should export START()? How do I do that, since it is part of the View command? Do I need to structure my App differently than the example in the manual in order to use the code troubleshooting method Cyrille suggested?

[Han]

(04-02-2017 08:06 PM)Bob Frazee Wrote:  Han wrote;
"In other words, how do you normally start your app?"
I typically start it by either tapping on the "HeatIndex" App screen icon or highlighting the App screen icon and hitting the "Enter" key.

This suggests that the START() function is where your app gets run. The code you posted confirms this.

Quote:I presume that HeatIndex() starts the program, and even though it appears to do nothing, the BEGIN END pair has to be there, or the App will not run. If it actually does nothing, then it should execute the next instruction, which is the VIEW command. The order of this App follows the DiceSimulation() App example on p 579 of the manual.

You can simply delete the HeatIndex function (including the BEGIN/END pair) and your app will run just fine. This is just part of the template that gets created when copying an existing app (which you presumably renamed as HeatIndex) or when creating a new program file.

[quote]Cyrille wrote;
"Note that you can test your faulty app program function by exporting it and calling it directly from the command line. At this point, it will behave like a normal program."
So in this case, Han is correct?, I should export START()? How do I do that, since it is part of the View command? Do I need to structure my App differently than the example in the manual in order to use the code troubleshooting method Cyrille suggested?

In this case, where you have the START function defined with the VIEW command, I would simply rename it and create a wrapping START function.

Code:


START()
BEGIN
  ViewStart();
END;

VIEW "Start HeatIndex", ViewStart()
BEGIN
  // your original code here
END;

Now, you can add EXPORT in front of START and debug normally. Or, you can optionally just insert the DEBUG command anywhere in your code where you wish to start the debugging process. I find this second method much easier. By using multiple calls to the DEBUG command, I "skip" unnecessary debugging steps using the "continue" option, which runs the app/program up until the next instance of DEBUG.

[Bob Frazee]

Thankyou Han for your explanation. I took your examples and modified them a little, and this is what I ended up with;

Code:


//Variables... 
t;rh;
hi;hi2;tmp;

// Subroutine...
HeatIndexCalc();

EXPORT START()
BEGIN
STARTVIEW(-1,1);
WHILE GETKEY<>4 DO
.
.
.
The rest of the code follows unchanged (see previous post)

I buried a divide by zero in the HeatIndexCalc () subroutine, EXPORTED START to the home screen and ran it. This time instead of just dumping me to the home screen and telling me nothing, it dumped me to the home screen and displayed a dialog box with an "X START" in it. Really not as useful as a "divide by zero" error message that a regular hpprgm displays. I use divide by zero as an example, because it is pretty cut and dried and should be easy to catch. I know I have had other errors that have dumped me to the home screen and told me nothing, but I don't have them documented, and they may be a lot more difficult to alarm.

So back to my original question to the Hp group;
The division by 0 anomaly in an App has existed for a long time. I was wondering if improving App error message creation is at least being considered?

[Han]

Encapsulate your routines in an IFERR block; use Ans(0) to get the error number, if there was an error.

Code:


IFERR
  DoMyCode();
THEN
  RETURN(Ans(0));
END;

Only slightly more useful; division by 0 is error number 4.