Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

We are now officially living in a 64-bit world



  • TorvalTorval Member LegendaryPosts: 20,627
    Quizzical said:
    Cleffy said:
    You can process more data 64-bits at a time than 32-bits at a time. A 64-bit float is also more precise than a 32-bit float. Of course a 64-bit float really isn't something necessary for consumer applications. It's really an edge case for certain types of precise computations
    Programmers commonly use doubles (64-bit floating-point) just so that they don't have to stop to think about whether a float will be sufficient precision.  And then sometimes find a creative way to do something stupid so that a double isn't sufficient precision, either.
    I can second the fact that doubles are seen as a default.  I've started taking classes towards an IT degree and the material and professor always use doubles whenever integers aren't sufficient.

    It spent like one paragraph explaining the difference between float and double, then discarded float completely.
    In school that's fine. In real world it's not really. There is a lot to it. If you're really interested in the craft join some coding communities (like reddit subs - there are others) and you can have real discussions on best practices in context. Consider that "doubles being a default" is only true for some languages in some specific contexts. There is a big world out there where that statement is not only wrong, but even when it could be true is a horrible practice.

    You can write a "32-bit" application and target the binary for 64-bit operating systems in a weakly or implicitly typed language. Be super careful about using always and never except to say that never is always never true and there are always exceptions to everything except the exception of where there aren't any. :lol: Have fun in your new IT direction from whatever your previous tech path was.
    Fedora - A modern, free, and open source Operating System. https://getfedora.org/

    traveller, interloper, anomaly, iteration

  • ScotScot Member LegendaryPosts: 14,170
    "In school that's fine. In real world it's not really."

    A truism from Torval. :)

     25 Agrees

    You received 25 Agrees. You're posting some good content. Great!

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

    Now Doesn't That Make You Feel All Warm And Fuzzy Inside? :P

  • RidelynnRidelynn Member EpicPosts: 7,143
    edited October 2018
    I do find there is a great divide between coding for school, and coding for work (and coding for hobby, fwiw).

    I don't code a lot - my degree is in IT, I do occasional database or scripting work to support my work, but I don't code as my primary job. It's just a tool that occasionally I get to dust off. I am pretty bad at it, especially by academic standards. 

    Academic world - elegance and efficiency count for a lot. Clean, well documented code that executes efficiently... even if it takes you hours upon hours to generate that code.

    At the workplace - your getting paid by the hour for results. That doesn't mean that clean, elegant code isn't desired, but there's definitely a tradeoff between the cost to set your butt in a chair and polish code, versus pushing something quickly that just brute force works.

    Even outside of code, for all our projects, we have three metrics we use to judge:

    First, it has to work. I don't care how efficient it does it, or what it looks like, or anything else. If it can't fulfill the job requirements and specifications, then it fails. This is usually the hardest hurdle to overcome, especially if you are doing something that you can't just buy an off-the-shelf part to accomplish.

    Second, it should do so efficiently as possible. Efficiency counts against multiple metrics here: cost, speed, energy, manpower, etc. If two widget makers both complete the same task, but widget A does it twice as fast, or with half the cost, widget A wins the bid.

    And finally, it should look pretty. People like pretty things, and two widgets that are otherwise functionally equivalent, the prettier one gets the nod.
Sign In or Register to comment.