News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

Possible additional calibration mechanism for passenger transport

Started by jamespetts, May 18, 2020, 12:21:06 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Vladki

Just a note to Stephenson-siemens -- I think we did a good work to have the map covered by public transport as much as possible ;-)

Ves

Interresting results, and I would kind of still be profitable, which is a good thing! 😝

I remember we talked about a while ago (years, maybe) that passengers would ignore the waiting time on their first stop, as to simulate them showing up only when they expect a convoy to depart. But I dont remember wether that is actually incorporated?

jamespetts

Some further testing in relation to patterns of visitor success on the Stephenson-Seimens map before and after the changes.

Before



After



As can be seen, although the overall map is a different colour, indicating that fewer successful visiting trips are being made overall, there does not appear to be any stronger patterning in the new state of affairs than in the old.

The purpose of the patterning is to allow the planned town growth mechanism to find the best places to put new buildings on the basis of the transport success of neighbouring buildings, so it is important to have differential data so that the system can pick appropriate places to build. As can be seen, the level of differentiation is very much the same in the before and after versions.

This does suggest that it is likely to be beneficial for the town growth system to use relative visitor success to determine town growth rather than absolute numbers (except, perhaps, for floor thresholds of absolute numbers) so that an essentially fixed rate of population growth can be distributed among different towns on a competitive basis, with those localities with the highest success rates receiving the most growth, albeit in a semi-randomised manner so as to prevent all growth happening in just one location. Other localised desirability data will also need to be taken into account.




Freahk - thank you for link to the German source: that is interesting. I had wondered about walking statistics yesterday evening: it is very important that they be included, as statistics relying only on motorised transport would result in a significant distortion when applied to Simutrans-Extended.

Fortunately, checking the latest UK statistics, I find that this does include walking, so these statistics can safely be used as the basis for the calibration.

As to actual journey times closely matching average tolerances, remember, these are mean averages, so it is possible for a great majority of journey times to be much lower than the average tolerance, but a few to be very high. Also note that the alternative destination system will result in the code effectively optimising for reachable destinations, and, if these destinations tend to be only just within tolerance, one might well see actual journey times matching tolerances, as we do when we reduce the tolerances.




Ves - this system was ultimately rejected on the basis that what counts as the first stop is uncontrollably arbitrary: in the example of a long sea voyage with a very low frequency, people living right next to the dock would use the dock itself as their first stop, and halve the long waiting times of the ships as intended, but people living on the other side of town might catch a 'bus to the dock, and their first stop would be the 'bus stop, not the dock, so this would be unworkable in practice.




One other thing needs to be considered with Marchetti's Constant: that is the relationship between the duration of individual trips and the number of trips made. It will be recalled that the principle of Marchetti's Constant is that there is a fixed travel time budget: people tend to spend approximately 80 minutes per day on average travelling. This means that passengers might make a large number of short trips or a smaller number of long trips, and so the system should replicate this relationship between the number of trips and the duration of trips. The current system does not do this.

A possible solution to this is to multiply the journey time tolerance of passengers by 100 divided by the success percentage of the building in question, at least for visiting passengers: for commuting passengers, the number of trips per day is fixed, of course. So, for example, if a building's visitor success is 50% and the base journey time tolerance generated is 10 minutes, this would be multiplied by 100 / 50 = 2 to get the adjusted tolerance, in this case being 20 minutes. If the success rate were 100%, this would be multiplied by 100 / 100 = 1 (10 minutes). If the success rate were 10%, this would be multiplied by 100 / 10 = 10 (100 minutes).

This would result in visiting passengers from poorly connected areas being willing to take longer trips than those from well connected areas, as one might expect in reality. This would, of course, result in increased success, which would in turn lower the multiplier until an equilibrium were reached.

However, this would also increase journey time tolerances overall, and may require further recalibration of the journey time tolerance figures to get a result that falls within the normal value for Marchetti's Constant.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

Ok. Did we also talk about then that the passengers additionally would "skip" the waiting time of the longest waiting time on the jurney? So that passengers would ignore the waiting time of the first, as well as the longest waiting time. The narrative would be that the passengers know the schedule of all the lines they are taking, and are planning to leave with that in consideration. Although it would probably not be perfect, it would certainly help circumvent the issue you describe.

jamespetts

Ves - I cannot recall that suggestion being discussed, but such hackish mechanisms are almost invariably unworkable in that they lead to manifold anomalies and cause more problems than they solve. For example, this would mean that keeping passengers at an interchange for 10 hours on an urban metro line would have no effect. This would prevent one of the important systems for preventing extreme station overcrowding (of the sort that plagues Standard) from working.

In any event, passengers are inconvenienced by low frequencies even if they can plan their schedules, as the service in question does not depart when they want it to depart, and they are unable to travel at the optimum time for them, so it makes sense to take into account waiting time even in circumstances where the passengers might in reality choose to wait at home rather than at a station.




I have now had a chance to test the mechanism to which I refer above with various skew, minimum and maximum settings, largely on the Stephenson-Seimens server, as this most closely replicates conditions in 21st century Britain that are comparable to the available statistics.

