# Fast!

Discussion in 'Computing and Networks' started by markdem, Feb 15, 2017.

1. ### markdem Thread Starter Member

Jul 31, 2013
105
63
I have built some fast networks in my day, but this takes the cake.
The part I wonder about here is what kind of math would give that result?
Cool to think that somewhere, in the who knows how many lines of code, there is a condition for this...

BR-549 likes this.
2. ### WBahn Moderator

Mar 31, 2012
20,057
5,644
Assuming that your question is serious, the time is being tracked as an integer (and apparently not just being displayed as a whole number of seconds); This is likely because most downloads take well over one second and most people would find a bunch of stuff to the right of the decimal point distracting, so the programmer just captured the time at the start of the download and again at the end (and most time() functions return an integer that is the number of seconds that have passed since the "epoch").

But the person that wrote the code knows that the transfer rate is a floating point number so they are casting it as such before dividing it into the number of bytes transferred (or otherwise forcing floating point division). But that results in division by zero -- however this is a legal operation in most floating point libraries since infinity can be represented in IEEE-754 floating point representations. Additionally, when you print out such a value using most print utilities that are capable of printing floating point values, they have a way of displaying all three flag values, +INF, -INF, and NaN (the last is Not A Number, which results when doing something like taking the square root of a negative value).

3. ### markdem Thread Starter Member

Jul 31, 2013
105
63
I agree it was a div by zero issue that did this, but would you not agree that it would make more science in this case just to report the transfer rate as been the file size? In this case it would of been 257k\sec as it must of taken some time to transfer. Infinity just seems "too wrong".

4. ### WBahn Moderator

Mar 31, 2012
20,057
5,644
There are all kinds of special cases that could be trapped and something more sensible done. I have no problem with them doing so, either. But there's no point getting worked up over something that just doesn't matter unless it potentially unmasks a true bug in the code. Just look at all the progress bars that tell you that something is 99% done after a few seconds and yet it takes several minutes to actually finish. Could something more sensible be done there? Sure.

5. ### joeyd999 AAC Fanatic!

Jun 6, 2011
2,964
3,778
These days, 257K/s (about 2.5 Mbit/s) is nothing. ADSL over POTS can do 10x that.

6. ### markdem Thread Starter Member

Jul 31, 2013
105
63
Agree, no need to get worked up about it, just seemed odd that someone thought it would be a good idea to type the word "infinity" into something that looked after speed

This was on a 1Gbit network so no, the speed was not that high (the title was more tongue in cheek). It was the "reported" speed I thought was cool as it would be impossible to have infinity\sec as that would suggest it took no time to transfer.

7. ### WBahn Moderator

Mar 31, 2012
20,057
5,644
They DIDN'T think to type the word infinity! They probably never gave the possibility a thought at all -- if they did they probably would have had it print something else, such as "????". All they did was naively calculate a speed and print it out. They called a standard library function such as

printf("%f kB/s", speed);

and when it turned out that speed was +INF because of a division by zero, the library function printed the "infinity" because that's what the printf() function prints when it's passed a floating point value that is equal to +INF.

8. ### markdem Thread Starter Member

Jul 31, 2013
105
63
Fair call, I did not think about the fact that it could be a external function returning the "infinity".