Re: final message
- Posted by DerekParnell (admin) May 24, 2012
- 1463 views
I don't believe you guys will ever take any notice of what an outsider has to say, but..
What are you talking about? Where did you get that idea?
You cannot assume that "you guys" are all against you just because some disagree with your opinions. That attitude is not realistic.
These are thingns of some consequence:
Primary facts:
1 There is no multiplicative inverse of zero.
2 A Greatest Common Divisor has to:
. 1 be a divisor. ie it cannot be equal to zero.
. 2 be greater than any other divisor.
. Defining GCD(0,0) = 0 doesn't satisfy either
. condition 2.1 or 2.2.
No mathematical theory defines GCD(0,0) = 0.
The lattice theory article referenced defines
GCD(0,0) = 1 on the grounds that every integer is
divisible by 1. It doesn't satidfy 2.2.
Practical:
GCD(0,0) is given as 0 by a number of programming
languages because the Knuth algorithm would give
that result. Haskell gives it as undefined.
If used as a divisor it will likely produce an
exception or error. This would not necessarily occur
near where the exceptional result was produced.
There is, of course, the other difficulty that the
language may not have a value to return for
'not an integer'.
0/0:
Not indeterminate. See 1.
Can be defined to be any number with the consequence
of talking nonsense.
We are limited to the constraints of the programming language we are working with. As such, we have chosen that under some circumstances GCD() might not return a divisor. When the result of GCD() is not possible, we have decided to return 0 as a way to alert the calling code that something exceptional might have to be done.
We agree that GCD(0, x) where x != 0, returns abs(x), because that is the greatest number that divides into both 0 and x.
We agree that GCD(0, 0) is a special case. As every number (except 0) can divide into 0, the greatest divisor approaches infinity and thus cannot be determined. In this case, we have our GCD() function also return 0 to alert the calling code that something maybe wrong with the inputs to the function.
If Euphoria supported Exceptions, the we could have it raise an exception in this case, but we can't do that (yet) so a the function returns a special value (0) to indicate an exception.
intdiv(-8,-3):
Dividing -8 envelopes into sets of maximum -3 is easy
1 set holds -8 envelopes. Not what you wanted?
-1 set holds 8 envelopes? - No you can't do that!
Perhaps I am wrong and you can do this. Show me!
Divide -8 envelopes into -3 sets, not so easy
-2 sets hold 3 envelopes, -1 set holds 2 envelopes or
-4 sets hold 2 envelopes, 1 set holds 0 envelopes.
At some time you guys are going to have to admit that
you are seriously talking shit.
It is easy to get distracted here, but this function is working with magnitudes, not envelopes or any other units-of-measure. The UOM question is one that the standard library leaves for the calling code to work with.
The difference between intdiv() and div() is that the intdiv() result is always an integer.
So, div(-8, -3) gives 2.666666666666666... thus intdiv() needs to return this result but as an integer. The discussion is whether it should floor(), ceil(), or round() the result. It could be argued that the behaviour to take would depend on the reason the function is being called, but that is clearly in the domain of the calling code and intdiv() should be agnostic about why it is being called.
Sometimes we might want to know the maximum number of sets needed to contain all the items being divided; in which case ceil() is useful. However, sometimes we might be trying to find the number of complete sets needed; in which case floor() is better. I'm not sure why one would need to round() the div() result but there could be a valid use-case for that.
So, maybe we we need is to have intdiv() accept a third argument, that tells it how to handle the result of div() before returning. I would like to see ceil() be the default behaviour if the third argument was omitted, but that's negotiable.
Now it does get interesting when the arguments have different signs. div(-8, 3) and div(8, -3) give -2.666666666... So what should intdiv() do here? I'm thinking that we just keep the metaphor of intdiv() returning a number of sets in which case, it would always return a non-negative result. In other words, it should just ignore the arguments' signs.