With the mechanism implemented and with the skew/mode set to 7, the minumum visiting time set to 2 minutes and the maximum to 20,000 minutes, we get an average journey time of 40.5 minutes with a success rate of 66%, giving a daily journey time average of 126 minutes per person. Notably, the average tolerance per generated is just 26.3 minutes, suggesting that there are a lot of low tolerance passengers generated who do not travel at all. Thus, the average is getting closer, but I am doubtful that a skew as high as 7 is workable here.

Tests continue...
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Mariculous

Quote from: Ves on May 27, 2020, 07:54:25 AMI remember we talked about a while ago (years, maybe) that passengers would ignore the waiting time on their first stop, as to simulate them showing up only when they expect a convoy to depart. But I dont remember wether that is actually incorporated?
Handling this properly would require a much more extended waiting time system.
If trains are scheduled to arrive only every 2 hours, but they do so all at once, waiting for each other, there effectively won't be any waiting time either.
This can be observed in the real-world quite frequently, but simulating this would be very complicated, thus I'd also consider it to be fair to handle all kinds of transfers the same: Waiting time is half of line frequency, as would be on average if lines arrival times were uniform distribiuted.


Quote from: jamespetts on May 27, 2020, 12:10:26 PMThis means that passengers might make a large number of short trips or a smaller number of long trips, and so the system should replicate this relationship between the number of trips and the duration of trips. The current system does not do this.
That's the nature of working with statistical models instead of actually simulating each single inhabitant.
Thus, it is important to get a fairly well matching distribution. On average, we get many short journeys and few long journeys. If the distribution is selected well, it will result in the same figure as actually simulating each single inhabitant according to Marchetti's Constant would do.
I do not think it's a quite good idea to force individuality into a statistical model. Further note, the number of journeys per day is also an average!
Some inhabitants might do 10 journeys per day to the local kiosk, to buy a single bottle of beer each time, others might stay home for months, whilst even others might try to get around globe using only trains and ships.
So if there is a house spawning 10 very long journeys in a row ba (very low) chanche, that's fine as long as on average the journey time figure fits the real-world.

One aspect on the suggestion is interessting but needs a whole discussion on it's own, I suspect:
Quote from: jamespetts on May 27, 2020, 12:10:26 PMThis would result in visiting passengers from poorly connected areas being willing to take longer trips than those from well connected areas, as one might expect in reality.
I suspect that one is quite difficult to calibrate and it would reduce the effect of a good transport network on the overall passenger numbers.

Imho, such a system would require a different system of private car ownership, which does not follow a fixed figure from the real-world but is instead based on a per-house public transportation reputation value.
There are two thresholds in the reputation: The privatecar_ownership threshold and the niggled threshold.
Any inhabitant above the privatecar_ownership threshold does not own a private car at all. Anyone below is considered to own a car, anyone below the niggled threshold will always prefer the car.

When searching a route, inhabitants will always calculate a private car and public transport route.
They will weighten up expected journey times, congestion and overcrowding.
If the private car is considered better, the public stransportation reputation will fall, otherwise it will rise.

The logic which service will actually be used remains the same:
If the inhabitant does not have a car, but using the car would be better, he still cannot use a car and will take public transport.
If the inhabitant does always prefer the car and public transport would be better, he will still use the private car.

Newly built houses will have a public transportation reputation of surrounding buildings, with some randomised varations.



Quote from: Ves on May 27, 2020, 03:51:04 PMSo that passengers would ignore the waiting time of the first, as well as the longest waiting time.
When commuting to university, I always have to wait 23 minutes (it had been 27 minutes a few years ago) at one station, where three trains per hour continue on my route.
The connection is simply scheduled to miss the half-hourly line by 7 minutes (it was 3 minutes a few years ago) and the hourly express service by 13 minutes.

I'd really like to simply skip that waiting time and get the express train at my transfer station, so I could leave my home 55 minutes later and still arrive at the university in time, only 5 minutes later than currently (because of a little better bus connection at the destination)

Sadly, reality is mean. I can't! I always have to wait 23 minutes. There are alternative routes, but none of these is faster.

jamespetts

I have been undertaking some further testing, as I have been concerned that increasing the skew results in an especially large numbers of journeys with very short tolerances being generated.

On the Stephenson-Seimens map with a random mode/skew of 6, a minimum visiting tolerance of 5 and a maximum visiting tolerance of 9600, with the new mechanism enabled, I get the following statistics:

Average tolerance: 38 minutes
Average journey time: 40 minutes
Average journey time minutes per Simutrans day: 163

Proportion of passengers with a tolerance of >10 hours: 0.37%
Proportion of passengers with a tolerance of <10 minutes: 39%
Proportion of passengers with a tolerance of < 10 minutes who made a successful trip: 0.27%

Thus, it seems that increasing the skew is simply creating a large number of passengers with a tolerance so low that they fail to travel entirely on almost every occasion, which is not a useful method of calibration: there is no point in these passengers being generated if their chance of travelling even on an extremely well served map is negligible.

