There are many open questions in complexity theory concerning "a deeper reality below the one we perceive" that may be relevant, even fundamental, to Yannis Papakonstantinou’s Viewpoint "Created Computed Universe" (June 2015). Suppose our own familiar universe is indeed a simulation and not the best of all possible universes at that. If the exponential time hypothesis is true, the entity running the simulation might defend itself against ethics charges of simulating a non-optimal universe by pointing out it cannot find the optimal parameters for such a universe without effectively running a large number of simulations, most of which would be launched with non-optimal parameters.
Now suppose the exponential time hypothesis is false. An entity wishing to find a reasonably accurate value for the probability that the Allies would win World War II, over some given probability distribution for the initial state, could use approximate counting and a sub-exponential SAT solver to compute an approximation to this probability in a time much shorter than would be required to run enough simulations to gain the same amount of accuracy, perhaps under the assumption there are good local approximations to the simulation outcome in some sets of parameter options. It could then argue it was working at a more abstract level than such simulations that might be regarded as gratuitously violent to their simulated occupants, as they were not necessary to solve the problem of calculating the probability of victory.
A.G. McDowell, Chippenham, England
Let Programmers Copy Code Between Languages
In his letter to the editor "When Software Is Not Protected by Copyright" (June 2015) on Pamela Samuelson’s Viewpoint "Copyrightability of Java APIs Revisited" (Mar. 2015), Marc K. Temin said, "… the Java APIs were new, and their creation was not dictated by compatibility requirements of other programs." While this assertion was true in one sense, as compatibility with programs was not required, the Java APIs were in fact partially designed to match standard C libraries; for example, according to Java documentation, the sole method, compareTo, of a Java interface called Comparable returns "a negative integer, zero, or a positive integer as this object is less than, equal to, or greater than the specified object." The manual page for the qsort function (the function was defined in the sixth edition of Unix, released May 1975) said the last argument to qsort is a pointer to a function that returns "an integer less than, equal to, or greater than 0 according as the first argument is to be considered less than, equal to, or greater than the second."
The Java method Math.atan2 returns the arctangent of its first argument y divided by its second argument x, the same calling convention used by the C library function atan2. The calling convention used by C is not the most natural one because the C function is intended for conversions from rectangular coordinates to polar coordinates. It would have been more natural in retrospect for x to be the first argument, not the second, due to the traditional ordered-pair notation for points in a two-dimensional space. Yet those who designed the corresponding Java class chose compatibility as a more important goal than correcting what is arguably a suboptimal option.
Meanwhile, the API documentation for the Java class Formatter says, "Formatted printing for the Java language is heavily inspired by C’s printf," a statement not surprising to those who were at Sun Microsystems when Java was first released in 1995. Nearly every programmer at Sun used C. Keeping similar interfaces consistent between the libraries of the two languages reduces the learning curve, which was, and still is, important for gaining programmer acceptance. Consistent interfaces almost certainly reduce the number of bugs resulting from programmers switching between the two languages many times per day, perhaps due to using the Java Native Interface. It is all too easy to inadvertently use the other language’s calling conventions. Regardless of legalities, reducing bugs delivers enormous benefit to society by making software more reliable and cheaper to develop. If copyright law does not allow such copying (where the main goal is to reduce complexity for programmers), then the law on software copyright as applied to APIs should be changed.
William T. Zaumen, Palo Alto, CA
Why Indian Female CS Representation Is Different
I hope Roli Varma’s and Deepak Kapur’s article "Decoding Femininity in Computer Science in India" (May 2015) opens a wider discussion on women’s participation in CS education and career development, which is generally U.S.-centric. As someone who has worked in the IT industry, been involved in campus recruitment, taught CS undergrads, and counts many relatives pursuing the CS discipline, I would say underrepresentation of women in CS is nation- and society-specific, and certainly not universal.
Since 2000, the Indian software industry has grown significantly, and the local need for CS professionals is strong. Large companies (such as Infosys, TCS, and Wipro) continue to recruit thousands at the entry level. Other sectors of the Indian economy are nowhere near in terms of job opportunities for fresh graduates. At the same time, opportunities for studying medicine, a traditional goal for high-achieving female students in India, remains restricted and costly. Female students who achieve academically at the high school level thus increasingly opt for CS undergraduate programs.
Most Indian families do not know what constitutes a CS or IT job but assume it pays well and takes place at a desk in a nice environment and IT professionals get to travel overseas, thus influencing university students’ options in case they choose engineering. Before the software boom, girls who aimed for engineering, mainly preferred electronics or its related branches. Few girls opted for civil or mechanical engineering, as these disciplines are viewed by Indian families as leading to a physically demanding job generally not confined to a fixed schedule.
Indian universities have seen the ratio of boys and girls in undergraduate CS classes at around 60 to 40, with the same ratio continuing at the entry level in IT companies. In staffing, with more than four years’ service in India-based IT companies, women show less representation, as many of them sacrifice a potential career for family.
India sees notable representation of female students on the merit list in high school exams and even in undergraduate engineering exams. Men dominate staffing in certain roles, including system architects, software engineers, and database administrators, that require deep knowledge and understanding of CS. With intake in entry-level IT positions is trending downward today and layoffs seen for the first time in years, female students are again tilting toward electronics.
Researchers should look into female student representation in CS education in countries that are similar to India. They should also compare representation of women at senior levels and in deep technology roles in CS and IT in the U.S. with other countries. Over a long career, I have seen IT education and jobs in India continue to emphasize performance, with no caste factor in any discussion, evaluation, appointment, or achievement.
NK Mehta, Bangalore, India
When Enough Is More Than Good Enough
Logan Kugler’s news story "Is ‘Good Enough’ Computing Good Enough?" (May 2015) reminded me that such a heuristic approach to reasoning and computing is fundamental in software development. As young students of computer science and software engineering, we were taught the "absolute perfection" of our work products is an elusive goal due to the fact the development process of any meaningful algorithmic solution is both iterative and optimizing.
Although seemingly amateurish, iterative refinement of "Hello World" can actually produce a useful product. But client needs evolve, affecting the desired baseline of product features. Even when a software product’s change manager says, "No more!," thus fixing the requirements, what the client ultimately needs and wants is inconsistent with what developers can deliver during a given development cycle. Although verified and validated based on an agreed feature set, the work product is inevitably less than perfect.
"Good enough?" is a question all developers should ask themselves when faced with an eternal stream of demands. They must prioritize, assess delivery requirements, and estimate the effort associated with each activity. When overwhelmed with requests, they should "punt" on some tasks and accept the consequences of not completing them. This "Aw, forget it!," or AFI, algorithm, reducing one’s work burden, is necessary for preventing developer overload. When the flow of tasks is arithmetic, logic-unit computations, or Web-server requests, quality-of-service requirements might not ensure each instruction or query is processed.
The topic of computing "just when needed," or JWN, arose during an Omaha-area Java User’s Group I attended earlier this year, spawned by a discussion about processing in the reactive-programming model for Web transactions. The group accepted that any server request, accompanied by a "performance contract" saying how long users expect a Web server would work on it, could let the server decide whether to ignore it. This workload-limiting alternative could greatly reduce a Web server’s burden during peak traffic periods. A process in a low-priority thread could maintain the needed meta-information, including the average work and wait times of available services, for making these decisions. The parallels with work Kugler described are interesting in that the goal of processing is not "perfect" but "acceptable" performance.
Considering that research is really "re-search" and "re-evaluation" of existing ideas, the AFI and JWN concepts are indeed nothing new. Developers with similar academic training draw common conclusions, and most research is really only a rehashing of old, fundamental, abstract concepts. As a superset of AFI and JWN, the "good enough?" concept is archetypal in all areas of processing. It reduces energy consumption in a server’s circuits, as well as in the brain’s organic neural networks. Saying "Good enough!" not only means it exceeds "good," it even approaches "perfect completion."
Jody Sharpe, Omaha, NE
Join the Discussion (0)
Become a Member or Sign In to Post a Comment