The International Simutrans Forum

 

Author Topic: Oneway Twoway Road Patch for the Extended  (Read 10963 times)

0 Members and 1 Guest are viewing this topic.

Offline Andyh

  • *
  • Posts: 74
Re: Oneway Twoway Road Patch for the Extended
« Reply #35 on: June 02, 2018, 10:56:54 PM »
Thank you and congratulations to everyone involved in bringing this new functionality into the game.  It really does bring a whole new level of realism to road transportation in Simutrans. 

I have a question: what is the purpose of the "Inverted lane" option?  I know what it does mechanically, but what sort of real life situation is it meant to simulate, or what problem in the game is it meant to solve?  The other road types I get, but I'm scratching my head with this one.

Offline ACarlotti

  • *
  • Posts: 483
Re: Oneway Twoway Road Patch for the Extended
« Reply #36 on: June 06, 2018, 01:06:53 AM »
Originally posted June 02, 2018, 02:07:40 PM; partially reposted to assist splitting the topic. This section of the original post is about specific issues in THLeaderH's changes, many of which had been raised before. The remaing paragraphs can be found here.

I was looking through these changes last night, and I noticed that many of the issues mentioned in the Standard thread for this patch are still present in this thread. I've made some changes to your code, which James has now incorporated into master, so you should be able to look at them fairly easily. In no particular order:

(Also the patch files of github seems uneccessary large since a lot of identical lines (maybe with whitespaces) are contained within.)
This was my first observation too. In fact, while the full diff of your changes (using standard git diff settings) is over 10000 lines long, if I tell git to ignore whitespace changes then the diff is less than 5000 lines long. While it might be good to fix whitespace inconsistencies, this should always be done separately to other changes. The reasons for this are that it allows people to inspect and understand your changes, and that it makes it easier for people to understand the history of the code.
To take one particular example, if I look at boden/wege/weg.cc, there are a lot of changes to whitespace mixed in with actual code changes, all under the commit message "bring from standard". Ideally the code changes would have been separate to the whitespace changes, and that commit message (at least read in isolation) is quite misleading, as these changes were not taken from standard, but from a patch on top of standard.

Logic incomplete and even flagged with TODO's, yet still left.
I spotted and removed one out-of-date TODO relating to version numbers (which is fairly reasonably something to leave in until James merged it). However, there are still some others, among which this one in bauer/wegbauer.cc particularly worries me:
Code: [Select]
// TODO: not edited since it's quite different from that of standard...To me, this TODO suggests that you haven't bothered to port part of the code because it was difficult. I hope this is not the case, but some reassurance here would be appreciated.

Maybe try using this new fangled keyword called 'else'. if(a), if(!a) yeesh.
It took me less than a minute to find an instance of if(a) {stuff} if(!a) {stuff} in your changes, and even though it might take you longer if you're not as familiar with the relevant git commands, you should still be capable of looking at your changes and reading through for things like this. I think I replaced all the instances of this particular non-pattern, but since I haven't read the patch through line-by-line I cannot be certain.

refleshing. what? I can't even...
I think Turfit could have written this better, but I'm pretty sure his gist is that "reflesh" is almost certainly not the word you meant. My guess would be that you meant "refresh" instead, but even that seems like a poor name choice, with "refresh_vehicle_images" probably being a better name for the method in overtaker_t. (I would also make this method take no arguments, and move the check into overtaker.cc).
I also removed the "reflesh" method from vehicles because (as it was implemented) it was duplicating a lot of code that already existed - see my changes for (in my opinion, at least) a better way of doing that.

Another thing I've noticed that could be improved in your code is a lot of places where your manipulation of booleans is unecessarily complicated, or you store intermediate results that don't need to be stored. In one example that I simplified last night, you use about 5 lines of code with an if branch in the middle where you could have used a short boolean expression. A couple of lines later you create a whole new overtaker_t variable just to test if it is null. Storing the object suggested that you would use it again later and that the null check was partly to avoid null dereference errors; in fact I realised after a bit that the null check was the entire usage of the object.

Out of interest, how did you solve this issue? I came across it this morning while reading through the Standard thread, and didn't notice any mention of how you resolved it.
https://forum.simutrans.com/index.php/topic,16659.msg165492.html#msg165492

Edit: Four paragraphs extracted to a new topic - see here.