Further testing is required.

Edit: A further test. With skew increased to 6, the new mechanism in use, but not modifying the current Stephenson-Seimens minimum and maximum visiting journey time tolerances, (8 minutes minimum, circa 5,600 minutes maximum), I get the following statistics:

Average tolerance: 33 minutes
Average journey time: 39 minutes
Average journey time minutes per Simutrans day: 162

Proportion of passengers with a tolerance of >10 hours: 0.07%
Proportion of passengers with a tolerance of <10 minutes: 26.5%
Proportion of passengers with a tolerance of < 10 minutes who made a successful trip: 0.5%

Note that I am currently measuring only the initial trip: for onward journeys, the tolerance for those journeys is subtracted from the starting tolerance, and earlier statistics in this thread included those lower tolerances, whereas those in this post do not.

Edit 2: A further test, this time using the Stephenson-Seimens settings without modifications (i.e. skew of 6, 8 minutes minimum visiting tolerance, circa 5600 minutes maximum visiting tolerance), but with the new mechanism, I get the following:

Average tolerance: 100 minutes
Average journey time: 57 minutes
Average journey time minutes per Simutrans day: 212

Proportion of passengers with a tolerance of >10 hours: 2.63%
Proportion of passengers with a tolerance of <10 minutes: 7.73%
Proportion of passengers with a tolerance of < 10 minutes who made a successful trip: 0.68%

Edit 3: A further test, this time with the new mechanism disabled, otherwise with the same settings as the immediately preceding test. The results are:

Average tolerance: 90 minutes
Average journey time: 56 minutes
Average journey time minutes per Simutrans day: 205

Proportion of passengers with a tolerance of >10 hours: 2.13%
Proportion of passengers with a tolerance of <10 minutes: 13.4%
Proportion of passengers with a tolerance of < 10 minutes who made a successful trip: 0.54%

Edit 4: Here is test under edit 1 repeated (skew 6, other settings unchanged from Stephenson-Seimens) but with the new mechanism disabled:

Average tolerance: 31 minutes
Average journey time: 39 minutes
Average journey time minutes per Simutrans day: 146

Proportion of passengers with a tolerance of >10 hours: 0.03%
Proportion of passengers with a tolerance of <10 minutes: 40%
Proportion of passengers with a tolerance of < 10 minutes who made a successful trip: 0.24%
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Mariculous

Sounds a little like passengers attempting to get somewhere impossible in that time even considering a "perfect" network.
Some rather overestimating heuristics or an entirely different destination selection method for short journey times might be required here.
Maybe place a rather optimistic guess on which distance can be travelled within the tolerable time and restrict potential destinations to be within that range.

We could get such an optimistic guess by maintaining per air-distance journey time stats of calculated routes.
Longer journeys will have greater average speeds, thats why different stats need to be recorded for different distances and it needs to underestimate journey times, otherwise we will never get close to the maximum tolerable time.

Alternatively, we might pick any destination and calculate the route. If the journey time is exceeded, we will iterate that journey back to a point that can be reached within journey time, select a new point that we expect to be reachable within the remaining journey time and do a few attempts to find a suitable destination around that point, using a rather understimated average journey time (e.g. walking speed) to check if these actually are within journey time tolerance.

The real-world idea behind this is, that people will not even attempt to reach a 50 km far-away destination in ten minutes.4

jamespetts

Freahk - the approach that you suggest is not consistent with the underlying design and purpose of the passenger generation algorithm. Generated passengers are desired trips, not attempted trips. The inherent desirability of a destination is a fundamentally different thing to its reachability: the current system is specifically designed to simulate that separation, and the alternative destinations system to simulate the fact that people will choose less than ideally desirable destinations on the basis of reachability. This system was designed to replace an earlier, much cruder system using distance ranges because that system produced intractable anomalies.

Rather than use the crude proxy of distance for destination choosing in passenger generation, it is better to calibrate the parameters of the current system to work better. One thing to consider is increasing the minimum journey time, as it is in reality likely to be rare for people to be willing to make a trip outside their homes, but only if that trip can be completed in less than 10 minutes. A 12-15 minute minimum journey time may well be worth considering.

Before looking into that, however, I am in the process of re-running the above tests but with more fine grained data about tolerances to get a better idea of the distribution produced by each minimum, maximum and skew set. The result of the first of these tests, with the current Stephenson-Seimens settings unchanged (skew 5, minimum visiting journey time tolerance of 8 minutes and maximum of 5,400) is as follows:

Average tolerance: 89 minutes
Average journey time: 56 minutes
Average journey time minutes per Simutrans day: 205

Proportion of passengers with a tolerance of >10 hours: 1.9%
Proportion of passengers with a tolerance of <10 minutes: 13%
Proportion of passengers with a tolerance of <30 minutes: 40%
Proportion of passengers with a tolerance of <1 hour: 53%
Proportion of passengers with a tolerance of <3 hours: 68%

This shows a very high proportion of trips (32%) with a tolerance of >3 hours, which does suggest that a skew of 5 leads to excessive journey time tolerances overall.

