Imagine someone put you in a wheelchair and blindfolded you, then let you reach your arm out and touch a wall. You could tell how far away the wall was, but as long as you were pushed parallel to the wall, how would you know how far you had gone? You can't count steps or see the end of the hall, so you do not have a way to index your samples of where the wall is.
In a similar way, you have handicapped your robot in the simulation. You state you are using aHokuyo URG 04LX, and you also state that your hall is 15 meters long. The range on that scanner is 4 meters, so it cannot "see" the end of the hall and cannot use that information to index its scans. You are also not providing any odometry, so it can't guess where to index the scans either.
SLAM is simultaneous localization and mapping - if the current "image" (scan) looks just like the previous image, and you provide no odometry, it does not update its position and thus you do not get a map. This is true as long as you move parallel to the wall, which is your problem case.
When you advance or retreat from a wall (feature) within range, as you do when you take the sinusoidal path, the images are different from one scan to the next. The algorithm looks for the rotation and translation that yields a "best fit" between those two different images and assumes that the difference between the two was due to motion, updates its estimate of location accordingly, then indexes that scan to the new position.
Regarding the path you are shown, I would look for a range issue somewhere, probably in a tangent expression. Always use atan2 instead of atan whenever possible to avoid errors due to quadrant location; (-y)/x and y/(-x) both evaluate to -(y/x) inside an atan expression but those are two totally different angles. :EDIT: See below, but this may also be due to a lack of features.
RECOMMENDATIONS
Get a scanner that has a range greater than the hall length, OR reduce the hall length, OR start your craft within "sight" of the end of the hall, OR add features such as alcoves/recesses along the hall to give the algorithm a key point with which it can localize and index.
A final note regarding the alcoves: (In Bruges reference) they must be spaced closer together than the twice the maximum scan range because the craft is operating in the center of the hall. Distance to wall (squared) + distance to alcove (squared) = max range (squared). You need a new feature to enter the frame before the old feature leaves, so if the max distance to one alcove is sqrt (max range (squared) - distance to wall (squared)), then the spacing needs to be less than (or equal, if you enjoy pain and borderline cases) double that distance. Finally note that this is assuming your scanner has a 360 degree view and can see the feature behind it until it passes the maximum scanning range. In actuality your scanner has a 240 degree field of view, but I'll let you work that math out on your own.
:EDIT:
With a little further reflection, I don't know that a straight, infinitely long wall (which is what you have if both ends are out of range) is sufficient to provide lateral position estimation. This may also help to explain your weird path. As an easy check, try putting it within sight of the end of the hall without your feature to see if you get the smooth sine you would expect. Then I would add alcoves at the 1x spacing I described above (range^2 - (wall dist)^2) and see if that also fixes it. I would do both of these before hunting through the algorithm for trig out of range errors.
