Tweet
Hi Dear Biomch-L Readers,
Here is a summary of the messages I received after my posting regarding the
zero division problem.
Actually, it's not a summary, but a list. Of course you can call me
lazy, but the point of views were so different I preffered to keep
them in their 'original version'.
What I'm doing now is to put a variable in the setup file of the program.
According to the value of this variable, the program may adopt one of the
following solutions:
warning messages, add a value to denominator if zero, always add value ...
Also admire and enjoy the lesson of geography about Norway sent by
Oyvind Stavdahl!!
___
|. .|
Serge Van Sint Jan (sabbatical) | " |
Department for Mechanical Engineering \=/
The University of New Mexico \|/ | \|/
Albuquerque, USA \ | /
voice: int + 1 505 277 2339 -^-----^-
fax: 1571 |
email: serge@slider.unm.edu |
( )
/ \
/ \
| |
| |
-- --
--------- ORIGINAL POSTING ----------
Dear Biomch-L Readers,
Everybody knows the problem of a division with a divisor
equal to ZERO.
When programming, three solutions can be used to avoid an interruption of
your program with display of inflamed error messages from the system:
1: Test the divisor before each division and if it is equal
to zero skip the division or even abort the current
subroutine.
2: Test the divisor before each division and if it is equal
to zero, add a very small number to the divisor.
3: Systematically add a very small number to ANY divisor.
(In the examples of Matlab, 2.204e-16 is added systematically).
Solution 1 is surely the most honnest. But it is difficult to explain to a user,
who does not care about math, that his data can not be processed
because somewhere "a division by zero" appears.
So, Solution 2 can be used. But the addition of the small number only takes
place for some data and not for the others (because of the "if").
To avoid to disturb the "harmony of the balance" in the data set, Solution
3 may be applied. But is it really scientific to alter numbers with the
only reason that one of them will produce a 0 divide exception?
So, after this (maybe too!) long introduction, my questions are:
1- What is your personal opinion and experience on the subject?
How do you solve the problem when programming and why?
2- Are they any well-defined rules?
Or maybe nobody cares and uses the best solution according to
his own application?
Thank you for any answers! I shall post a summary of the answers later.
---- From: "Will G Hopkins"
You should do what SAS does: abort that step and return a missing value.
Nothing else makes sense. Maybe if the numerator is zero too, you could
flag it specially, because 0/0 is a bit different from (nonzero)/0.
Will G Hopkins PhD
Physiology and Physical Education
University of Otago, Dunedin, NZ
---- From deleva@risccics.ing.uniroma1.it
A division by zero should give as a result an infinite number.
For example, the slope of a straight line parallel to the y axis is
infinite, and so is the tangent of 90 degrees (PI/2).
I suggest to change the result of a division by 0, instead of
the divisor.
If your programming language allows computing the tangent of
PI/2, the result of a division by zero could be made equal to:
TAN (ATAN(1) * 2),
where ATAN(1) * 2 is the value of PI/2. (TAN=tangent, ATAN=arctangent).
Computing the tangent of PI/2, you will have the largest number
your machine can produce, i.e. the colosest to infinite.
Adding the same infinitesimal number to any divisors is not
a good solution: an error will occur when the divisor is equal to the
opposite of your infinitesimal number (i.e., the number times -1)
The best solution anyway, in my opinion, is to write appropriate
specific code for handling the condition divisor=0, in each part of
your program where the division=0 might occur.
However, SOMETIMES IT IS RIGHT for a program to stop and report an
unrecoverable error when a division by zero is attempted. A division by
zero could indicate either the use of wrong input data, or a BUG in the
program, and this is a good reason not to automatically correct
any division by zero, wherever it occurs, without knowing the specific
consequences of this action in each particular segment of your program.
Please, let me know what are the resposes of the other
subscribers.
__________ _________ ___________~___ ________ _________________~___
/ ~ ~ ~ ~ \
/______________~______~__________ _______~_____~______________~_____~_____\
| Paolo de Leva ~ \ Tel.+ FAX: (39-6) 575.40.81 |
| Istituto Superiore di Educazione Fisica > other FAX: (39-6) 361.30.65 |
| Biomechanics Lab / |
| Via di Villa Pepoli, 4 < INTERNET e-mail address: |
| 00153 ROME - ITALY \ deLEVA@RISCcics.Ing.UniRoma1.IT |
|_____________________~________~__________________ __________________ _____|
Panta rei :-)
---- From dapena@valeri.hper.indiana.edu
In our work, there are certain situations in which a division by
zero is possible, although unlikely. For instance, it is possible that a
short segment (say, a hand) may very occasionally come out as having length
zero through a quirk in digitizing the raw data. In some of the
calculations that we do when looking for the angular velocity of a segment,
this will give a "divide by zero" error.
To handle these problems, I take what you call "approach #2", i.e.,
fix the problem, but only when there truly is a divison by zero. But I do
an extra thing. When the computer makes such a fix, I make it write to the
screen (not to any file) a message such as, "AT TIME T = 9.98 S THE LENGTH
OF SEGMENT 6 WAS ZERO", or something like that. That way, I know when one
of these adjustments has happened (which is extremely rare).
The possible solution #1 that you mention would be terrible, because
then every time that the program fails, you have to go crazy looking for
where it failed, and that can be very time consuming and frustrating. We've
all been there!!
Solution #3 is also not very good in my opinion because it adds a
lot of extra computation to the program if you have to add a small value to
each divisor before performing tha division. Also, I am not sure, but would
it not be possible that the addition of a small value to the divisor might
MAKE the divisor a previously safe (i.e., non-zero) divisor acquire the zero
value that will make it fail?
As I said before, I like best your solution #2 with the added
warning each time that the solution is actually used.
Of course, as i am sure that you realize, you have to consider also
what will happen to the number that comes out of the division in which we
have made the denominator be slightly off from zero. The number that will
come out will be a huge number, and we have to think of what the program
will later do with it, and what are the implications.
Continuing with the example that I mentioned previously, I alter the
segment length to a non-zero value to be able to make the division, and thus
calculate the angular velocity. However, the result will be a near-infinite
angular velocity, which when later multiplied by the moment of inertia of
the segment will give us a near-infinite angular momentum for the segment
(and consequently also for the whole body), which would mess up our results.
So what I do is alter the denominator into a non-zero value, and let the
computer calculate the (garbage) angular velocity. That way I keep the job
alive. Then I declare that the angular velocity just calculated for the
segment was zero, and make the program continue from there as when the
divider was not close to zero.
In other situations you may want to set up other "salvaging" routes.
This is one that works well in the situation described.
Jesus Dapena
---
Jesus Dapena
Department of Kinesiology
Indiana University
Bloomington, IN 47405, USA
1-812-855-8407 (office phone)
dapena@valeri.hper.indiana.edu (email)
---- From STERGIOU@OREGON.UOREGON.EDU
Dear Serge,
the problem can be solved if before you will do any divisions or any other
math, you check your data for zeros. If you will find any zeros, then you
can offer several interpolating solutions to the user. The user will then
decide what is best for his/her data.
Nick Stergiou
Biomechanics Lab
Univ. of Oregon
---- From Oddvar.Arntzen@avh.unit.no
Hello Serge!
You may instruct your compiler to generate error checking code for
the part of your program where divisions take place. When a division
by zero happens (or other illegal divisions as well), this error is
trapped by your program. Control is then transferred to an error handler
written by you. The error handler must have the ability to take the
needed precautions. This method let you divide anything by anyting
without abortion of the program. As an example, if a division by zero
takes place, the error handling routine may try to find why the divisisor
is zero (it may be that the divisor is a result of a data acquisition,
and this acquisition is not yet performed), and if wanted, adjust the
divisor accordingly, skip the division or whatever you want.
This error trapping method can also be utilized for other mathematical
purposes such as logarithms (what is the logarithm to zero?).
Oddvar Arntzen
Faculty of Social Sciences
University of Trondheim
7055 Dragvoll
NORWAY
Phones 47-73591908 47-74827673
Fax 47-73591901
E-mail oddvar.arntzen@avh.unit.no
---- From Oyvind.Stavdahl@itk.unit.no
Dear Serge,
I do not know any standard solution to the Divide-by-zero
problem, but I do have a personal opinion:
Any computer algorithm is constructed in order to solve
a (more or less) "realistic" problem, that is, which is
somehow related to a real-world problem. Therefore, when the
divide-by-zero problem arises and indicates "no solution",
it may have two (or probably more) reasons:
1. The real-world problem related to the running computer
algorithm DOES NOT HAVE a numerical solution. The reason for
this cold be, say, that the physical conditions present
during the data aquisition did not match the assumptions made
when constructing the algorithm. Therefore, an error message
would actually be the RIGHT RESULT of the computation; any
data adjustments that would cause the divide-by-zero not to
occur, would probably cause erroneous conclusions in this case.
2. If the data set is "valid", the problem might be related to the
computer software or hardware, such as roundoff errors or simply
program BUGS (logical algorithmic errors). The correct action
would be redesigning the algorithm or updating/improving the
hardware. If the problem is roundoff errors, a minor adjustment
of the data set could solve the problem, but one must carefully
examine the consequences of such an action (if the divisor is so
small that it is being rounded off to zero, adding a "small number"
is likely to change its value by several orders of magnintude; the
result of the division would be canged by the same factor).
To sum up this ("maybe too long") tirade, I believe one must determine
the REASON for the zero divisor in each case, otherwise one may deceive
oneself by creating solutions that are erroneous or even impossible.
If you get any "standard solution" responses, I would love to see them.
Good luck dividing numbers!
Regards,
Oyvind Stavdahl (Siv.Ing., Doctoral student)
THE NORWEGIAN INSTITUTE OF TECHNOLOGY
Dept. of Engineering Cybernetics
O. Bragstads plass 8
N-7034 TRONDHEIM
NORWAY
Phone +47 73 59 43 91 (direct)
+47 73 59 43 76 (switchboard)
Fax +47 73 59 43 99
Email stavdahl@itk.unit.no
_____
NORWAY - _/ /| '`-.
The land _// ' _ _,'
of the _/`-/ / \ -,
Vikings /._/ ,-. | |/
/_ - \ \_,_/
;' / ._/
' ,','
/ /
/ ;
/ /
/, /
_,-'O--- Trondheim
_/ /
/ \ \
,'- /
|--' O---- Lillehammer
|,-, ' |
`, O---- Oslo
/ _/\ /
\ / '
`-'
......................................
---- From salviap@ulb.ac.be
Salut Serge
J'ai lu ton message concernant les divisions par zero, la plupart du temps
lorsque j'ai un tel probleme, j'essaye d'abord de voir si la facon de
presenter le probleme necessite reellement d'utiliser la division. Si je suis
oblige de diviser, j'utilise une variable au denominateur que je teste.
Je pense que chaque situation a sa solution.
A Bientot, Patrick.
Patrick Salvia
Departement for Functionnal Anatomy
University of Brussels - Belgium
TRANSLATION:
I read your message about divisions by zero. Most of the time when I have
such a problem, I first try to see if the problem really needs to use
a zero division. And if I have to use it, I test the denominator.
I think each case has its specific solution.
---- From yhc3@cornell.edu
I am fairly new to the research scene, but it seems to me that altering
numbers to the nth degree changes the data very slightly. As long as when
you are interpreting your results, you don't expect to proclaim the same
(or even anywher near the same) magnitude of precision as the alteration,
then the addition will be lost during the analysis. I think it depends upon
how precisely you intend to interpret your results. Anyway, that's one grad
students opinion.
regards,
Young Hui
================================================== ===========================
CCCC
Young Hui Chang C C
Department of Anatomy C e-mail: yhc3@cornell.edu
College of Veterinary Medicine C U U phone: 607-253-3551
Ithaca, NY 14853-6401 C U C U fax: 607-253-3541
CUCC U
U U
UUUU
================================================== ===========================
---- From CORNWALL@NAUVAX.UCC.NAU.EDU
I use solution #1 because it is the most honest
Mark Cornwall
Northern Arizona University
Here is a summary of the messages I received after my posting regarding the
zero division problem.
Actually, it's not a summary, but a list. Of course you can call me
lazy, but the point of views were so different I preffered to keep
them in their 'original version'.
What I'm doing now is to put a variable in the setup file of the program.
According to the value of this variable, the program may adopt one of the
following solutions:
warning messages, add a value to denominator if zero, always add value ...
Also admire and enjoy the lesson of geography about Norway sent by
Oyvind Stavdahl!!
___
|. .|
Serge Van Sint Jan (sabbatical) | " |
Department for Mechanical Engineering \=/
The University of New Mexico \|/ | \|/
Albuquerque, USA \ | /
voice: int + 1 505 277 2339 -^-----^-
fax: 1571 |
email: serge@slider.unm.edu |
( )
/ \
/ \
| |
| |
-- --
--------- ORIGINAL POSTING ----------
Dear Biomch-L Readers,
Everybody knows the problem of a division with a divisor
equal to ZERO.
When programming, three solutions can be used to avoid an interruption of
your program with display of inflamed error messages from the system:
1: Test the divisor before each division and if it is equal
to zero skip the division or even abort the current
subroutine.
2: Test the divisor before each division and if it is equal
to zero, add a very small number to the divisor.
3: Systematically add a very small number to ANY divisor.
(In the examples of Matlab, 2.204e-16 is added systematically).
Solution 1 is surely the most honnest. But it is difficult to explain to a user,
who does not care about math, that his data can not be processed
because somewhere "a division by zero" appears.
So, Solution 2 can be used. But the addition of the small number only takes
place for some data and not for the others (because of the "if").
To avoid to disturb the "harmony of the balance" in the data set, Solution
3 may be applied. But is it really scientific to alter numbers with the
only reason that one of them will produce a 0 divide exception?
So, after this (maybe too!) long introduction, my questions are:
1- What is your personal opinion and experience on the subject?
How do you solve the problem when programming and why?
2- Are they any well-defined rules?
Or maybe nobody cares and uses the best solution according to
his own application?
Thank you for any answers! I shall post a summary of the answers later.
---- From: "Will G Hopkins"
You should do what SAS does: abort that step and return a missing value.
Nothing else makes sense. Maybe if the numerator is zero too, you could
flag it specially, because 0/0 is a bit different from (nonzero)/0.
Will G Hopkins PhD
Physiology and Physical Education
University of Otago, Dunedin, NZ
---- From deleva@risccics.ing.uniroma1.it
A division by zero should give as a result an infinite number.
For example, the slope of a straight line parallel to the y axis is
infinite, and so is the tangent of 90 degrees (PI/2).
I suggest to change the result of a division by 0, instead of
the divisor.
If your programming language allows computing the tangent of
PI/2, the result of a division by zero could be made equal to:
TAN (ATAN(1) * 2),
where ATAN(1) * 2 is the value of PI/2. (TAN=tangent, ATAN=arctangent).
Computing the tangent of PI/2, you will have the largest number
your machine can produce, i.e. the colosest to infinite.
Adding the same infinitesimal number to any divisors is not
a good solution: an error will occur when the divisor is equal to the
opposite of your infinitesimal number (i.e., the number times -1)
The best solution anyway, in my opinion, is to write appropriate
specific code for handling the condition divisor=0, in each part of
your program where the division=0 might occur.
However, SOMETIMES IT IS RIGHT for a program to stop and report an
unrecoverable error when a division by zero is attempted. A division by
zero could indicate either the use of wrong input data, or a BUG in the
program, and this is a good reason not to automatically correct
any division by zero, wherever it occurs, without knowing the specific
consequences of this action in each particular segment of your program.
Please, let me know what are the resposes of the other
subscribers.
__________ _________ ___________~___ ________ _________________~___
/ ~ ~ ~ ~ \
/______________~______~__________ _______~_____~______________~_____~_____\
| Paolo de Leva ~ \ Tel.+ FAX: (39-6) 575.40.81 |
| Istituto Superiore di Educazione Fisica > other FAX: (39-6) 361.30.65 |
| Biomechanics Lab / |
| Via di Villa Pepoli, 4 < INTERNET e-mail address: |
| 00153 ROME - ITALY \ deLEVA@RISCcics.Ing.UniRoma1.IT |
|_____________________~________~__________________ __________________ _____|
Panta rei :-)
---- From dapena@valeri.hper.indiana.edu
In our work, there are certain situations in which a division by
zero is possible, although unlikely. For instance, it is possible that a
short segment (say, a hand) may very occasionally come out as having length
zero through a quirk in digitizing the raw data. In some of the
calculations that we do when looking for the angular velocity of a segment,
this will give a "divide by zero" error.
To handle these problems, I take what you call "approach #2", i.e.,
fix the problem, but only when there truly is a divison by zero. But I do
an extra thing. When the computer makes such a fix, I make it write to the
screen (not to any file) a message such as, "AT TIME T = 9.98 S THE LENGTH
OF SEGMENT 6 WAS ZERO", or something like that. That way, I know when one
of these adjustments has happened (which is extremely rare).
The possible solution #1 that you mention would be terrible, because
then every time that the program fails, you have to go crazy looking for
where it failed, and that can be very time consuming and frustrating. We've
all been there!!
Solution #3 is also not very good in my opinion because it adds a
lot of extra computation to the program if you have to add a small value to
each divisor before performing tha division. Also, I am not sure, but would
it not be possible that the addition of a small value to the divisor might
MAKE the divisor a previously safe (i.e., non-zero) divisor acquire the zero
value that will make it fail?
As I said before, I like best your solution #2 with the added
warning each time that the solution is actually used.
Of course, as i am sure that you realize, you have to consider also
what will happen to the number that comes out of the division in which we
have made the denominator be slightly off from zero. The number that will
come out will be a huge number, and we have to think of what the program
will later do with it, and what are the implications.
Continuing with the example that I mentioned previously, I alter the
segment length to a non-zero value to be able to make the division, and thus
calculate the angular velocity. However, the result will be a near-infinite
angular velocity, which when later multiplied by the moment of inertia of
the segment will give us a near-infinite angular momentum for the segment
(and consequently also for the whole body), which would mess up our results.
So what I do is alter the denominator into a non-zero value, and let the
computer calculate the (garbage) angular velocity. That way I keep the job
alive. Then I declare that the angular velocity just calculated for the
segment was zero, and make the program continue from there as when the
divider was not close to zero.
In other situations you may want to set up other "salvaging" routes.
This is one that works well in the situation described.
Jesus Dapena
---
Jesus Dapena
Department of Kinesiology
Indiana University
Bloomington, IN 47405, USA
1-812-855-8407 (office phone)
dapena@valeri.hper.indiana.edu (email)
---- From STERGIOU@OREGON.UOREGON.EDU
Dear Serge,
the problem can be solved if before you will do any divisions or any other
math, you check your data for zeros. If you will find any zeros, then you
can offer several interpolating solutions to the user. The user will then
decide what is best for his/her data.
Nick Stergiou
Biomechanics Lab
Univ. of Oregon
---- From Oddvar.Arntzen@avh.unit.no
Hello Serge!
You may instruct your compiler to generate error checking code for
the part of your program where divisions take place. When a division
by zero happens (or other illegal divisions as well), this error is
trapped by your program. Control is then transferred to an error handler
written by you. The error handler must have the ability to take the
needed precautions. This method let you divide anything by anyting
without abortion of the program. As an example, if a division by zero
takes place, the error handling routine may try to find why the divisisor
is zero (it may be that the divisor is a result of a data acquisition,
and this acquisition is not yet performed), and if wanted, adjust the
divisor accordingly, skip the division or whatever you want.
This error trapping method can also be utilized for other mathematical
purposes such as logarithms (what is the logarithm to zero?).
Oddvar Arntzen
Faculty of Social Sciences
University of Trondheim
7055 Dragvoll
NORWAY
Phones 47-73591908 47-74827673
Fax 47-73591901
E-mail oddvar.arntzen@avh.unit.no
---- From Oyvind.Stavdahl@itk.unit.no
Dear Serge,
I do not know any standard solution to the Divide-by-zero
problem, but I do have a personal opinion:
Any computer algorithm is constructed in order to solve
a (more or less) "realistic" problem, that is, which is
somehow related to a real-world problem. Therefore, when the
divide-by-zero problem arises and indicates "no solution",
it may have two (or probably more) reasons:
1. The real-world problem related to the running computer
algorithm DOES NOT HAVE a numerical solution. The reason for
this cold be, say, that the physical conditions present
during the data aquisition did not match the assumptions made
when constructing the algorithm. Therefore, an error message
would actually be the RIGHT RESULT of the computation; any
data adjustments that would cause the divide-by-zero not to
occur, would probably cause erroneous conclusions in this case.
2. If the data set is "valid", the problem might be related to the
computer software or hardware, such as roundoff errors or simply
program BUGS (logical algorithmic errors). The correct action
would be redesigning the algorithm or updating/improving the
hardware. If the problem is roundoff errors, a minor adjustment
of the data set could solve the problem, but one must carefully
examine the consequences of such an action (if the divisor is so
small that it is being rounded off to zero, adding a "small number"
is likely to change its value by several orders of magnintude; the
result of the division would be canged by the same factor).
To sum up this ("maybe too long") tirade, I believe one must determine
the REASON for the zero divisor in each case, otherwise one may deceive
oneself by creating solutions that are erroneous or even impossible.
If you get any "standard solution" responses, I would love to see them.
Good luck dividing numbers!
Regards,
Oyvind Stavdahl (Siv.Ing., Doctoral student)
THE NORWEGIAN INSTITUTE OF TECHNOLOGY
Dept. of Engineering Cybernetics
O. Bragstads plass 8
N-7034 TRONDHEIM
NORWAY
Phone +47 73 59 43 91 (direct)
+47 73 59 43 76 (switchboard)
Fax +47 73 59 43 99
Email stavdahl@itk.unit.no
_____
NORWAY - _/ /| '`-.
The land _// ' _ _,'
of the _/`-/ / \ -,
Vikings /._/ ,-. | |/
/_ - \ \_,_/
;' / ._/
' ,','
/ /
/ ;
/ /
/, /
_,-'O--- Trondheim
_/ /
/ \ \
,'- /
|--' O---- Lillehammer
|,-, ' |
`, O---- Oslo
/ _/\ /
\ / '
`-'
......................................
---- From salviap@ulb.ac.be
Salut Serge
J'ai lu ton message concernant les divisions par zero, la plupart du temps
lorsque j'ai un tel probleme, j'essaye d'abord de voir si la facon de
presenter le probleme necessite reellement d'utiliser la division. Si je suis
oblige de diviser, j'utilise une variable au denominateur que je teste.
Je pense que chaque situation a sa solution.
A Bientot, Patrick.
Patrick Salvia
Departement for Functionnal Anatomy
University of Brussels - Belgium
TRANSLATION:
I read your message about divisions by zero. Most of the time when I have
such a problem, I first try to see if the problem really needs to use
a zero division. And if I have to use it, I test the denominator.
I think each case has its specific solution.
---- From yhc3@cornell.edu
I am fairly new to the research scene, but it seems to me that altering
numbers to the nth degree changes the data very slightly. As long as when
you are interpreting your results, you don't expect to proclaim the same
(or even anywher near the same) magnitude of precision as the alteration,
then the addition will be lost during the analysis. I think it depends upon
how precisely you intend to interpret your results. Anyway, that's one grad
students opinion.
regards,
Young Hui
================================================== ===========================
CCCC
Young Hui Chang C C
Department of Anatomy C e-mail: yhc3@cornell.edu
College of Veterinary Medicine C U U phone: 607-253-3551
Ithaca, NY 14853-6401 C U C U fax: 607-253-3541
CUCC U
U U
UUUU
================================================== ===========================
---- From CORNWALL@NAUVAX.UCC.NAU.EDU
I use solution #1 because it is the most honest
Mark Cornwall
Northern Arizona University