Edit 1: Running the same test again, with skew at 6 instead of 5, we get the following:

Average tolerance: 31 minutes
Average journey time: 37 minutes
Average journey time minutes per Simutrans day: 147

Proportion of passengers with a tolerance of >10 hours: 0.02%
Proportion of passengers with a tolerance of <10 minutes: 40%
Proportion of passengers with a tolerance of <30 minutes: 70%
Proportion of passengers with a tolerance of <1 hour: 75%
Proportion of passengers with a tolerance of <3 hours: 79%

Edit 2: The same test again, but with a skew of 7 gives the following:

Average tolerance: 23 minutes
Average journey time: 36 minutes
Average journey time minutes per Simutrans day: 135

Proportion of passengers with a tolerance of >10 hours: 0%
Proportion of passengers with a tolerance of <10 minutes: 59%
Proportion of passengers with a tolerance of <30 minutes: 78%
Proportion of passengers with a tolerance of <1 hour: 79%
Proportion of passengers with a tolerance of <3 hours: 79%

Edit 3:

Here is a chart of the distribution curves with the three levels of skew:



Edit 4: For clarity, I should note that all of these results were obtained with the system for adjusting journey time tolerance based on the passenger success rate of the origin building disabled.

Edit 5: Re-running the test, but with altering the minimum an maximum as well as the skew, with the minimum now being 12 minutes and the maximum now being 12,000 minutes and with a skew of 6, we get these results:

Average tolerance: 45 minutes
Average journey time: 42 minutes
Average journey time minutes per Simutrans day: 171

Proportion of passengers with a tolerance of >10 hours: 0.35%
Proportion of passengers with a tolerance of <10 minutes: 0%
Proportion of passengers with a tolerance of <30 minutes: 56%
Proportion of passengers with a tolerance of <1 hour: 70%
Proportion of passengers with a tolerance of <3 hours: 77%

Edit 6: The same minimum and maximum with a skew of 7 gives:

Average tolerance: 28 minutes
Average journey time: 36 minutes
Average journey time minutes per Simutrans day: 114

Proportion of passengers with a tolerance of >10 hours: 0.002%
Proportion of passengers with a tolerance of <10 minutes: 0%
Proportion of passengers with a tolerance of <30 minutes: 70%
Proportion of passengers with a tolerance of <1 hour: 78%
Proportion of passengers with a tolerance of <3 hours: 80%
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Mariculous

Quote from: jamespetts on May 28, 2020, 10:12:03 AMFreahk - the approach that you suggest is not consistent with the underlying design and purpose of the passenger generation algorithm.
In which case you'll have to conform with passengers that only have a short period of time, e.g. in a short lunch-break, to very rarely arive anywhere they actually desire to go.

Quote from: jamespetts on May 28, 2020, 10:12:03 AMit is better to calibrate the parameters of the current system to work better
I'd be very surprised if you ever get an acceptable success rate in case of such short maximum journey times by simply calibrating the parameters.

jamespetts

Quote from: Freahk on May 28, 2020, 11:09:41 AM
In that case, you'll have to conform with short distance passengers not finding a detination in many cases, although there would be suitable destinations in that range.

What exactly do you mean by "suitable destinations" here? A place where it is reasonable for a person to go is not the same as a place where a person wants to go. If somebody wants to buy a rug, a person will not go to a shop selling rope and candles just because he/she cannot get to a shop selling rugs within a reasonable time, even though it is perfectly reasonable for a generic person to make a trip to a shop selling rope and candles. People do not, in reality, first decide that they will make a trip and then think where would be a suitable place for them to go. Rather, people start with a desire to achieve something, and, if leaving the house and going somewhere else is necessary to achieve that end, do so if and in so far as this can be done within what the person in the particular circumstances considers a reasonable time.

Thus, one would expect a system that simulates reality to be one that has people not making trips where the journey time to a desired destination is too long even where there are other destinations nearby that a person might reasonably want to go to in some circumstances. Indeed, the planned town growth mechanism relies on there being a difference in the number of successful trips made by people who live very close to a lot of desirable destinations and those who do not.

Edit 1: I am now repeating some of the above tests with the success influenced journey time tolerance re-enabled. Here is the first result.

Skew: 6
Minimum visiting tolerance: 12 minutes
Maximum visiting tolerance: 12,000 minutes

Average tolerance: 73 minutes
Average journey time: 49 minutes
Average journey time minutes per Simutrans day: 155

Proportion of passengers with a tolerance of >10 hours: 1.08%
Proportion of passengers with a tolerance of <10 minutes: 0%
Proportion of passengers with a tolerance of <30 minutes: 35%
Proportion of passengers with a tolerance of <1 hour: 57%
Proportion of passengers with a tolerance of <3 hours: 73%

Edit 2: Here is the second result.

Skew: 7
Minimum visiting tolerance: 12 minutes
Maximum visiting tolerance: 12,000 minutes

Average tolerance: 42 minutes
Average journey time: 40 minutes
Average journey time minutes per Simutrans day: 129

