the world's smallest number?

[Steven Bell]

Originally posted by James Christian:


public void shareOutSurplus(int surplus, int dividedBy) {

int bonus = surplus/dividedBy;
int remainder = surplus%dividedBy;
}

But in a world were everything is dictated by intellectuals who give more weight to unproven theoretical maths than common sense the code actually needs this:

if (surplus != 0)

No, surplus can be zero, you have to check if dividedBy is zero. The problem is that you see division by zero where there is no division.

Lets try this.

If I owned a business and decided that I would take $1000 into work at 6am and divide it among the employees that were there (bonus for being early). I walk into work and there are no employees I don't attempt to divide the money, no division takes place. Yes the remainder is $1000, but notice that in my above example, using the subtraction you brought up, the remainder is 5, but the number of subtractions is infinite.

It's not that we have some wonderful common sense ability to divide by zero it's that we have a wonderful common sense ability to know not to divide.

[Gerald Davis]

This is all over me head man! I think I should leave it to you guys

[Nick George]

I'd say that your $1000 remains in one peice, which is to say it was divided by 1, $1000 with $0 remainder.

[Steven Bell]

Yes Nick, In that case I (as the manager/owner) would be the 1. The point I was trying to make to James is that I don't attempt to divide by zero. James seems to think it is perfectly ok to divide by zero.

Although while I'm thinking about it.

James,
Knowing that computers are only capable of addition devise a way to divide by zero using only addition (in this case we'll allow adding negative numbers without the 2's complement longhand). There can be no check for zero of the inputs and it must work for all integers (within computer range). If you can do that I'll buy that division by zero is not a special case.

[James Christian]

Dearest Fred,

It's not a contradiction. The only evidence you offered me is that you can't accept that dividing by 0 is the same as not dividing yet in your code you write well accepted staments such as:

5 - 0 = 5

If you accept that when we subtract 0 from 5 the amount subtracted is 0 and that the remainder is five you must also accept that repeatedly subtracting 0 also leaves a remainder of 5 no matter how many times you do it.

In my previous example I have demonstrated the practicallity of the fact that dividing by 0 is the same as not dividing. You would eliminate the overhead of Runtime checking for division by 0 and also the added overhead in my code " if(surplur!=0) " which I have to supply to counteract the already not necessary overhead and you would also eliminate the need to implement an "else" statement which would provide the correct implementation, that of giving a bonus of 0 and leaving the surplus in tact for the next day.

Hence I challenge you to a gentlmenly dual of coding whereby you give to this forum a sample of code which practically justifies the Runtime exception of checking for division by 0 in a way that reflects a real life situation.

If you are unable to produce such an example I will understand that you finally admit that dividing by 0 is the same as not dividing just as subtracting 0 is the same as not subtracting at all.

[Jim Yingst]

James, consider this method:

    public static void showCompoundFraction(int numerator, int denominator)
    {
        int result = numerator / denominator;
        int remainder = numerator % denominator;
        System.out.println(numerator + " divided by " + denominator + " is " + result
                + " and " + remainder + "/" + denominator );
    }

This seems to give fairly sensible results for all positive inputs. What should the output be if it's called with numerator = 5 and denominator = 0? (By "should" I mean, what woud the result be if division in Java worked the way you describe?)

[James Christian]

Dear Jim,

if you divide 5 by 0 and JVM is working as I say it should the result should be 0 with a remainder of 5.

[James Christian]

No, surplus can be zero, you have to check if dividedBy is zero. The problem is that you see division by zero where there is no division.

Dear Steven,

you are absolutely right. I meant to write if (dividedBY != 0). Sorry if it caused any confusion.

[James Christian]

To make it even more interesting can anyone justify adding to the JVM Runtime exceptions which check for adding 0 or subtracting 0.

[James Christian]

Dear Steven,

posted April 05, 2005 02:22 PM Profile for Steven Bell Edit/Delete Post Reply With Quote Yes Nick, In that case I (as the manager/owner) would be the 1. The point I was trying to make to James is that I don't attempt to divide by zero. James seems to think it is perfectly ok to divide by zero.

