Відео

Dang! Maybe a TypedDict type hint for the logging config would be a good idea to prevent those kinds of typos.

I think I know the video you're referring to, by the Cherno, right? I'm not sure why this has become a popular reference against the use of the stl, but that was very much an instance of the author writing code that the compiler was not able to optimize (with the optimization settings he used), not a problem with the performance of the stl. Basically he used accumulate where it does not make sense at all to use accumulate. The error is akin to sorting a vector and grabbing the first element to get the min and then complaining that std::sort is slow, when in reality sort is just not the right tool for finding the min. An important part of using tools is knowing which tool to use even when many of them *can* be used.

That was gibberish. 0.999... := lim n->oo 0.999...9 (n 9s) = lim n->oo 1 - 1/10^n = 1. He did prove that final limit starting at 6:47

It's basic Calculus 2 and is taught to the brighter students at high school. Calculus goes to at least level 8. I learnt properly (as per the video, using epsilon-N) in in the first or second term of the first year of my _Electronics_ degree course. It is that basic.

What is 0.001r supposed to be? The rest of what you say makes no sense either. Both 0.999... and 1 are the unique number that is greater than every term on the sequence 0.9, 0.99, 0.999, ... and less than every term in the sequence 1.1, 1.01, 1.001, ..., so is 1. Hence 0.999... = 1. FWIW The difference sequence is 1.1 - 0.9, 1.01 - 0.99, 1.001 - 0.999, ... = 0.2, 0.02, 0.002, ... and the limit of that sequence is 0. Hence both of the original sequence have the same limit. (I've skipped a few obvious details).

@@Chris-5318 " both .999... And 1 are a unique number" .999.... Is not a number. It is an infinite sequence. It has no value of itself and is incalculable. It can only be understood by series. As each step in the series, it will be .o1... From 1. As you have pointed out. What I have stated is that if .999... =1 therefore 1.001... equals 1 for both will have an equal algebraic result, that being .001..., and as you progress through the series all results will be equal. However, at each step in this sequence the difference between 1 and 1 is always 0 but the difference between.999... and 1.001... will always be .002.... The question is: If .999...=1 then why does the difference double but the difference between 1 and itself not? Surely, if .999... were =1 then we would not see one value double.

​@@supernovaaust 0.999... is a numeral that represents a number. It is conventional to say that a decimal numeral is a number. You are right in that 0.999... is simply a concise notation for the geometric series 0.9 + 0.09 + 0.009 + .... The "steps" of that series is the sequence 0.9, 0.99, 0.999, ... and *>>by definition<<* the limit of that sequence is the value of the numeral 0.999.... You: " therefore 1.001... equals 1" Me: 1.001.. has the value of at 1 + 1/1000. You haven't said what the ... is supposed to indicate. Did you mean 1.001001001... or 1.00111... or was it an abysmal attempt at 1.000...1? If the latter, then that is not a valid decimal. You: the difference between.999... and 1.001... will always be .002...." Me: No, it isn't. 1.001... - 0.999... = 0.001... e.g. 1.0012 - 0.999... = 0.0012. I have no idea what this doubling is that you keep referring to. Try to be clearer. I'm sure that I have actually dealt with what you really meant, even though you aren't capable of understanding me. FYI here are the two main definitions that you need: Definition: The sum of a series is the limit of the sequence of its partial sums (if the limit exists). Definition: Let {S_n} be a sequence of real numbers and let S be a real number. Then S = lim n->oo S_n means that for every real ε > 0 there is a natural N such that for every natural n > N that |S_n - S| < ε. The sequence of the partial sums of 0.999... is 0.9, 0.99, 0.999, .... The n th term is 0.999...9 (n 9s) = 1 - 1/10^n Therefore: [the sum of] 0.999... := lim n->oo 0.999...9 (n 9s) = lim n->>oo 1 - 1/10^n = 1 I can prove the last equality using the definition of limit if you don't accept it. Regards your 1.001... thingy. I'm sure that you really mean 1.000...1. The problem with that is that it cannot possibly be an infinite (AKA endless) decimal because it has a last digit. If we try to construct what I expect that you are thinking of, the sequence of partial sums would be 1.1, 1.01,1.001, 1.0001, ... whose nth term is 1 + 1/10^n. The limit of that as n->oo is 1, not 1.000...1, yet alone your 1.001... abominotation. Before you reply again, I suggest that you read the geometric series Wiki. Better still learn this trivial Calculus 2 math. I won't respond for at least 8 hours as I'm going to bed.

I have to disagree that 1.0000...1 is not infinite as everytime you add a zero the number differs even though the final number remains same. What you say?

​@@supernovaaust Of course 1.000...1 is not infinite. "Infinite" means "endless". 0.000...1 has a last digit (at the end). Infinite decimals do not have a last digit at the end because they do not have an end at which to place or a last digit. I can't readily imagine what you think infinite decimals are about. I assume that the digit before the 1 is also the last 0. You can't have infinitely (AKA endlessly) many 0s and have a last 0 at the non-existent end. You haven't understood the most basic definition of infinity. You: "... everytime you add a zero the number differs ... " Me: Clearly you are thinking of the SEQUENCE 0.1, 0.01, 0.001, ... where every time you "add" a 0 the new term differ from the previous one (by a factor of 10). If I temporarily accept your abysmal 0.000...1 and the like, then surely 0.999... + 0.000...1 = 0.999...1 and not 1 and 1 - 0.000...1 = 0.999...9 and not the 0.999... that it is supposed to be (using your farcically faulty ideas). Whatever, you are wrong according to literally everyone that has learnt Calculus 2. That includes several million degreed mathematicians.

This video is using CLion, which is a paid product by JetBrains

Yes you can have any number of bits (until you run out of memory). The typical implementation of bitset holds an array of unsigned longs (of size=ceiling of how many bits you want/8) that it accesses by calculating offsets and masking.

No it isn't. Decimals can't represent numbers that differ from a real any a non-zero infinitesimal amount. Infinitesimals most definitely are numbers. e.g. they are elements of Robinson's hyperreal numbers and Conway's surreal numbers. You are confusing infinitesimal numbers with the concept of convergence. They are completely different things.

@@Chris-5318 Ohh yeah, I agree 0.999999… Isn’t an actual number because it just shows a limit, not a number, but I think what people are thinking when they ask this question is that 0.99999… is an infinitesimal less than 1 and what they are really wondering is whether an infinitesimal is zero

​@@ScienceSpider-sigma 0.999... is a numeral that represents a number. Numbers are pure abstract - they only exist as ideas. The number that the numeral 0.999... represents is a limit. It is the limit of the sequence 0.9, 0.99, 0.999, ... and that is easily provable to be the same number that is usually represented with the numeral 1. Limits are numbers. I can't imagine what else you think a limit could possibly be. The n th term of the sequence 0.9, 0.99, 0.999, ... is 0.999...9 (n 9s) = 1 - 1/10^n. Altogether: [the value of] 0.999... := lim n->oo 0.999...9 (n 9s) = lim n->oo 1 - 1/10^n = 1 Zero is an infinitesimal. However, people commonly mean a non-zero number when they refer to infinitesimals. As I previously said, decimals cannot represent numbers that differ from a real by a non-zero infinitesimal. For example, if 0.999... was infinitesimally less than 1, then there would be no decimal for 1 - 0.999... or 10 * 0.999... - 9. There is an extended decimal notation, called Lightstone notation, that can deal with infinitesimals.

Great question! In C++, a pointer is not nullptr if and only if it is nonzero, so if (p) and if (p != nullptr) are semantically identical, although you may prefer to use one over the other for stylistic reasons.

The only surefire way would be to read the C source code, but you can reason about it by putting in a really big number and checking to see whether you RAM usage goes up by a proportional amount 😉