Proportion of passengers with a tolerance of >10 hours: 0.03%
Proportion of passengers with a tolerance of <10 minutes: 0%
Proportion of passengers with a tolerance of <30 minutes: 52%
Proportion of passengers with a tolerance of <1 hour: 70%
Proportion of passengers with a tolerance of <3 hours: 78%
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Mariculous

Usually people won't desire a far-away building, if there is not anything special about it.
E.g. we got very many kiosks here, a few nearby supermarkets and so on.
The weekly shopping is usually not done in the most local supermarket, because we got the car available, there's a little preference of that supermarket and we got a much larger time budget.

Frequently it appears that there is something missing for dinner or the bread runs out in the evening, in which case we got a rather short time budget, so we simply walk to the ~200m far-away supermarket.
I have never even thought about going to the much farer-away supermarket in that case, nor it's it's a hidden desire to have a door-to supermarket hyperloop, which would allow me to travel these 3 kilometers 15 minutes, including the shopping itself.


So the second suggestion above is about first randomising any destination. If that's within tolerable journey time, it's fine. Otherwise attemt to find the same building that actually is withing journey time tolerance.
this should be fairly realistic in case of commercial and industry visits, but might not be in case of residental visits.

The first suggestion above is about resticting the area of "desired" destination to an overestimated area of which could be reached in case of very good transport, so people won't desire to make a trip to Japan  within their lunch break, as I don't think anyone in the real-world would seriously desire this.
It is important that this area is an overestimation, based on the global best case, so effectively success rates will rise, especially in case of short distances, but but there will also be many more misses in areas that are served worse than others.

jamespetts

Quote from: Freahk on May 28, 2020, 11:45:39 AM
Usually people won't desire a far-away building, if there is not anything special about it.
E.g. we got very many kiosks here, a few nearby supermarkets and so on.
The weekly shopping is usually not done in the most local supermarket, because we got the car available, there's a little preference of that supermarket and we got a much larger time budget.

Frequently it appears that there is something missing for dinner or the bread runs out in the evening, in which case we got a rather short time budget, so we simply walk to the ~200m far-away supermarket.
I have never even thought about going to the much farer-away supermarket in that case, nor it's it's a hidden desire to have a door-to supermarket hyperloop, which would allow me to travel these 3 kilometers 15 minutes, including the shopping itself.

But the only reason that you do not think about places that are geographically far away is the amount of time that it takes to get there. If and in so far as these buildings were closer in time, you would be more likely to consider going there. If all supermarkets in the world were equally close in terms of travel time, then you would have a preference as to which one to go to. For supermarkets, your preference would be weak, and most alternative supermarkets would suffice. In Simutrans-Extended terms, you would have a high number of alternative destinations.

For other things, your preferences would be stronger: you would not go to a local supermarket instead of a distant antiques shop, even if the distant antiques shop were too far to get to. Your underlying desire to do something that can only be done in a far-away destination is not affected by the fact that the destination is far away (and by far away here I mean far in time): only whether you are reasonably able to fulfil the desire is so affected. Such preferences for more specific destinations are simulated in Simutrans-Extended by the passengers with a lower number of alternative destinations.

QuoteSo the suggestion above is about first randomising any destination, if that's within tolerable journey time, it's fine, otherwise attemt to find the same building that actually is withing journey time tolerance.
This is exactly what the alternative destination system does, except that there is no concept of "the same building" (and there is not in the system that you suggest, either).

Edit 1:
As can be seen from the above results, there is no single setting that keeps the average within Marchetti's Constant whilst giving reasonable numbers of journeys at the far ends of the spectrum, so I am testing another method for calibration, which is a uniform proportion reduction in journey time tolerance by a specified percentage (in effect, an adjunct of the system described above for calibration of journey time tolerance by success percentages). These tests are run with the method for adjusting journey time tolerances based on building success percentages enabled. The first results are as follows.

Skew: 6
Minimum visiting tolerance: 12 minutes
Maximum visiting tolerance: 12,000 minutes
Uniform adjustment percentage: 75%

Average tolerance: 59 minutes
Average journey time: 45 minutes
Average journey time minutes per Simutrans day: 144

Proportion of passengers with a tolerance of >10 hours: 0.7%
Proportion of passengers with a tolerance of <10 minutes: 0.008%
Proportion of passengers with a tolerance of <30 minutes: 45%
Proportion of passengers with a tolerance of <1 hour: 64%
Proportion of passengers with a tolerance of <3 hours: 75%

Edit 2: Here is another set of results.

Skew: 7
Minimum visiting tolerance: 12 minutes
Maximum visiting tolerance: 12,000 minutes
Uniform adjustment percentage: 125%

Average tolerance: 48 minutes
Average journey time: 44 minutes
Average journey time minutes per Simutrans day: 138

Proportion of passengers with a tolerance of >10 hours: 0.06%
Proportion of passengers with a tolerance of <10 minutes: 0%
Proportion of passengers with a tolerance of <30 minutes: 34%
Proportion of passengers with a tolerance of <1 hour: 65%
Proportion of passengers with a tolerance of <3 hours: 78%
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Mariculous

