Posts Tagged ‘Programming Principles’

Auctioning Algorithms : for those who design algorithms!

In Education, Research and Development on April 20, 2017 at 4:56 PM

The Algorithm Auction was the world’s first auction of algorithms in 2015. This auction was meant, like most other auctions, to celebrate something. In this case, it was the algorithms (in the form of code) that can be considered artsy. Organized by Cooper Hewitt, Smithsonian Design Museum and Artsy, the auction brought together vintage items like hand written and signed code of the original Hello World C program by Brian Kernighan, a very compact Perl code (6 lines and named qrpff) that could decrypt content on a DRM protected video disc etc. The qrpff code fetched 2500 US$.

I had only heard about auctions of cellular spectrum, houses, historical artifacts and vintage collection items. The auction of algorithms was the idea of a company by the name Ruse Laboratories which it seems has ceased to exist. I could not find any good reference or website. Nevertheless, I think that this was a wonderful idea. Looking for art in science and technology is very interesting. I had organized a thematic issue around this subject in the Nov-Dec. 2016 issue of IEEE Potentials.  This auction goes to prove that a curious mind can come up with really novel ideas and open up doors for others. My friends who design algorithms have something more to cheer about!

Do you read User Guides?

In Design Methodologies, Education, Embedded Systems, Engineering Principles, Research and Development on May 14, 2014 at 6:32 PM

I am a member of LinkedIn and like many of you am also a member of quite a few LinkedIn groups. The good thing about LinkedIn groups is that the discussions remain professional in tone and content. This is why I like them compared to discussions on other social media platforms where they can vary in tone and content from the most professional to the most ridiculous. In a discussion on such a LinkedIn forum meant for engineers, someone admitted that very few engineers or users of tech tools read the user guides. This is not far from reality. I have seen this when I interacted with practicing engineers on a more regular basis than now. I also see it in academic life.

Personally, I find user guides of development boards, software and hardware tools extremely useful. Reading them once gives me enough confidence in extracting the best out of these tools. For instance, user guides of FPGA vendor providers are very helpful and I am more confident about my design after having referred to the user guide at least once though often these guides can be voluminous. I guess the verbosity of these guides is one main reason why people don’t feel like reading them. The other reason, I think, is the propensity of many practicing engineers, graduate students and others to get  their hands dirty as soon as possible. They want to write code, design a circuit, run simulations etc. without getting bored reading these guides. While this enthusiasm to start working is worth appreciation, ignoring the “reading” part leads to problems later on in the product development process, research methods and has the potential to creep into the results. Basically, this haste leaves one vulnerable to questioning at a later stage. Sometimes this can prove very costly as well especially if it is related to product development. Of course one can always talk about pressure for results from managers, supervisors, customers etc.; this is not a very good excuse. Good managers etc. also understand the importance of being abreast with background information.

Is this issue observed more in the engineering industry than say banking or insurance sectors or for that matter safety critical engineering domains? Perhaps. Engineers take great pride in fixing things. They can use patches for software, make new releases, change components or simply replace the product.  However, bankers and insurers cannot do much once money is gone. The fear of losing money is too great to sustain the dislike for reading guides, whitepapers etc. Similarly those involved with safety critical engineering domains are more mindful about liability issues that aversion to poring over thick user guides is probably a non-issue.

One can also argue that  the presentation style of many user guides is quite boring. I agree when you compare with things that provide “instant thrill” thus leading to a desire to know more. User guides do not provide that thrill but writing code, experimenting with a development board etc. does give a lot of thrill to many engineers. Nevertheless, when it comes to getting a job done properly, there is no other choice but to sweat it out! 🙂

What is optimization?

In Design Methodologies, Embedded Systems, Engineering Principles, Mathematics on April 15, 2013 at 12:04 AM

Perhaps optimization is the most abused word in all of research, engineering work or any task that seeks to maximize some intent. The Merriam-Webster dictionary defines it as “an act, process, or methodology of making something (as a design, system, or decision) as fully perfect, functional, or effective as possible; specifically : the mathematical procedures (as finding the maximum of a function) involved in this”. We can hear about optimizing power, area, a  performance metric like latency etc. Many people pass of every design decision as an optimization strategy. While such decisions may contribute to local optimization, they may fail in achieving global optimization. In fact such optimizations may actually degrade performance when the software or the design is used in a context which was not anticipated or thought of by the original developers. Read here about some insight into optimizing a memory allocator in C++.  You will find another debatable example of optimization to make software run faster here. And here is a nice article on efficiency versus intent. Typically optimization is associated with increasing the efficiency of a design (hardware or software) in some aspect. But such optimizations should not destroy the intent of the design. This requires a bit more analysis on part of the designer/developer to ensure that the intent is not lost. Here is another example.

The field of mathematical optimization, which is related to selecting the most appropriate choice (that satisfies a given set of criteria) from a set of alternatives, is vast and varied. There are numerous techniques suitable for different kinds of problems. You can see the list here. Frankly, it is a tough job to recommend one of these techniques for non-trivial problems. One needs to understand the nature of the problem in detail to make a just recommendation. Understanding the nature of such problems or modeling such problems in a way which is suitable for any of these techniques to be applicable is a non-trivial task. It requires a lot of theoretical and practical insight.

Relearning addition

In Design Methodologies, Education, Embedded Systems, Mathematics on March 22, 2013 at 7:13 PM

