Showing posts with label university. Show all posts
Showing posts with label university. Show all posts

Sunday, April 4, 2010

Perl and The Time It Owes Me

These days I'm working on a my final Verilog project, where I create a simulator for a basic Verilog syntax (netlist only) in Verilog.

The first stage in creating such simulator is parsing the input .v file into two data structures that contain the netlist and the list of cells in the file. This code was given to us by the instructor, and it's written in Perl.

To gather more knowledge about our design, I've decided to create a Python Verilog simulator, similar in concepts to the one we're going to create and verify that it's behaving like the well-known software simulator that we're working with.

After fixing some small bugs, I've noticed that my code generates some events in one time-unit less than the real simulator. After checking my code again and verifying that no bugs lie there I checked the tables that were created by the Perl script that my instructor wrote, and there it was: one line of a bad parsed data.

The parser takes a line that looks like "bla bla bla 1.974 bla bla bla", parses it using a Regular Expression and converts the number to a floating point number (which is always in the format d.ddd) to integer by multiplying it by 1000 and then formatting it using sprintf() (casting to int using the int() function yields the same results).

Looks fine, ain't it? That's what I thought too, but it seems that there's a floating point error that causes a lot of trouble for specific numbers, like 1.007. Then after conversion you get 1006 and some temporary madness.

If you don't believe me, check the following code:

$num = 1.007;
print "Floating number: $num\n";

$newNum = $num * 1000;
print "Possibly integer: $newNum\n";

print sprintf("Real integer: %d\n", $newNum);

Say it's a bug, say it's a feature, I don't care.

This was tested under Perl 5.10.0 under Linux and Windows.

Update: to clear this out, the problem lies in rounding of floating point numbers, and probably exists in every implementation that uses the IEEE representation format. The solution as I see it right now is to use string formatting "%.0f" to convert the floating point variable to string with rounding and not truncation (that's what casting to integer does) and then convert it from string to integer.

Thanks goes to lorg and Michael for clarifying the real facts.

Update 2: it seems that this "feature" doesn't apply to C, because these numbers can be represented in the regular IEEE standards. Now it's a bit weird to me that Perl and Python act exactly the same (any suggestions?).

Monday, February 25, 2008

80's The Limit


I'm currently "studying" the course "Introduction to computer science" at the university.

Why "studying"? Because I have to, and because I don't really go to lectures because they are boring as hell and useless.

Anyhow, the course has its own coding conventions and style. Most of the conventions are totally fine and agreeable, but there's one that's driving me crazy - "Thou shall not write lines that include more than 80 characters.".
The reason is not specified (as usual here - why specify why to do something when you can just tell the students to do A and B), but I may assume it concerns the 1980's DOS/Amiga/Mainframes 80 chars limit, when working in textual video mode.

So let's count how many graphical operating systems that can display and print lines longer than 80 chars in one line got released by Microsoft(TM) 'till now:
  1. Microsoft(TM) Windows(R) 3.1
  2. Microsoft(TM) Windows(R) NT 4
  3. Microsoft(TM) Windows(R) 95
  4. Microsoft(TM) Windows(R) 98
  5. Microsoft(TM) Windows(R) ME
  6. Microsoft(TM) Windows(R) 2000
  7. Microsoft(TM) Windows(R) XP
  8. Microsoft(TM) Windows(R) 2003
  9. Microsoft(TM) Windows(R) Vista

And they still haven't found the "Change font size" button... too sad.

Limiting line length is good, but why limit it to the ridiculous number of 80? When programming in an object oriented language, creating a line which calls a class method and specifying 2-3 parameters will exceed this limit. So to avoid losing points an evil linefeed needs to be inserted.

The huge problem here, as I see it, is that most of the people studying with me haven't programmed in a real programming language (not Pascal) and doesn't know how a real-life code should look like. This is one of some bad habits they learn in a place that should theoretically teach them everything they should know about programming.

So what's the moral here? Read Code Complete and forget about people who know nothing about programming.