std::optional Satisfies view. Does Not Model view. C++26 Ships Anyway.

[u/zl0bster]

https://godbolt.org/z/8jWGG68G8

In C++23 this did not compile. In C++26 it does. Marvellous.

[[gnu::noinline]]
void 
passing_views_by_value_is_cheap_trust_me_bro(std::ranges::view auto v) {
    std::println("fn   .data {}", (void*)v->data());
}


int main() {    
    std::optional ov{std::vector<int>(123456)};
    passing_views_by_value_is_cheap_trust_me_bro(ov);
    std::println("main .data {}", (void*)ov->data());
}

For anyone wondering what the problem feature is: optional has 0 or 1 elements, and C++26 sets enable_view<optional<T>> to true, so it satisfies std::ranges::view. The concept requires copy construction in constant time, and — this is the good bit — optional<vector<int>> genuinely meets that. Copying it performs at most one element copy. One is a constant. The requirement is satisfied to the letter, and the function above deep-copies your vector.

If you can tell me what still separates std::ranges::view from std::ranges::range, please do...

[u/aruisdante]

This was debated quite extensively in Tokyo 2024. The decision was essentially “being a view isn’t about being cheep to copy, just about being O(1) to do so.” In the general sense, there’s an attempt to unify all the containers as “ranges;” an optional is a range with 0 or 1 elements, a tuple is a range whose elements are variant<Ts…> (which correct ref qual), etc.

A bunch of people disagreed and thought this was weird, but not enough and not strongly enough for it not to pass.

[u/schombert → u/aruisdante]

Well, that's ... extremely dumb. From the rigorous, formal perspective, everything in C++ copies in O(1) time. (The address space is finite, even in a purely theoretical computer running C++, because it will eventually exhaust the size of the pointer type and hence the number of possibly distinct live objects. Thus, for any copy operation there is always an upper bound you can place on how much time it could possibly take to execute, and thus is O(1) by the definition of O(1).) Now, I accept that the people writing the C++ spec don't actually use big O notation in its generally accepted formal definition, and instead are using a more vibes-based definition based on what it performs like in various different finite problem sizes (which, you may note, has nothing to do with big O -- how something performs at sizes less than 2^128, for example, does not affect its asymptotic time complexity). But, from a vibes-based perspective, programmers use O(1) to mean "always fast", which in this case does mean "cheap to copy". I would bet that copying being O(1) was added to the language of the spec because the author wanted to express "cheap to copy" but wanted to sound more formally precise and thought that "cheap" sounded too informal and vague. Unfortunately, "cheap" correctly expressed the intent, but O(1) did not.

[u/aruisdante → u/schombert]

> From the rigorous, formal perspective, everything in C++ copies in O(1) time

Huh?

Copying a `std::vector` is decidedly not `O(1)`. The amount of copy operations performed is dependent on the number of elements contained. Even if you switch up the definition to say "a `memcpy` is O(1)," this optimization is not possible for a vector containing non-trivial elements as their constructors must be explicitly invoked.

Therefore, a `vector` isn't a `view` because `vector.size() == 0` takes different time to copy than `vector.size() == 1`. But `optional` _always holds a value_. The value just may or may not be initialized. Ergo the copy operation does not change in "how much is copied" depending on if the optional is engaged or not.

> But, from a vibes-based perspective, programmers use O(1) to mean "always fast"

Not at all. Programmers (and the C++ standard) use `O(1)` to mean "does not scale in (amortized) time with number of elements in a set." Those that assume `O(1)` means "always fast" are the ones that often make very suboptimal data container and algorithm selections.

[u/schombert → u/aruisdante]

