142

Coding level: jedi master

Comments
  • 25
    It's easier to write a script that writes this shit than writing this shit.
  • 4
    KLOCs! It's all about the KLOCs!
  • 12
    There are actually cases where this is the fastest implementation.
  • 2
    It did exactly that well, almost that, in some c++ code than ran as part if the graphical rendering in a game. It could only do it for a max of 5 digits but i couldn't think of a faster solution.
  • 0
    Probably a dumb solution to the nightmare and idk how efficient it is, but wouldn’t it be easier to cast the long var into a string, and then just get the length of the string?
  • 3
    @Japorized easier but not faster.

    A log10 is also simple.
  • 6
    This should probably work (pseudocode)
    1 + floor(logtobase10(num))
  • 1
    @runfrodorun The ifs are not the problem, but the first comparison in each if is unnecessary.
    I love the conditional operator but I think in this case I would find the if solution more readable.
  • 11
    I wrote a horrible java benchmark which generates a very long long array and measures the time for calling each function 100 times with each element.

    This version: 8878ms
    Log: 581ms
    Division: 31687ms
    Improved ifs: 4357ms

    Also 19 is missing.
  • 1
    Wouldn't the most efficent solution be to just convert the integer to a string (itoa) and getting size of the character array.
  • 0
    @runfrodorun Sorry, my bad. Forgot we are dealing with base 2 to base 10. My excuse is that I usually work with very high level languages so I don't have to deal with this.
  • 2
    Or

    return num.toString().length
  • 0
    @jalebiBhai read above what @runfrodorun just said
  • 0
    Coding level: AI
  • 1
    long getLength(long num){
    return new String( num ).length;
    }
  • 1
    The gist of the comments is...

    Fast: hardcoded solution that dies not use arithmetics or type conversions

    Fast not hardcoded: log or other operations, speed depending on the hardware and language

    Dumb and slow, but sufficient: Most of the other stuff. Eg casting to String

    So. Pick your poison.
  • 1
    @runfrodorun I know what branch prediction is. If one is worried about speed to that extend, one should use assembly in the first place instead of relying on the compiler.
  • 1
    @Scade totally agree with you. A matter of ms on such a high level language it means that the problem isn't the algorithm but the developer and the choice of the technology
  • 0
    I actually came across exactly this Problem once and after a lot of testing I used this Implementation with conditional operators, but the numbers were a bit smaller so maybe logs are better in this case
  • 1
    I know its wrong but I'm fucking in love with this code, soo beautiful 😍
  • 0
    @runfrodorun isn't it faster to do a logarithm? The CPU can probably execute it as a couple of FLOP, compared to loads of IOP in this example.
  • 0
  • 0
    Agree with @runfrodorun answer with ternary operators.
    Slight change to use divide and conquer to further improve time.
  • 0
    Who did this?
  • 0
    @runfrodorun Most of the time that is true, but there is s reason why, for example, most audio decoders have some parts written in assembly. Compilers often fail to generate the most effective implementation, especially when it comes to instruction set extensions like DSP.
  • 0
    return len(str(number))
  • 0
  • 0
    @runfrodorun Teach me Senpai!
  • 1
    @runfrodorun Your right. Log is not necessarily the fastest but if available its short and elegant.

    For extreme performance I would recommend testing for the platform.
  • 0
    @runfrodorun Again, you are right. But there are compilers, which will not make use of all instruction set extensions and that was what I talked about. Nothing more specific. Back to my original point, because I think I didn't express it well: There are some time-critical things, you should not let up to the compiler. Even when you can predict the output, you will not know when it changes, i.e. und a compiler update. If the task is so critical, that you care about the compiler output, I think assembly is the more appropriate tool.
    Anyway, I enjoy the discussion with you. Hope you do the same.
  • 0
    @omom

    I put things into a global perspective and compared the answers.

    Dumb... Compared to the given solutions, taking string length is dumb. It's a brute force approach.

    Slow... Again. Compared to the other solutions it is slower, Frodo and others explained in great detail why.

    I never said anything about hard work. I used the word sufficient to emphasize that it works.

    Assembly... Well... Compilers can nowadays generate faster code than Assembler....

    But again. This was just looking at the solutions given and stating the truth that String handling cannot be faster than the others...
  • 0
    I have to admit, it's kinda beautiful, like ASCII art.
  • 0
    some will do a cast to string then return the length which is also bad ... I'm looking at you high level dudes
    #computersareveryfastnoneedtooptimize #myvmoptimizesforme
  • 0
    i'm pretty sure this can be code golfed; maybe with bitwise operator
  • 2
    Wow I wonder how long it took to write this number length AI!

    🤣 So close to typing that with a straight face
  • 0
    Losta sh!t here there, everywhere.
Add Comment