I also know that there are many more changes that could (and should) be made to improve the code. I'm not going to list every single change that should be made, because that would take me days or more likely weeks, and then I might as well make them myself. (See also 'code smells'.) That is the point Turfit was making - we can tell you the sorts of issues we see, and we can maybe give you some examples, but you then have to be able to extrapolate from this and seek out other instances of these issues yourself. For example, you complained "Please make your issue posts as concrete as possible. For example of if ~ else, please point out at least 1 line that is malformed."  Did you even try looking yourself? As I said, it took me less than a minute of skimming through your changes to find an example of this; it shouldn't have taken you too long to find one yourself, even if you were unlucky and looked in the wrong places first. If you can't look for and find issues yourself, even after you are told what those issues look like, then the only alternative is that someone else rewrites your patch for you. That shouldn't be necessary.

With your knowledge and understanding of the code, you should be able read through it and rewrite bits of it more easily than me, because everywhere that something is written out poorly (e.g. with duplication, unnecessary complexity or vague of misleading code/comments) you already know what it's supposed to do. Fundamentally, what I (and Turfit, and prissi, and Ters) want is for you to read through the entire patch, line by line, and section by section, a couple of times, and think about how you could make it easier for other people to read. I'm sure James will be glad to incorporate such changes, and that is also the only way you're going to get this into Standard.

(James: I think this should enable you to split the topics - posts 34 and 37-41 being the new topic)
« Last Edit: June 06, 2018, 11:25:26 PM by jamespetts »

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18745
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #37 on: June 06, 2018, 11:25:49 PM »
Thank you - I think that I have split this correctly (and edited your post to insert the links in the designated places).

Offline TurfIt

  • Dev Team, Coder/patcher
  • Devotee
  • *
  • Posts: 1326
Re: Oneway Twoway Road Patch for the Extended
« Reply #38 on: June 14, 2018, 11:27:49 PM »
Note: This ended up being quite a long post, in which I express quite a bit of frustration.
Frustration for sure with this patch, and ultimately somewhat disappointment. From a "Fun patch", to claimed trunk candidates, through sheer obstinance and even outright bold faced lies (Multiplayer tested working while the required code was completely missing!), to a final give up and ceasing work. Not fun, but wait, it's back with a series of 'updates' to fire up the rah rah crowd, all the while not addressing the deep functionality issues, and then into SimEx it goes seemingly duping with it's shiny bauble...
If feeling generous, I'd assign it a 30% completion. If not, a failed proof of concept. In neither case, something 'ready'.

I get there's serious pent-up demand for such a feature, and I truly hoped this patch would've been usable/went somewhere, but the experience has definitely reinforced my gut feeling that this approach in the code is not workable.


To me, this TODO suggests that you haven't bothered to port part of the code because it was difficult. I hope this is not the case, but some reassurance here would be appreciated.
Out of interest, how did you solve this issue? I came across it this morning while reading through the Standard thread, and didn't notice any mention of how you resolved it.
I expect such issues have not been resolved, and TODO's remain undone, even if the TODO itself is removed from the patch after pointing out it's existence. It's trivial to setup tests where the vehicle behaviour fails; Let's not even talk about trying corner cases. Expect bad things whenever the overtaking mode changes, or worse where they meet - aka intersections. Restrict the patch's use to creation of controlled access divided highways, and things mostly work (still issues with the inherent intersection where on/off ramps are...), but for avenues which seem to be the most desired feature, disaster.


refleshing. what? I can't even...
I think Turfit could have written this better, but I'm pretty sure his gist is that "reflesh" is almost certainly not the word you meant."
'tis like something straight out of a horror movie. Tops even the factory boost mechanism 'consuming' passengers we had for a while in development of that patch I thinks.


The signalling code is, I must confess, an example of an erroneous decision on my part about how to handle the project at an early stage. The erroneous decision was to keep as much of the Standard signalling code as possible and build the additional features by adding to that code rather than starting afresh.
That sums up my feelings on the approach taken with OTRP. The existing code for vehicle movement through intersections is already stretched to the limit. Grafting multilane road logic onto it, and the existing overtaking logic takes it beyond breaking; Erroneous to continue in this way.

I intend to revisit getting the previously discussed 'intersection_t' object implemented. That should greatly simplify things w.r.t vehicle control especially with multi tile intersections. Unfortunately my on again, off again enthusiasm for contributing anything, and meandering interests has already delayed that by years...

Offline Ranran jp

  • *
  • Posts: 483
  • Languages: ja