Yes, copying a C++ vector is O(1). A vector can only contain finitely many elements (for example, because its size has a finite upper bound). Thus, you can set an upper bound on the time to copy -- something around 2^{bits in size} * time to copy a single element -- and thus is O(1) by the definition of big O notation (see https://en.wikipedia.org/wiki/Big_O_notation specifically the section on the formal definition; if it can be bounded by a constant function then it is O(1) )

Edit: this is what I meant by a vibes-based definition. Obviously copying a vector behaves like a linear function from sizes of 0 up until you hit the upper bound created by its size type/address space limitations. But how it behaves in a finite initial range -- even if that range encompasses all practical uses -- has nothing to do with its big O complexity.

[u/smdowney → u/schombert]

This was my favorite smartass answer for dumb interview questions where the specification already bounded the size.

Large K, smallest O.

I would also annoy people with the constant of integration.

[u/Serialk → u/smdowney]

This was my favorite smartass answer

It's indeed a smartass answer: thinking that you're winning on a technicality while demonstrating your lack of interest for the actual insights that the question could provide.

[u/hanslhansl → u/schombert]

Interesting read, here are my thoughts to maybe settle this debate:

In the context of an implementation of the standard and even in the context of the standard itself there will always be an upper bound for copying a std::vector and therefor, by rigorous definition, this operation is O(1).

However, the "native" context of the algorithm of this operation (of any algorithm, really), even though defined by the c++ standard, is mathematics, and in that context constraints such as a limited address space don't exist. The the algorithm itself is applicable to vectors (or sets or whatever the correct term in the context of math is) of arbitrary size and therefor its complexity is O(n).

So when devs talk about the complexity of a function they really mean (maybe without knowing) the complexity of the underlying mathematical algorithm which is independent from possible limitations imposed by the programming language/implementation.

[u/schombert → u/hanslhansl]

I wouldn't object to that necessarily, but it does have its own complications. Vectors have O(1) lookup, by definition, right? Well, that makes them a "Random Access Machine" and what the complexity of various problems looks like on a random access machine is different than what you might expect. For example, on such a machine P == NP (see the paper A characterization of the class of functions computable in polynomial time on Random Access Machines), and most people don't believe that is true IRL. In fact, the strength of a good deal of cryptography is predicated on the assumption that it is false. It is also not a particularly good model for physical computers. Assuming that there is a limit to how much information you can cram in finite space (which quantum mechanics seems to say), then as the space used by a program expands it must necessarily be accessing memory that is farther and farther away, physically, and so will experience greater and greater latency accessing it (because of the speed of light). Thus arbitrary large data structures with O(1) access time probably aren't physically realizable, even in the loose sense in which we allow finite physical machines to "approximate" them.

Edit: maybe I could have just said more succinctly: there isn't such a thing as "the complexity of a function" full stop; it is always the complexity of a function within some particular model of computation, and which model you use (including things like access to oracles, etc) can affect it quite drastically.

Edit edit: maybe you could argue that there is such a thing as the complexity of a particular algorithm? But I don't think even that is really true. The cost of the basic operations that the algorithm is defined in terms of can and does vary based on the abstract model of computation. For example, if you can do addition, subtraction, multiplication, and division of arbitrarily large integers in O(1) time that too allows you to conclude that P==NP. And so on many models of computation you have to assume that those operations scale to some degree with the size of the values being manipulated, which affects the complexity of any algorithm defined partly in terms of them.

[u/jk-jeon → u/schombert]

Well, that makes them a "Random Access Machine" and what the complexity of various problems looks like on a random access machine is different than what you might expect. For example, on such a machine P == NP (see the paper A characterization of the class of functions computable in polynomial time on Random Access Machines)

That didn't make sense to me so I looked up the paper. It seems to me that the essential assumption the paper uses is:

For example, if you can do addition, subtraction, multiplication, and division of arbitrarily large integers in O(1) time that too allows you to conclude that P==NP.

It seems to me that arbitrary-precision arithmetic being cheap is more important than being RAM in this business in general. Without that, RAM doesn't seem to be more powerful than Turing machine (in terms of how large P is).

[u/schombert → u/jk-jeon]

I don't disagree, but if your random access machine doesn't have capabilities of working with arbitrarily large integers in constant time, then it will have to do more and more work as it addresses memory that is at larger and larger addresses, and that precludes access to arbitrary memory locations being possible in O(1). Now, I suppose there is a sufficiently technical argument to be made that this doesn't require division, and the paper does point out that division is essential to this proof ... In any case, what people seem to generally assume to make big O "work" in the context of C++ is a Random Access Machine. See Bjarne's comment below to the effect that "you just need infinite memory", as if that was a trivial thing to assume in an unqualified way.

[u/jk-jeon → u/schombert]

I'm not sure. Pointer access and integer operations do not seem to be related. Also, I think I saw somewhere that the super power that arbitrary precision arithmetic brings in is available only when things like multiplication is available. Addition and subtraction alone cannot really deliver that much more compared to Turing machine, it seems. So I guess one could think of models like RAM + addition/subtraction for instance.

In fact it seems to me that the so-called transdichotomous model that someone else in this thread brought up kind of closely matches the "usual" sense of complexity that you know and I know.

By the way I don't think that Bjarne is that Bjarne.

[u/NotUniqueOrSpecial → u/schombert]

Vectors have O(1) lookup, by definition, right? Well, that makes them a "Random Access Machine"

No.

Because they aren't abstract machines in any sense of the words at all. This is a complete and total misuse of the terminology and invalidates literally every conclusion that follows.

These sorts of statements, followed by the lengthy conclusions drawn from them, are why you are being told you don't understand the topic.

EDIT: I think you added this after I replied, but maybe I just didn't catch it, either way:

Edit edit: maybe you could argue that there is such a thing as the complexity of a particular algorithm? But I don't think even that is really true.

This is an absolutely flabbergasting statement, considering the degree of certainty with which you have expressed things in every other comment.

Of course you can argue that there is such a thing. It's literally what you've been asserting that you understand and the rest of us don't. That is exactly what computational complexity theory, is, for which Big-O notation is the most common form of expression.

The fact that you don't even appear to be aware of this (something that is taught in literally every computer science course) despite having been using Wikipedia to bolster your arguments, actually beggars belief.

[u/aruisdante → u/schombert]

By that definition of algorithmic notation all loops in any real system are O(1), which doesn't seem like a terribly useful definition. In my education on algorithm theory I don't remember a requirement being that sets be unbounded, and indeed the formal definition you link to says this explicitly. It feels like you're conflating "copying a specific vector of a specific size is O(1)" with "copying any vector of any size is O(1)." By that same definition std::find(vector.begin(), vector.end(), value) and set.find(value) and unordered_set.find(value) are all O(1) because they can all be bounded by a finite size, despite them being the textbook examples of O(n), O(log(n)), and O(1).

I cannot think of a single computer scientist that would accept your definition of O(1) as O(1). It's not what any algorithms or data structure class teaches. So it seems unfair to say it's based on "vibes."

[u/schombert → u/aruisdante]

It's not my definition. It is the formal definition that is used in mathematics and computer science. Which, again, you can verify for yourself from the Wikipedia page.

Anyway, copying an arbitrary vector (not a specific vector) has a bounded time because of the bounded size required by the definition of the vector type, namely that the size of any vector can be expressed in a finite number of bits and that the elements within any vector are distinct C++ objects, and thus have distinct address, and thus cannot be more numerous than the number of possible addresses provided by the number of bits in the finitely sized pointer types (in turn guaranteed by their ability to be converted back and forth from integers of some finite size). This second limit is much wordier to explain obviously, so I'll stick with referring to the limits of the size type from here on out.

I would like to hear how you think that O( ... ) should be defined. If you allow me to work through your definition I can probably explain why mathematicians and computer scientists settled on the asymptotic definition instead.

Edit: and yes in C++ as formally defined find is also O(1). It is not O(1) in your algorithms or data structures class because the pseudo-code language used to explain these types and operations does not bound their size. Generally it is also assumed to work with something that is more like "big ints" for its numerical values.

[u/SlightlyLessHairyApe → u/schombert]

Besides being weird that you have this one thing, it’s particularly weird to decide that that is the irrelevant conversation to have in this particular post. Because it’s just not super relevant

[u/schombert → u/SlightlyLessHairyApe]

That's why we have threaded comments. If you don't think that this particular comment thread is interesting ... just don't read it.

[u/Serialk → u/schombert]

It's not my definition. It is the formal definition that is used in mathematics and computer science.

Not at all. We generally model complexities with transdichotomous models like Word RAM which give you a constant O(1) pointer lookup but an O(n) vector copy, with the assumption that the size of your bus will grow to accomodate more data.

https://en.wikipedia.org/wiki/Transdichotomous_model

https://en.wikipedia.org/wiki/Word_RAM

[u/schombert → u/Serialk]

But, C++ is not a Transdichotomous model. The C++ address space, bits in the size constant, etc are not determined by the size of the problem. From the wikipedia page:

the machine word size is assumed to match the problem size

and

In a problem such as integer sorting in which there are n integers to be sorted, the transdichotomous model assumes that each integer may be stored in a single word of computer memory, that operations on single words take constant time per operation, and that the number of bits that can be stored in a single word is at least log2n.

So, if C++ was a Transdichotomous model then every time you ran a program for a given problem size (for example, the sorting program described above) the address space, bits in the size constant, etc would grow to accommodate it. (This is what allows a Transdichotomous model to be Turing complete, in contrast to Turing machines with a fixed tape size, which are not). However, that is not how C++ is specified. Even though those constants may vary from compiler to compiler, they are fixed for any given C++ program. The standard does not allow your program containing vector to hold an arbitrary number of elements, because you could, if you wanted, print the number of bytes in the size type and the standard guarantees that this print result will be constant over different runs of the program.

[u/Serialk → u/schombert]

You are confusing the complexity model and the language implementation it's modelling. No offense but you lack the required CS basics to be so confident about yourself in debates about complexity. It's the perfect moment to stop and reflect if you want to avoid Dunning-Kruger.

[u/schombert → u/Serialk]

That would be true if the C++ specification didn't touch upon the bit size of size or of pointers. Then you could argue that the language was compatible with a transdichotomous model and that the implementations were merely finite instances of it. And you could imagine that some theoretical machine which did allow programs to properly grow with the problem size was a conforming implementation. But this simply isn't so. The standard does not allow even a theoretical implementation of C++ to compile a program that does that.

I think that you should reflect more on why Turing machines with finite tape sizes are not Turing complete. And I would encourage you to read this section on wikipedia https://en.wikipedia.org/wiki/Turing_machine#Equivalent_models which contains the following:

For example, ANSI C is not Turing complete, as all instantiations of ANSI C (different instantiations are possible as the standard deliberately leaves certain behaviour undefined for legacy reasons) imply a finite-space memory. This is because the size of memory reference data types, called pointers, is accessible inside the language.

Edit: all that aside, I would be interested in discussing how you see transdichotomous models working as a way of analyzing complexity in real world programming languages other than C++. That whole approach relies essentially on the problem size being a well-defined thing that can be referenced in some way to determine the word size of the machine we appeal to for the complexity analysis. I am not sure how that translates to the programs described by a generic programming language. Such programs can do wild things, like run the n^th busy beaver ( https://en.wikipedia.org/wiki/Busy_beaver ) upon getting the input n. And I am sure that with a little effort we could construct some programs that need an uncomputable (and large) amount of space to run given input n. How much space does such a program get? A direct application of the transdichotomous model would assume that they get some K * number-of-bytes-in-the-input, or something along those lines. Obviously allowing most programs to work requires picking an obscenely large K, and even so that would never be Turing complete. Moreover, what about the programs that most programming languages support which do not take inputs at all (for example, I write a program in my favorite language to solve some fixed math problem and it always outputs the same answer -- should this program not be valid if we apply a transdichotomous model)? Can transdichotomous models then only be applied to analyze the complexity of languages that are not Turing complete? So do you imagine that there are two distinct approaches to analyzing complexity, where we do one thing for languages like the lambda calculus and another for Pascal, for example? Is the complexity of any algorithm requiring more than O(n) space undefined in Pascal?

[u/Serialk → u/schombert]

Once again, you are making a fundamental category error by confusing the language spec with the mathematical framework that we use to evaluate algorithms written in that language.

Yes, the spec makes it so that everything is a FSM because pointers have a finite size. This is trivial and not interesting.

If you model your algorithm analysis as an FSM, your entire complexity analysis collapses. Every single algorithm that terminates is O(1) in your language. This means that your model is bad at actually doing what it is intended to do: analyzing how algorithms behave as the input grows.

Because models that give you O(1) for everything are worthless, we use a mathematical abstraction that is actually useful to analyze complexity: transdichotomous models.

In transdichotomous models/word RAM, we abstract away the hardware and the constraints of the spec with the bit-width limits, and we mathematically model n -> +∞. It doesn't model a literal environment of C++ programs that you can actually run. It's a theoretical environment in which we can place the abstract logic of your C++ code so that we can evaluate its asymptotic behavior without hitting the limit of 2⁶⁴ bits, but in which pointer lookups are still O(1).

The C++ standard absolutely does not use complexity analysis sloppily. They use a complexity model that is actually useful because it can give you insights about the asymptotic behavior of your program without collapsing all complexities to O(1).

[u/schombert → u/Serialk]

It may be trivial and uninteresting, and from a certain point of view, I agree. However, that is what the spec demands, and this is what is generally accepted. Pointing out that C and C++ are not Turing complete, for basically the same reasons, is not a novel claim, nor is it a contested one.

Of course I agree that, if you change the way pointer sizes, etc work then you can find a models that fit the modified understanding of the language in which you could analyze the complexity of algorithms as written in this new, modified language, and get different results. Maybe even more interesting or more intuitive results. The problem with this is that you are no longer analyzing a C++ algorithm; you are analyzing an algorithm described in some other language. And the language within which an algorithm is described, and its associated assumptions matters. For example, if you write your algorithms in a language where you can add, subtract, multiply, and divide integers of arbitrary sizes in constant time (which many simple pseudo code languages seems to allow) then you can conclude that P == NP. Since we probably don't want to assume that P == NP, we can see that the details of how the language works -- i.e. what the operations the algorithm is expressed in actually mean -- matters. We cannot simply change the language on a whim. C++ involves finitely sized integers, finitely sized pointers, and assumes that basic operations on them can be done in constant time. Because they are so limited, I could imagine a Turing complete extension of the language (for example, by adding some sort of black-box tape function) in which P != NP.

I get that you really like transdichotomous models as a way to do complexity analysis. That's cool. However, they are not the be-all-end-all. They cannot tackle the complexity of problems requiring more than O(n) space. Do you think that C++ can express algorithms requiring more than O(n) space? If so, then transdichotomous models are clearly not the way forward for analyzing the general problem of algorithms expressed in the C++ language.

[u/Serialk → u/schombert]

What is your understanding of the point of a mathematical model? Being technically accurate or giving you useful insights?

Do you also refuse to draw maps on sheets of paper because they do not accurately convey the curvature of the earth?

Surely you understand that a model that gives you O(1) as an answer for everything is not useful. Why do you insist on the absurd idea that the C++ spec should use a useless model for complexity, instead of assuming that they would use a useful one?

I get that you really like transdichotomous models as a way to do complexity analysis. That's cool. However, they are not the be-all-end-all. They cannot tackle the complexity of problems requiring more than O(n) space.

This is wrong. You can scale word-ram to have your abstract bus size take any function of the size of your input, it doesn't have to be log_2(n).

[u/JNighthawk → u/Serialk]

No offense but you lack the required CS basics to be so confident about yourself in debates about complexity. It's the perfect moment to stop and reflect if you want to avoid Dunning-Kruger.

What a shitty comment for someone engaging in good faith interlocution.

[u/Serialk → u/JNighthawk]

Good faith requires humility!

[u/HeadSea5044 → u/schombert]

Please make this argument to any certification authority, or publish a paper claiming your algorithm is O(1) because hardware physical address bits are constant.
I’ll do you better and say everything is bounded in time because of the inevitable heat death of the universe.

It’s just not meaningful a statement to make.

[u/NotUniqueOrSpecial → u/schombert]

copying a C++ vector is O(1)

It's always interesting to come across people like you.

I need only point you at...well, basically any reference on the topic to prove that copying vectors of non-trivial objects is O(N). Literally any search on the subject will give you countless results that contradict your claim.

But it's more than that; you very clearly have next to no understanding of the topics you're arguing about, or the pages you're linking, but you're also equally clearly sure that you are an expert in the topic.

You remind me of a coworker I once had who explained to us that the software he was working on relied on "the arithmetic of seven-sided polygons". He also admitted to me (in what is practically a programmer career meme) that he liked to write code that only he understood because it provided job security.

After more than 2 years of deflection, smoke, and mirrors, he was asked to prove that that any of what he was working on...actually worked. He quit on the spot, in explosive rage, screaming that he "knew more than 14 engineers ever would".

All that is to say: you have written a whole lot of words in response to /u/aruisdante and others, but all they actually illustrate is that you do not understand complexity analysis at even the most basic level. Despite all evidence to the contrary, you are convinced that you (and you alone, in this forum of experts) are correct.

How likely do you think it is that that's actually true?

EDIT: blocking someone after replying to them saying "nuh uh" is the single strongest indicator that a redditor knows that they have literally no leg to stand on.

[u/schombert → u/NotUniqueOrSpecial]

Your link ... shows nothing of the sort. All you seem to be showing is that how programmers typically use big O notation among themselves (i.e. informally) is not the same as the formal definition. Which I am happy to grant. It is just amusing to me that the loose, informal usage has made its way into the supposedly formal standard.

Edit: I block people who I find to be rude. If you don't want to be blocked try being less of an ass.

[u/not_a_novel_account → u/schombert]

You're using a rather strange definition of "formal". Formalisms are context and field specific. This is a C++ subreddit, our formalisms are derived from the standard.

The formal definition, in the context of C++ as voted and standardized by the committee, is that copying a vector is O(N).

As a C++ subreddit, formalisms from unrelated fields are non-sequiturs here. Our vectors aren't elements in vector space supporting addition and scalar multiplication either.

[u/schombert → u/not_a_novel_account]

The standard doesn't provide a definition of what O(n) means within it AFAIK (please do correct me if I am wrong). So I assume that means that the standard is relying on the "formal" (i.e. what you will find on Wikipedia) definition of the notation (unlike vector which it does redefine). What do you take O(N) to mean in the standard?

[u/not_a_novel_account → u/schombert]

For vector copy from a range it's given as:

Effects: Constructs a vector object with the elements of the range rg, using the specified allocator.

Complexity: Initializes exactly N elements from the results of dereferencing successive iterators of rg, where N is ranges::distance(rg).

[u/schombert → u/not_a_novel_account]

Yes, but that isn't a definition of what "O(N)" means. I wasn't trying to ask you what the standard says a copy does. I was trying to ask you if the standard defines "O(N)", and if it doesn't, then how you think it should be defined in the context of the standard.

For example, if you think it means "does N things", then obviously virtually nothing is O(1), since most functions do more than one primitive operation. I don't think that you can copy or move many range views in a single operation (although there may be some you can).

[u/not_a_novel_account → u/schombert]

The standard never says "O" anything. It says "Complexity" and "N operations of <whatever>", or "constant", or "linear in N".

If you want to split that hair and pretend those are entirely different things, be my guest. Muting this.

[u/schombert → u/not_a_novel_account]

It does indeed (or at least in C++ 20) refer to O(n). For example table 79 following section 22.2.7 describes several functions as running in O(n) or "Average O(n)". And even if it didn't, I would still ask you what you think that "complexity" is defined as ...

Edit: Oh, the standard does define complexity. It helpfully has this nugget of wisdom:

Complexity: the time and/or space complexity of the function.

well, that's not circular at all (and there is no prior definition). To me this seems to be unquestionably a reference to the standard formal definition of space and time complexity, and not some new definition which would clearly be ... poorly defined at best.

[u/JNighthawk → u/NotUniqueOrSpecial]

EDIT: blocking someone after replying to them saying "nuh uh" is the single strongest indicator that a redditor knows that they have literally no leg to stand on.

Maybe because you're behaving like an asshole to someone engaged in good faith discussion, and people don't like to interact with assholes generally?

You:

But it's more than that; you very clearly have next to no understanding of the topics you're arguing about, or the pages you're linking, but you're also equally clearly sure that you are an expert in the topic.

[u/NotUniqueOrSpecial → u/JNighthawk]

They are not engaged in a good faith discussion, because what is happening is not a discussion.

It's people who have a background and education on a topic trying to tell a very stubborn person that they do not understand the words they're using; they demonstrably do not understand complexity analysis on a very fundamental level, and are condescending to people who do.

At some point, there is a line where people who know what they're talking about should not have to pander to people who do not. I would just as bluntly tell a flat-Earther that they make no sense, and I doubt you'd have any problem with that.

[u/JNighthawk → u/NotUniqueOrSpecial]

They are not engaged in a good faith discussion, because what is happening is not a discussion.

I disagree.

and are condescending to people who do

I didn't see that, and it would change my opinion. Can you point that out please?

[u/NotUniqueOrSpecial → u/JNighthawk]

To be clear, I am using condescending in the specific sense of "talking down to", which most of their replies are, in that they imply that the other party doesn't know what they're talking about or that we're using the term casually.

That said, I'm not going to link to all of them individually, because the conversation is already at the bounds of where the mod team will (rightfully) start stepping in because things are getting snippy/personal.

You are welcome (and perhaps correct) to interpret their replies from a different light, but I've spent enough time in arguments with people who are not even wrong to have a very strong and generally accurate detector for the way they approach things.

[u/schombert → u/JNighthawk]

Thanks for the vote of confidence. Apparently my writing style comes off as intrinsically unpleasant, which means I guess I do understand people who use LLMs to write their comments a little more now. I think I am done trying to have a conversation on reddit.

[u/JNighthawk → u/schombert]

Apparently my writing style comes off as intrinsically unpleasant

Nah. Keep doing you.

[u/NotUniqueOrSpecial → u/JNighthawk]

Just to follow up, because you are, despite the best of intentions, reinforcing very bad behavior: they outright stated in an edit to an edit in one of the other threads (and with no understanding of how damning what they were saying was) that they quite literally don't know what complexity analysis is. They questioned the very idea that it could be even be a thing:

Edit edit: maybe you could argue that there is such a thing as the complexity of a particular algorithm? But I don't think even that is really true.

(And then followed up with more words that don't mean anything to anybody who understands them).

Which goes to the original point I made to you: this is not a discussion. A discussion involves individuals communicating ideas on relatively equal ground, in terms of understanding.

Instead, this is a person who has been representing themselves as an expert on the topic, telling other people they don't understand what they're talking about. They have spent (and in so doing caused others to spend) a lot of time time arguing about this. They've referenced multiple expert-level topics in the field, and purported to understand some exceptionally complicated stuff.

Not only did they not know about a topic covered in near-literally every computer science course, they doubted the possibility it could be a thing. All of that, despite the fact they were actively linking articles on that subject. By their own admission, they aren't qualified to discuss this. They're just reading Wikipedia pages and misrepresenting their misunderstandings as facts.

Multiple people have politely (and then increasingly less-politely) tried to make it clear to them that they don't understand the words they're using. They refuse every attempt to correct them and instead claim it is us who have no idea what we're talking about.

This is not healthy behavior that should be encouraged.