• (unregistered)

    explination? explin yourself!

  • (cs)

    <FONT style="BACKGROUND-COLOR: #efefef">That is the coolest const name EVER</FONT>

  • (cs)

    What confuses me is the really, really confusing names for the constants. Where they've had to have comments associated.

    And then, there are the pointless comments next to the conversion functions. Why? Those functions actually have sensible names, so why bother appending a gazillion digit constant to the end of the line? After all, you either trust the writer, or you go check what the conversion value really is.

  • (unregistered)

    All that work, and there are STILL magic numbers in it...

     return i*2.54;

    [:)]

  • (unregistered)

    Excelent use of comments<font color="#008000"> </font><font color="#008000">//good commenting</font>

  • (unregistered)

    Where is the WTF in this?  It looks like a perfectly good library for performing unit conversions and geometric calcs.  Plus it is fast, since the functions are declared inline.  I like the way the constants are named.  Personally, I would have defined a couple more:

    const double Twenty5Point4 = 25.4
    const double TwoPoint54 = 2.54
    const double Ten = 10.0

    etc.

     

  • (unregistered)

    beause this is from a library, and because all the functions are inlined, the guy was clearly worried about perf. however, somebody has to maintain this, and the sheer volume that could be cut down with a couple of much simpler functions would be worth the perf hit.

    but those const declarations are a total WTF; maybe he hoped the compiler would calculate those and not the run time?

  • (unregistered)

    [:|]  Wow!  I can see creating the conversions, but having to declare the constants for 1/12 is unacceptable.  [:D]

  • (unregistered) in reply to

    This represents my #1 pet peeve when reading other people's code. I just can't stand developers that simply "don't get" the purpose of constants.

     - Sergio Pereira

  • (cs)

    <FONT style="BACKGROUND-COLOR: #efefef">What's the licensing terms for that code? Cause I could sure use it.</FONT>

  • (cs) in reply to jesper

    What's next?

    <FONT color=#0000ff>function</FONT> ThisFunctionConvertsFeetToInches (Feet) {
    <FONT color=#008000>      //here we go....</FONT>
    }

  • (cs) in reply to jesper
    jesper:

    <FONT style="BACKGROUND-COLOR: #efefef">What's the licensing terms for that code? Cause I could sure use it.</FONT>

    You would be granted the license for one year and five days.

    const double OneYear5Days = 370.0/365.0    //1.01369863

  • (unregistered) 
    Moin,

    While I can see the reason behind the Pi and Deg2Rad/Rad2Dec (I 
    always confuse them myself) definitions, why on earth should one 
    want to have a constant for OneThird? I mean, on what planet is 
    it easier to write OneThird instead of 1./3.? Yet alone 
    One2Pt20462262185th. If you can remember that name, you could as 
    well write 1./2.20462262185. Or is that in case the value of 1./3. 
    should ever change?

    And why oh why are these variables and functions at all? If the 
    author wanted to make it fast he should've used preprocessor macros.

    -- 
    Henryk Plötz
    Grüße aus Berlin
  • (unregistered)

    I'm not Isaac's coworker (although my son is named Isaac, an interesting coincidence) but here's an attempt at a justification ...

    I once worked on a tiny embedded system that had no floating-point hardware and a compiler with absolutely no optimization, but the system had real-time performance requirements.

    Division is often much slower than multiplication, even with floating-point hardware. In such a situation, it makes sense to calculate the reciprocal once so that conversions at run-time are all multiplications. (As other folks have commented, the constant names are still questionable.)

    Of course, in my case the compiler didn't grok inlining either, so I would have had to use macros instead of typed functions. And "static_cast" -- never heard of it. (A friend of mine says "Embedded Systems: Yesterday's Technology Tomorrow".)

    -- Scott

  • (unregistered)

    i love how everyone either is posting the same thing or somehow totally misses the wtf and posts the wtf thinking they've found it

     

    and/or defends names like "OnePtThreeFourTimesFiveSixSevenEight"

  • (unregistered)

    WTF?  This makes sense to me!  What do you do when the Lbs->Kgs conversion factor changes?  Huh, Mr. Smarty Pants?

  • (unregistered)

    Not a comment on this entry, per se. But the last couple of days the RSS XML has been contaminated with what looks like a bunch of style-sheet crap.  Am I the only person seeing this?

  • (cs) in reply to

    :
    Not a comment on this entry, per se. But the last couple of days the RSS XML has been contaminated with what looks like a bunch of style-sheet crap.  Am I the only person seeing this?

    Your RSS reader should either ignore them, or use them in a meaningful way. They're all within properly structured [style] tags, so any self-respecting reader should be able to use them as styling classes that are defined within the same entry. It's a very elegant and standardized way to handle formatting.

    I mean, seriously, "contaminated", "crap", and "stylesheets" in the same sentence? [^o)]

  • (unregistered)

    You should note that math.h includes a bunch of weird constant names like M_PI, M_PI_2, M_2_PI, M_SQRT1_2.  Not as eggregiously bad as naming a constant after the number that's in it since the ones in math.h at least involve things normally known by their name rather than their numeric value like pi, e and sqrt(2), but you can sort of see where they got the idea.

  • (unregistered) in reply to alexb

    I'm not complaining about you using stylesheets, I'm just baffled as to why your RSS feed doesn't strip them out.

    I think at least part of the problem is that there is no standard in RSS about whether or how much to strip html mark-up in the description field.  Your RSS doesn't have header that defines the stylesheet, without with your style tags are pretty useless.  So why isn't it stripping the style tags and their contents?  And my RSS aggregator generates a web page that has its own style sheet, its own markup, its own div and style tags, so it is quite properly stripping yours, but for some reason not what's in between them.  Strangely enough it leaves the <span></span> tags alone.

  • (cs) in reply to

    Isaac's Father:
    And "static_cast" -- never heard of it.

    Those lines should look like:

    <FONT face="Courier New">const float  fDeg2Rad = static_cast<float>(Deg2Rad);</FONT>

    which is the modern C++ way of saying

    <FONT face="Courier New">const float  fDeg2Rad = (float)Deg2Rad;</FONT>

    except, apparently, when Alex posted it, the <float> was taken as embedded HTML and striped from the message.

  • (cs) in reply to

    :
    I'm not complaining about you using stylesheets, I'm just baffled as to why your RSS feed doesn't strip them out.

    I think at least part of the problem is that there is no standard in RSS about whether or how much to strip html mark-up in the description field.  Your RSS doesn't have header that defines the stylesheet, without with your style tags are pretty useless.  So why isn't it stripping the style tags and their contents?  And my RSS aggregator generates a web page that has its own style sheet, its own markup, its own div and style tags, so it is quite properly stripping yours, but for some reason not what's in between them.  Strangely enough it leaves the <span></span> tags alone.

    Your aggregator is mishandling the proper XHTML that is contained in the entry. It shouldn't just strip out tags, it should strip out contents of tags as well. If it's trying to enforce its own styles, it should care to, at least, respect the standard way of handling CSS.

    You shouldn't blame the RSS provider (or any content provider, for that matter) if they're offering you a fully standardized enhanced experience. If your aggregator is misbehaving, you should either re-configure/re-write it, or switch to a better one -- there's a plethora of them out there.

     

  • (unregistered)

    I think this person may not realize that even a crappy compiler will optimize out any math between literals.  It doesn't change the run time speed of a program to just write 1.0/1760 instead of One1760th.

    I've seen even experienced programmers sometimes unable to grasp this concept.  I've heard some excuses like "I don't trust the compiler," but seriously this is not complex optimization, it's just the simplest inline math.  If you don't trust your compiler to do that you're better off programming in assembly.

    Also I'm interested to know why he/she is using doubles everywhere, the only thing you need measurement accuracy like that is on a space shuttle or maybe a missiles launch program, wait, oh my god!

  • (unregistered)

    The whole reason for using constants is to remove the use of arbitrary magic numbers in your code. By including the magic number in the constant name, you're sort of defeating the purpose. It also completely hides the purpose of the constant: what exactly does 1/1760 signify? (I'm actually not sure without whipping out a calculator or checking a reference).

    If you went:

         const double CONVERT_INCH_MM = 1.0/25.4;

    then your intent is perfectly clear without the need for comments.

    Besides, if you wrote a constant like One3Pt785411th wrong you'd either have to change the constant name everywhere (defeats the purpose of having a constant) or have something just as bad like:

        const double One3Pt785411th = 1.0/3.78644278401;

    which just screams for someone to 'fix' it later on.

  • (cs) in reply to

    :

    If you went:
    <pre>
    const double CONVERT_INCH_MM = 1.0/25.4;
    </Pre>

    then your intent is perfectly clear without the need for comments.

    "Convert" is an verb. If you ask me, variable names that don't include verbs are more useful and direct because you don't use verbs in regular English as a primary means to describe something. In my experience, sticking to nouns and adjectives is the best way to come up with a variable name.

    I think CENTIMETERS_PER_INCH, INCHES_PER_CENTIMETER (or any variant of those) would be a very decent set of constant names for this purpose.

     

  • (cs) in reply to Goudinov
    Goudinov:

    What's next?

    <font color="#0000ff">function</font> ThisFunctionConvertsFeetToInches (Feet) {
    <font color="#008000">      //here we go....</font>
    }



    You can laugh all you want, but I used to have a teacher that gave his variables similar names, like for a boolean: blnReturnsTrueIfThisActionOccurs . His exams were really horrible and that was just for JavaScript[:D]
  • (cs) in reply to

    'I've seen even experienced programmers sometimes unable to grasp this concept.  I've heard some excuses like "I don't trust the compiler,"'

    Which brings me to pet peeves of mine:

    • people not understanding what the compiler will generate 
    • people who can't read enough assembly to SEE what the compiler generates 
    • people who -assume- that X technique is faster because someone somewhere told them it was
    • people who don't understand that gaining a couple clock ticks enhancement is pointless when we're waiting -minutes- for a query to return...
  • (cs)

    The WTF that I see is the naming conventions for each const.



    Well, that and the bright lime green that I was greeted by when I browsed to http://www.thedailywtf.com. Kind of hurt my eyes; made me say "wtf?" quietly to myself as soon as I saw it[:O]

  • (unregistered)

    What language was this written in? Javascript? LOL

  • (cs) in reply to

    what exactly does 1/1760 signify?

    1760 is the number of yards in a mile.

  • (cs) in reply to
    :
    WTF?  This makes sense to me!  What do you do when the Lbs->Kgs conversion factor changes?  Huh, Mr. Smarty Pants?

    But the conversion factor is changing!

    http://www.physics.capcollege.bc.ca/oldphys108/kilogram_standard.htm

  • (cs) in reply to JoeNotCharles

    Hey - I'm logged in for once. Cool. But quoting's still broken! Gawd, how hard can it be to set this software up?

  • (unregistered)

    I have an explanation. Intellisense.

  • (unregistered)

    This has got to be a joke.

  • (unregistered) in reply to
    :

    Plus it is fast, since the functions are declared inline.

    I hope this comment is sarcastic, because things like "const double &cm" as a parameter definition can be so bad for performance...



  • (unregistered) in reply to

    Actually, I write quite a bit of floating point code, and I have noticed that a lot of CPU-intensive math algorithms will run quite a bit faster in C/C++ if everything is done in double-precision.  At first, I was mystified by this counterintuitive result, but after looking at the disassembly of the compiler-generated code, I realized why:  if you use type 'float', C/C++ converts them to double precision every time they are used in a calculation, then converts them back to float to store them in a variable.

    Bottom line:  now the only time I use float is if I have to allocate a huge array of floating point numbers and want to save some memory.

  • (unregistered) in reply to

    You're either using a very odd flavor of compiler or targeting a processor with a different FPU architecture than most. The only time C++ should preform type promotion is if one of the values in the calculation is already a double. Most of the time this is a constant, which default to double precision. For example:
    float fHours = fDays / 24.;
    will promote fDays to a double, divide by 24, discard the extra precision and shove it into fHours.
    float fHours = fDays / 24.f;
    will use only float precision math.

  • (cs)

    Modern x86 architectures treat float and double exactly the same, because it's internally 64/80 bit operations. The only difference would be in memory bandwidth - a good compiler would just load the float and let the FPU backfill it.

    Not all compilers are good and not all architectures are x86, however. Particularly embedded systems/ultra-low-power have terrible performance if you pick the one that isn't its native internal size, 32 or 64. (In which case you'd want to use a fixed-point integer math library anyway.) But that's one of the trade-offs of going to a raw RISC.

  • (cs) in reply to
    :

    Where is the WTF in this?  It looks like a perfectly good library for performing unit conversions and geometric calcs.  Plus it is fast, since the functions are declared inline.  I like the way the constants are named.  Personally, I would have defined a couple more:

    const double Twenty5Point4 = 25.4
    const double TwoPoint54 = 2.54
    const double Ten = 10.0

    etc.

     



    WTF??? You're defining those constants completely wrong!!!

    const double Twenty5Point4 = 20/5.4;
    const double TwoPoint54 = 1/2.54;
    const double Ten = 10.0; // Well, you got this one right, I think...

    You also forgot the semi-colons so are you a VB programmer? [:P]
  • (cs) in reply to Katja

    But then again, if you define constants like this:


    
