Depending on what language/program/whatever you're using, it'll either round towards -inf (as apparently they've patched this one to do), or towards 0. The mathematical definition of the term "floor" is -inf, so I guess this change makes it "more correct." But God help you if you have a program that relied on the previous behavior.
But God help you if you have a program that relied on the previous behavior.
Well, IIUC, that would just entail converting all floors on negative numbers to ceils: double floorToZero (double n) {
return (n < 0) ? ceil(n) : floor(n); }
Depending on what language/program/whatever you're using, it'll either round towards -inf (as apparently they've patched this one to do), or towards 0.
This cursed wrongness of many implementations of floor (returning closest integer not further from zero) has caused me no end of hassle through many different environments. The bugs can be quite subtle, but significant, and occasionally really weird. This uncertainty in floor behavior is not limited to c-libraries, but can also be encountered in some higher-level analysis packages, such as in graphical programming environments and interactive data analysis packages. After being bitten in the butt too many t
Yeah, it's a huge fucking pain. One of those functions you have to look up for every environment-- even though you know exactly what it's "supposed" to do, you have no idea if it's right in any given environment.
I haven't gone as far as just writing my own all the time, but if the library version is prone to changing from one implementation to another, I really should... that's a bug waiting to happen.
God help you if you have a program that [relies on floor() truncating toward zero]
So true. Either the person writing the library or the person writing the program has no mathematical training or little concern over disregarding conventions long associated with quality software.
The authors of APL back in 1963 worked very, very hard to define the computational equivalents of common mathematical notation to preserve and obey the maximal set of mathematical identities. Perhaps they worked harder at this than
The authors of APL back in 1963 worked very, very hard to define the computational equivalents of common mathematical notation to preserve and obey the maximal set of mathematical identities. Perhaps they worked harder at this than other language teams because identities are none too compelling expressed in Lisp notation.
Later, when I learned many ideas about program correctness and defensive programming from Dijkstra, his notions of program correctness were highly APL compliant. People don't understand the full gravity of Dijkstra's lament APL is a mistake, carried through to perfection. The only language consistent with his notions of programming elegance was a failed enterprise out of the starting gate. His implied converse also interests me: X, for X != APL, is a valuable step forward, borked beyond all recognition.
Old geezer reminisces: APL was my first computer language, back in the 1970s. It's notational elegance is still my favourite, and I occasionally use it as a sort of pseudocode to describe a computation. A few lines of APL can convey an unambiguous algorithm equivalent to hundreds of lines of C or C++.
FYI, Ken Iverson (inventor of the APL notation and abstract language in 1958) was also involved in the design of Mathematica, and produced an APL successor named J (before Microsoft assigned the name J++ to a
Those who can, do; those who can't, write.
Those who can't write work for the Bell Labs Record.
Re: (Score:0)
Re:make (Score:2)
"floor" is one of those functions... ugh.
Depending on what language/program/whatever you're using, it'll either round towards -inf (as apparently they've patched this one to do), or towards 0. The mathematical definition of the term "floor" is -inf, so I guess this change makes it "more correct." But God help you if you have a program that relied on the previous behavior.
Re: (Score:2, Informative)
Well, IIUC, that would just entail converting all floors on negative numbers to ceils:
double floorToZero (double n)
{
return (n < 0) ? ceil(n) : floor(n);
}
Re: (Score:2)
Once you notice the bug... after possibly years of extremely subtle incorrect accounting errors.
I'm not saying it's hard to fix. It's hard to find.
Re: (Score:2)
Depending on what language/program/whatever you're using, it'll either round towards -inf (as apparently they've patched this one to do), or towards 0.
This cursed wrongness of many implementations of floor (returning closest integer not further from zero) has caused me no end of hassle through many different environments. The bugs can be quite subtle, but significant, and occasionally really weird. This uncertainty in floor behavior is not limited to c-libraries, but can also be encountered in some higher-level analysis packages, such as in graphical programming environments and interactive data analysis packages. After being bitten in the butt too many t
Re: (Score:2)
Yeah, it's a huge fucking pain. One of those functions you have to look up for every environment-- even though you know exactly what it's "supposed" to do, you have no idea if it's right in any given environment.
I haven't gone as far as just writing my own all the time, but if the library version is prone to changing from one implementation to another, I really should... that's a bug waiting to happen.
rant for the aged (Score:2)
So true. Either the person writing the library or the person writing the program has no mathematical training or little concern over disregarding conventions long associated with quality software.
The authors of APL back in 1963 worked very, very hard to define the computational equivalents of common mathematical notation to preserve and obey the maximal set of mathematical identities. Perhaps they worked harder at this than
Re: (Score:2)
The authors of APL back in 1963 worked very, very hard to define the computational equivalents of common mathematical notation to preserve and obey the maximal set of mathematical identities. Perhaps they worked harder at this than other language teams because identities are none too compelling expressed in Lisp notation.
Later, when I learned many ideas about program correctness and defensive programming from Dijkstra, his notions of program correctness were highly APL compliant. People don't understand the full gravity of Dijkstra's lament APL is a mistake, carried through to perfection. The only language consistent with his notions of programming elegance was a failed enterprise out of the starting gate. His implied converse also interests me: X, for X != APL, is a valuable step forward, borked beyond all recognition.
Old geezer reminisces: APL was my first computer language, back in the 1970s. It's notational elegance is still my favourite, and I occasionally use it as a sort of pseudocode to describe a computation. A few lines of APL can convey an unambiguous algorithm equivalent to hundreds of lines of C or C++.
FYI, Ken Iverson (inventor of the APL notation and abstract language in 1958) was also involved in the design of Mathematica, and produced an APL successor named J (before Microsoft assigned the name J++ to a