• blarg (unregistered) in reply to lolwtf
    lolwtf:
    blarg:
    for those complaining about float for monetary values, how would you suggest storing $0.018372 ?

    Not all applications are built for airline tickets and groceries you know...

    As either the integer 18372 (or 183720 if you deal in hundred-thousandths of a dollar, etc) or the value 0.018372 represented by something more precise than floating-point.

    ok, now lets say the next number has an extra digit - are you going to re-write all your code because you came up with a ridiculously non-flexible design?

    Saying "something more precise...." is a complete cop out. Either name what this "something" is, or accept that you don't have the answer.

    I work in finance, and valuing things to numerous decimal places is common place. floats work fine for this purpose.

  • Brian White (unregistered) in reply to BentFranklin
    BentFranklin:
    Eisentein:
    kadal:
    Some equality are more equal than others

    x = y // "y" is assigned to "x" x == y // "y" is logically equivalent to "x", can convert types if required x === y // "y" is identical to "x", no conversion of types allowed x ==== y // "y" is composed of the same electrons as "x" x ===== y // "y" ==== "x" and across all space/time continua

    (equal x y) x and y evaluate to the same result (eq? x y) x and y are the same object

    (wtf x y) // x has been proclaimed as TRWTF for an instance of y on this site. (beatsUp x y) // x would win in a fight against y. NO CONVERTING TYPES Y, THAT IS CHEATING! (hat? x y) // x and y wear the same hat

  • Brian White (unregistered) in reply to blarg
    blarg:
    lolwtf:
    blarg:
    for those complaining about float for monetary values, how would you suggest storing $0.018372 ?

    Not all applications are built for airline tickets and groceries you know...

    As either the integer 18372 (or 183720 if you deal in hundred-thousandths of a dollar, etc) or the value 0.018372 represented by something more precise than floating-point.

    ok, now lets say the next number has an extra digit - are you going to re-write all your code because you came up with a ridiculously non-flexible design?

    Saying "something more precise...." is a complete cop out. Either name what this "something" is, or accept that you don't have the answer.

    I work in finance, and valuing things to numerous decimal places is common place. floats work fine for this purpose.

    Really? I wonder why every major RDBMS has a money type in that case.

  • (cs) in reply to Brian White
    Brian White:
    blarg:
    lolwtf:
    blarg:
    for those complaining about float for monetary values, how would you suggest storing $0.018372 ?

    Not all applications are built for airline tickets and groceries you know...

    As either the integer 18372 (or 183720 if you deal in hundred-thousandths of a dollar, etc) or the value 0.018372 represented by something more precise than floating-point.

    ok, now lets say the next number has an extra digit - are you going to re-write all your code because you came up with a ridiculously non-flexible design?

    Saying "something more precise...." is a complete cop out. Either name what this "something" is, or accept that you don't have the answer.

    I work in finance, and valuing things to numerous decimal places is common place. floats work fine for this purpose.

    Really? I wonder why every major RDBMS has a money type in that case.

    If you are in finance and evaluating things to an arbitrary number of decimal places, then yes, floats are fine.

  • trtrwtf (unregistered) in reply to hoodaticus
    hoodaticus:
    Brian White:
    blarg:
    lolwtf:
    blarg:
    for those complaining about float for monetary values, how would you suggest storing $0.018372 ?

    Not all applications are built for airline tickets and groceries you know...

    As either the integer 18372 (or 183720 if you deal in hundred-thousandths of a dollar, etc) or the value 0.018372 represented by something more precise than floating-point.

    ok, now lets say the next number has an extra digit - are you going to re-write all your code because you came up with a ridiculously non-flexible design?

    Saying "something more precise...." is a complete cop out. Either name what this "something" is, or accept that you don't have the answer.

    I work in finance, and valuing things to numerous decimal places is common place. floats work fine for this purpose.

    Really? I wonder why every major RDBMS has a money type in that case.

    If you are in finance and evaluating things to an arbitrary number of decimal places, then yes, floats are fine.

    If you are in finance and evaluating things to arbitrary decimal places, can I have a float until Friday?

  • (cs) in reply to jasmine2501
    jasmine2501:

    Back when that was legal, it caused a huge amount of problems. What if obj1 is zero? That is/was false in some C implementations, even though it's not null. I'm on board with the requirement that whatever goes in the IF condition should be a boolean expression. There should be no confusion about whether the programmer meant non-zero, non-null, or whatever they meant to say.

    Unless they changed it, the C standard covers this by explicitly stating that pointers (and only pointers) set to the literal value 0 always represent the null pointer, even if the OS has 0 as a valid address. Even in C, you're not supposed to deal with the underlying format of pointers; you're just supposed to use pointer math on the pointers provided by the OS.

    To be honest, though, I don't know if evaluation of a pointer as a Boolean implicitly compares it to the literal 0 (and so always compares to the true null pointer) or if it treats it as an integer type. I would expect the former, though, so a compiler that didn't do this would be non-conforming.

  • (cs) in reply to blarg
    blarg:
    Saying "something more precise...." is a complete cop out. Either name what this "something" is, or accept that you don't have the answer.
    Let me try: Rather than say "something more precise" (I agree that really is a bullshit comment) let's say something that doesn't store currency in a binary pseudo-scientific notation, since that seems to be the root cause of all problems related to floating-point currency.

    Then again, I do wonder if sometimes the real issues with using floating-point currency aren't real issues for the application or the business. And I always have to laugh when the "anti-floating-point-currency" folks stubbornly argue their case in the presentation layer.

  • (cs) in reply to jasmine2501
    jasmine2501:
    I'm on board with the requirement that whatever goes in the IF condition should be a boolean expression. There should be no confusion about whether the programmer meant non-zero, non-null, or whatever they meant to say.
    So you think that programmers should have to be clear and specific when they write code? That precision should be a virtue, nay an expectation?

    Interesting...

  • (cs) in reply to too_many_usernames
    too_many_usernames:
    Unless they changed it, the C standard covers this by explicitly stating that pointers (and only pointers) set to the literal value 0 always represent the null pointer, even if the OS has 0 as a valid address. Even in C, you're not supposed to deal with the underlying format of pointers; you're just supposed to use pointer math on the pointers provided by the OS.

    To be honest, though, I don't know if evaluation of a pointer as a Boolean implicitly compares it to the literal 0 (and so always compares to the true null pointer) or if it treats it as an integer type. I would expect the former, though, so a compiler that didn't do this would be non-conforming.

    If I was inventing it, it would be:

    I would have the C pointers with NULL work like: An implicit cast from a constant 0 is NULL. An implicit cast from any other number, or a non-constant 0, is a compile error. An explicit cast from any number to a pointer is the corresponding address, so 0 might not necessarily be NULL. An implicit cast from a pointer to boolean is true if and only if it is not NULL. An implicit cast from pointer to number is a compiler error, but an explicit cast works and 0 will not necessarily be NULL.

  • Meep (unregistered) in reply to blarg
    blarg:
    for those complaining about float for monetary values, how would you suggest storing $0.018372 ?

    Not all applications are built for airline tickets and groceries you know...

    No, let's keep it simple. How do you store 0.2 in a binary floating point field? It winds up being 0.001100110011.... You're storing an approximation of the number, which means your books won't balance.

    That's why DBMSs generally have a decimal format where you can specify the number of digits you need.

  • Egats (unregistered) in reply to Anon

    I wish the hoare that I frequent would charge me null

  • Egats (unregistered) in reply to Anon
    Anon:
    Nagesh:
    In my point of view, NULLS are completely useless and stupid. Whoever came with NuLL concept need to be drawn, quartered and then left to rot on the pikes of the RDBMS compound.

    Amazingly Nagesh, the guy who invented Null sort of agrees with you.

    i feel like a real null forgetting to quote...

  • Gunslinger (unregistered) in reply to blarg
    blarg:
    lolwtf:
    blarg:
    for those complaining about float for monetary values, how would you suggest storing $0.018372 ?

    Not all applications are built for airline tickets and groceries you know...

    As either the integer 18372 (or 183720 if you deal in hundred-thousandths of a dollar, etc) or the value 0.018372 represented by something more precise than floating-point.

    ok, now lets say the next number has an extra digit - are you going to re-write all your code because you came up with a ridiculously non-flexible design?

    Saying "something more precise...." is a complete cop out. Either name what this "something" is, or accept that you don't have the answer.

    I work in finance, and valuing things to numerous decimal places is common place. floats work fine for this purpose.

    No wonder the financial system is crap.

  • Herby (unregistered)

    Money? Floating point?? Fail!!

    If you want to do money, make sure that the programmer who does it uses his OWN paycheck as beta test. Then when it agrees with the manual calculation and verified by a nice higher up (don't want errors in the wrong direction), he gets paid. If there are ANY miscalculations, the IRS gets involved, and they don't take kindly to "round off error" as an excuse.

    Yes, I did some money calculations in floating point. It didn't take long to find out that single precision was bad. Thankfully the money amounts weren't too high enough for double precision (actually REAL*8) to make drastic errors.

    You see they invented Cobol for a reason!

  • Brian White (unregistered) in reply to hoodaticus
    hoodaticus:
    Brian White:
    blarg:
    lolwtf:
    blarg:
    for those complaining about float for monetary values, how would you suggest storing $0.018372 ?

    Not all applications are built for airline tickets and groceries you know...

    As either the integer 18372 (or 183720 if you deal in hundred-thousandths of a dollar, etc) or the value 0.018372 represented by something more precise than floating-point.

    ok, now lets say the next number has an extra digit - are you going to re-write all your code because you came up with a ridiculously non-flexible design?

    Saying "something more precise...." is a complete cop out. Either name what this "something" is, or accept that you don't have the answer.

    I work in finance, and valuing things to numerous decimal places is common place. floats work fine for this purpose.

    Really? I wonder why every major RDBMS has a money type in that case.

    If you are in finance and evaluating things to an arbitrary number of decimal places, then yes, floats are fine.

    So do you invoice people for $101,491.3954928211 on a regular basis? And then hound them if they are .000000000001 cents short of what they owe? Keeping track of sub-penny amounts seems pointless when you can only be paid in multiples of pennies. It just gives rise to a situation where sum(what we were owed) <> sum(what we were paid) even when everyone has paid you everything you asked for. What do you do with the incremental difference? Do you carry it forward to the next month and try to invoice for it then, hoping that the customer won't notice you are invoicing them for 1 penny more than they see on their monthly usage report?

  • Fedaykin (unregistered) in reply to blarg
    blarg:
    lolwtf:
    blarg:
    for those complaining about float for monetary values, how would you suggest storing $0.018372 ?

    Not all applications are built for airline tickets and groceries you know...

    As either the integer 18372 (or 183720 if you deal in hundred-thousandths of a dollar, etc) or the value 0.018372 represented by something more precise than floating-point.

    ok, now lets say the next number has an extra digit - are you going to re-write all your code because you came up with a ridiculously non-flexible design?

    Saying "something more precise...." is a complete cop out. Either name what this "something" is, or accept that you don't have the answer.

    I work in finance, and valuing things to numerous decimal places is common place. floats work fine for this purpose.

    Floats are terrible, because you cannot precisely represent 0.1 in binary, which is very common in financial transactions. This leads to things like

    0.1 + 0.1 = 0.1999999999999

  • Brian White (unregistered) in reply to Meep
    Meep:
    blarg:
    for those complaining about float for monetary values, how would you suggest storing $0.018372 ?

    Not all applications are built for airline tickets and groceries you know...

    No, let's keep it simple. How do you store 0.2 in a binary floating point field? It winds up being 0.001100110011.... You're storing an approximation of the number, which means your books won't balance.

    That's why DBMSs generally have a decimal format where you can specify the number of digits you need.

    If your DBMS provides it, there is this nice data type called MONEY. You want to use the MONEY data type to store money, not numeric(18,12) or (6,2) or some other homegrown approximation. Money data types are fixed point instead of floating point. In sql server it goes out to 4 decimal points. In Informix you can specify a precision up to 32 or something crazy like that.

  • John Muller (unregistered)

    I think the confusion here is between Finance and Accounting.

    Finance can use floating point to calculate things like componding interest rates, while Accounting deals with the actual transactions that take place in integer units.

    Some of the highest FLOP supercomputers are owned/used by financial companies, for doing market speculation... (i.e. no direct value to society)

  • (cs) in reply to Herby
    Herby:
    Money? Floating point?? Fail!!

    If you want to do money, make sure that the programmer who does it uses his OWN paycheck as beta test.

    The total discrepancies you would get from that are not enough for me to bend over and pick up should I drop it.

  • (cs) in reply to John Muller
    John Muller:
    I think the confusion here is between Finance and Accounting.

    Finance can use floating point to calculate things like componding interest rates, while Accounting deals with the actual transactions that take place in integer units.

    Some of the highest FLOP supercomputers are owned/used by financial companies, for doing market speculation... (i.e. no direct value to society)

    NICE.

  • (cs) in reply to Vacaloca
    Vacaloca:
    SCSimmons:
    Magnus:
    SCSimmons:
    (Or is this where I say "TRWTF is Java"?)
    TRWTH is that both the Java and the C# snippet look exactly the same. I mean, wasn't C# meant to improve on Java?
    Well, both Java and C# get their basic syntax from C/C++. A lot of code is interchangeable--in fact, I'm not positive glancing over it that the last snippet is C#. (It's not Java, but it could be C++, couldn't it? Or maybe not--I've been using VB.NET too long, so I've lost a lot of brain cells.)

    Sounds like you should go back to VB6 is this wasn't a dead giveaway..

    import java.util.Calendar; import java.util.Date; import java.util.GregorianCalendar;

    import org.apache.log4j.Logger;

    I was talking about the last snippet, from Neville. Obviously the first snippet from Willy was java.

    VB.NET hasn't killed that many of my brain cells. Yet.

    Magnus:
    The clues are using Object.Equals (with uppercase E), meaning it's not Java, and "public static" (instead of "public: static"), meaning it's not C++.

    See, I didn't even notice the missing colon. Back in the early eighties, overlooking something like that could result in a horrible death.

  • Brian White (unregistered) in reply to hoodaticus
    hoodaticus:
    Herby:
    Money? Floating point?? Fail!!

    If you want to do money, make sure that the programmer who does it uses his OWN paycheck as beta test.

    The total discrepancies you would get from that are not enough for me to bend over and pick up should I drop it.

    Yes, that is what we tell our customers when the amounts we show are wrong by a penny. We're like what the fuck man, who cares it's just a penny. That is why we are the dominant software company in the world.

  • WthyrBendragon (unregistered) in reply to Larrik Jaerico
    Larrik Jaerico:
    (Of course I just replaced a 6000 line C program that made use of tiny variable names and loops filled with insane Switch/Case statements, so perhaps my bar for WTFs has gotten too high.)

    Me thinks you needs to submit a sample case as a future WTF. At the very least it sounds like an example of what happens when wanna-be's code with too many beers between the keyboard and the chair.

  • WthyrBendragon (unregistered) in reply to Brian White
    Brian White:
    Yes, that is what we tell our customers when the amounts we show are wrong by a penny. We're like what the fuck man, who cares it's just a penny. That is why we are the dominant software company in the world.
    Off by a penny per transaction is pretty significant when the POS app in question processes several million transactions a day.
  • Bit Head (unregistered) in reply to Brian White
    Brian White:
    hoodaticus:
    Brian White:
    blarg:
    lolwtf:
    blarg:
    for those complaining about float for monetary values, how would you suggest storing $0.018372 ?

    Not all applications are built for airline tickets and groceries you know...

    As either the integer 18372 (or 183720 if you deal in hundred-thousandths of a dollar, etc) or the value 0.018372 represented by something more precise than floating-point.

    ok, now lets say the next number has an extra digit - are you going to re-write all your code because you came up with a ridiculously non-flexible design?

    Saying "something more precise...." is a complete cop out. Either name what this "something" is, or accept that you don't have the answer.

    I work in finance, and valuing things to numerous decimal places is common place. floats work fine for this purpose.

    Really? I wonder why every major RDBMS has a money type in that case.

    If you are in finance and evaluating things to an arbitrary number of decimal places, then yes, floats are fine.

    So do you invoice people for $101,491.3954928211 on a regular basis? And then hound them if they are .000000000001 cents short of what they owe? Keeping track of sub-penny amounts seems pointless when you can only be paid in multiples of pennies. It just gives rise to a situation where sum(what we were owed) <> sum(what we were paid) even when everyone has paid you everything you asked for. What do you do with the incremental difference? Do you carry it forward to the next month and try to invoice for it then, hoping that the customer won't notice you are invoicing them for 1 penny more than they see on their monthly usage report?

    You scrape off that residual amount into another account (that you own) and let it accumulate. Haven't you ever watched Office Space?

  • Admittedly, not a java programmer (unregistered) in reply to Magnus
    Magnus:
    No WTFs here, move along.

    As others have pointed out: for floats, you need an epsilon. Either you put it in a common function like here, or you put it in every single compare (which would not be fun to maintain).

    For the nulls, well, that's the alternative? obj1.equals(obj2) will give you a NullPointerException if obj1 is null. If your code really does have to deal with that condition, then this is the way to do it.

    Surely, though, if you really need a static method, you could say:

    if(obj1==null) return obj1 == obj2;
    else return obj1.equals(obj2);
    

    If object 1 is null, then we are equal if object 2 is too. Otherwise, we can call Object 1's equals method.

    I sort of thought the whole OO think was about dealing with objects directly, so if we have obj1 outside the static method, we presumably know whether it is null or not (or we can trivially check), and then we can compare it using the .equals method

    The code itself works in the WTF, no doubt about that, but it's whether there's any point to it that remains to be seen. Sometimes you have that moment where you think: "Why was I trying to reinvent the wheel?"

  • Jelly (unregistered) in reply to Nagesh
    Nagesh:
    In my point of view, NULLS are completely useless and stupid. Whoever came with NuLL concept need to be drawn, quartered and then left to rot on the pikes of the RDBMS compound.

    I nearly got caught!!

    Hi Nagesh!

  • (cs) in reply to Herby
    Herby:
    Money? Floating point?? Fail!!

    If you want to do money, make sure that the programmer who does it uses his OWN paycheck as beta test. Then when it agrees with the manual calculation and verified by a nice higher up (don't want errors in the wrong direction), he gets paid. If there are ANY miscalculations, the IRS gets involved, and they don't take kindly to "round off error" as an excuse.

    Yes, I did some money calculations in floating point. It didn't take long to find out that single precision was bad. Thankfully the money amounts weren't too high enough for double precision (actually REAL*8) to make drastic errors.

    You see they invented Cobol for a reason!

    You're saying they invented COBOL just to solve the floating-point currency problem? If so, then that's an awful lot of feature creep.

  • AnotherAnon (unregistered)

    Another financial worker throwing in my 2.00000001 cents.

    When I worked in banking (e.g. user accounts, business transactions, SWIFT...) we used precise money types.

    Then I moved to Wall St. I don't know any execution management system (at any brokerage firm or quant shop) that doesn't use plain old doubles. The problems don't exist in real life. Numbers have "clumped" precision (if that makes sense). A small number can happily be rounded. A large number (that matters) isn't going to have any decimals and gets happily rounded too.

    Any pennies missing would get noticed. We need speed: doubles give us this with no loss.

  • Baw Hogwash (unregistered) in reply to Meep
    Meep:
    Nagesh:
    In my point of view, NULLS are completely useless and stupid. Whoever came with NuLL concept need to be drawn, quartered and then left to rot on the pikes of the RDBMS compound.

    The problem with NULLs isn't having some "I don't know what this is" type marker, after all, enumerated types work just fine, so there's no reason you can't have a single-value type called null. It's that people can't leave it alone at that. So they come up with idiotic stuff like three-valued logic and try to shoehorn it into relational algebra that is implicitly based on two-valued logic. A table is a set of rows that correspond to logical propositions. If a row is in the table, the database asserts that the corresponding proposition is true, and if it's not, the corresponding proposition is false. So if the corresponding proposition is null, should the row be in the table or not?

    And then you have Java, where every "type", if such a term can be used for classes of mutable objects, includes the null type. So every parameter of every function is possibly going to get this null whether it's legal or not. Which is not quite as dumb as C, where the null value for a pointer is... a perfectly valid pointer that just happens to be considered an error condition by the operating system. Complete insanity.

    And most people just take this for granted because they've never used a good type system. It's shameful, truly shameful.

    C's Null is simply a pointer to nowhere (or to a place that has been defined as nowhere). This is a far better approach than assigning a pointer that actually points somewhere. I'm not really sure what you mean about the validity of it...A Null Pointer is a perfectly valid pointer (same as 0 is a perfectly valid integer), but what's the alternative? Setting a pointer to something invalid would be akin to setting an integer variable to "Fred". I find the statement that the null pointer is valid but an error somewhat confusing. Any value that the pointer can take must be valid, thus of course the null pointer is a valid pointer, it simply points to somewhere we shouldn't be doing anything. The Null pointer is not considered an error condition by the operating system, trying to use the memory it points to is considered an error condition. This is very, very sensible is fou ask me.

    Maybe it's because I've grown up with C, I think there's a certain amount of sense in initialising a variable (irrespective of type) to some known and consistent value.

    We should keep in mind that in C things don't (by default) get initialised to any particular value (ok, it might be compiler specific), so NULL is optionally used by programmers.

    Oh, and did I just get trolled?

  • Ol Boozy (unregistered) in reply to C-Octothorpe
    C-Octothorpe:
    Nagesh:
    hoodaticus:
    Nagesh:
    boog:
    Nagesh:
    In my point of view, NULLS are completely useless and stupid. Whoever came with NuLL concept need to be drawn, quartered and then left to rot on the pikes of the RDBMS compound.
    Nice try Nagesh-old-buddy, but the article doesn't appear to have anything to do with RDBMS.

    Keep on trollin!

    bogger baby, i am rollin with lafter all over at your pathetic attempt to seek my attention...

    i said before, i hold nothing against trolls, but for sake of everyone on internet, be interesting. Sorry bogger you're number two boring dude!

    Are you still hungover from celebrating the world cup or something?

    First time in my entire life, I had more than 6 big beers at one single sitting.

    Don't worry Nagesh, you're in good company here... I'm sure at least half the people on this forum are drunk right now.

    Or is that just me?

    Yeah, but off somewhat more than 6 beers.

  • Collete (unregistered)

    I always wondered why I never get many presents on my birthday, must be because its on a "null"

  • Kohlrak (unregistered)

    Sorry, i had to do this (the java specification implies that 2 nulls would return false, which conflicts with the specification of the exercise [my old teacher was a stickler for the specification]):

    public boolean IsEqual(Object a, Object b){
    	if(a!=null && b!=null) return a.Equals(b);
    	else if (a!=null || b!=null) return false;
    	return true;
    }
    
    public boolean IsEqual(Object a, Object b){ return !IsEqual(a,b); }
  • (cs)

    Apart from the other problems already mentioned in the second set, in what case would you ever need this logic?

    • Comparing two nulls, notEqual and isEqual both return false
    • Comparing a null and an empty string, notEqual and isEqual both return false
    • Comparing a null and any other value, notEqual returns true and isEqual returns false
  • (cs) in reply to Fedaykin
    Fedaykin:
    Floats are terrible, because you cannot precisely represent 0.1 in binary, which is very common in financial transactions. This leads to things like

    0.1 + 0.1 = 0.1999999999999

    That's where sprintf() and atof() come in...

  • iusto (unregistered) in reply to Kohlrak
    Kohlrak:
    Sorry, i had to do this (the java specification implies that 2 nulls would return false, which conflicts with the specification of the exercise [my old teacher was a stickler for the specification]):
    public boolean IsEqual(Object a, Object b){
    	if(a!=null && b!=null) return a.Equals(b);
    	else if (a!=null || b!=null) return false;
    	return true;
    }
    
    public boolean IsEqual(Object a, Object b){ return !IsEqual(a,b); }

    Wouldn't

    a.equals(NULL);
    

    be false (if a is not null). Based on wot you sed about the spec^n, we only have to check the nullity of a....

    (how does the java spec imply that 2 nulls would equal false? Surely this whole idea of a static comparator is not very javanesque?)

    So...couldn't we have

    public boolean IsEqual(Object a, Object b){
      if(a==NULL) return false;
      else return a.equals(b);
    }
    
  • lucidfox (unregistered)

    TRWTF is log4j. It really is time now to move to SLF4J.

  • lucidfox (unregistered)

    Also, I recommend using Guava and Objects.equal().

  • Not of this Earth (unregistered)

    TRWTF is Java.

    Captcha: validus - yes, I'm right.

  • Marvin the Martian (unregistered) in reply to WthyrBendragon
    WthyrBendragon:
    Brian White:
    Yes, that is what we tell our customers when the amounts we show are wrong by a penny. We're like what the fuck man, who cares it's just a penny. That is why we are the dominant software company in the world.
    Off by a penny per transaction is pretty significant when the POS app in question processes several million transactions a day.
    Hear, hear. Someone's seen Office Space recently.
  • Peter (unregistered) in reply to Nagesh
    Nagesh:
    boog:
    Nagesh:
    Whoever came with NuLL concept need to be drawn, quartered and then left to rot on the pikes of the RDBMS compound.
    Nice try Nagesh-old-buddy, but the article doesn't appear to have anything to do with RDBMS.

    Keep on trollin!

    bogger baby, i am rollin with lafter all over at your pathetic attempt to seek my attention...

    i said before, i hold nothing against trolls, but for sake of everyone on internet, be interesting. Sorry bogger you're number two boring dude!

    Isn't that sweet? They're bonding...

  • Swedish tard (unregistered) in reply to Marvin the Martian
    Marvin the Martian:
    WthyrBendragon:
    Brian White:
    Yes, that is what we tell our customers when the amounts we show are wrong by a penny. We're like what the fuck man, who cares it's just a penny. That is why we are the dominant software company in the world.
    Off by a penny per transaction is pretty significant when the POS app in question processes several million transactions a day.
    Hear, hear. Someone's seen Office Space recently.

    Or worked in a multinational company. there are countries that requires 6 correct decimal places for money, even if you toss 1000000000 amounts around. Our system has a homebrewed "Money" class that even takes care of rounding problems that occur when dividing say 10 by 3.

    Some places are anal about silly stuff.

  • Level 2 (unregistered)

    TRWTF is

          if(obj1==null && obj2 == null){
             return true;
    

    Obj1 does not exist and obj2 does not exist, so they are equal? Of course not, they don't exist. Equality has no meaning for objects that don't exist.

    The Other WTF with checking for null in equals methods is that the programmer expects to compare uninitalized objects. I can't imagine circumstances where that is not a bug in the calling code.

  • Sten (unregistered)

    TRWTF is using float for money. Geez, precision is so unnecessary when dealing with money, right? (Can I have one cent from each operation ane call it rounding error?)

  • (cs) in reply to Not of this Earth
    Not of this Earth:
    TRWTF is Java.

    Captcha: validus - yes, I'm right.

    This comment prime example of stupidity and uninformedness rolled into one.

    Akismet, you stupid robot.

  • (cs) in reply to Nagesh
    Nagesh:
    This comment prime example of stupidity and uninformedness rolled into one.

    That's very meta of you, Nagesh.

  • anonymousse (unregistered) in reply to IronMensan

    So... it's not, quite indeedleeo, not useless? Not that I couldn't care less.

  • Meep (unregistered) in reply to Baw Hogwash
    Baw Hogwash:
    Meep:
    Nagesh:
    In my point of view, NULLS are completely useless and stupid. Whoever came with NuLL concept need to be drawn, quartered and then left to rot on the pikes of the RDBMS compound.

    The problem with NULLs isn't having some "I don't know what this is" type marker, after all, enumerated types work just fine, so there's no reason you can't have a single-value type called null. It's that people can't leave it alone at that. So they come up with idiotic stuff like three-valued logic and try to shoehorn it into relational algebra that is implicitly based on two-valued logic. A table is a set of rows that correspond to logical propositions. If a row is in the table, the database asserts that the corresponding proposition is true, and if it's not, the corresponding proposition is false. So if the corresponding proposition is null, should the row be in the table or not?

    And then you have Java, where every "type", if such a term can be used for classes of mutable objects, includes the null type. So every parameter of every function is possibly going to get this null whether it's legal or not. Which is not quite as dumb as C, where the null value for a pointer is... a perfectly valid pointer that just happens to be considered an error condition by the operating system. Complete insanity.

    And most people just take this for granted because they've never used a good type system. It's shameful, truly shameful.

    C's Null is simply a pointer to nowhere (or to a place that has been defined as nowhere). This is a far better approach than assigning a pointer that actually points somewhere. I'm not really sure what you mean about the validity of it...

    Of course you're not sure. The type system doesn't tell you enough to be sure. Null pointers are enforced by convention rather than the type system, which is a reasonable hack for C.

    What's truly insane is trying to formalize that convention into null references in Java.

    A Null Pointer is a perfectly valid pointer (same as 0 is a perfectly valid integer),

    Except that, according to man malloc, if malloc returns a null pointer, it's an error condition.

    but what's the alternative? Setting a pointer to something invalid would be akin to setting an integer variable to "Fred".

    Union types? Exceptions?

    Maybe it's because I've grown up with C, I think there's a certain amount of sense in initialising a variable (irrespective of type) to some known and consistent value.

    We should keep in mind that in C things don't (by default) get initialised to any particular value (ok, it might be compiler specific), so NULL is optionally used by programmers.

    Oh, and did I just get trolled?

    I think you were trolled by K&R.

    You say you grew up with C, and you say memory should be initialized to some known and consistent value. In the next sentence you explain that C doesn't initialize values.

    Instead of initializing pointers to something that isn't a useful value but is rather, at least sometimes, an error condition...

    Why not have pointers be initialized with what they fucking point to? Maybe I've been using too many fruity computer sciencey functional languages, but I would have thought that's the calling, the reason, the raison d'etre, the vocation, wait for it, the "point" of a pointer.

    If it's perfectly natural for you to assign meaningless values to all your variables because your language doesn't initialize memory by default, yes, you're affected by the inanities of your language. Sure, if I'm implementing an entropy pool I don't care if my buffer has stuff in it, and if I'm explicitly scanning memory or rolling my own IPC, I'd want that. C is doing the wrong thing 99.999% of the time by default, and you're taking that as the natural way of things.

  • (cs) in reply to Marvin the Martian
    Marvin the Martian:
    WthyrBendragon:
    Off by a penny per transaction is pretty significant when the POS app in question processes several million transactions a day.
    Hear, hear. Someone's seen Office Space recently.
    Just don't misplace the decimal point. That's the kind of mundane detail you don't want to mess up.
  • Valczir (unregistered) in reply to Anon
    Anon:
    Trying that again... The guy who invented null kind of agrees with you.

    (And yet akismet thinks this one is spam?)

    Augh! The flash! It burns my eyes!

    Thank goodness I have flash block, or I would have had a sudden enormous spike in CPU usage. Flash on linux freaking sucks.

Leave a comment on “The Qualities of Equality”

Log In or post as a guest

Replying to comment #:

« Return to Article