const double   CentimeterPerInch = 2.54;

    What if you decide to use it for a different purpose, instead of doing imperial <-> metric conversions? Say, you decide that there's as many beers in a crate as ten times the amount of centimeters per inch, minus 1.4? That would mean you'd have to change the constant's name everywhere! A more universal way to name this constant would be:


    
const double    TwoPointFiftyFour = 2.54;

    or, less flexible:


    
const double    CentimeterPerInchAndOneTenthOfTheAmountOfBottlesInACrateOfTwentyFourPlusOnePointFour = 2.54

    I don't think either of both ways is 'better' or the 'best'. It really depends on the spec.

  • (unregistered)

    Will someone please back me up when I say that Katja's picture is reminiscent of Renee Zellweger?

  • (unregistered) in reply to

    One does have to be a little careful when writing expressions that should be optimized by the compiler.  Integer operations are more likely to reveal the difference between "var * CONST1 / CONST2" and "var * (CONST1 / CONST2)" than floating-point, but the order of operations can be significant to both.  Because of that, the compiler generally should not rewrite the former as the latter.

  • (unregistered)

    I am reminded of some classics from a "A Field Guide to Your Unix Sysadmin":

    • alias kitty cat
    • alias process_table ps
  • (cs) in reply to

    :
    Will someone please back me up when I say that Katja's picture is reminiscent of Renee Zellweger?

    Would someone please remind anonimous that comparing a young girl with a FAT ACTRESS is a real WTF too...[:@] I am 186 CM tall and my weight is 61 KG. Definitely not fat...

  • (unregistered) in reply to Katja

    Katja: I did not mean the comparison as an insult. BTW, Renee only gained weight for her role in the Bridget Jones films, and possibly for the movie Cold Mountain (a very good movie IMO). In her other films she was not as "plump". I sort of think she's a good actress...if I can admit that. I'm sorry you took the comment as an insult, I meant it more as a compliment.

    Oh yeah, being an American I have no idea what 186CM or 61KG equates to. We're on the dewey decimal system over here.

  • (unregistered) in reply to

    "We're on the dewey decimal system over here."?

    WTF!  I hope you're being sarcastic.

  • (unregistered)

    Renee...I mean, Katja...what's it like over there in Amsterdam? That's in Holland/Norway/Netherlands/Sweden right? Pardon my complete ignorance of geography. Are there a lot of programmers over there? Is it cold? What kind of things do you do for fun over there? You know how in Spain they chase bulls? Do you have anything similar? Like horseshoe tossing. Is that the national passtime there? I bet that's fun. One day I would like to visit. And toss horseshoes. I'll have to buy some more winter clothes though. I really want to see those windmills too. Didn't Sandy Duncan film The Sound of Music over there? (Or maybe that was Fiddler on the Roof.) Anyways, let me know what it's like. We are so ignorant of other cultures here in the U.S. It's not our fault though, it's our education system. It kinda sucks. Oh well, chat with you later. -Mike

  • (cs) in reply to
    :

    Oh yeah, being an American I have no idea what 186CM or 61KG equates to.



    Well, according to the post, you need only multiply 186 by One30Pt48th to find out.
  • (unregistered) in reply to
    :
    Renee...I mean, Katja...what's it like over there in Amsterdam? That's in Holland/Norway/Netherlands/Sweden right? Pardon my complete ignorance of geography. Are there a lot of programmers over there? Is it cold? What kind of things do you do for fun over there? You know how in Spain they chase bulls? Do you have anything similar? Like horseshoe tossing. Is that the national passtime there? I bet that's fun. One day I would like to visit. And toss horseshoes. I'll have to buy some more winter clothes though. I really want to see those windmills too. Didn't Sandy Duncan film The Sound of Music over there? (Or maybe that was Fiddler on the Roof.) Anyways, let me know what it's like. We are so ignorant of other cultures here in the U.S. It's not our fault though, it's our education system. It kinda sucks. Oh well, chat with you later. -Mike


    Now that's a WTF... I quoted this post yesterday, and I even checked whether the quote worked, but WTF? It's gone now.
  • (unregistered) in reply to
    While I can see the reason behind the Pi and Deg2Rad/Rad2Dec (I
    always confuse them myself) definitions, why on earth should one
    want to have a constant for OneThird?


    You never know when the value of one third will change in the future...

Leave a comment on “One2Pt20462262185th”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article