Runtime: Improvements in the System.Random methods

[varocarbas]

When relying on the System.Random methods, I usually expect to get unique numbers; or might prefer to only account for specific values within the input range (e.g., all the numbers from 0 to 1000 except 5, 10 and 200). That's why I am used to complement my calls to these methods with a code like this one:

``` C#
private static int GetRandom(int min, int max, int[] toIgnore)
{
Random rand = new Random();
int outVal = min;

while (true)
{
    int number = rand.Next(min, max);
    if (!toIgnore.Contains(number))
    {
        outVal = number;
        break;
    }
}

return outVal;

}

This code can become a bit more complex under certain conditions to avoid too-slow/infinite loops, but it is a quite simple implementation anyway.

Can I write a code like the aforementioned one every time I need `System.Random` to ignore certain numbers? Sure. Is such an eventuality part of the most common requirements associated with using random numbers (and, consequently, should these methods account for it)? I think so. 

I am also proposing to add new overloads for other commonly-used numeric types (i.e., `long` and `decimal`).

Below these lines, you can find all the API calls associated with my proposal together with the existing ones.

``` C#
public class Random
{
    //---- Existing
    public int Next() { }
    public int Next(int maxValue) { }
    public int Next(int minValue, int maxValue) { }
    public double NextDouble() { }
    public void NextBytes(byte[] buffer) { }

    //---- New
    public int Next(int[] ignoredValues) { }
    public int Next(int maxValue, int[] ignoredValues) { }
    public int Next(int minValue, int maxValue, int[] ignoredValues) { }
    public long NextInt64() { }
    public long NextInt64(long[] ignoredValues) { }
    public long NextInt64(long maxValue) { }
    public long NextInt64(long maxValue, long[] ignoredValues) { }
    public long NextInt64(long minValue, long maxValue) { }
    public long NextInt64(long minValue, long maxValue, long[] ignoredValues) { }
    public double NextDouble(double[] ignoredValues) { }
    public decimal NextDecimal() { }
    public decimal NextDecimal(decimal[] ignoredValues) { }
    public void NextBytes(byte[] buffer, byte[] ignoredValues) { }
}

In case of going ahead with these suggestions, I would like to take care of the implementation myself. Additionally and as discussed in some of my previous issues, I want to highlight my interest in minimising everyone's unnecessary efforts; for example, I wouldn't find any problem with a relatively quick "sorry, but we aren't interested in this implementation for the time being".

[svick]

All I can do is to be part of a discussion, including details like naming. So, feel free to ignore me to whatever degree you want.

---

I usually expect to get unique numbers; or might prefer to only account for specific values within the input range

I think that getting a sequence of unique numbers sounds like a relatively common requirement. But I'm not sure why would you want to exclude specific values otherwise, could you explain what the use cases for that are?

And when it comes to getting a sequence of unique numbers, I think the convenience methods you proposed are not very convenient and using them would also lead to fairly inefficient code.

Consider something like:

``` c#
public static IEnumerable NextNUnique(this Random random, int n)
{
var alreadySeen = new List();

for (int i = 0; i < n; i++)
{
    var next = random.Next(alreadySeen.ToArray());
    yield return next;
    alreadySeen.Add(next);
}

}

It's not convenient, because I had to write the helper method. And it's not efficient, because I have to allocate new array on every iteration and because `Random` can't really use some better data structure internally.

Both my issues could be solved by adding a method like `NextNUnique` (probably with a better name), instead, or in addition to, the overloads you propose.

---

``` c#
public long NextLong();
public long Next(long maxValue);

This does not follow Framework Design Guidelines. Method names should be language-independent, i.e. the method name should be NextInt64, not NextLong.

Also, I think it would be more consistent if all long-returning methods had the same name.

---

c# public decimal NextDecimal();

What distribution does this method have? Is it the same as NextDouble(), which returns values in the interval [0, 1), using effectively uniform distribution (though this second part is not documented)?

[varocarbas]

@svick

So, feel free to ignore me to whatever degree you want.