Re: Oneway Twoway Road Patch for the Extended
« Reply #39 on: June 21, 2018, 01:41:07 PM »
Currently, menuconf.tab of 128britain-EX has not been edited so you can not see the OTRP arrow as it is. (Is this intentional?)
If you add it to line 191 in menuconf.tab as follows, you can see the OTRP arrow by pressing ":" key.
Code: [Select]
simple_tool[37]=,:
OTRP arrow is also displayed on tracks, trams, rivers or canals. I believe it is unnecessary on there.
These ways can not be controlled with OTRP and these run on a system different from the road, for example, railway track controls the direction of the train using one way sign, but OTRP arrows are not linked with railway direction restriction, so players will get confused.

When you build the tram track on the road, these two arrows are integrated and the display of the arrow no longer makes sense. This is an obvious bug that should be fixed. (´・ω・`)

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18745
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #40 on: June 21, 2018, 09:43:52 PM »
The "," key cannot be used for this, I am afraid, since it is already used for reducing the rate at which time passes - do you think that you could find a spare key?

Offline Rollmaterial fi

  • Devotee
  • *
  • Posts: 572
  • Languages: EN, FR, DE, FI, SE
Re: Oneway Twoway Road Patch for the Extended
« Reply #41 on: June 21, 2018, 09:53:43 PM »
He meant the ":" key, not the comma.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18745
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #42 on: June 21, 2018, 10:03:54 PM »
Ahh - I misunderstood, my apologies. The : key appears to be free, so I have integrated this.

Offline Phystam jp

  • *
  • Posts: 248
  • Pak256.Ex developer
  • Languages: JP, EN, EO
Re: Oneway Twoway Road Patch for the Extended
« Reply #43 on: June 22, 2018, 12:49:03 AM »
Ranran — I think that the ribiarrow (you say “OTRP arrow”) is not only for road waytype, so it is not a bug. This is also useful for confirmation of railroad oneway sign :)
However, if we can display arrows for each waytype separately, it will be more convenient, I think.

Offline THLeaderH jp

  • Coder/patcher
  • Devotee
  • *
  • Posts: 334
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #44 on: June 22, 2018, 11:43:00 AM »
James, thank you for making a change to enable the feature of showing Ribi-Arrow.

As Ranran says, I think ribi-arrow should be only showed for street. I made a pull request.
https://github.com/jamespetts/simutrans-extended/pull/90

As Phystam put it, ribi-arrow might be useful for checking the direction of railroad oneway sign. Ribi-Arrow should be configured separately for each waytypes, but assigning keys for all waytypes is not appropriate. Also, creating GUI selection window is not a good solution. I don't know what is a suitable interface for this...

Offline THLeaderH jp

  • Coder/patcher
  • Devotee
  • *
  • Posts: 334
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #45 on: July 06, 2018, 12:56:25 PM »
Hello, James.
My recent releases of OTRP for standard contain some bug fixes and I brought them into the extended. Please refer the pull request.

P.S. I'm sorry that one of the commits contains an unnecessary change, the removal of spaces, but Atom editor forced me to do so :(

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18745
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #46 on: July 06, 2018, 11:57:38 PM »
Thank you for that. Can I ask which bug fixes have been ported to Extended?

Offline THLeaderH jp

  • Coder/patcher
  • Devotee
  • *
  • Posts: 334
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #47 on: July 07, 2018, 12:06:52 AM »
This pull request contains bug fixes that was done in OTRP v14.
  • bug fix for algorithm of vehicle control
  • bug fix for lane yielding
  • do not execute other_lane_blocked when street is twoway
  • allow changing overtaking_mode for elevated way with ground way
The last one is an improvement of UI, not a bug fix.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18745
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #48 on: July 07, 2018, 03:31:40 PM »
Splendid, thank you: now incorporated.

Offline THLeaderH jp

  • Coder/patcher
  • Devotee
  • *
  • Posts: 334
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #49 on: August 06, 2018, 10:54:01 AM »
OTRP now becomes a kind of fork project of simutrans and continues evolvement. And it's time to bring the improvements into the extended. The latest version of OTRP is v17, so I want to bring the following changes.

  • The ribi-arrow can be called from the display settings window.
  • Some fixes around vehicle movement.
  • Flags for road. "citycars do not enter" and "avoid becoming cityroad" feature.
  • Improvement of citycars. Citycars follows lane affinity signs and the lane yielding rule.

In OTRP, Citycars now determine their route for certain tiles (e.g. 15 tiles). Determination of the route in advance is needed for lane affinity signs and other OTRP's function. Also, routing algorithm is modified so that citycars avoid a sharp turn and congested road. The acceleration of citycars is also changed to simulate a smoother movement. Are these changes acceptable for simutrans extended?

Thanks to @shingoushori, recent versions of OTRP contains some construction tools which are useful for the large scale development. The transplantation of these tools to simutrans extended should be discussed as another topic.

Offline ACarlotti

  • *
  • Posts: 483
Re: Oneway Twoway Road Patch for the Extended
« Reply #50 on: August 06, 2018, 09:00:39 PM »
Are these changes acceptable for simutrans extended?

I think there are at least three questions to ask here:
1) Are these features desirable? (Probably? I haven't tested related stuff yet.)
2) Are these features that would also be accepted in Standard (in theory, not just for the current implementation)? (If so, then I think work should probably be to add them to Standard first, so as to minimise unnecessary divergence between the code for Standard and Extended)
3) Is the code well written and likely to be maintainable? (I have my doubts based upon previous code, but will have a look if/when there is a specific proposed patch.)

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18745
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #51 on: August 06, 2018, 11:17:13 PM »
Yes, given some of the problems identified with the previous version of this, we do need to be careful about merging anything other than fixes.

It would be helpful to have two things in particular (1) a separate patch just with the fixes; and (2) a more detailed description (and possibly demonstration) of the new features.

Thank you very much for your work on this.

Offline Phystam jp

  • *
  • Posts: 248
  • Pak256.Ex developer
  • Languages: JP, EN, EO
Re: Oneway Twoway Road Patch for the Extended
« Reply #52 on: August 07, 2018, 09:46:05 AM »
THLeaderH, thank you for your great works!

I have a question about "avoid becoming cityroad" feature.
Currently there is almost same feature in Extended version, and this is implemented with "waytype=noise_barrier" configuration for wayobj .dat file. (but I have never seen it in pak128.Britain-Ex)
So I do not think it should be incorporated for extended version, at least.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18745
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #53 on: March 10, 2019, 02:27:10 PM »
THLeaderH - can I ask whether you might be able to provide:

(1) the fixes on their own; and
(2) a more detailed description of the new features?


Offline THLeaderH jp

  • Coder/patcher
  • Devotee
  • *
  • Posts: 334
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #54 on: March 10, 2019, 04:12:10 PM »
Quote
(1) the fixes on their own;
Yes, I will do that. I apologize for leaving OTRP related bugs for a long time.
However, I've not heard about the defects of OTRP related feature in extended recently. Could you explain some of the defects that I have to fix?

Quote
(2) a more detailed description of the new features?
I apologize for not having provided the description while it had been requested before. Is there any template of feature description or articles that I should refer to write the description?

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18745
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #55 on: March 10, 2019, 10:51:39 PM »
Thank you for your reply. I am not aware of any defects other than those that have been reported on this forum (and I think mainly in this thread). As to documenting the new features, there is not a standard template for this. I suggest that, for each feature, you set out a separate heading and describe (1) what problem that it is seeking to solve; (2) in general terms how it does it; (3) how it works algorithmically; and (4) how it works from a user interface perspective.

Thank you for your work on this so far.

Offline THLeaderH jp

  • Coder/patcher
  • Devotee
  • *
  • Posts: 334
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #56 on: March 12, 2019, 11:28:21 AM »
A description of OTRP for extended.

Oneway Two Lane Road

The road of simutrans standard supports only two-way traffic. Even when the road is operated as oneway with oneway signs, vehicles use only one of two lanes. When roads are congested, the traffic lane is filled and the passing lane is empty.
With simutrans extended, passing lanes are used more effectively than simutrans standard when road is set "oneway mode" by relaxing the conditions to overtake other vehicles. oneway mode enables you to build a 4-lane highway. To set the mode to roads, please select a road icon holding a ctrl key, and the road configuration dialog appears. Halt mode, oneway, twoway, only loading convoy, prohibited and inverted mode are available. With halt mode, vehicles are allowed to stop on the passing lane. This is useful to build a bus terminal.

Show Road Connection Tool

Conventionally, road tile dialogue that appears by clicking the tile was the only way to check which directions the road is connected. With the oneway mode feature for roads, checking road connection is frequently needed. In simutrans extended, simple_tool[37] is assigned to "show road connection tool". This tool visualizes the directions of road connections with arrow images.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18745
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #57 on: March 12, 2019, 12:25:53 PM »
I think that you may have misunderstood the request: my apologies if this was not clear. I was referring to this post. That post referred to a pull request, which contained both bug fixes and additional features for the OTRP. What I was after was:

(1) a separate branch/commit containing only the bug fixes already contained in the commit to which the pull request referred so that I can apply the bug fixes straight away; and
(2) a description of the new features in the commit referable to that pull request so that consideration can be given to whether also to incorporate those features.

The description above seems to be a description of the OTRP generally. I should be very grateful if you could provide the items listed above so that progress can be made. Thank you again for your work on this.

Offline THLeaderH jp

  • Coder/patcher
  • Devotee
  • *
  • Posts: 334
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #58 on: March 15, 2019, 01:50:28 PM »
The bug fixes that I planned to post a PR are
https://github.com/teamhimeh/simutrans/commit/bfd5806f6cc3b4a955929fae403e8c9c051c0750
https://github.com/teamhimeh/simutrans/commit/e7266465ada1cb33e7788c0a736f6ddcae85c527
https://github.com/teamhimeh/simutrans/commit/fb76da14392aeaf3e6fcb0147677d3741ee9a391

The new feature is road reservation. With this feature, vehicles reserve tiles in intersections and this prevents dead lock in big intersections that consists of more than one tiles.

I'm working on TWO pull requests separating the bug fixes and the road reservation. However, I have a trouble in compiling the code. I apologize you to take some more time to post the two pull requests.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18745
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #59 on: March 15, 2019, 02:01:07 PM »
That is very helpful, thank you. There is no rush as there are many other things to be done - but when you have the time, I shall look forward to the bug fix commits/pull requests.

As to the new feature, this is an interesting idea. Do road vehicles often get stuck at intersections? I thought that Standard had solved this issue a while back (and that this had been incorporated into Extended)? I am playing on the Bridgewater-Brunel server at present with a 'bus company and I have not noticed vehicles getting stuck at intersections, but perhaps the traffic is not busy enough in 1942.

I should be grateful for feedback more generally on the tile reservation feature. In the meantime, I shall look forward to the bug fixes. Thank you again for your work on this - it is appreciated.

Offline THLeaderH jp

  • Coder/patcher
  • Devotee
  • *
  • Posts: 334
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #60 on: March 15, 2019, 02:36:55 PM »
Quote
Do road vehicles often get stuck at intersections? I thought that Standard had solved this issue a while back (and that this had been incorporated into Extended)? I am playing on the Bridgewater-Brunel server at present with a 'bus company and I have not noticed vehicles getting stuck at intersections, but perhaps the traffic is not busy enough in 1942.
Traffic stuck can be often seen in the intersection that consists of multiple tiles with a dense traffic like this.


Vehicles checks the existence of other vehicles in advance when they enters an intersection. However, vehicles only checks, do not reserve the tiles. If two vehicles reache the intersection at the same step (time) , the vehicles cannot recognize other vehicles and enter the intersection. This can cause a traffic stuck. Tile reservation can solve this problem, because vehicles reserves the whole path of the intersection before they enter. As a fact, I implemented this feature because users of OTRP for standard reported me that road vehicles often stuck in a big intersection.

I continue dealing with the compile problems and they can be posted in another thread as a bug report.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18745
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #61 on: March 15, 2019, 02:39:25 PM »
Can I clarify - does the problem that intersection reservation addresses exist only when the OTRP features are used, or does it exist even with the roads' default settings?

Offline THLeaderH jp

  • Coder/patcher
  • Devotee
  • *
  • Posts: 334
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #62 on: March 15, 2019, 02:44:20 PM »
Theoretically, this problem exists even with the default settings, twoway mode. However, the traffic stuck phenomenon itself emerges much more frequently when the road is oneway mode. It is not clear why it is.

Offline Phystam jp

  • *
  • Posts: 248
  • Pak256.Ex developer
  • Languages: JP, EN, EO
Re: Oneway Twoway Road Patch for the Extended
« Reply #63 on: March 15, 2019, 04:09:24 PM »
Implementation of “intersection_t” is now needed, as A. Carlotti suggests. This class makes more simpler the code.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18745
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #64 on: March 15, 2019, 05:21:06 PM »
Thank you both for your replies. Some consideration may be needed of whether it would be preferable to implement intersection_t before making these changes; I should be grateful for A. Carlotti's view on that, since it was he who suggested adding this class.