• coyo (unregistered)

    Moo Moo Moo

    I think what they wanted is foo != Integer.NAN the, um, cadillac version.

    captcha suscipit - Suspicion of Incipidness.

  • Lothar (unregistered) in reply to coyo
    coyo:
    Moo Moo Moo

    I think what they wanted is foo != Integer.NAN the, um, cadillac version.

    1. There is no Integer.NaN
    2. Even if there is, foo != Integer.NaN would always return true, even if foo == Integer.NaN
  • (cs) in reply to KLOCker
    KLOCker:
    I know how to loop integers, but not floats. Could someone plezz send me teh codez?

    C++ way:

    union { float f; UINT32 u; } float_uint32;

    float_uint32 fu32;

    for (UINT64 i = 0; i <= 0xffffffff; i++) { fu32.u = (UINT32)i; float f = fu32.f;

    // do something with f
    

    }

  • Xythar (unregistered)

    What is CMMI?

  • (cs) in reply to Xythar
    Xythar:
    What is CMMI?
    http://en.wikipedia.org/wiki/CMMI
  • Simon (unregistered)

    The thing you have to realise when it comes to outsourcing firms, especially in the subcontinent, is that the higher their CMMI level, the more likely they are to develop your software exactly according to the way you spec it. Even when that spec is wrong.

    Clearly somewhere along the line as part of the design specifications, someone has requested that a function be added to validate integer input. This is exactly what this function does. It takes an integer input and checks that it's a valid integer. The developer who implemented it probably also thought it was stupid, but the spec said that they had to have this function and so he came up with a fairly decent, well-written and well-documented way to do that. The fact that it's utterly retarded is a completely separate matter entirely.

    You don't want stupid code from CMMI Level 5 outsourcers? Don't put stupid things in your specs and make sure you word every requirement precisely.

  • coyo (unregistered) in reply to Lothar
    Lothar:
    coyo:
    Moo Moo Moo

    I think what they wanted is foo != Integer.NAN the, um, cadillac version.

    1. There is no Integer.NaN
    2. Even if there is, foo != Integer.NaN would always return true, even if foo == Integer.NaN

    Is been a while. I think there is a method though, maybe in Number, like foo.isNaN() or some such.

  • Max (unregistered) in reply to Simon

    Please tell me if you're just fucking with us.

  • (cs)

    It seems to me that if this is really what you're after, you could have a compiler or preprocessor or something do most of the work for you instead of spelling it out like this...

  • ToAshamedToName (unregistered) in reply to luis.espinal

    Thanks for replying to my question. I come from a c# background but I am only now learning for my .net certificaiton. If Java (and c#) will automatically box anything passed to this method, what will happen if the value passed to this method can't be cast to an integer (i.e. someone accidentally passes it a string)? Won't that cause an exception in itself, before the method even executes or will the runtime simply assign the parameter a null value?

  • ToAshamedToName (unregistered) in reply to luis.espinal
    luis.espinal:
    It wouldn't even compile pre Java 5, but from 5 forwards, we get auto-boxing of primitive types (similar, but not quite like, auto-boxing in C#).

    So if you were to pass an int variable, say x, as an argument to a function taking an Integer, the compiler would create an Integer object initialized with x. Same when assigning an Integer to a int (or any standard primitive wrapper to/from an actual primitive type.) <snip>

    Thanks for replying to my question. I come from a c# background but I am only now learning for my .net certificaiton. If Java (and c#) will automatically box anything passed to this method, what will happen if the value passed to this method can't be cast to an integer (i.e. someone accidentally passes it a string)? Won't that cause an exception in itself, before the method even executes or will the runtime simply assign the parameter a null value?

  • (cs)

    Having CMMI level 5 does not mean one is not producing crap. It just means they are producing crap deterministically.

  • Mike U of I EE (unregistered) in reply to ath

    Yeah, you can. I was once involved in developing a system where I was in charge of a key DLL. My log file was in the form of executable C++ code. Therefore, any logged session could be sent to me so that I could see, compile, run, and debug what their GUI code and the user's input had been doing with my DLL.

  • storray expert (unregistered)

    he was saying "heck" half jokingly, right?

  • storray expert (unregistered) in reply to mypalmike

    uhh.... not in Java.

  • storray expert (unregistered) in reply to mypalmike
    mypalmike:
    I like the fact that this can return false:
    public static boolean equalToSelf(float n) {
       return n == n;
    }
    
    uhh, not in java
  • CMMie (unregistered)

    ... does not mean that you are not producing crap. It just means that you have a process in place to improve the kind of crap you are producing, even if it is a slow and inconsequential improvement that is heading your company into oblivion.

    Typically, the situation just described would produce some "key learnings", such as the following:

    1. Do not write crap, if possible. If not possible, try to learn the other key points.
    2. Make sure you disguise the crap written with official sounding comments, TLAs, etc. so that the people who read the code are not inspired to post it to thedailywtf.com.
    3. Make sure you keep your people busy by filing trivial issues against some complicated CMMI compliant code so that they are not inspired to read thedailywtf.com
  • chris (unregistered) in reply to chewbacha
    chewbacha:
    mypalmike:
    I like the fact that this can return false:
    public static boolean equalToSelf(float n) {
       return n == n;
    }
    

    I'm pretty sure it cannot... floats don't "miraculously" change value, the bits are still the same. What happens to floats are that sometimes the arithmetic is "fuzzy" and the result of a function may not be exactly what you would expect. The value of a float in memory will always be the same (unless the memory is faulty).

    I know that the function is in Java not C++, but take a look at the fifth bullet point: http://gcc.gnu.org/onlinedocs/gcc-3.1.1/gcc/Disappointments.html

    Worth considering if you're ever considering using == on floats.

  • Design Pattern (unregistered) in reply to storray expert
    storray expert:
    mypalmike:
    I like the fact that this can return false:
    public static boolean equalToSelf(float n) {
       return n == n;
    }
    
    uhh, not in java

    Why not reading the rest of the thread (especially this post) before posting utter bullshit?

  • Ouch! (unregistered) in reply to Design Pattern
    Design Pattern:
    storray expert:
    mypalmike:
    I like the fact that this can return false:
    public static boolean equalToSelf(float n) {
       return n == n;
    }
    
    uhh, not in java

    Why not reading the rest of the thread (especially this post) before posting utter bullshit?

    Wouldn't that be against the rules?

  • repeat of other posts (unregistered) in reply to Lothar
    Lothar:
    TGV:
    steenbergh:
    When exactly will this function return False?
    When the ToString() method produces something the parseInt() method cannot parse, or throws an exception all by itself (say, out of memory). So it's a really good check of whether the library programmers have done a good job. It will trigger some unwanted behavior at a random moment if the library programmers overlooked a small thing. Awesome.

    Since it's a Java-program and Integer is part of the standard java library, a point where Integer.parseInt(myint.toString()) fails, it would be time to shutdown the application instead of just returning false. BTW: The point where these checks should take place is the unit-test and not the productive code.

    If you changed the language formatting 1/2 way through could it fail? Iff parseInt or Integer.toString are localised it your return "10,000" and expect "10.000".

  • anyone (unregistered) in reply to steenbergh

    try with null

  • Bosshog (unregistered) in reply to Simon
    Simon:
    You don't want stupid code from CMMI Level 5 outsourcers? Don't put stupid things in your specs and make sure you word every requirement precisely.
    Alternatively known as, "specify it so precisely that it is easier to just write the code yourself".
  • Lothar (unregistered) in reply to repeat of other posts
    repeat of other posts:
    Lothar:
    Since it's a Java-program and Integer is part of the standard java library, a point where Integer.parseInt(myint.toString()) fails, it would be time to shutdown the application instead of just returning false. BTW: The point where these checks should take place is the unit-test and not the productive code.
    If you changed the language formatting 1/2 way through could it fail? Iff parseInt or Integer.toString are localised it your return "10,000" and expect "10.000".
    It helps knowing something about the language in question. parseInt and toString don't parse or return Strings that are localized according to a given locale (e.g. Locale.getDefault()). In Java you use NumberFormat etc. for this kind of thing.

    Parsing 10,000 will lead to a NumberFormatException, 10.000 AFAIR as well but might end up with 10. toString will always return 10000.

  • Lothar (unregistered) in reply to ToAshamedToName
    ToAshamedToName:
    If Java (and c#) will automatically box anything passed to this method, what will happen if the value passed to this method can't be cast to an integer (i.e. someone accidentally passes it a string)? Won't that cause an exception in itself, before the method even executes or will the runtime simply assign the parameter a null value?
    Autoboxing and casting are different things. In Java there is no such thing like an implicit cast for other things than casting from one primitive to the other (int to long but not view versa where the compiler will complain that there might be a loss of information). So if you pass an object and you cast it to a String, you will get (and have to expect) ClassCastExceptions. Strings are not automatically "converted" to an Integer.

    Autoboxing on the other side (since Java 1.5) is only working between primitives (int, long, float, ...) and their corresponding Object-Wrappers (java.lang.Integer, .Long, .Float, etc.). So you can "use" primitives e.g. as key for a Map (that needs classes derived from java.lang.Object). The compiler changes a call of

    mymap.put(1, 2L)
    to
    mymap.put(Integer.valueOf(1), Long.valueOf(2))
    and vice versa from
    int key = mapentry.getKey()
    to
    int key = mapentry.getKey().intValue()
    And if getKey() returns null there will be of course a NullPointerException leading to big questionmarks to the programmer who is not aware of that implicit change of code.
  • taste are so many... (unregistered) in reply to Andreas
    Andreas:
    [...] These guys had great processes that forced them to write
    if (a == b){
      return "something";
    }
    return "soemthingElse";
    
    it's almost a matter of test but I (often) like the first solution better which is much more expressive if the first part is checking for precondition and the last part is the normal flow of the program
    if (precond == false){
      return "something is wrong darling";
    }
    return "the normal flow";
    
  • chadsexington (unregistered)

    This is the worst null-checker i've ever seen. The one that I stand by checks every number against the input to see if its that number, and if it loops all the way to int_max, then its null.

    That way nothing gets through

    CAPTCHA : Nulla; used to describe how non-existantly good things are.

    That band was nulla good.

    They were that good?

    No, they were bad.

  • (cs) in reply to coyo
    coyo:
    Moo Moo Moo

    I think what they wanted is foo != Integer.NAN the, um, cadillac version.

    Imagine that, another coder who has no clue as to how computers work.

  • josefx (unregistered) in reply to Maurits
    KLOCker:
    I know how to loop integers, but not floats. Could someone plezz send me teh codez?
    the java way is Float.intBitsToFloat(int) int counter = 0; int i = INTEGER.MAX_VALUE do {

    float a = Float.intBitsToFloat(i); if(a != a) counter++; i++; }while(i != INTEGER_MAX_VALUE)

    There are quite a few NaN values in the spec

  • (cs)

    Interesting. It doesn't call logger.exiting in the case where someone passes in a value that trips the exception handler. Thankfully that only happens when someone's foolish enough to pass in a null but even so, have they never heard of a finally clause?

  • (cs) in reply to Design Pattern
    Design Pattern:
    storray expert:
    mypalmike:
    I like the fact that this can return false:
    public static boolean equalToSelf(float n) {
       return n == n;
    }
    
    uhh, not in java

    Why not reading the rest of the thread (especially this post) before posting utter bullshit?

    Don't get bent over dude. That reply you got was a natural response (most Java developers don't seem to know the intricacies of IEEE 754) to your example, which though correct, comes a bit off on the obscurantist side.

    I do strongly believe CS people should know these kind of things (Numerical Analysis or at least consistent coverage of floating point stuff should be required topics). But unfortunate as it is, many programmers come from a CS background that does not cover floating point arithmetic at all (much less anything related to numerical analysis.) This is not counting MIS programmers, and non-EE/non-CE engineering grads who end up becoming full-time programmers on the job. It is what it is.

    I would have been a bit more constructive if you had prefaced your example with a mention of IEEE 754 floats and a caveat saying that passing something like 0.0/0.0 or Float.NaN as arguments would make the method return false... just sayin' man.

  • Clebert Suconic (unregistered) in reply to Richard C Haven

    At least you got a CMM level 5 code, where the log is properly done :-)

  • Ouch! (unregistered) in reply to luis.espinal
    luis.espinal:
    Design Pattern:
    storray expert:
    mypalmike:
    I like the fact that this can return false:
    public static boolean equalToSelf(float n) {
       return n == n;
    }
    
    uhh, not in java

    Why not reading the rest of the thread (especially this post) before posting utter bullshit?

    Don't get bent over dude. That reply you got was a natural response (most Java developers don't seem to know the intricacies of IEEE 754) to your example, which though correct, comes a bit off on the obscurantist side.

    I do strongly believe CS people should know these kind of things (Numerical Analysis or at least consistent coverage of floating point stuff should be required topics). But unfortunate as it is, many programmers come from a CS background that does not cover floating point arithmetic at all (much less anything related to numerical analysis.) This is not counting MIS programmers, and non-EE/non-CE engineering grads who end up becoming full-time programmers on the job. It is what it is.

    I would have been a bit more constructive if you had prefaced your example with a mention of IEEE 754 floats and a caveat saying that passing something like 0.0/0.0 or Float.NaN as arguments would make the method return false... just sayin' man.

    luis, did you even bother to read the posts you quoted? Design Pattern, who may or may not be mypalmike, chided storray expert for posting a wrong assertion that had already been made and refuted previously in the thread. Naïve and futile, considering where we are, but understandable.

    BTW, I haven't found that Java developers know less about IEEE 754 than other developers on average (in other words, VB/C#/C++/Perl/Ruby developers don't know shit about floating point arithmetic either in general) - just sayin' man.

  • (cs) in reply to uzytkownik
    uzytkownik:
    Fred:
    public static boolean isUniverseStillDeterministic(Integer number) {
            try {
                Integer.parseInt(number.toString());
            } catch(Exception ex) {
                return false; 
            }
            return true;      
        }
    
    You're going to want to call this about 100 times a second, because if the Universe ever stops being deterministic you'll want to know right away that your calculations and logic are no longer reliable.

    Where it really gets interesting, then, is the code that calls isUniverseStillDeterministic. What are you going to do when you get a false? Better yet, how do you test that branch in your code? And if it does happen, you better log as much detail as possible to help unravel some of the fundamental problems of quantum mechanics.

    This code is incorrect. It can return true - a result with which any person knowing quantum mechanics (or QED) would disagree.

    Only if you examine the return value.
  • Josh (unregistered) in reply to steenbergh

    It will return false when it is called with a null argument. Because they are using the upper case Integer class rather than the primitive type int, the integer that gets passed in must be wrapped in the Integer object.

    the code will capture the NullPointerException, and incorrectly log a parse exception to the log file.

  • coyo (unregistered) in reply to frits
    frits:
    coyo:
    Moo Moo Moo

    I think what they wanted is foo != Integer.NAN the, um, cadillac version.

    Imagine that, another coder who has no clue as to how computers work.

    Imagine that. Someone so pedantic that their proctologist needs a ladder and a hazmat suit.

    Don't confuse syntax with pointer arithmetic.

  • Dave C (unregistered)

    In all seriousness, I've seen cases where plugins or JNI code can corrupt the internals of objects that are Java system pre-defined types, notably Jython can corrupt a java.lang.String which contains multibyte characters to the point where you can't even pass it to System.out.println()

    However, the data inside a java.lang.Integer is just a 32-bit int value, and all possible bit patterns are valid data, so the only way I can figure this could throw a NFE is if the input data is either null or some weird homegrown subclass of Integer with bugs.

    CAPTCHA spelled wrong: delenit / delinit

  • Dave C (unregistered) in reply to ath

    No.

    http://en.wikipedia.org/wiki/Halting_problem

    CAPTCHA: "nibh" == misspelled Gaelic girls' name?

  • Dave C (unregistered) in reply to Anonymous
    Anonymous:
    Trial by exception is bad enough - there are almost always ways to check for validity without relying on exception handling - but catching a top-level System.Exception when you're specifically looking for a FormatException is utterly retarded. The JVM could throw any number of internal exceptions (OutOfMemoryException for example) and this handler would pick them all up, even though it has no way of handling them and will actually misinterpret the results, thinking it's a FormatException when it could be something different.

    This code offends me.

    There is no such thing as OutOfMemoryException, it's OutOfMemoryError, and it is not a subclass of java.lang.Exception, because in general you're not supposed to catch it.

    java.lang.Error directly inherits from java.lang.Throwable

    CAPTCHA: "erat" == Latin for "was"

  • (cs) in reply to coyo
    coyo:
    frits:
    coyo:
    Moo Moo Moo

    I think what they wanted is foo != Integer.NAN the, um, cadillac version.

    Imagine that, another coder who has no clue as to how computers work.

    Imagine that. Someone so pedantic that their proctologist needs a ladder and a hazmat suit.

    Don't confuse syntax with pointer arithmetic.

    It's not my fault you tried to look smart, but ended up looking stupid.

  • Anonymous (unregistered)

    Did you ask your employer you can publish the code of your company?

    This is really a WTF - if you are stealing code from company without permission.

  • aristos_achaion (unregistered) in reply to Anonymous
    Anonymous:
    Did you ask your employer you can publish the code of your company?

    This is really a WTF - if you are stealing code from company without permission.

    Making fun of is scarcely stealing (whether "stealing" is the proper term for use with copyright is another matter...I'd say you're taking liberties with language and legality there)...and, honestly, I'm not entirely sure this wouldn't be covered under fair use anyhow. It's the somewhere between the gray areas of whistleblowers and parodists.

    If anyone wants to "steal" this for use in actual code, they deserve every copyright suit coming to them.

  • crutax (unregistered) in reply to ToAshamedToName

    That was my LOL too

  • BobbyB (unregistered)

    I used to love it when I was told as a consultant that they were 'going with an Indian company.' I'd say, "See you in six months" and almost never was turned away a second time.

  • Darek (unregistered) in reply to steenbergh

    When some sort of solar winds/cosmic rays/little green men change the string before parsing

  • Pete (unregistered) in reply to aristos_achaion
    aristos_achaion:
    luis.espinal:
    But there aren't any clean alternatives in Java.

    Couldn't you just use regex matching to match a string to "\d+.?\d*" or similar? Or, for integers only (as here), just "\d+"?

    In Java Integers/ints are signed 32 bit values, and the strings which can be parsed using Integer.parseInt can have a leading '-', and any number of leading zeros (after the minus if present). You get a NFE if the value parsed would exceed Integer.MAX_VALUE or be less than Integer.MIN_VALUE. As the max and min are different in value as well as sign, the regex has around 20 different branches ( if the first non-zero digit is 2 the next digit must be 0 or 1 or there must be fewer than 10 non-zero digits, and so on through 2147483647). I wouldn't want to hazard a guess on whether testing that lot with a regex is actually any more efficient that catching an exception.

  • Pedro (unregistered)

    Brother,

    This is what happens when you have a CTO that doesn't code anymore. They fall for the fancy words and the cost savings that will occur with outsourcing. As usual they find out you get what you pay for. My advice, start looking for a new job. This CTO will throw you under the bus and won't even realize it.

  • Damo (unregistered) in reply to Rodney

    its a matter of style. coding is like art and when its crap you know it. I believe that a good method should have one entry and exit point. Too many returns reflects that the programmer has not fully followed the logic from start to end, from the begining of the function to the end of the function, with all conditions tested for.

    we could have recoded the above code to this:

    var zRetValue = false; if (a == b){ zRetValue = true; } return zRetValue;

    simple! one return point and the returned value gets set along its execution path.

    KISS

  • Ben (unregistered)

    Log driven development is a perfect excuse for not having any unittests!

  • VR (unregistered) in reply to ToAshamedToName
    ToAshamedToName:
    Ok so logging each call to isValidNumber() is a wtf, but isn't having a paramater of type Integer also a wtf? Won't the call to the method fail if anything but an integer is passed?

    Parameter of type Integer is not 'a' wtf... it is 'the' wtf in my opinion. Logging asid, you're taking an Integer, calling toString and then parsing the resultant string to see if it's a valid number? WTF?! :)

    I guess most people are talking about logging because they didn't look at the parameter type and assumed it would be a String. I don't blame the. It would be really hard to imagine someone doing the above... LOL...

Leave a comment on “isValidNumber()”

Log In or post as a guest

Replying to comment #:

« Return to Article