Alvin Toffler in his book “Future Shock” says that  “The illiterate of the 21st century will not be those who cannot read or write; they will be those who cannot learn, unlearn, and relearn“. Taking this quote a little out of context in which Alvin used it, I would say that the process of learning, unlearning and relearning basically embodies the principles of evolution and adaptation. And these are equally applicable to education. Are these emphasized enough in universities and schools? Can they be taught? May be yes, may be no. I will give one simple example here. Every electronics or computer engineer would have done some basic C programming. To add two numbers, A and B, one just needs to use the expression ‘A+B’. Does it always work? Not in the world of computers where one has to deal with overflows and underflows. And there is always a limit to the biggest number that a computer or a computing platform can support.

So, how are we going to add two arbitrarily sized positive integers. Examples of positive integers are 123456, 90913456 etc. I will use positive integers to illustrate ‘learn, unlearn and relearn’. The example can easily be extended to other data types. In C language, the integer data type can only support a maximum value of 2,147,483,647 when adding two numbers. So there is an overflow if sum exceeds this value and addition is not possible if either A or B is bigger than this value. To avoid this, one can use other data types supporting greater number of bits until one hits yet another ceiling. After a point, you hit the final ceiling. If the numbers are really so big, one way to deal with them is to go back to our old school days when we learned to add numbers: 2 digits at a time with a carry propagated. Yes, that is all you need to do! And this does not require in-depth of knowledge of various IEEE methods to represent numbers. It is simple and good old school method. Of course, the old school method may not have a very wide application, but it does help where possible and makes it clear that  the symbol for addition “+” (or the add operator as it is referred to in programming languages) should not make us forget how addition is done. We “learn” to add 2 digits at a time in school, then we learn to use the “+” operator in programming languages. Thereafter we have to unlearn this concept to relearn (or recall) the school method.  I have written a reference implementation in C which you can find here. You can also find its link under the software tools tab here.

Error Documentation: Why not?

In Design Methodologies, Embedded Systems on August 27, 2012 at 12:48 PM

I am sure that many of you who have used any software tool that throws up errors have spent time (at one point or another) figuring out what those errors mean. Every software tool that is used in any electronics or software design project throws up errors. Be it is GCC, EDA tools etc. One might have used the support channel of the vendor, user forums, websites like stackoverflow etc. to understand the meaning of those errors. A number of times, these errors do not make any immediate sense to the user. There are also many errors which can be because of multiple reasons. Once one gets a list of these reasons, one has to choose the one that is most likely to be applicable to the case at hand. All this reduces productivity. The time spent searching, gathering and analyzing information could have been better utilized focusing on design. Would it not be better if tool vendors also released documentation on the different kinds of errors that their tools might throw up and the associated reasons? I believe that this “ready-reference” would be very beneficial. After all during the development of those tools, the vendors are indeed aware of why a particular error has been thrown up. Why not just compile all that information in one place and help the user? Also, the errors are not always due to problems in the design source files. Sometimes they are there because the tool expects the user to structure the project, tool inputs etc. in a certain way. Given the complexity of modern EDA and other development tools and the time spent in learning them for effective use, it would only be welcomed if vendors offered this extra level of documentation.

Teaching Productive Programming

In Education on June 19, 2012 at 11:29 PM

The past semester (Jan-May 2012), I supervised a lab on Data Structures and C for 1st year undergraduates. It was a good experience. The students were very bright and they all did well in their assignments. Recently, I have been doing quite a lot of programming related to electronic design automation as part of my research to test some of our proposed algorithms etc. I came to the realization that while many students are taught programming with a heavy focus on improving their programming skills (smaller code size, faster implementation etc.), there is a lack of focus on teaching them how to manage large codebases. When these students will go out to work in the industry, they won’t be writing just one program, they will be writing many as part of just one project. Understanding how to keep code modular by splitting into multiple source files, a few header files  etc. is very important. It also helps in code reuse, which unfortunately is grossly underemphasized in universities but is a huge practice in the industry. Writing code that can be reused requires skills in including proper comments in code, meaningful naming of variables and functions, maintaining proper code documentation. While some of these are dealt with in pieces here and there, it is important to let students see and apppreciate the need for this process. Reducing effort and increasing productivity is another important issue that is underestimated in teaching. These two need not always be equated with superb coding skills. The ability to write makefiles and compile multiple source files using them, keep directories clean, have separate release and build directories, understand the need for bug tracking systems (like bugzilla etc.) and sourcecode/project/file versioning systems (like Tortoise Hg, Tortoise CVS etc.) are important for a successful, clean and productive project development. Many of these abilities are equally appplicable to both software and hardware development exercises. Things like versioning systems, bug tracking also help in understanding how people work in teams. It is all about team play when it comes to conceptualizaing, designing, building and shipping a product in the market. Take a look at the team size chart in a typical high end product development team (which itself is a combination of multiple sub teams) here and convince yourself!

Comment About Code Comments

In Design Methodologies on March 31, 2012 at 11:48 AM

Anyone writing a program in any programming language is encouraged to add comments to the code. Comments help in understanding code. Well yes, this is true as long as the programmer and a reader of a piece of code understand the language in which comments were added. Understanding any programming language is not difficult. They require one to know English. That’s all! However, code comments could be in the native language of a programmer. This is where lies the problem in understanding code comments (besides the usual case of ineffective comments). Code comments in Spanish would be of no use to a non-Spanish user/reader. Shouldn’t there be a universal language or way to add comments? Or, should it the be the case where comments c0-exist in multiple languages: native language of the programmer as well as in English,the universal language of business? Programmers may find it easier to understand comments in native languages (like Spanish, French etc.) while others may find it easier to understand if they were in English. I think that comments should serve both the original developer/programmer as well as anyone else who reads them.