Quote from: jamespetts on May 28, 2020, 11:52:17 AMBut the only reason that you do not think about places that are geographically far away is the amount of time that it takes to get there.
If I got a few hours available for shopping in the supermarket, which is usually the case on saturdays, I won't desire nor attempt to move to the next city to do so if there is nothing special about that supermarket. It doesn't even matter if that's within my tolerable time or not, as long as it takes longer to get there and even if it's roughly the same time, I'd rather prefer the one that is closer.
I don't take the motorway to get to the next town, just because it's 5 minutes faster, but twice the distance either.


Quote from: jamespetts on May 28, 2020, 11:52:17 AMFor other things, your preferences would be stronger: you would not go to a local supermarket instead of a distant antiques shop, even if the distant antiques shop were too far to get to.
Which is obviously an entirely different thing as there is something special about that destination that cannot be found nearby.


Quote from: jamespetts on May 28, 2020, 11:52:17 AMThis is exactly what the alternative destination system does
It doesn't. It allows people that wanted to get to an far-away antiques shop, to visit a friend instead, if the shop is not within journey time.
This might be fairly realistic, as can be observed in the real-world "Oh I don't have enough time to do this anymore, so I'll do something different and do the other thing tomorrow", but is exactly your counter argument against my suggestion.

Quote from: jamespetts on May 28, 2020, 11:52:17 AMand there is not in the system that you suggest, either
Well that's what was actually meant by a suitable destination.

Anyways, let's stick with these people not getting something to eat in their lunch break, although there is a baker just over the road, whilst these people got a desire to get their lunch from a 30 minutes far-away baker.


jamespetts

Freahk - I am not sure that I understand how any of that is a reason to use a distance based system?




Further results:

Skew: 6
Minimum visiting tolerance: 12 minutes
Maximum visiting tolerance: 12,000 minutes
Uniform adjustment percentage: 66%

Average tolerance: 54 minutes
Average journey time: 44 minutes
Average journey time minutes per Simutrans day: 140

Proportion of passengers with a tolerance of >10 hours: 0.6%
Proportion of passengers with a tolerance of <10 minutes: 0.03%
Proportion of passengers with a tolerance of <30 minutes: 49%
Proportion of passengers with a tolerance of <1 hour: 67%
Proportion of passengers with a tolerance of <3 hours: 76%
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Mariculous

It is reasonable to use a distance based system to restrict the search-space to a much smaller area, which still is a superset (or at least nearly a superset) of the actually reachable area within the journey times limit, to increase the number of successfully selected destinations, especially in cases of short distance preferences. This will increase success rates, which can be compensated by decreasing the number of retries.

The issue of passengers visiting a local supermarket, instead of an antiques shop is a different issue, that does also exist in the current system and needs to be handled by a different system on its own, if we wanted to handle this properly.

Such a system would require a building type system, building type specific journey times and supposedly a locality preference, also specific to building (types).
A passenger will then first decide what to do, which means selecting a building type and a tolerable time and then he would be searching for a building of that type within the tolerable time limit.

Just short thoughts, as I don't think that's a quick and easy thing.

jamespetts

Quote from: Freahk on May 28, 2020, 01:11:22 PM
It is reasonable to use a distance based system to restrict the search-space to a much smaller area, which still is a superset (or at least nearly a superset) of the actually reachable area within the journey times limit, to increase the number of successfully selected destinations, especially in cases of short distance preferences. This will increase success rates, which can be compensated by decreasing the number of retries.

The issue of passengers visiting a local supermarket, instead of an antiques shop needs to be handled by a different system on its own. Using the restricted search area will handle this issue just as bad, in case of very low distances admittedly even worse, than the current system that does not restrict the search-space.

If we want to increase the success rate, we can increase the number of alternative destinations (indeed, this has already been calibrated extensively). Anything else risks anomalies, of exactly the type that we had when the system was distance based. The fundamental principle must always be that it is time, not geographical distance, that determines whether passengers travel.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Mariculous

So it's actually realistic, that passengers are dreaming of transportation that boosts them to far-away destinations within only 10 minutes?
If that's realistic, it's fine and I'm an extremely rare kind of realist.
I never had the desire to visit a far-away bakery and rejected the short journey to the other side of the road, because there was no scifi mode of transport boosting me to a bakery in another town and back in only 10 minutes.

Sure, we can also brute-force more, more and even more "desired" destinations, but that doesn't solve the problem.
It will lead to much increased success rates in case of long journeys, whilst there will still be many unsuccessful short journeys although there would be a suitable destination (that means a destination that will fullfill the desire of the inhabitant, not any destination that offers something completely different than what the inhabitant wanted to do)

jamespetts

Quote from: Freahk on May 28, 2020, 01:46:18 PM
So it's actually realistic, that passengers are dreaming of transportation that boosts them to far-away destinations within only 10 minutes?
If that's realistic, it's fine and I'm an extremely rare kind of realist.
I never had the desire to visit a far-away bakery and rejected the short journey to the other side of the road, because there was no scifi mode of transport boosting me to a bakery in another town and back in only 10 minutes.

