tags:

views:

290

answers:

4
+14  A: 

You're using integer division.

Try 7.0/10 instead.

Xavier Ho
I'll add that this is not a bug. It's a feature. `:]`
Xavier Ho
Thanks a lot! That solved the problem. Ok I added "feature" in the title of my question :) Thanks once again!
msr
@msr: No worries. Feel free to "tick" one of the answers you feel appropriate!
Xavier Ho
neither bug nor feature - it is "working as designed".
Thorbjørn Ravn Andersen
+9  A: 

You've used integers in the expression 7/10, and integer 7 divided by integer 10 is zero.

What you're expecting is floating point division. Any of the following would evaluate the way you expected:

7.0 / 10
7 / 10.0
7.0 / 10.0
7 / (double) 10
JustJeff
+1  A: 

I find letter identifiers to be more readable and more indicative of parsed type:

1 - 7f / 10
1 - 7 / 10f

or:

1 - 7d / 10
1 - 7 / 10d
Fred Haslam
A: 

Please do not take this as an answer to the question. It is not, but an advice related to exploiting the difference of int and float. I would have put this under a comment except that the answer box allows me to format this comment.

This feature has been used in every respectable programming language since the days of fortran (or earlier) - I must confess I was once a Fortran and Cobol punch card programmer.

As an example, integer division of 10/3 yields integer value 3 since an integer has no facility to hold fractional residual .3333.. .

One of the ways we (old time ancient programmers) had been using this feature is loop control.

Let's say we wish to print an array of 1000 strings, but we wish to insert a line break after every 15th string, to insert some prettyfying chars at the end of the line and at the beginning of the next line. We exploit this, given that integer k is the position of a string in that array.

int(k/15)*15 == k

is true only when k is divisible by 15, an occurrence at a frequency of every 15th cell. Which is akin to what my friend said about his grandfather's dead watch being accurate twice a day.

int(1/15) = 0 -> int(1/15)*15 = 0
int(2/15) = 0 -> int(2/15)*15 = 0
...
int(14/15) = 0 -> int(14/15)*15 = 0
int(15/15) = 1 -> int(15/15)*15 = 15

int(16/15) = 1 -> int(16/15)*15 = 15
int(17/15) = 1 -> int(17/15)*15 = 15
...
int(29/15) = 1 -> int(29/15)*15 = 15
int(30/15) = 2 -> int(30/15)*15 = 30

Therefore, the loop,

leftPrettyfy();
for(int k=0; k<sa.length; k++){
  print(sa[k]);
  int z = k + 1;
  if ((z/15)*15 == z){
    rightPrettyfy();
    leftPrettyfy();
  }
}

By varying k in a fanciful way in the loop, we could print a triangular printout

1
2  3
4  5  6
7  8  9  10
11 12 13 14 15

That is to demonstrate that, if you consider this a bug, this "bug" is a useful feature that we would not want to be removed from any of the various languages that we have used thus far.

Blessed Geek
Is something wrong with `k % 15 == 0`?
Corey
Since mod (a,x) = a - (x * int(a/x)), I think the answer lies in that besides burden of constructing an argument stack repeatedly plus a code jmp to call a modulo subroutine, you can count that the inlined a == (x * int(a/x)) is one operation more efficient thana - (x * int(a/x)) == 0.
Blessed Geek
I wrote "By varying k in a fanciful way in the loop, we could print a triangular printout", for k==(k/L)*L. It should have been - "By varying L in a fanciful way in the loop, we could print a triangular printout."
Blessed Geek