I do not know what is wrong with my code. The v1 and the 2 are defined. And I do not want to copy the code of double newStart and the for-loop behind the else if because than the code will become too long.
I think it is a good learning experience to look at code formatted by professional programmers. An example here:
(Click on the link “show original” and scroll down. That is professional code.
Again, code must be readable. If not, it’s worthless. Code needs to be maintained, debugged, and often readable by others (as to no provoke introducing even more bugs, aso).
Compacting code like the first snippet in the first post is exactly what you should not do.
Here is the new version, ‘how to redesign it’ where you put the cliffhanger at?
(I do not know yet where to exactly ‘public or private yet’ public or private or something else as Rolf’s example, but this is what I have).
List<double> rangeByDistanceAtMid(double start, double end, double distance){
List<double> range = new List<double>();
if (start == end){
range.Add(start); return range;
}
double v1 = Math.Min(start, end);
double v2 = Math.Max(start, end);
//double vm = (((v2 - v1) % distance) / 2) + v1;
double vm = ((((v2 - v1) / 2) % distance) + v1);
for(double v = vm; v < v2; v += distance)
range.Add(v);
return range;
}
The problem with floating point numbers is that you can never use equality on two numbers which are the result of some computation. Because the least significant digits of a floating point number are untrustworthy once you’ve performed an addition, subtraction, multiplication or division.
Oftentimes it will work as you expect, and then sometimes, under some very special condition it rounds the other way and boom, your sequence now contains fewer or more numbers than you wanted. Developing algorithms which correctly deal with floating point numbers is difficult. Oftentimes impossible. Best you can do is kinda-sorta-correct, and even that can be hard.
As a side note, the increment instruction v += distance in this loop:
for(double v = vm; v < v2; v += distance)
is particularly bad. Every floating point error you encounter during the running of this loop will become part of the sequence; they are cumulative. Okay, some of them will cancel out against others, but you definitely want to avoid that if at all possible.
Even worse, it may cause the loop to never terminate at all. Every floating point number has 15 to 16 decimal places, regardless of its magnitude. (But let’s say it’s only 4 to make this explanation somewhat easier.)
So if you compute \frac{1.0}{3.0} you get the result 0.3333, with all remaining digits implied to be zero. But calculate \frac{1000000.0}{3.0}, and your result will be 333300.0. You’re not allowed to store more than four digits in your number, so the least significant ones are dropped from the calculation.
Now what happens if you compute \frac{1000000.0}{3.0} + \frac{1.0}{3.0}? That’s right, the addition just disappears. In floating point maths, a+b=a whenever the magnitude of b is less than the least significant digit of a. So that original loop could end up in a state where v += distance always just yields v over and over again, and therefore v will never become larger than v2.
I am now reading David’s answer. Besides that, I am still learning and try to teach myself all solutions in order to get experience and becoming better in problem solving, a small question, based on your code, line 67 what am I doing wrong?