Although while I'm thinking about it.

James,
Knowing that computers are only capable of addition devise a way to divide by zero using only addition (in this case we'll allow adding negative numbers without the 2's complement longhand). There can be no check for zero of the inputs and it must work for all integers (within computer range). If you can do that I'll buy that division by zero is not a special case.

As far as I can remember from Uni days when we did computer organisation and architecture this would have been automatic with the existing architecture. The fact is that we have hard wired into the silicon to check for division by 0 so that the normal (and in my opinion realistic) operation does not take place.

I have to admit that I can't remember the exact mechanics of it but I'll be sure to get back to you on it.

But before I go shaking the dust of my old uni books. Do you promise that you will accept it once I've demontrated the mechanics of it all?

[Warren Dew]

Gosh, I never realized that real people got confused between dividing by zero and dividing by one.

James, the reason processors check for division by zero as a special case is because they normally perform division by repeated subtraction. Without the special case, division by zero would cause a hardware level infinite loop (until the computer got shut off, as you point out). Some people seem to think having the option of handling a hardware exception is better than having to manually pull the plug each time.

[Jayesh Lalwani]

Originally posted by Warren Dew:
Gosh, I never realized that real people got confused between dividing by zero and dividing by one.

James, the reason processors check for division by zero as a special case is because they normally perform division by repeated subtraction. Without the special case, division by zero would cause a hardware level infinite loop (until the computer got shut off, as you point out). Some people seem to think having the option of handling a hardware exception is better than having to manually pull the plug each time.

yup, that's how I remember my 8086 programming class(I am rusty on the syntax )

      set result 0
:loop if numerator < denominator jump to end
      numerator = numerator - denominator      
      increment result
      jump to loop
:end  set numerator to remainder
 

I don't see how you can get 5/0=0 without checking the denominator for 0. Maybe, our math expert aka James can come up with a better logic.

[James Christian]

Yes Warren you are absolutely right of course. But let us not miss my major point here.

The point wasn't whether the hardware must or must not check for the exceptional circumstance the point is how it is dealt with.

What I'm trying to explain without diverging too far from the point is that dividing by 0 is the same as not dividing at all (i.e 5 /0 = 0 remainder 5) just as subtracting 0 is the same as not subtracting at all (i.e 5 - 0 = 5).

My challenge still stands and has thus far remained unanswered to provide a practical java coded example that reflects a real situation where the Runtime exception is justified rather than just giving 0 remainder x (where x = original amount). My example clearly illustrates that this behaviour gives practical and useful results for real life situations and I can think of many more. But no-one can present a realistic (i.e non theoretical) situation where the Runtime exception actually saves the normal functioning of the program.

Anyway returning to Paul's original question all of this was merely to demonstrate to Paul that there is no such smallest number greater than 0 as both infinity and 0.99(9) repetend are merely theoretical concepts and represent no real mathematical function. When a calculator gives the infinity symbol as its answer what it is really saying is "Sorry, I can't count that far". Everything in the physical universe depends on its finiteness. Dividing a cake by 0 people doesn't make it magically become infinite in size and just as it would be absurd to say it does it is just as absurd to say that 5 / 0 = infinity as does 3 / 0, as does 2 / 0.

As stated before by our compadre Fred multiplication and division must complement each other for our implementation to be correct. So by this logic if 5/0=infinity the reverse operation infiniy infinity * 0 should equal 5 but it doesn't so obviously our understanding and implementation is flawed.

As I have said before just as adding 0 is the same as not adding anything and subtractracting 0 is the same as not subtracting anything dividing by 0 is the same as not dividing (the cake remains whole until it divided 1 or more people).

So the challenge still stands. Who can present a coded example of a real life situation which demonstrates the usefulness of and justifies the behaviour of the JVM when we divide by 0. My example has more than irrefiutably demonstrated that this is not the case.

[Steven Bell]

Adding and subtracting zero have a known, quantifiable, result. Dividing by zero does not.