Why would I ignore you? Have I ever done such a thing in the past? I never ignore people unless under very specific circumstances (e.g., unreasonable individuals). I want to certainly minimise the discussion, but I guess that you know that from previous conversations with me (didn't write this in my post). I think that you misunderstood the minimising everyone's unnecessary efforts part; it was meant to ensure a quick rejection in case of not being of interest for the .NET team (to avoid the situation of waiting for months and being rejected anyway).

you want to exclude specific values otherwise

Today, I was precisely working on a code having this requirement. I had a list with 900 elements and a loop iterating through each of them. In each iteration, other two random elements in that list except the current one were chosen. For example, with a list formed by {0, 1, 2, 3, 4, 5}; in the first iteration, a random number from 1 to 5; in the second iteration, from 0 to 5 except 1; in the third iteration, from 0 to 5 except 2; etc.

adding a method like NextNUnique

A fair enough proposal. As said, I do see the utility of ignoring some values within the given range, but something (i.e., addressing just the unique numbers scenario) is certainly better than nothing.

the method name should be NextInt64, not NextLong.

Already fixed.

I think it would be more consistent if all long-returning methods had the same name.

I agree. This was a typo which I fixed a short while after posting the issue, but apparently not before you seeing it and writing your reply.

What distribution does this method have?

The intention of my proposal is to emulate NextDouble and, consequently, to have [0,1) too.

[dasMulli]

Assuming your list of excludes is sorted and contains no element > max / < min, you could write the following (not tested):

``` c#
private Random rnd = new Random();

private static int GetRandom(int min, int max, int[] toIgnoreSorted)
{
var outVal = rnd.Next(min, max - toIgnoreSorted.Length);

foreach(var ignored in toIgnoreSorted)
{
    if (outVal < ignored) return outVal;
    outVal++;
}
return outVal;

}
```

It's just creating a continuous virtual range of numbers and mapping it to the fragmented range. The time complexity is O(n) of toIgnoreSorted.Length. And you will get Random's distribution algorithm for all values, not introducing any bias (except for Random's implicit bias as it is just a pseudo-random algorithm).

Also, always re-use the same Random instance so you actually get the pseudo-random algorithm and not just it's seeding logic. The default constructor uses Environment.TickCount which is in milliseconds, but increases only at the system's timer resolution interval which can be up to ~15ms on desktop machines so if your code runs fast enough, you will get the same number multiple times.

[varocarbas]

@dasMulli

Assuming your list of excludes is sorted and contains no element

Too many assumptions (= you have to make sure that the input set verify them = you have to spend additional resources).

you could write the following (not tested)

No, I couldn't. Your code has numerous mistakes, as explained below. In any case, note that I wrote a sample code to illustrate my point; this isn't even the code which I would be implementing in the proposed APIs. Additionally, this isn't a StackOverflow-like forum where I am asking my doubts and random people (with random knowledge and random understanding capabilities) come up with answers like "you could write the following (not tested)" (BTW, in that case, I would be answering rather than asking). The whole point of this discussion is to agree/disagree with the modifications which I am proposing: adding a list of items to be ignored by the corresponding System.Random methods (+ accounting for additional types) or not.

There are quite a few problems in the code you wrote. You are clearly trying to come up with a binary-search-based algorithm, but you aren't doing it even right. First of all, you should replace your "Assuming your list of excludes is sorted..." with actually sorting the array because this is part of the resources which have to be measured to determine the best approach. Secondly, your var outVal = rnd.Next(min, max - toIgnoreSorted.Length); is wrong; not sure what you are trying to accomplish there, but this doesn't make any sense (+ potential source of errors/crashes). It seems that what you want to do is var outVal = rnd.Next(min, max - toIgnoreSorted.Max());, but still no idea why (+ potential source of errors/crashes). Other interpretation might be var outVal = rnd.Next(min, toIgnoreSorted.Min());, still not sure why and still potential source of errors/crashes. So, the most logical first step would be var outVal = rnd.Next(min, max);, why trying a different thing?! The whole point of having min/max variables is actually using them. Other error is using private Random rnd (non static) inside a static method; you have to make private static Random rnd or, even better (relying on global variables so easily isn't precisely an ideal proceeding), pass it as an argument. Other error is that you aren't confirming that outVal remains within the min/max range inside the loop (new source of errors/crashes). Your code doesn't compile. Even after making it compile, it would crash under many scenarios. On top of everything, it would also deliver wrong outputs (i.e., outside min/max).

Your approach of plainly adding rather than calling again Random isn't that bad (actually, I do that in some cases), although as said, you should make sure that the value remains within the min/max boundaries. Regarding iterating through all the contents of the array to ignore (+ ordering it) vs. doing a while (true) and relying on the very efficient .Contains (or you might use the even more efficient .BinarySearch), it would depend upon the conditions, but in principle I do prefer my option (or a similar one) because it is much more neutral to the number of items to ignore (the in-built methods are really fast and don’t care much about relevant changes in the array size). The best way to know for sure the best approach? Doing tests under a reasonably-big number of different input conditions. Is it sensible to blindly recommend one alternative over the other one as objectively better? Certainly not.

it's just creating a continuous virtual range of numbers and mapping it to the fragmented range

Where is all this exactly happening? In your imagination? You aren't creating anything, you are plainly assuming certain conditions (the values are ordered) which, in a real scenario, you should make sure that happen at all (= ordering them yourself and check whether the values lie inside/outside the boundaries).

Also, always re-use the same Random instance so you actually get the pseudo-random algorithm and not just it's seeding logic

Thanks for a new non-requested advice from what I consider (no offense) a quite unreliable source. Here goes mine: as what happens with most of generic statements, yours is wrong; there is no general rule, it depends upon the given conditions (including special cases; note that the behaviour of System.Random methods when dealing with multiple threads is a bit special); although in most of scenarios, it is better to reuse the same instance. FYI, the reason why I didn't use the same instance in my extremely-simple-just-to-give-a-preliminary-idea-ideally-to-properly-understanding-prone-people was to not unnecesarily increase the complexity. Note that the whole point of this issue isn't showing my code (and clearly not asking for advice), but proposing changes in the System.Random methods (e.g., adding Next(valuesToIgnore) on top of Next()); that's why I tried to keep my sample code as similar to the proposed changes as possible (where a Random instance wouldn't be provided as an argument).

And?! No comment about my suggestions? You are writing a (very) faulty code to correct inexistent problems/address inexistent concerns and you aren't even saying a word about the whole point here?! Do you think that the new overloads should be included or not?! What are your ideas on this front? Your personal experiences? Why are you participating here if you are plainly ignoring the only thing about which you should be concerned?

You aren't making any effort to understand what is going on here; you aren't making any effort to propose a relevant improvement (what you wrote wasn't requested or required and is even completely wrong); you aren't even using this issue as intended! You are plainly trying to force your participation by showing a knowledge which you don't seem to possess (first step to solve a problem is understanding it). What is this? Some teachers are pushing their students to participate in open-source forums and I have to be part of the learning process? Or is it about people with some kind of obsession whose only point is provoking chaos? (I am a magnet for them because of my first attempt here or for my numerous I-dont-care-about-your-fanaticism-based-whatever outputs?). Either way, I don't have to tolerate any of this.

In summary, your contribution represents an excellent sample of the kind of behaviour which I will be ignoring. Sorry if someone misguided you or if you are plainly too wrong (learn and grow), but nothing of this is my problem (= I don't have to waste my time to teach you, to show you how to behave or even to make an effort to be polite to someone showing a so invasive/careless/non-understanding behaviour).

[varocarbas]

@svick

After answering to the last contribution (and quite a few past experiences, some of them with you), I think that it will be better to systematically apply "let's call everything by its exact name, just to avoid problems" ideas.

I guess that you work for the .NET team and you are expected to somehow trigger a discussion (+ help to correct problems). I don't want to make anyone's work harder, but this is precisely the point of this post and my underlying intention.

Yesterday, I accepted your suggestion of NextNUnique without even looking at your code, mainly to somehow appraise your contribution (-> my opinion in general? Not always perfect, but most of times somehow relevant. Perhaps, you should analyse the given problem a bit better; it seems that you are more interested in delivering quick answers rather than accurate ones. Logically, you are completely free to ignore my opinion). But some people tend to misunderstand me when I behave in this way, what provokes the aforementioned bad-to-everyone situations. That's why I will better be completely honest with you on this front: I don't fully see it, at least not as per your proposal. The code you wrote is faulty. Could you please write a proper code which can somehow support your claim that such an alternative would be more efficient than only accounting for the ignored values? How are you expecting to pass the already-used information? You should also bear in mind the existing overloads and the general expectations (= the less modifications, the better).

Hopefully, this somehow weird post will not bother you. As said, all what I want is to minimise everyone's useless time wastes and/or not-positive-to-anyone outputs.

[stephentoub]

@varocarbas, I appreciate your passion and interest, and your desire to contribute. I want to let you know that, at least from my perspective, many of your comments come off sounding combative and insulting. Chastising someone for providing what you believe is unsolicited advice, stating that things are happening only in one's imagination, calling someone an unreliable source, etc. I realize that writing can be an imperfect form of communicating sarcasm, humor, and the like, so you may not have meant any of your comments to be taken negatively, but here and in previous posts from you, I've seen similar behaviors; if it's unintentional, then please excuse me and just know that's how some people perceive it, and if it's intentional, we have a code of conduct for this repo, and we would appreciate it if you'd follow it (http://www.dotnetfoundation.org/code-of-conduct).

As for discussion, you seem to want to throw out an idea for an API and just get an up/down vote from someone, "minimizing" discussion. That is not how this process works. We only want to add features that are proven in value, that don't have existing good alternatives, that don't themselves lead to additional problems, that will be valuable to many developers, etc. Discussion that gets to the heart of what you're trying to accomplish, discussion of alternatives, discussion of how others have solved the same problem or similar problems, discussion where others get to cite whether something would be useful to them and for what scenarios, discussion of related issues, etc., is all part of that process. If you're looking for a simple yes or no answer without any discussion, then the answer will be no. But if you're amenable, we're happy to have a fruitful discussion about all aspects of the proposal before such a decision is made.

Thank you.

cc: @terrajobst, @weshaggard, @martinwoodward

[varocarbas]

@stephentoub

come off sounding combative and insulting

I am sorry that you see it in this way, because my only intention is making sure that the conversation doesn't derail much. Perhaps my tone is a bit hard, but there are some reasons for it; to not mention that it pursues a beneficial-to-everyone goal. In any case, I do understand that my behaviour might be some times against what you like.

If you're looking for a simple yes or no answer without any discussion, then the answer will be no. But if you're amenable, we're happy to have a fruitful discussion

No problem with a fruitful discussion. My intention is transmitting my ideas clearly enough, rather than imposing them. I am not looking for a simple yes or no, but for you feeling completely free to say "no" right away in case of already considering this to be the most likely output for my proposal.

Thanks (to you and the other .NET team members) for being understanding with an attitude which isn’t too compatible with what most of people think here. I am sure that my ideas are now completely clear (also yours) and, in the future, I will plainly apply them. From now on, in case of not agreeing with certain behaviour, I would plainly ignore that person or write a clear but polite answer. No more explanations or a bit-too-aggressive comments.

[stephentoub]

Thanks, @varocarbas :smile:

[svick]

@varocarbas

I guess that you work for the .NET team

I do not. I am a non-MS contributor, just like you. (Though ask me again in two years, maybe the answer will be different by then 😄.)

you are expected to somehow trigger a discussion (+ help to correct problems)

My aim is not really to trigger a discussion. It's to express flaws that I perceive in proposals and to get them fixed, if others agree with my perception.

The code you wrote is faulty. Could you please write a proper code which can somehow support your claim that such an alternative would be more efficient than only accounting for the ignored values? How are you expecting to pass the already-used information?

My code was meant to show that your proposed API is not sufficient for the "getting a sequence of unique numbers" use case. I'm not sure what you mean by "faulty", but my implementation of NextNUnique is certainly inefficient, which was my point.

A proper implementation of NextNUnique (i.e. one not built on top of your proposed int[] ignoredValues overloads) would definitely be more efficient; at the very least, it wouldn't have to allocate a new array for every random number on the output. (That could be achieved by passing ignoredValues as a List<int>, or possibly by using a more complex implementation, probably based on binary search.)

[varocarbas]

@svick

I do not. I am a non-MS contributor, just like you.

Seriously? By answering so much and so quickly? (You wrote your reply to my first post around 30 mins after I wrote it!). Honestly, I thought that you were somehow related to Microsoft, perhaps not a member of the .NET team but paid by them. Sorry for the misunderstanding.

A proper implementation of NextNUnique (i.e. one not built on top of your proposed int[] ignoredValues overloads) would definitely be more efficient

How do you expect to avoid repeating random numbers without storing the previously generated ones? Most of the System.Random methods output one single value and I am not proposing to change this aspect. That's why I can only think of one way to implement this functionality: passing an array with the values to be skipped; exactly what I proposed.

[svick]

Most of the System.Random methods output one single value and I am not proposing to change this aspect.

I don't see why this is something that shouldn't be changed. If the goal is to make generating a specific kind of a sequence of random numbers better, then I think it's natural to do that using a method that returns a sequence, especially if doing that was more efficient.

That's why I can only think of one way to implement this functionality: passing an array with the values to be skipped; exactly what I proposed.

If I accept your assumption that Random should always return values one by one, then a more efficient way would be to accept IEnumerable<int> instead of an array. That way, you can reuse one List<int> (or another collection) for multiple iterations. With array, you have to reallocate it whenever you add (or remove) an item.

[varocarbas]

@svick

I don't see why this is something that shouldn't be changed

Mainly because of the way in which things work around here. Improvements in existing method are quite difficult to be accepted; the more modifications, the less likely the proposal to go through. I think that my original suggestions are quite good because of covering the probable scenarios and not requiring many modifications.

then a more efficient way would be to accept IEnumerable instead of an array

I plainly emulated the most common structure for these cases (most of the in-built methods take arrays as arguments). Although IEnumerable does seem to be a better option, I am not sure about the reason for arrays being so commonly used either (because most of these methods were created long time ago? To minimise memory usage? No idea); that's why I don't have a clear preference on this front.

[AlexGhiondea]

@varocarbas thank you for your proposal.

I am not sure if we want to take the overloads that use the array of ignored values. As you pointed out in the first post, writing code that will filter out the values is trivial and would not seem to add a lot of value as an API in Core.

I do see some potential value in having the NextDecimal and NextInt64 APIs.

@terrajobst what do you think?

[varocarbas]

@AlexGhiondea OK.
BTW, would you mind to remove the up-for-grabs tag? In case that my proposal is accepted, I would like to take care of this implementation myself and some people might find that tag misleading.

[AlexGhiondea]

@karelz I have assigned @varocarbas the issue. Is that the right thing to do to make sure people know who is working on an up-for-grabs issue?

[karelz]

We do not have to remove the up-for-grabs - assignee set means someone is working on it.

BTW: Assigning it to someone before the API is approved is a bit premature, unless that person is driving the API design discussion, but I don't care that much :)

[varocarbas]

@AlexGhiondea @karelz OK. I thought that up-for-grabs was just for issues whose proposer wasn't willing to take care of the implementation (none of the issues I have created so far got that tag). Sorry about the misunderstanding.

[karelz]

Are we ready for API review @AlexGhiondea? (marking so, feel free to undo)

[SunnyWar]

Concerning the proposal, I've had to write similar code several times and never thought to myself that the Framework should provide it. In my experience, the primary use for something like this is to randomly pick from a range or collection of values and not repeat one until the range or collection of values is exhausted. Given this use-case, the proposed API adds little value.

[JonHanna]

For the case @SunnyWar mentions a shuffle method would perhaps serve better than a random-with-ignore. Fisher-Yates has optimal performance for that and doesn't succumb to bias as some approaches do, but is wasteful if one wants just a few elements from a large potential set (since it's O(n) in space relative to the source range). It's possible to use a variant with a Dictionary<int, int> as the source (or a cut-down version of that, since not all of its overhead is needed) flipping to an array once that no longer saves anything, and hence avoid that memory cost. There's a simple Fisher-Yates implementation in the tests for System.Linq but as a test helper class it doesn't bother with any optimisations, wasn't thoroughly checked for bias (wouldn't hurt the tests its used for if it was slightly biased) etc.

[karelz]

Should I read it as that the proposal doesn't have a strong support from community yet?
Does it need more bake time?

I admit I didn't read the whole thread, but until we have majority involved community members agreeing with the proposal or at least with its direction, then we should not submit the proposal to API review.

@svick @dasMulli @SunnyWar @JonHanna do you want to chime in?

[SunnyWar]

@karelz I'm against this proposal as it stands. It does not solve the stated problem directly. To try to use it to solve the problem is inefficient and cumbersome. Sorry, I'm just not seeing the value the way it stands now.

btw: I think the case of generating a unique set of random values from a range or collection is common enough to be considered for addition to the framework, I just don't think this is the right way to go about it.

[JonHanna]

The idea of a shuffle method has been asked for a few times before, and rejected, but I think it's common enough and easy enough to accidentally introduce bias when rolling ones own that it would be worth adding.

For the cases where either this or shuffle would be useful, shuffle would be superior.

I don't see other cases being common, but maybe there's some domain where it comes up a lot that I don't know.

[karelz]

@JonHanna so your position is: No for this particular API shape. General direction is ok, if we make it "shuffle". Did I get it right?

[JonHanna]

It's no, but if I learnt of use-cases that weren't better-served by a shuffle, then I'd reconsider. (Assuming that because I can't think of any such uses means there aren't none, would be arrogant 😄 )

[karelz]

Looks like we do not have consensus yet. Flipping back to api-needs-work. If substantial number of votes tips it the other way, we can change it again :)

[varocarbas]

@SunnyWar Sorry for joining a bit late this chat. Just wanted to thanks you for your extremely valuable contribution.

Nice nick and pic, although kind of incompatible with the personality you have shown. I mean... some people might have some prejudices about the true intentions of someone whose nick includes "war", has a pic like the one you have and comes with a so curious concern in a so curious moment.

(To address the confused emoji which this post got 1-min after being written, I do confirm that I am being 100% sarcastic and that I don't understand what might be the motivation of anyone to do what this war-guy did. Perhaps because I am a peaceful person who hasn't ever felt irrational hate for anything/anyone, who only wants to understand and be understood and who will never do anything for the sole purpose of bothering/damaging others/arbitrarily censoring/trying to impose his own views/elevating himself to absolute authority and dismiss others opinions/including the word "war" while defining himself/ etc.)

[varocarbas]

@karelz Not sure if you read my last comment to terrajobs (I wrote it in a thread to which you might be subscribed), but here comes a good summary just in case: I don't want to create problems, neither I will tolerate certain behaviours. As proven by what the war fellow above did or the emoticon which my answer got just 1 minute after being written (-> equivalent behaviour than the one which motivated my aforementioned message to terrajobs), I (or what I do) cannot avoid being a magnet for some attitudes.

Feel completely free to close all my pending issues if you like, because continuing with the conversations in any of them will most likely drive to certain tone (about which I don't really care, but which seems to bother some people here). Also understand the reason why I prefer to not participate anymore: certainly not because of agreeing or accepting certain attitudes (fanaticism/unfairness will never succeed if I am around). What you (as a community) seem to accept/expect is different than what I do, pure and simple. I plainly don't like what you can deliver, neither you like what I do. That's why I don't see the point of continuing participating here.

[varocarbas]

@JonHanna I saw that you were the confused-emoji guy. Yes, this is a certainly off-topic post, but IMO motivated for quite a few reasons. I think that we discussed the technical aspects of my proposal at the start. I continue thinking the same than before (i.e., I would like to have this feature), but apparently not too many people think like me (or the noisy ones or the ones whose motivation I don't understand).

As far as the reasons for one and the other side (being useful or not) should be extremely clear since the start and I don't see how I could convince anyone (neither interested; the reason for all my issues was assuming that other people would think that they were useful, otherwise what would be the point? I don't need to convince anyone to see things as I do. I can create my own code to address my own needs), I cannot understand the point of continuing this conversation. But, as written above to karelz, it might be because of me, because this is not my place and cannot share/understand some of the motivations/expectations/behaviours here (neither want to change anyone's views, just highlighting mine).

[karelz]

@varocarbas
I'd like to ask you to reread https://github.com/dotnet/corefx/issues/12492#issuecomment-252607964 above and also code of conduct.

Please refrain from any attacks on others in your responses (incl. discussing their user names, past behavior, etc.), please keep the discussion strictly technical. If you were personally offended by someone in the past, please try not to bring it back over and over again. It's not helping anyone, it actually hurts you and your image more.
Also, we will not tolerate such continuous behavior as it violates code of conduct.

---

I tend to believe that every person means well in his/her heart. From your responses I have a feeling that you also try to mean well deep down inside, so let me try to help you see what you might be missing.
(please take the following as well-intended personal advice and feel free to discard it if you strongly disagree, or feel free to follow up offline via email if you want to)

I don't want to create problems.

I appreciate that. What would truly help is to not getting personal and sticking strictly to technical discussion. If you feel offended by an answer or emoji reaction, step back and first ask yourself and/or the person, what they meant? If they get personal, ignore it and let project maintainers deal with it. If you think project maintainers are missing some personal attacks, report it to them (there's email contact in code of conduct).

neither I will tolerate certain behaviours

Understood. However, personal attacks are not the right response on this repo, even if you feel offended. If you feel attacked, ignore the attacks, raise awareness to project maintainers. Definitely don't attack back, resist the temptation, stick to technical discussion only.
As an example: Look back at your replies from last 24h. There has been strictly technical discussion since your last reply in December. You dragged personal attacks back into the game. That's not cool. Your response was unprovoked in this case.
I understand you may be frustrated with some community members from past engagements, however, I would strongly encourage you to get over such encounters and start fresh, stick to technical discussions with them and ignore anything else.

As proven by ... the emoticon which my answer got just 1 minute after being written

First, I don't see anything bad on having fast reaction to a post via emoticons. It expresses immediate feel and provides early feedback to author of the reply/post.
In this particular case, I was actually tempted to do +1 on the same emoticon, because it captures how I feel about personal attacks being dragged back into the game. I decided a clarifying response will be better received than just an emoticon.
Note: I am not trying to defend this particular emoticon. I don't know if @JonHanna had the same reason in his mind.
The key advice I have here is to first find out what people mean, before jumping to assumptions and conclusions. Don't get offended by emojis, if you don't like them and you think they are unjust, ask the people who added them what they meant (as you partially did in next reply). Or ignore them.

Not sure if you read my last comment to terrajobs (I wrote it in a thread to which you might be subscribed
(-> equivalent behaviour than the one which motivated my aforementioned message to terrajobs)

I am not sure which reply you refer to (sorry, I don't have such great memory), but I feel you covered it in your response here. If there's more, feel free to follow up offline with me. I'll be happy to provide more insights.

I (or what I do) cannot avoid being a magnet for some attitudes.

I understand your feeling. I strongly believe that if you stick to pure technical discussions, you will find out that you are not magnet at all. Just try to stay away from personal attacks, that's all.

---

Feel completely free to close all my pending issues if you like,

Let's take emotions out first.
Issues are technical proposals. We should close them only if there is consensus in the community that the proposal is not viable/reasonable/in the right direction.
The only tricky part is: What happens if one or two people strongly believe in X, while 5-10 other community members are against? Should we close such issue?
I don't have strong opinion. I am fine leaving it open to collect more ideas over time, if nothing new comes, it can be always closed later. I leave the decision to the people who filed the issue and to the area experts in such cases.
The key thing is that we don't want to come over as dismissive to alternative ideas, or to hurt anyone's feelings.

because continuing with the conversations in any of them will most likely drive to certain tone (about which I don't really care, but which seems to bother some people here).

If the tone is leading to personal attacks, then it's a problem. Everyone should care about his/her tone from that perspective. Stick to technical discussion, without personal attacks and everything will be fine.

Also understand the reason why I prefer to not participate anymore: certainly not because of agreeing or accepting certain attitudes (fanaticism/unfairness will never succeed if I am around). What you (as a community) seem to accept/expect is different than what I do, pure and simple. I plainly don't like what you can deliver, neither you like what I do. That's why I don't see the point of continuing participating here.

I didn't fully understand all your points here, but ultimately OSS contributions are voluntary and OSS rules (incl. code of conduct) have to be respected in each project. It is up to you to decide if contributing to CoreFX is valuable to you and if you are ok to respect the rules of CoreFX.

as written above to karelz, it might be because of me, because this is not my place and cannot share/understand some of the motivations/expectations/behaviours here (neither want to change anyone's views, just highlighting mine).

I am not sure what you refer to. I don't think I wrote anything close to that on this issue. Would you mind to clarify why you think I did? (maybe I am missing something)
Either way, it is up to you to decide if you want to accept the rules of CoreFX (incl. no personal attacks) and keep contributing.
We would never force anyone out of repo, just because the person has different technical view points. But we will ask everyone to respect the rules and be polite.

[varocarbas]

@karelz

I'd like to ask you to reread dotnet/corefx#12492 (comment) above and also code of conduct.

Even better: comment where I expressly said that I will not behave like this ever again. There is no justification for my behaviour, other than this being my official farewell :)

I tend to believe that every person means well in his/her heart. From your responses I have a feeling that you also try to mean well deep down inside

I have to cut you right there, because my principles (among them always acting in good faith) are the most important thing to me. I don't mean well deep down; I mean well right away in each single action. You don't agree with my means and it is OK, but don't misinterpret my motivations so horribly. I do recognise that I have shown a too aggressive (mainly for what most of you consider acceptable) attitude quite a few times, but always for a reason. A punctual reason, but also an accumulated reason after having tolerated many things (take a look at all my issues, all what I wrote and all what I had to address). To not mention that I am straightforward and honest when some people here prefer to show a quite sneaky (to say it really softly) behaviour. My intention has always been to create/propose/improve, but I had faced quite a few people almost (or directly or sneakily) attacking me and taking my proposals as almost offences (?!). I accept that this isn't my place and that a behaviour which I consider somehow justifiable is completely unwelcome here (don't agree with that but respect it). That's why I will better not participate more, but please don't offend me by even insinuating a slight bad faith in any of my actions (much less after the behaviours which I have seen here).

Your response was unprovoked in this case.

You are right. I do recognise that this wasn't my most-reasonable reaction (although by bearing in mind all the accumulated "peculiarities", the story might change a bit).

I didn't fully understand all your points here

As said, all this comes from numerous events in different issues/chats, what I do understand that you don't have to know (or even share my interpretation).

I am not sure what you refer to.

I was referring to my previous post to terrajobs, where I explained all this thing of not being willing to change my behaviour and accepting that this isn't my place.

Anyway, thanks for your efforts in trying to address my behaviour, but I am afraid that there is no solution. I will better focus on applying what I say and stop participating here (at least, in certain kind of discussions). In any case, I want to highlight that I did get a good impression (contents under "OVER-8-MONTH-LATER UPDATE") about the .NET team/community. Also feel free to do whatever you wish with my issues (in fact, they belong to the community, not to me), but understand that I might not participate in future discussions (unless being sure that 100% objective aspects will be discussed).

[karelz]

Thanks @varocarbas for your reply. I wish you best luck.

Back to discussion on this issue:
Given that we have some push back on the proposal, and the discussion is somewhat tainted with off-track discussions, I will close this particular issue. -- If someone is passionate about the direction and has different/improved API proposal, please file a new issue. Feel free to reference this one if you find it useful.

If someone disagrees with my conclusion, please say so and we can reconsider. Thanks!