The only reason that you do not think about visiting a bakery in Paris when you have a spare half hour in an afternoon is precisely because of the time that it takes to get from Germany to Paris. You use the distance as a proxy for journey time when the distance gets sufficiently high, and, thus, when you have a low journey time tolerance, you do not even consider things outside a certain distance because it is easier mentally to think about distance than to work out the journey time precisely.

But there would have been a time in the past (and within the time that we simulate in Simutrans-Extended) when it took ~6 hours to get from central London to what are now the northern suburbs of London and when people would have applied the same heuristic and not even considered going anywhere outside their village if they could not spare the whole day for the trip. In modern times, it is entirely reasonable to make a round trip of hundreds of miles within a day. That would have been considered science fiction transport in the 18th century. We need to simulate the 18th century as much as we simulate the 21st. We need a universal mechanism, not a crude proxy that relies on assumptions that are very specific in time and place.

Distance based mechanisms always risk resulting in anomalies. Imagine three towns: town A, a small town on the coast; town B, a large town along the coast, and town C, a small town on an island just off the coast. Town C is much closer to town A than either are to town B, but the only connexion to town C is by a ferry from town B. With a distance based system, passengers in town A are more likely to seek to travel to town C than town B, whereas, in reality, people will be more likely to choose a destination in town B. Precisely this sort of situation in fact occurred regularly when we had distance based mechanisms. This does not occur with the current mechanism.




I have now run a further test, this time using the Bridgewater-Brunel saved game from 1757. Here are the results:

Skew: 6
Minimum visiting tolerance: 12 minutes
Maximum visiting tolerance: 12,000 minutes
Uniform adjustment percentage: 66%

Average tolerance: 58 minutes
Average journey time: 28 minutes
Average journey time minutes per Simutrans day: 78

Proportion of passengers with a tolerance of >10 hours: 0.68%
Proportion of passengers with a tolerance of <10 minutes: 0.4%
Proportion of passengers with a tolerance of <30 minutes: 47%
Proportion of passengers with a tolerance of <1 hour: 65%
Proportion of passengers with a tolerance of <3 hours: 75%

Global passenger success rate: 58% (down from 69% with current settings)

Prominster Shipping & Coaches monthly profit: 10,133c (down from 47,545c)
East Oceanic monthly profit: 12,805c (down from 73,122c)
Azuma Shipping monthly profit: -2,671c (down from 41,667c)
Ves Transport Corp. monthly profit: 534c (down from 11,594c)
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ranran(retired)

Quote from: jamespetts on May 28, 2020, 02:02:00 PMAzuma Shipping monthly profit: -2,671c (down from 41,667c)
I would have to stop most freight networks as freight is not profitable. (´・ω・`)
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

jamespetts

Quote from: Ranran on May 28, 2020, 02:42:12 PMI would have to stop most freight networks as freight is not profitable. (´・ω・`)
Interesting - you are using passenger revenues to subsidise freight operations?
(Incidentally, apologies for accidentally modifying your message instead of replying: I believe that I have put it back to how it was before the error).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Mariculous

Quote from: jamespetts on May 28, 2020, 02:02:00 PMThis does not occur with the current mechanism.
And won't appear with a system restricting the search-space to a distance based area (as we can calculate distances much more easily), that is a superset of the area that can actually be reached within our maximum journey time (which we cannot calculate easily).

To ensure it is a superset, we need to record (global, or per-city) stats about the maximum distance we could reach in a given time, when calculating routes.
Thus, when calculating a new route, we can always definitely say if it might be possible to reach that destination or of it's unrealistic to reach that destination in the given time.

Refering to your example, I don't see the described issue:
An inhabitant attempting to travel from A to anythwere will have a maximum journey time and won't exceed it.
Assuming B could be reached within the journey time limit, C will also be assumed to be within the limit, so destinations in C might get picked, but withdrawn as being to far-away in terms of time, whilst a destination in B might be close enough in terms of time.

As the service gehts improved, the heuristics might be wrong for a while, thus it's important that it is an overestmation to quickly react to such improvements. In a fairly short amount of time, an inhabitant attempting to do a longer journey will notice that there is something in range, at a distance we didn't expect to be in range within a given tolerable time, thus this stat will be updated.
To react on decreasing levels of service, these stats need to be rejected after some time.


