in reply to Re^2: How to convert between decimal and binary for negative numbers?
in thread How to convert between decimal and binary for positive/negative numbers?

Yes, of course, I agree. If execution time is really critical, then I can easily believe that pack is faster, I have observed that myself quite a few times. But if execution time is not so crucial, then I would say that the time you spend writing relatively complicated subroutines using pack and unpack might not be worth the effort. An hour of a developer's working time is worth many many many CPU cycles. But this is of course your decision, based on your knowledge of the process.

Writing the examples above using printf took me probably about 5 to 6 minutes, perhaps even less, I know that using pack will probably take me hours, because the syntax is quite complicated (or perhaps because I don't master it well enough, but that does not really change the net result). Being an independent consultant, I know what my time is worth, and I know that I will go for the smaller developer's time consuming option, except if high performance is really badly needed.

Oh, and BTW,the solution I offered seems to work also with negative integers.

Replies are listed 'Best First'.
Re^4: How to convert between decimal and binary for negative numbers?
by BrowserUk (Patriarch) on Sep 19, 2014 at 00:02 UTC
    An hour of a developer's working time is worth many many many CPU cycles.

    True! But ...

    If the code the programmer spent that 1 hour optimizing, saves 1 minute per run; and that program is run by 60 users, once per day; and the program has a life expectancy of 3 years; we get:

    60 * 48 * 5 * 3 = 720 hr/year saved by the users.

    Now imagine this is used hourly (say email, or inventory, or CMS, or...) by half the employees of a moderately large company -- say, 10,000 employees -- then that hour of investment saves that company 5,000(people) * 8(mins/day) * 5(working days/week) * 48(working weeks/year = 9,600,000 mins = 160,000 hrs = 20,000 work days = 4,000 work weeks *every year* of its usable life time.

    Programmers are so in love with the idea that their time is valuable and expensive, that they completely forget (or ignore) the most important fact about software: whilst it is expensive to write, it is extremely cheap to replicate; and it ends up being used by 10s, 100s, or 1000s; and in some cases, 100s of 1000s of users.

    That multiplier effect makes programmer time a very cheap commodity in the bigger picture.

    According to this, it is estimated that (as of 2014/05/11) there are still just under half a billion people still running Windows XP. According to one set of figures I read, but cannot currently locate, there have been something like 3 billion copies of XP sold since 2002.

    (With apologies to John), Imagine ...

    That MS programmers had taken the time to optimize the boot procedures for XP, and cut the start-up time from ~30s to 15s. Being conservative, saving just 15s/day for an average of 1 billion people every day for 10 years ...

    How much would that have saved the global economy?

    In the real world, programmmer's time is a capital expenditure -- like the cost of: electricity for a sheet metal press; or napkins for a fast food outlet; or tyres for a trucking company;

    A minor capital cost of doing business.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      I agree, BrowserUk, that's why I said to the OP that it was her or his decision, based on her or his knowledge of the process. Most of the programs I write nowodays are run typically once per month, but, on the other hand, they handle very large volumes of data (usually tens or hundreds of GB) and may take long times to run. I have to make sure my programs are efficient, to make sure that they don't take days to complete, and I take great care making my algorithms efficient, and that can make quite a large difference (and that is important to me because the people running my programs are often part of my team), but, on the other hand, gaining a few seconds on a micro-optimization is not worth the effort if the rest of the program is taking 2 hours to run. Sometimes, on the other hand, a micro-optimization is a real win, for example if it applies on an operation that will be executed billions of times. I had a couple of cases in the past year where it really made sense to think at the micro-optimization level (and at least one case where I changed from a regex to unpack), but most of the time it does not cxut a real difference. Again, the decisions to carry out optimizations should be based on a good knowledge of the business process; sometimes they are really woreth it, sometimes not.
Re^4: How to convert between decimal and binary for negative numbers?
by thanos1983 (Parson) on Sep 19, 2014 at 11:43 UTC

    Hello Laurent_R,

    You are absolutely right about the time, it just dose not worth it spending time to make your code executing faster and faster. Unless performance is really something so so critical.

    The reason that I am trying to make my code run faster and actually playing around with pack and unpack is that I still learning. I am trying to get the most out of it by testing any possible aspect for future reference. At the same time when I found a good solution I tent to keep it in my database so I can easily recover it when needed and just applied it with small modifications.

    The truth is that I still found my self reading and spending hours for something so small and sometimes so stupid that I do not really know if it does worth it. But as I said I am still learning so I tent to believe that I will stop doing that in future.

    Again I want to say thank you for your time and effort reading and replying to my question.

    Seeking for Perl wisdom...on the process of learning...not there...yet!