Division by zero question

[Cobalt]

small question, why if I do this
print 5 / 0
gives 1.#INF
but if I do this
m! = match~& / LOF(5)
and file #5=0 bytes
it throws a Division by zero exception and crashes the program?

this is a arse pain too cause its roughly 8 hours of processing before it happens and I bumped a key and closed the window before I could screen capture it to check out the file it just processed . so it will be like 8 hours before I could repeat it.
I have an IF THEN checking to make sure that the file opened as #5 is not 0 bytes( IF LOF(5) = LOF(6) AND LOF(5) > 0 THEN ) which makes me even more curious about it.


if I just try opening a blank file and running that line it doesn't crash as stand alone

open "blankfile.txt" for binary as #5
m! = match~& / LOF(5)
('PRINT m!' shows that m!= 1.#IND not 1.#INF??)

so its gotta be something else but thats the only line that doesn't have a hard coded value as the divisor.  thats the only / that could have a 0 value and there are no \ that are not directory\file related. I even used the SEARCH to find all the / and \ to make sure I wasn't missing one. and nothing else showed up. there is a / in the startup but that happens within the first 18.5 seconds of run and is never used again. This error happened in the COMPARE routine. Its running again right now but its it will be another 8 hours or so before it should happen again. 10 pm here so should happen around 6am EST

[SMcNeill]

Can you set on ON ERROR event to tell you what line the glitch shows up on?  It doesn't sound as if it's that one, from your own testing.

[Pete]

I don't have the most outdated, but I do know the early 2018 version gave division by zer error if you used integer division...

OPEN "junk.tmp" FOR BINARY AS #1 ' Empty file.
PRINT 1 \ LOF(1)

Same for

PRINT 3 \ 0

I don't know if this is different in the latest version. My point is simply, are you sure in your code it's regular division, the forward slash "/" or is it by any chance the backslash, "\" for integer division?

Pete

[TerryRitchie]

Regardless of what you get for an error, either a stop condition or undefined value, you should always put an error trap in your code to stop this from happening any way if you are not sure of what the divisor may be.

IF a <> 0 THEN  ' will a division by zero occur?
    B = 10 / a '      no, proceed with calculation
END IF

[Cobalt]

I don't have the most outdated, but I do know the early 2018 version gave division by zer error if you used integer division...

OPEN "junk.tmp" FOR BINARY AS #1 ' Empty file.
PRINT 1 \ LOF(1)

Same for

PRINT 3 \ 0

I don't know if this is different in the latest version. My point is simply, are you sure in your code it's regular division, the forward slash "/" or is it by any chance the backslash, "\" for integer division?

Pete

Yeah thats why I used search to look for them cause that does cause the crash when tested, none came up. was actually my first thought till I saw the line had "/" and crushed my hopes of a quick fix.

Regardless of what you get for an error, either a stop condition or undefined value, you should always put an error trap in your code to stop this from happening any way if you are not sure of what the divisor may be.

IF a <> 0 THEN  ' will a division by zero occur?
    B = 10 / a '      no, proceed with calculation
END IF

thats what this line does:
                                        | make sure the file is not empty (>0)
IF LOF(5) = LOF(6) AND LOF(5) > 0 THEN

Can you set on ON ERROR event to tell you what line the glitch shows up on?  It doesn't sound as if it's that one, from your own testing.

find out in another  7 hours. Thats the worst part, the wait, since I don't remember just how many files had been processed I can't just have it start in that area and see what happens.

[Cobalt]

ON ERROR wont catch it, critical errors and kills the program, thing is the file isn't even 0 bytes it 8 as you can see in the image.

but I isolated the line its not a division in the direct visual sense, its actually cause by a MOD. I was thinking strictly '/' or '\' and was looking just for those, easy to forget MOD is a division under the hood.

IF (LOC(5) MOD modd&) = 0 THEN LOCATE 17, 1: PRINT LOC(5)

that causes the error cause the file isn't 0 its 8 bytes and 8/10 is .8 and QB64 turns INT(.8) to 0 will be adding a +1 to the end of that.

Code: QB64: [Select]

1.     CASE IS <= 250000
2.      PRINT "<= 250000 small run"
3.      modd& = INT(LOF(5) / 10)  '<--- thee offending 0 is produced here.
4.      DO
5.       GET #5, , temp1~%
6.       GET #6, , temp2~%
7.       IF temp1~% = temp2~% THEN match~& = match~& + 2 ELSE nomatch~& = nomatch~& + 2
8.       IF (LOC(5) MOD modd&) = 0 THEN LOCATE 17, 1: PRINT LOC(5)  '<--- causing this innocent line to error out.
9.      LOOP UNTIL EOF(5) OR EOF(6)
10.  

so apparently MOD is treated like an integer division '\' and doesn't get the 1.#INF treatment.

Would there be anyway to change that? cause ON ERROR doesn't seem to catch before the program gets killed by the CRITICAL ERROR msg from the OS(windows anyway).

[TerryRitchie]

IF LOF(5) = LOF(6) AND LOF(5) > 0 THEN

Try reworking this line a few ways. I have had unexpected results when using boolean in this type of manner. Try adding parenthesis around areas and test the results:

IF LOF(5) = (LOF(6) AND LOF(5)) > 0 THEN

IF LOF(5) = LOF(6) AND (LOF(5) > 0) THEN

etc..

Just a thought that may help.

[codeguy]

I have found mod when using large numbers and small divisors to be problematic.
For a large number mod 2, it's been more than disappointing. So I use constructions like

v&=n& \ 10000
r&= (n& - 10000* v&) mod 2

Which then correctly gives the remainder after division. Not sure if this problem has been solved in newer releases, but v1.2 seems to require this workaround.