Quote from: Ranran on May 28, 2020, 02:42:12 PMI would have to stop most freight networks as freight is not profitable. (´・ω・`)
I agree, in most cases.
It seems like there are very few profitable cargo lines currently. Coal and iron ore cannot be transported profitably at all using current vehicles.

Ves

I agree with James, that we most likely use distance as a proxy for time. I myself live 160km from my work, and take the train every day (when I dont have this Corona-holiday) to go there. From door to door it takes me ca 2,5 hours. 20 years ago, this would have been a much longer travel, but thanks to a new bridge connection, replacing a 45 minute ferry connection with the 10 minute bridge connection, this is now feasable.
However, I also believe that we humans are lazy. Unless we live in Star Trek future, where we can beam ourself around the globe, we still need to spend (some) time and effort to go places. For many things, we just have to accept this fact, like going to work, or visiting friends or special stores. But for other things, we definitively want to spend as little time as possible.

So in Simutrans, this could be simulated that some proportion of the generated passengers will first choose a type of destination (say a building or industry), and then look for a similar destination on the map which has the smallest jurneytime possible.




Well, most of my freightlines are also running negative, but I have two boats that (sometimes) doesnt. Most horses are negative, or in the best part barely breaking even.

jamespetts

I am afraid that I still do not understand the purported benefit of trying to use distance as a mechanism, especially in circumstances where the current system was implemented precisely because using distance in this way caused intractable problems. It is not a bad simulation of reality that passengers are being generated all of whose alternative destinations are too far away to be reachable within their journey time tolerance even with modern transportation. If this were not the case, how would it be possible for a transport success percentage system to favour large towns with many amenities within walking distances over isolated settlements without some additional complex proxy that would be difficult to code and potentially prone to its own anomalies?

There is nothing inherently unrealistic about this. The simulation of passengers is not intended to represent peoples' actual explicit thoughts. It is intended to represent (in part) what economists call latent demand: that is, extra journeys that people would make if only there were more interesting or useful things to visit within a reasonable amount of time. What thoughts that actually do or do not go through the minds of people when deciding whether to make these trips is not relevant.





In any event, I have been carrying out further testing, this time with the Bridgewater-Brunel game again, but running for > 1 game year to see the long-term effects, especially the recursive effects of the new mechanism for adjusting journey time tolerances based on actual success rates.

The findings are as follows.

Skew: 6
Minimum visiting tolerance: 12 minutes
Maximum visiting tolerance: 12,000 minutes
Uniform adjustment percentage: 66%

Average tolerance: 63 minutes
Average journey time: 24 minutes
Average journey time minutes per Simutrans day: 71

Proportion of passengers with a tolerance of >10 hours: 0.85%
Proportion of passengers with a tolerance of <10 minutes: 0.22%
Proportion of passengers with a tolerance of <30 minutes: 43%
Proportion of passengers with a tolerance of <1 hour: 63%
Proportion of passengers with a tolerance of <3 hours: 74%

Global passenger success rate: 61%

As we can see, there is a noticeable adjustment of the success rate and the distribution of tolerances in response to the reduced success rate, showing that the negative feedback of the new mechanism does work.

Here are some screenshots of the minimap showing visiting passenger success after running with the new calibration as above for > 1 year, showing separately east and west of the Bridgewater-Brunel game map:





As we see, there is strong patterning: towns with no service or only coasting boats and with few local amenities tend to get very poor visiting success, whereas larger towns, especially those with local amenities, tend to get much higher visiting success. As is realistic in this era, what is needed is for local industries to be well served with freight transport so that they can operate, so that the local market, public house, etc., can absorb the local desired visiting population simply by walking trips to generate a higher rate of visitor success which will in turn, when the new town growth mechanism comes to be implemented, lead to higher town growth, especially in the areas within easy walking distance of the amenities in question.

Longer distance passenger transport, although it may be profitable for the player, is unlikely to have a major impact on local success rates until the era of the steam train, although may make a difference in connecting larger towns or small, cut-off towns with few amenities to neighbouring larger towns with more amenities.

The calibration that we are getting with these settings and the new mechanism seem to be satisfactory and a significant improvement on the existing calibration.

I will now have to make the percentage adjustment for tolerances configurable in simuconf.tab and then consider why freight transport is currently so unprofitable, as, for the reasons given above, freight transport is especially important in this early era.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ranran(retired)

Quote from: jamespetts on May 28, 2020, 05:09:19 PMI will now have to make the percentage adjustment for tolerances configurable in simuconf.tab and then consider why freight transport is currently so unprofitable, as, for the reasons given above, freight transport is especially important in this early era.
As I reported in another thread, the shipping volume is limited.
Frequently small carriages wait idle for months or move empty once a month to create a deficit.
It is difficult to recover the fixed cost with such a small amount of transportation.  ::-\

Meat and wheat shipments are extremely tightly regulated, while restrictions on fishing appear to be loose.
The port tends to overflow with fish. British people seem to prefer fish than Japanese. :::)

Especially bad is livestock. Despite the vast ranch, they do not ship even one a month.
And the livestock manger demands a large salary every month as they can carry 35 livestock.  ::'(
I have to feed them who do very little work with the money I make on the ship!
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

jamespetts

I have now implemented this change on the master branch of both code and pakset. I should be grateful for feedback on passenger generation from to-morrow's nightly build. Please note that it may take a few months for the negative feedback mechanism to produce fully stable behaviour.

I have also reduced considerably the monthly cost of early goods transport with a small volume, including carts, wagons, the skiff wherry, livestock drover and pack horses. These were too great to allow a profit to be made and higher than wage levels of the time (when compared to goods revenue) suggested that they should be.

I should be grateful if people could confirm whether goods transport is now more workable than before in financial terms.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.