153
human06
6y

Boy oh boy .... 五 .. look what I came across !!

Comments
  • 20
    Lol coulda just converted to string and .lengthed it :s
  • 4
    You would think so .... But 五
  • 13
    brb gonna puke
  • 35
    This is what happens when you pay developer by line of code...

    (It is the only reason I can see to produce this abortion of a thought process)
  • 5
    @rEaL-jAsE time to send a PR
  • 8
    @hexc I was thinking of returning the integer part of the logarithm but I guess yours is a more understandable solution
  • 8
    Log 10 all the way \o/
  • 4
    it's so bad it's good
  • 1
    @ConnorD totally agree
  • 9
    You may laugh but its the most efficient way to do it
  • 4
    @gnulinuxer4fun I feel like the log 10 trick is faster. Or at least better style, if you made it a C++ constexpr it be best of both
  • 1
    He could have simply returned the log of the input.
  • 1
  • 5
    This is the next step after hadoken code: the pyramid conditional!
  • 19
    A) Repost.
    B) Most optional solution. (Benchmark it.)
    C) Best approach for low-resource scenarios, e.g. embedded systems
    D) Ugly, but considering the above: swallow your pride.
  • 4
    to be honest the thing that triggers me about this code is the name of the function: “numLen”
    Are we not allowed to use full words?
  • 4
    @gnulinuxer4fun floor(log_10(x))==number of digits of x
  • 3
    give a warning for eye cancer
  • 1
    Solution for every programming situations
  • 3
    @Root how is this faster than something involving log10 or even casting to string? Is does log10 involve a cast to floating point that is slower than these bare checks?
  • 2
    @rEaL-jAsE long long is a valid type specifier.
  • 3
    This looks so satisfying, even if it's wrong.
  • 1
    @hexc don't forget to intval it first, then... ;)
  • 2
    Looks like a code we used to make for the exam during the 1st year of college. Hell we knew that lenght function existed.
  • 3
    @Root swallow my pride !!
    Do I need to remind you that this app for ranting !!
  • 5
    You guys need to appreciate more.
    Don't read the code. Just look at it as an artistic point of view.
    Owo! What a nice piece of artwork!
    What I see is 2 mountain inside 3 railroad track.
  • 3
    @shahriyer I know I felt like a hugeass smart OP developer when writing 20 else if lines of code.

    "MOM, I'M CODING!"
  • 2
    Log10 trick lol as if a lookup table andor the calculation of log is faster than sub, followed by some jnz.
    If the numbers had the 10eN style, it'd be pretty and fast.
  • 2
    this is mesmerizing
  • 1
    The program will also crash or misbehave if it gets a number higher than in the last if-statement or a negative one. 不
    I didn't even know that common C++-Compilers allow such methods to compile.
  • 3
    @Root I still would have never done this on an 8bit microcontroller in C. And that thing had low resources.
  • 0
    @rEaL-jAsE not judging from your previous comment
  • 2
    WHYYY

    and this is the 2nd or 3rd time I saw someone here come across exactly this kind of code D;
  • 2
    This has been posted here at least three times already.
  • 3
    @corscheid maybe because we all share things we find funny.. and not everyone have seen what have been shared !
  • 11
    @eeee Consider the assembly a compiler would generate for every approach:

    Raw comparisons:
    The raw checks are only a few instructions per tier. Given the presented code as-is, it would be two compares and two jumps per failed check, plus a move/load and a ret upon success (may differ by compiler and architecture). Also, any number that falls in an earlier block will resolve faster, meaning the theoretical median execution would be around 38 instructions ((18/2)*4+2). The number of clocks should closely mirror ther instruction count; I'm unsure how many clocks a 4-byte comparison takes, however.

    Also, this is before compiler optimizations: All of the first comparisons (save the initial >=0) should simply go away, leaving one compare and one jump per failed check. That lowers the median to 22 instructions ((18/2)*2+2+2). Very inexpensive!

    (The only thing I'm wondering about here is memory paging for the constants; they should be in cache, though.)

    Log10:
    I don't actually know how expensive a log10 implementation would be as I've never needed to use/write one in assembly before, but given the math required, I believe it would be consistently more expensive than the median above.

    Lookup table:
    A log10 lookup table for such a large value range would need to do basically the same checks the presented code is already doing prior to actually looking up the data. It would also have the added overhead of calling it, so unless the program is only ever using a smaller set of numbers, this approach would not help.

    Casting:
    String casting? Are you kidding?
    Try converting 0x100000 to "32" and returning the byte count in around 8 instructions. Go on. Longer strings would have better efficiency, but this approach could never hope to compete.

    -----

    So, save possibly a log10 implementation I'm not aware of, the presented code is definitely the better approach. (Even if it is ugly.)
  • -1
    AAAAAAAAAAAAAHHH FRIGGGINGG FRIGGG EYE CANCEEEEEER

    You guys upvote this thing, he's going to need a stress ball :v
  • 1
    How about x%=10,i++ ?
    @Root
  • 3
    @Root now I'm eager to find out what is a common way to implement log10 on the instruction level...
  • 0
  • 2
    @hch11
    x = 100000000
    X %= 10
    // x is now 0
  • 1
    // @Root
    long long copyThisFrigg(long long x) {
    //{

    if (x<0L) throw FriggYourselfExeption;

    if (x==0L) return 1;//should be 0, drives me nuts, but whatever

    int len=1;

    for( ; x<10L;
    x=x%10,
    len++) ;

    return len;

    }
  • 0
    Just
    Log10 sounds very good but it's some error prone in the float->int casting part, and it's pretty more expensive.
  • 1
    @hch11
    I knew what you meant, actually.

    I wanted to write up an implementation and compare the assembly produced between that and (optimized) hardcoded compares.

    I started to, but got called away on two work emergencies today and just haven't had time.
  • 5
    @Root just been noticing you like assembly. Do you know Compiler Explorer, by any chance?
    https://godbolt.org
    It lets you see the assembly output of a C/C++ and more, and compare different optimization flags, compilers, and even versions .
  • 4
    @aritzh Oooh, I did not. Thankee!
  • 1
    so what? it's absolutely ok to clone a pyramid
  • 1
  • 0
    What in Jesus hell
  • 0
    If you put it the other way up, you can remove the second condition from all of the ifs
  • 0
    @cyclic3 sorry but your comment makes no sense
  • 0
    @electrineer each of the if conditions check the condition below it isn't true. By reversing their order, you can make that condition redundant, allowing you to remove it and half the number of comparisons you need to make, giving a ~2x speed increase with no negative impacts
  • 1
    @cyclic3
    1) you can achieve the same whether you go from low to high or high to low
    2) don't estimate speed increases like that
  • 0
    Spaghetti is worse
    @858master
Add Comment