This is (roughly) the way integer division takes place at the hardware level. (Register access and 2s compliment simplified, basically sudocode)

result = 0;
while(numerator >= denominator){
  result++
  numerator -= denominator
}
return result

This simply doesn't allow division by zero, you would have to check and return 0 simply because you divide by zero, but that would contradict the definition of division.

If you can write a similar function/sudocode that allows the division of zero without explicit checks be my guest. What you are saying is that 'I don't like the way math works, we should just change it.'

[James Christian]

I agree that we need to check for the division by 0 so that we can handle it correctly. What I'm saying is, is that it isn't being handled correctly.

posted April 05, 2005 05:04 PM Profile for Steven Bell Edit/Delete Post Reply With Quote Adding and subtracting zero have a known, quantifiable, result. Dividing by zero does not.

Prove it! Give a real life example where the behaviour of the error check saves us.

I'm not saying that I don't like the way math works. I'm saying that when you divide a cake by 0 people it isn't broken up into a infinite number of infinitely small pieces and each of the small pieces is given to er well nobody. When you divide something by 0 it remains as it is.

Like I say prove it. Give a real life example where dividing by 0 gives infinity and the JVM saves the day.

[elizabeth smith]

I think there's an answer on this site:

[link removed-Max. I can't believe you went to all the trouble of setting up an account. I wish I had the kind of time on my hands that you seem to find on yours]

[ April 05, 2005: Message edited by: elizabeth smith ]
[ April 05, 2005: Message edited by: Max Habibi ]

[James Christian]

Dear Elizabeth,

the link takes you to a gorgeous blonde. Do you know her? Is she married? She says she's mother of two but hey I don't mind, I love children.

Anyway, where was the evidence dividing by 0 produces infinity (a number that does not exist)?

[Steven Bell]

Take a look here.

[fred rosenberger]

According to everything i learned in all my math classes (i don't have a B.A., but i'm certified to teach middle and high school math, which required me to take the same courses), division by 0 is undefined. you can't do it. it's not allowed. end of discussion.

as to how and why the hardware/software works how it does - i'm really not qualified to address that. My guess is that since MATHEMATICALLY, you can't divide by 0, they implemented it that way - to be consistant with the laws of mathematics.

it's not that I can't accept that "dividing by 0 is the same as not dividing", but that NO MATHEMATICIAN IN well, pretty much HISTORY can accept dividing by 0.

now, COULD they have implemented Java to allow you to divide by 0 without throwing an exception? probably. but then i doubt any serious scientific community would adopt a language that does something mathematical fundamentally wrong. I'm reasonalby sure Sun would have been the laughing stock of the programming world for years to come. People would have said "they can't even do THIS ONE SIMPLE THING RIGHT, so how can we trust them to do anything else right???"

remember when Intel got into trouble because on rare occasions, their floating point arithmatic was wrong? something that very few people would ever notice, let alone CARE about? this would have been worse...

[Nick George]

Wait.

This seems easy to settle.

James, I challenge you to a gentlmanly duel of defining, in which I challenge you to define the operation P(x,y) that is congruous with our intuitive understanding of "division," but which allows for either x or y to be 0. You previously claimed that all operations derive from addition, so I suggest you start with that. No defining special cases for y being 0.

[Joel McNary]

Hmm... I was always taught that x/0 is undefined, not infinity. That is, there is no solution, not even a non-existant number.

And my wife (with no mathematical background, keep in mind) says that 1.0000... - 0.99999... is 0.000...1

that is, a 1 with infinate zeros between it and the decimal. Since there are an infinate number of zeros, we on this side of infinity can never reach the one, but those living on the other side of infinity cannot reach the decimal point. If I can live with the fact that we cannot exceed the speed of light, but those things moving faster than light can not slow down slower than the speed of light, then I can live with this answer.

[David O'Meara]

Originally posted by Joel McNary:
Hmm... I was always taught that x/0 is undefined, not infinity. That is, there is no solution, not even a non-existant number.

True. Reaching back into calculus, limits, and dividing by zero, x/0 is undefined when x!=0, but there is a special case referred to as "L'Hopitals for zero on zero" which basically states:

if f(a)=0 and g(a)=0 then limit(x->a) f(x)/g(x) = lim(x->a) f'(x)/g'(x)

I hope I got that right. That is, while it is not possible to define what 'divide by zero' means, it may be posisble to define what zero/zero means. But sometimes it isn't

eg limit(x->0) 2x/3x = limit(x->0)2/3 = 2/3

I'm not sure if this a step towards the answer or will just stir the pot If Gerald doesn't like 'infinity' he may not like 'limits' either

I'm saving the concept of 'multiple infinities' for later in the conversation. :roll:

[Jim Yingst]

[James]: Prove it! Give a real life example where the behaviour of the error check saves us.

OK. To satisfy my own curiosity, I've just administered an IQ test for you. And I'm sorry to report that you scored 0 percent. Well, to be fair, the Java program I used to calculate the result actually reported an ArithmeticException. Here's the line of code that threw it:

int percentCorrect = (int) ((100.0 * numCorrect) / numQuestions + 0.5);

Ordinarily I would have considered the ArithmeticException as a sign that I might have committed an error of some sort, and reviewed my logic carefully in order to correct it. However after reading your posts, James, I've seen the light. The correct result of this line should have been zero, since numCorrect = 0 (number of correct answers you gave) and numQuestions = 0 (number of test questions I asked you). 0 / 0 = 0. I have a vague recollection of some professors of mine hinting that this sort of calculation might be a bad idea, but hey, they were just silly intellectuals. What do they know? So I corrected the output of the program for you. Sorry you got such a low score, but you wouldn't want to be thought of as an intellectual anyway, right?

[Steven Bell]

 1
 - = 0
 0
 
0   1
  * - = 0 * 0
    0
 
zero's cancel on left side
 
1=0

[James Christian]

Well, I left it for a good 24 hours, assuming that would be enough for at least one concrete real-life example to present itself into the forum which proves that wrong the fact that 100/0= 0 remainder 100.

So far I've only seen name-calling and criticism and reasoning such as "Because that's what all the other mathematicians say, so it must be right".

Allow me to give some real-life programming requirements and we'll say if anyone succeeds in writing the method that satisfies them without having to bypass the Runtime check for division by 0.

A supermarket has an amount oranges which are not sold each day. Most full-time employees clock off at 5pm and go home while the part-timers stay on for the evening but sometimes some full-timers stay pver to do some overtime. At 10pm (closing time) the oranges are divided among the full-time employees present and the remainder are logged as a loss to the company.

In the real world when one evening there are no fulltimers each portion shared out is equal to 0 and the remainder is logged as a loss. If the JVM were implemented as it should be this would not present any problems but as it isn't it does.

Either provide a solution to this scenario which doesn't need to check for 0 or handle the Runtime Exception OR provide a REALISTIC scenario that the current behaviour of the JVM saves the day.

Please remember fellow scientists that the whole point of OOP is that at the expense of a little performance we simplify the development of large applications by basing it on a model which reflects real-life. Everything is an object, has attributes and a behaviour. And in real-life when we add, subtract or divide by nothing it is the same as doing nothind and leaving the quantities untouched. In the real world arrows hit targets and everything, repeat, EVERYTHING i finite.

Arguing that that's the way to go because if not we'll get laughed at is not a sound basis for scientific thought and reasoning. Galileo was the laughing stock of the world when he suggested that the Earth was not at the centre of the Universe and almost paid for it with his life.

There is no smallest number greater than 0 because there will always be one smaller and saying "well, because it's infinitely small" doesn't prove anything either. You base the evidence for a theoretical concept on the fact that you blindly accept another theoretical concept. Neither infinity nor the smallest number greater than 0 exist. They are figments of philosophers over-active imaginations and relics of ancient cultures long dead who worshiped statues and poured out the blood of their children on altars before them lest they incurred the wrath of the gods. A sound basis for the technology of today's civilisation??? I think NOT!!!

Anyway, please provide a realistic example where the JVM saves the day with its behaviour regarding division by 0. I'm interested to know if such an example exists. I've been wracking my brain for one these last few days but have been unsuccessful.

With the greatest and sincerest respect for your expertise and the entertainment you have given me these last few days.

Love, Your fellow programmer

James

[Nick George]

have you declined my challenge, James?

[JC]Neither infinity nor the smallest number greater than 0 exist. They are figments of philosophers over-active imaginations and relics of ancient cultures long dead who worshiped statues and poured out the blood of their children on altars before them lest they incurred the wrath of the gods. A sound basis for the technology of today's civilisation??? I think NOT!!!

I advise you don't take calculus...
[ April 06, 2005: Message edited by: Nick George ]

[James Christian]

Hi Nick,

How are you?

I'd love to accept your challenge it's just that well eeerrrrrrrrrrr....

how can I say this without looking like an idiot?

well, eerrrr........... what is the operation P(x,y) is one of those curly graphs that never touch the x or y axis (because the number infinity does not exist) ? or am I barking up the wrong tree?

P.S I took calculus. Loved it. Can't remember a darn thing but I remember that it was interesting. It was nice the way people used letters instead of numbers when you don't know what they are. Great idea!

[James Christian]

And you my friend? (Nick) Are you going to provide us with a real-life example or does your silence indicate your acceptance of the matter?

[David O'Meara]

Buggered if I know a source which will confirm it, but here goes:

Dividing by zero is not infinity, it is undefined. It is undefined since it can be shown that depending on the context it can have any value. In many cases this 'any value' is so large it gets called 'infinity', which is a useful mathematical term but doesn't have useful real interpretation. (except maybe in terms of the ability for people to ignore facts)

A mathematical example showing this is shown above using L'Hopitals Rule (although it may be a theorem - I'm a bit rusty) which can be modified to return any value. Another is Jim's IQ test which doesn't actually define anything. Averaging your results over zero questions has no meaning and doesn't mean your IQ is infinite (we'd be able to tell). You're IQ is your IQ, and the answer changes depending on the person tested, however no information is given allowing a realistic answer. The answer is undefinied.

Getting back to realworld examples, I believe the difference is caused by 'mathematics versus natural language'. eg in mathematics a remainder is not the same as having a cake, but I digress. Saying 'divide a cake by zero' can have two interpretations and has different answers depending on this.

The first is to say "Share this cake amoung x people". When x=0 you have zero pieces and the cake remains. A discrete algorithm for this is: allow each person to take a share, when there are no more shares, reverse the process and give back shares until each person has the same amount (ie this 'creates' the remainder). When there are no people, there are no shares, but there is no remainder. Nothing happens.
The second is to say "Divide the cake into x pieces". When x=0 the answer is "Huh? That doesn't make sense". You can eat the cake and there are zero pieces, but this isn't division.

Since I'm bored and supposed to be working I'll stop, but if division by zero has a meaningful solution, please define it in terms of the IQ test above.

[Jim Yingst]

[James]: So far I've only seen name-calling and criticism and reasoning such as "Because that's what all the other mathematicians say, so it must be right".

Well my last post certainly didn't fall in the third category, so I guess you're grouping it in one of the first two. If it's the second category - well, what's wrong with criticism? People disagree with you. Either the reasons are valid or not, but dismissing ideas that disagree with yours just because they're "criticism" would be rather silly, and hardly convincing. But perhaps you're thinking my post was "name-calling", in which case I've failed to communicate my intent. I did not by any means intend to suggest that you would actually score 0% in a valid IQ test. Rather, my post was intended to show a formula which is perfectly reasonable for most possible inputs, but which breaks down and yields ludicrous results if applied with a zero denominator. My argument is that in this case (zero denominator), it's better if the program throws an exception and clearly indicates that it's a programming error, rather than blithely return "0" with no further warning of a possible problem. I believe that in many (in fact most) cases, it's better to encourage programmers to explicitly consider what happens if a denominator is zero, and code any necessary checks, rather than simply assert that the result is zero and move on. I agree that there are many cases where a result of zero is indeed a perfectly good result to return - but the programmer should explicitly consider this, and code for it, rather than simply rely on it as default behavior.


[James]: ...we'll say if anyone succeeds in writing the method that satisfies them without having to bypass the Runtime check for division by 0.

I won't be offering such a method, because I believe that in most cases the programmer should explicitly check for zero denominator, and write code to specify what should be done in this case. Because returning zero is often not the best solution, and it's generally trivial to provide a couple extra lines of code to explicitly specify the desired behavior in this case rather than rely on a default behavior that may be wrong.

I note that in most cases you've been careful to specify that division by zero should result in zero, with a remainder. Are you perhaps suggesting that integer division should always return two numbers? A quotient and a remainder? (Which in Java would presumably be wrapped in an object of some sort?) If so, that wouldn't be a bad idea necessarily; I'd have to think about it more. If we force (or at least strongly encourage) the programmer to be aware that the result consists of more than just the quotient, I think that's probably a good thing. And returning a quotient of zero (when dividing by zero) might be be OK. Provided there's also a remainder. But if the division operator / returns a single number representing the quotient, no remainder, then I think it would be a bad idea for division by zero to simply return zero. There are too many times that's misleading. Calculating any average (such as average number of correct IQ test answers, as previously cited) is one such example. Here's another:

    public static void showRequiredSpeed(
            double startPosition, double endPosition, double tripTime) {
        double distance = endPosition - startPosition;
        double speed = distance / tripTime;
        System.out.println("In order to travel a distance of " + distance
                + " in a time of " + tripTime
                + ", the necessary speed is " + speed );
    }

Here I've made the switch from integer division to floating point division, since the latter seems more natural for concepts like time, distance, and speed. If you run this method with parameters like (0, 10, 0) you will get a required speed of Infinity (as Java displays the result). Now maybe that's not the best answer - I would think it better if the programmer had coded a check for a zero denominator as a special case, to give an answer like "it is not possible to travel fast enough to satisfy these conditions". However, Infinity does seem like a better answer than 0 in this case. So this seems like a good example where dividing by 0 should return Infinity rather than zero. (Or throw an exception to encourage the programmer to rewrite; I'd agree with that as an acceptable alternative.) How would you propose we resolve this?
[ April 07, 2005: Message edited by: Jim Yingst ]

[Nick George]

Bah! I can't escape the fear that this is a silly conversation. James, division is defined by the repeated subtraction previously explained. Using this method, dividing by 0 doesn't make sense. If you would like to make up a new operation which is a compound founction of division when y != 0, and 0 when y == 0. And you can use it until you go blue in the face. But it ain't mathematical division, as by the mathematical definition of division it just doesn't make any sense. There's no need for any examples, because if you want to use that sort of operation, you certainly can. But it ain't proper divison, because it doesn't meet the definition.

It's like defining a leg to be a thing upon which you walk. Then, if you want to call a tail a leg, fine by me, but just understand that you are creating a new, generally unaccepted, definition of "leg."

[Ryan McGuire]

Just to reopen the original can of worms...

Concerning .999(9) == 1...
- Do we all agree that the proofs given so far are sufficient?
- Have there been counter-proofs?
- Are people still unconvinced but unable to explain why?
- Somthing else?

I tried to make that list un-biased to either the They're Equal or They're Unequal camps, but since I count myself as being on the Equal side of the fence (to mix my metaphors with a 9.999(9) foot pole), I may have failed.

Ryan
[ April 07, 2005: Message edited by: Ryan McGuire ]

[Steven Bell]

It seems to be you could use a similar argument to remove the NullPointerException from Java. Any code that would currently throw a null pointer exception should simply do nothing and if a return value is expected simply return null.

I'm tired of checking for null's all the time anyway.

[Nick George]

Double bah!

I told myself I'd leave this alone, but I stumbled upon something potentially useful in the Wikipedia definiton for Rational Numbers:

Two rational numbers a/b and c/d are equal iff ad = bc

 
 
Proof by contradiction:
 
Assume both a/0 = 0 and 0/a = 0.
 
 5       0
---  =  --- , by definition of division ( 0 = 0 )
 0       7   
 
therefore, since the rational numbers are equal,
 
0 * 0 = 5 * 7
 
0 = 35
 
qed

[James Christian]

So no practical programming examples then eh Nick. Just the same old walking talking mathematical dictionary speech.

[James Christian]

Dear Jim,

code:

int percentCorrect = (int) ((100.0 * numCorrect) / numQuestions + 0.5);

Your code seems to calculate a percentage right? but a percentage of what?
It seems that it is measuring the percentage of correct answers I gave you. Seeing as I haven't given you any answers it seems only logical that the result be 0. As you indicated the result was 0 so you only seem to have re-enforced my point.

The only problem in your logic here is that you have assumed the test to be a true measure of my IQ (which is of course impossible). Whereas actually the program is calculating the percentage I got right. I didn't answer any questions,(pause for effect) ... so I didn't get any right.

Seems perfectly normal to me.

[Warren Dew]

Practical example:

public void divvy_up_profits(Department department)
{   double surplus = department.get_surplus();
    department.decrement_surplus(surplus);
 
    double share = surplus / department.get_employees().size();
    Iterator employees = department.get_employees().iterator();
    while (employees.hasNext())
        {employees.next().add_to_paycheck(share);}
}

This department has recently had all its employees laid off. Without an exception, the money disappears silently. With a warning, one at least has a chance to fix things.
[ April 07, 2005: Message edited by: Warren Dew ]

[James Christian]

Dear Jim

I note that in most cases you've been careful to specify that division by zero should result in zero, with a remainder. Are you perhaps suggesting that integer division should always return two numbers? A quotient and a remainder? (Which in Java would presumably be wrapped in an object of some sort?) If so, that wouldn't be a bad idea necessarily; I'd have to think about it more. If we force (or at least strongly encourage) the programmer to be aware that the result consists of more than just the quotient, I think that's probably a good thing. And returning a quotient of zero (when dividing by zero) might be be OK.

Now that's what I'm talking about. High five brooooooooooo!

Provided there's also a remainder.

Division always DOES give a remainder. Just that sometimes that remainder happens to be 0.

As regards no default behaviours. Personally I feel that operating systems should come shipped with no configurations and refuse to operate until the user defines them so that he/she would be forced to communicate with, learn about and understand better their working environment. However, I don't Microsoft would have gained its undeserved dominion of power in the world had they adopted this strategy.

There are strong arguments for adopting a default behaviour when those behaviours represent the common case (or in Microsoft's case, whatever makes it work long enough to not spoil the magic of the new Desktop's jazzy look and feel).

Take instance variables for example. I've never met a java programmer who has complained about their default initialisation (not that I have met many).

Thanks Jim. You're the only one who seems to be giving any open minded attention to my proposals, contraversial as they may be.

[James Christian]

code:


public void divvy_up_profits(department)
{ double surplus = department.get_surplus();
department.decrement_surplus(surplus);

double share = surplus / department.get_employees().size();
Iterator employees = department.get_employees().iterator();
while (employees.hasNext())
{employees.next().add_to_paycheck(share);}
}



This department has recently had all its employees laid off. Without an exception, the money disappears silently. With a warning, one at least has a chance to fix things.

Yet again, you have only succeeded in proving my point.
In the case there are no employees the share which is added to each employee's pay is but the money does not, repeat NOT slip away silently. That's the whole point that I'm trying to put accross.

$1,000,000 / 0 = 0, wait for it,... REMAINDER $1,000,000.

[Steven Bell]

In the previous code you would have to explicitly check for a remainder else the department would lose the money. So you are traiding a zero check for a remainder check.

The point I'm getting at is not that what you suggest wouldn't work. I understand where you are comming from, but changing the defenition of something as fundamental as division becuase you don't like the way it works doesn't sit well with me.

I don't think what you suggest is unworkable. I do think that it is highly questionable especially considering the 'real world' of programming can and does encompass the world of theoretical mathmatics.