The Joy Of Programming

The Joy Of Programming

In Feb issue of Linux for You (http://www.linuxforu.com/index.php) magazine Joy Of Programming column, I
mentioned a floating point problem:
"Since the floating point arithmetic is not accurate, the operations can result in loss of precision and rounding errors.
In the loop, when the value of f reaches 16777216.0, adding one doesn’t increment the value of f by one, but gets
rounded off.

You can verify it with the following code segment:

float f = 16777216.0;
assert(f == (f + 1));

This doesn’t fail with an assertion failure and works fine!

"An astute reader observed that, if we change f + 1 to f + 1.0, it does fail!
The reason is that 1.0 is a double value. f + 1.0 becomes a double expression, which results in the
value 16777217.0, and hence the assertion fails.

Note that the code here assumes that the compiler is in C89 mode. In K&R mode, all floating
point operations are done in double, so the assertion will fail!

What can simple software problems do? It can cause even a rocket mission to get aborted, as happened with Ariane5 accident:

http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html

"The internal SRI software exception was caused during execution of a data conversion from 64-bit floating point to 16-bit signed integer value. The floating point number which was converted had a value greater than what could be represented by a 16-bit signed integer. This resulted in an Operand Error. The data conversion instructions (in Ada code) were not protected from causing an Operand Error, although other conversions of comparable variables in the same place in the code were protected.

The error occurred in a part of the software that only performs alignment of the strap-down inertial platform. This software module computes meaningful results only before lift-off. As soon as the launcher lifts off, this function serves no purpose."

Conceptual simplicity is something very important in the modern, complex, maddening world .
I thought about this when I just got a chance to take a look at the pascal sources:

http://invent.ucsd.edu/technology/cases/1995-prior/SD1991-807.htm

Its so compact and clear considering to the contributions and advancements it made in
programming languages/compilers!

Lack of support for decimal arithmetic is a painpoint for commercial software implementations.Put simply, the existing ieee 754 standard for floating points isn't much suitable for representing realworld decimal values (in other words, using binary floats with base 2 is not preferable, a float representation with base 10 is better).

Languages currently have not-so-good alternatives. C# supports the decimal type as a primitive type (borrowed from SQL). This type occupies 128 bytes and provides higher precision. It can be valuable in monetary calculations where it is necessary to represent exact values. For similar functionality, C++ provides the long double type (but don’t be mislead- implementations provide its supportthro following IEEE extended precision fp standard). Java provides the java.math.BigDecimal class- that’s much better; but since no H/W support is there, and all values calculated, the application will perform terribly slow if BigDecimal is used extensively. There are a few proposalswith IEEE for decimal arithmetic, and if its approved, things will be much better.

C99 provides a new meaning for static, consider:

void bar (int b[static 100]);

This is to ensure that bar will take an array argument which is promised to have size 100 or more. This is an optimization hint for the compiler (those that do vectorization).

The Standard C++ library has got a new TR1 (Technical Report 1). There are major additions to standard library with this (though TR1 is not part of the standard yet). Major components added include shared_ptr (and its relative weak_ptr), unordered associative containers, c99 compatibility features, tuples etc. Here is a small Q & A on questions you might have on TR1.

Q: A weak_ptr is for avoiding the shared_ptr circular reference. How can we ensure that the resource isn't freed when accessing a resource through a weak_ptr.
A: When we use a weak_ptr to access a resource when use_count might become zero, we can use "lock" function.
weak_ptr::expired() is the function that can be used to check if the memory resource has got freed or not.

Q: How to get a legacy C array out of a tr1::array?
A: Use array::data() function to get the equivalent C-style array from a tr1::array.

Q: Since using tr1::array is recommended over using legacy C style array, will it result in more type_info objects added to the object file and that the object file will become bigger?
A: type_info objects are per-class datastructures, so its unlikely that it will result in any significant change. Moreover, tr1::array is not polymorphic, so a compiler need not put type_info objects in the object file.

Q: What are the compiler changes that will be needed to accommodate TR1?
A: The C99 changes compatibility addition to TR1 for math libraries is one. If there are any other changes needed are not clear yet, but its unlikely that any changes will be needed.

Sometimes, I am just amazed by the power of the C++ standard library. Check the following simple
code:

#include
#include
#include
#include
using namespace std;

int main() {
ostringstream out(ios_base::in | ios_base::out);
ostream mycout(cin.rdbuf());
out << mycout.rdbuf();
printf("%s\n", out.str().c_str());
}

It reads the input, copies the output to the temporary ostream object. Then it puts whatever in the ostream to a string stream
and then, uses printf to get the underlying C string and put it in stdout. Another variation of this program is this:

#include
using namespace std;

int main() {
cout << cin.rdbuf();
}

This copies the standard input to stdout. The performance is also very good, comparable to the similar program written
with low-level C routines!

# posted by Ganesh @ 12:57 AM 1 comments

I (like many others) don't believe in rating programming languages, but it is still intructive/interesting to see whats happening in the programming language community. Recently, I saw one such rating in http://www.tiobe.com/tpci.htm.

Interesting to see C rated much higher than C++.

"October Headline: ColdFusion enters Top 20

The TIOBE Programming Community index gives an indication of the popularity of programming languages. The index is updated once a month. The ratings are based on the world-wide availability of skilled engineers, courses and third party vendors. The popular search engines Google, MSN, and Yahoo! are used to calculate the ratings. Observe that the TPC index is not about the best programming language or the language in which most lines of code have been written.

The index can be used to check whether your programming skills are still up to date or to make a strategic decision about what programming language should be adopted when starting to build a new software system...."

Position (Position) Programming Language Ratings (Ratings) Status

1 Java 21.871% +4.82% A
2 C 18.773% +0.60% A
3 C++ 11.820% -3.75% A
.
7 C# 3.462% +1.82% A
.
14 COBOL 0.859% +0.15% A
15 Lisp/Scheme 0.665% +0.23% A-
16 Fortran 0.640% +0.28% B
17 Ada 0.590% +0.23% B
18 Pascal 0.567% +0.10% B
.