LB Booster
General >> General Board >> "Number Too Big" error http://lbb.conforums.com/index.cgi?board=general&action=display&num=1428932740 "Number Too Big" error
Post by Monkfish on Apr 13th, 2015, 1:45pm
Very rarely I get this error message flag up from a line that is totally innocuous:
175900 temp1=grid(j1)
grid is simply created by Dim grid(52) j1 is simply created by the line
175600 j1=int(rnd(1)*weeks)+1
that comes just before.
weeks simply equals 28
I have not got a clue on this one.
Re: "Number Too Big" error
Post by Monkfish on Apr 13th, 2015, 1:59pm
It happens so rarely that it is difficult to trap. I know I have the right line because I forced an error on that line by trying to write to array element 100, which is out of bounds. That brought up a different massage but from the same line.
Is there an error log for LBB I could read.
So far it has only come up in the compiled executable version of the program not when I run from the LBB editor. I haven't been able to reproduce the error in debug mode either.
Strangely this step is in my inner loop which has executed hundreds of millions of times without error.
Re: "Number Too Big" error
Post by Richard Russell on Apr 13th, 2015, 3:23pm
Very rarely I get this error message flag up from a line that is totally innocuous: 175900 temp1=grid(j1)
Some questions:
1. Can you confirm you are using LBB v3.00 rather than an earlier version?
2. What is the 175900 here? Is it a line number, a numeric label or what?
3. The 'Number too big' error should say 'at line' something. What line number does it report (I'm guessing it is zero, otherwise you would have said)?
4. When you forced an error by writing to array index 100, what was the exact code you used? I am unclear how you used that to find the line.
5. Are there things happening 'in the background', such as TIMER events, GUI events or CALLBACKs, when the error occurs?
Richard. Re: "Number Too Big" error
Post by Monkfish on Apr 13th, 2015, 8:11pm
No, I am using LBB version 2.82
Yes 175600 is the line number. Old habits die hard.
Yes, the error message said at Line 823, which is this particular line number. To check I changed the line to temp1=grid(100), which forced a bad subscript error at line 823. It's the only way I could think of to confirm I had the right line.
I do use the timer instruction in the program, but it should be set to zero while this code is executed. It should be, unless there is something about the timer I don't understand... which is always possible. Here is the timer code:
timer 100, [cont] [back] i$=input$(1): if asc(i$)<>13 then goto [back] timer 0: goto [Enter_Pressed] [cont] timer 0: goto [Continue]
It essentially checks the entire keyboard buffer to see if the Return key has been pressed while the program was off doing other stuff (I stripped out the embarrassing line numbers and replaced them with labels instead). As you can see, the code shouldn't be able to escape without disabling the timer.
Thanks Richard Re: "Number Too Big" error
Post by tsh73 on Apr 13th, 2015, 9:32pm
wait - does LBB has non-blocking INPUT$(1)? does it documented somewhere? Code:
timer 100, [back]
[back]
print time$("ms")
scan
i$=input$(1): if asc(i$)<>13 then goto [back]
timer 0
print "Enter pressed"
end
*falls off chair*
Re: "Number Too Big" error
Post by Richard Russell on Apr 13th, 2015, 9:54pm
So please upgrade. I can only provide support for v3.00.
Quote:
Yes 175600 is the line number. Old habits die hard.
So are you using GOTOs or GOSUBs to line numbers? Although that works in LBB it's not a feature that is extensively tested because it's rarely used (and it's slow compared with using labels).
Quote:
It's the only way I could think of to confirm I had the right line.
If it said 'at line 823' that's the actual line in your source program where the error happened, so you need only page down and move the cursor (caret) until that number is displayed in the status bar. In v3.00 it's even easier: bring up the Goto Line dialog (e.g. Ctrl+G) and type in 823.
Quote:
Here is the timer code: Code:
timer 100, [cont]
[back]
i$=input$(1): if asc(i$)<>13 then goto [back]
timer 0: goto [Enter_Pressed]
It's a bit unusual but I can't see any obvious reason why it wouldn't work.
Edit: Anatoly has rightly identified a potential problem with this code, so it ought to be changed to use INPUT rather than INPUT$(1).
Richard.
Re: "Number Too Big" error
Post by Richard Russell on Apr 13th, 2015, 10:46pm
It works the same as the regular INPUT statement: it blocks but internally does a SCAN so can be interrupted by a TIMER or GUI event.
However in the case of INPUT$(1) that feature is really only intended to be used with a SUB handler. Using a label as the TIMER handler is risky because it may cause a jump out of the expression evaluator.
Maybe that is indeed the cause of the OP's problem. As he is trying to detect the Enter key being pressed a regular INPUT should work just as well, and is safer:
Richard. Re: "Number Too Big" error
Post by Monkfish on Apr 14th, 2015, 9:51pm
Thanks for all your help guys. I am now using V3.00 and have done what you suggested. I haven't seen the error again, so cross fingers
Richard, when you said that line numbers are slower what did you mean exactly? I thought line numbers were viewed by the compiler like labels... just that every line has a label. Will it actually make my program slower?
Re: "Number Too Big" error
Post by Richard Russell on Apr 14th, 2015, 10:45pm
I thought line numbers were viewed by the compiler like labels... just that every line has a label. Will it actually make my program slower?
It can, yes (in LBB; I can't speak for LB). It all depends on where the line you are jumping to is. If it's near the beginning of the program then using a line number may be no slower than a label (it may even be faster) but the further into the program the destination is, the slower using a line number will become. With a label the location of the destination makes little difference to the speed.
Richard.
Re: "Number Too Big" error
Post by Monkfish on Apr 15th, 2015, 07:58am
Oh, thanks Richard, I didn't know that. Clearly I need to go to programming Boot Camp!
