The International Simutrans Forum

 

Author Topic: Floating point elimination  (Read 6627 times)

0 Members and 1 Guest are viewing this topic.

Offline Bernd Gabriel

  • *
  • Posts: 230
  • Addicted to Simutrans: since 2003
    • Fast Function Factory
  • Languages: DE, EN, C++
Re: Floating point elimination
« Reply #35 on: May 25, 2011, 10:54:49 PM »
James,

there is no method teleport(). The existing code just tries to move the convoy a too large distance. The
Code: [Select]
while(steps_to_do>steps_next  &&  hop_check()) {
moves the convoy to the next tile until hop_check() returns false if reached the next destination, a blocking signal, or ....

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18745
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Floating point elimination
« Reply #36 on: May 25, 2011, 11:19:48 PM »
Ahh, thank you - I think that I see the immediate cause of the problem: the sp_soll value becomes negative in some cases as a result of the dx value becoming negative in the fractional code but not the double code. It is not immediately clear to me why that should be, however.

Edit: I think that I have now fixed the teleporting problem: it was a fraction overflow issue. See my Github 9.x branch for details. I have also recalibrated slightly to allow vehicles to get closer to their maximum speed: the class 121 is now able to go its full 86km/h. (In fact, this speed is too slow for this vehicle, whose real maximum speed was 110km/h, but this is now consistent with 9.5; the problem, I think, is really in the vehicle's .dat file here, as no tractive effort is set, although the default of 15Kn does seem rather low - can this be changed, do you think?).

The problem with inconsistent behaviour in fast forward mode remains, however, as does the issue of a nearly overloaded train (see "physics-test-2.sve") not exceeding 4km/h despite displaying an indication that it should be able to go faster.

I am debating whether to release as is, however, as those are rather more marginal issues than teleporting, although it would be far more satisfactory to fix them. Can you (or anyone else) think of any further final testing necessary before release of 9.6 and stripping out all the testing code?

Edit 2: Another, and somewhat more concerning difference that I have noticed from 9.5 is that acceleration seems to be much quicker, to the extent that a 'bus, for example, will reach its top speed of 50km/h almost instantly in the current 9.x branch. This seems to be a side effect of the changes made to the force calculations to allow vehicles to reach their advertised maximum speeds; yet it appears to affect acceleration, too. In other words, the relationship between acceleration and maximum speeds seems to have changed, which may not be desirable.

One solution might well be to revert the display of maximum speeds to fractional code to make it consistent with the actual code being used for calculating the movement (although did you have trouble with the power function for that?).

Edit 3: Even with the f = (get_force(v * fraction_t(9, 10)) - Frs).shorten(); line replaced with the original f = get_force(v.n / v.d) - Frs; line, the effect on acceleration is still present, albeit less pronounced, but is easily visible in 'buses compared to 9.5. Do you think that you could look into this? This seems to be outside tolerances for acceptable realism from my observations.

Edit 4: The main problem with the road vehicles appears to have been an incorrect specification of the rolling resistance on the road, which I have now fixed in the 9.x branch. However, further tests suggest that the  f = (get_force(v * fraction_t(9, 10)) - Frs).shorten(); modification causes more problems than it solves: it quickens acceleration excessively. Testing acceleration with the original  f = get_force(v.n / v.d) version of that line and comparing it with these data, it seems that the original version is correct (testing with the HST set comprising two HST power cars and 7 Mk. III coaches, one of which is a buffet). Diesel or electric rail vehicles are generally the best for accurate testing, as it is possible to find real life data on both power and tractive effort, whereas, for road vehicles, only power is usually available, and, for steam rail vehicles, only tractive effort is usually available. Interestingly, I have noted that, because some code that was previously integer code is now fractional, the physics is in some respects more accurate than previously. However, this still leaves a substantial discrepancy between the reported maximum speed and actual maximum speed in cases where the tractive effort to weight ratio is low.

Edit 5: Further testing shows that there are still serious problems at higher speeds. The HST test described above I had initially run at a distance of about 10km. At that distance, the acceleration matched the known data very well. I tried it again, however, with a new testing map and a distance of 40km. At that distance, the speed did not exceed 193km/h, whereas it should have reached top speed within about 20km. Testing with 9.5, the same HST set reaches 200km/h (its limit) within 19km, which is more or less exactly right. Something is still very wrong.

Edit 6: Trying to look into this further, I cannot understand where the difference is arising. Breaking the code both in the master branch and the 9.x branch when akt_speed == 2443, I haved looked at the values of v, dx (both before and after the line dx = x_to_steps(dx)), Frs and f, and all are very close (there are slight rounding differences in some values, but none that appear significant, and, indeed, those that there are would suggest greater acceleration, not less). The only number that seems to be significantly different is sp_soll, but that difference appears to come from outside the physics code itself, as the sp_soll value at the beginning of calc_move is where the discrepancy is, and the addition of dx to sp_soll cannot be the source of the divergence because dx itself does not diverge. I am extremely confused and do not understand how to deal with this issue. Any help from anyone would be very, very much appreciated.

Edit 7; Here is the latest testing game that I am using, as described above. One odd thing that I am noticing is that speed climbs steadily and fairly rapidly to 191km/h, and then suddenly stops climbing, whereas, in reality, one would expect the rate of acceleration to decay more gradually.

Edit 8: Further testing has shown that the problem seems to have been in the v_to_speed() method, inaccuracies in which had increasing impact as the vehicle speed increases. I have fixed this now, although the HST acceleration is still not right: it accelerates to maximum speed now in 15km rather than 19km as it should. This is much closer than previously, however, and vehicles now do reach their maximum speeds. This issue, however, does suggest a possible structural issue with the physics code, in that speed is converted into a more precise "v" figure for meters per second every iteration of the code, but is converted back to the less accurate internal units "akt_speed", and the "v" value is not saved between iterations. This has the potential to cause inaccuracies in calculation, and a better approach would probably be for "v" to persist between iterations. This, however, would require the saved game format to be stepped, as this value would then need to be saved.

Edit 9: Reverting the timing changes (const long dt_slice = (DT_TIME_FACTOR * DT_SLICE_SECONDS * simtime_factor).integer();) makes the 9.x branch perform more similarly to the master branch. Road vehicles accelerate at the same pace as hitherto, and the HST takes 17 rather than 15km to reach top speed (although 19 would be preferable).
« Last Edit: May 27, 2011, 09:54:19 PM by jamespetts »

Offline Bernd Gabriel

  • *
  • Posts: 230
  • Addicted to Simutrans: since 2003
    • Fast Function Factory
  • Languages: DE, EN, C++
Re: Floating point elimination
« Reply #37 on: May 28, 2011, 11:44:15 AM »
I created the new class float32e8_t, a floating point replacement for fraction_t.

I think I will try to branch from 9.5 again and eliminiate the built-in floating point with this class to avoid the sources of inaccuracy, which might have been introduced by the previous replacings.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18745
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Floating point elimination
« Reply #38 on: May 28, 2011, 11:50:14 AM »
Bernd,

thank you for your work on this. It seems to be working well enough with fractional code after the latest work on it, but it might be useful to see whether any advantage could be derived from a floating point system. Bear in mind also, however, if branching from 9.5 that there are many changes to the code in 9.6 other than the physics, including some non-float related bug fixes and feature tweaks.