just do long multiplication. this reduces the problem to repeated integer multiplications.

its also equivlent to his example of adding up the integer parts then you deal with the fractional part by multiply everything so that the fractional part is integral, doing the repeated addition then dividing the answer at the end by the factor you multiplied by. this is equvalent to shifting the decimal point. the point doesn't change how you approach the algorithm, and the answer in the end is still a rational fraction, not really a "single number" 0.25 isnt simpler than 1/4, its just another way to write it.

that trick wont work for irrationals though. but they aren't calculable no matter what you do so...

this is really trivial for binary multiplication, as it just reduces to shifting the number up one place across itself and adding the digits to itself IF the digit in that place is a 1; as you either add 0xthat (which is no addition) or 1xthat, (which is no multiplication). binary addition is also simple, it reduces to looking if they digits are different, in which case its 1, otherwise its 0 and u carry a 1 if theyre both 1.

    1011 (11)
   x0110 (6)
   -----
   1011  (22)
  1011   (44)
  ----
 1000010 (66)

>give me the exact value of 0.75 x 0.44, only using addition.

as for your question... we can agree integer multiplcation is trivial and can always reduce to repeted addition so i wont write it out but...

4x5 + 4x70 + 40x5 + 40x70 = 3300; put decimal place in correct 2x2=4 point position = 0.33

all of this works with rational numbers and they reduce to repeated addition. his example with pi is bogus for different reasons, and that's just because irrational and especially transcendental numbers like pi are just uncalculable; so you'd end up doing this long multiplication process forever; infact you wouldnt even get to the point of multiplying pi, because you're still working out what pi is so you can multiply it. all calculations that have ever been done are on rational numbers. "real" numbers are just symbols we manipulate and replace with approximations when a calculation is needed. they aren't real.

or you can just pretend its 22/7.

It's just a convention, you could instead write out each operation explicitly with brackets, this convention allows you to not need the brackets. The convention is far from perfect, leading to viral math problems of type 6 / 2(2 + 2) = ? Does that translate into this:

   6
--------
2(2 + 2)

or does that translate into that?

6
- (2 + 2)
2

You can argue about the right answer until the end of the universe, but the fundamental failure is that there is confusion to begin with, meaning that PEMDAS is not clear and unambiguous enough. In notation with the horizontal bar you notice there is no confusion, none of them are ever going to become viral math problems people fail to answer right.

They all use frequency hopping, in addition to encryption and such. This means that they automatically retune to a new frequency many times per second. A simple tuner can only stay on one frequency. Even if you have one that can hop, it needs to know the pattern to follow in order to track the signal, and the agreement on a pattern between the sender and receiver is kept secret by encryption. The common way to intercept cellphone communications is to have your own device that acts like a cellphone tower, trick the phone into connecting to that, and read off the data after it has been received, while transparently forwarding it to the real cellphone network.

You're not wrong, but most of the confusion with order of operations happens at the multiplication -> addition level. At least in my experience. Like 5x^2 is really obvious what it's supposed to be to most people (if you're using actual super script, anyway).

Although that said, I understand that this very well may be because once you start doing more complicated math that actually requires a lot of parentheses and exponents and stuff you've already used the order of operations so many times it starts to become second nature, so it might just be that those are more obvious because the people that are encountering them are already well practiced.

In the old times there was only goto. And it led to really bad code. Then there was a time where using goto was considered extremely bad programming.

I've seen a lot of places where gotos make sense. Mostly (if not always) in error handling where gotos can actually clean up convoluted code when you can't use exceptions for some reason.

It's not a bad practice because it's impossible to use it in a way that avoids problems; it's considered bad practice because it's possible to use it in a way that causes problems.

This is often the case in programming. You'll find that people will argue that such-and-such is okay because "if you just use it correctly, there's no problem." But correct usage isn't always straightforward, and the less straightforward it is, the more problems there are.

Ideally, a perfect programming language would provide only constructs that make it impossible to represent unintended things. In fact, this perfect programming language actually exists in theory! It would be a programming language which requires formal proofs of all possible functionality. This sounds absurd, but in reality, even though it's impossible, it's less impossible than it at first seems because you can do things like method guards and early escape returns, which reduce the space of test cases from virtually infinite to merely unmanageable and totally unrealistic (for real systems, not toys).

Example time. Say that I want to write a method that can multiply integers from 1 to 10. A first year student in coding 101 will write something like:

/** Return product of a and b. */
int mult(int a, int b) { return a*b; }

…and feel proud that they not only addressed the requirement, but produced something much more general purpose that will also work for any two integers.

How silly and naive. What they failed to account for is that this doesn't actually work for any two inputs, and if you were to exhaustively test every single combination of 32-bit inputs, you'd find a large number of them that result in overflow conditions (like a = b = max int). But that's okay, it still does the thing it's supposed to for the expected inputs, so what's the problem? The problem is that since you specified a looser contract for this method than was required, you have not addressed just the requirement but the looser contract you chose to support (because of Hyrum's law).

If you actually restricted the contract to just the requirement:

/** Return product of a and b if both are between 1 and 10 (inclusive). */
int mult1to10(int a, int b) {
  if (a > 0 && a <=10 && b > 0 && b <= 10) { return a*b; }
  // do some crazy ish
}

In design-by-contract rules, if you don't specify in the contract what a method does, then it is unspecified, meaning that you can literally do anything and still be in compliance. You could go into an infinite loop. Call System.exit(9). Whatever.

Because everything is allowed when a or b are outside the specified bounds, it's super easy to prove that this method formally complies with its contract. The space of the inputs is so small you can even practically write a set of exhaustive tests, and you could also formally prove using lambda calculus or whatever based on the code as written that it does exactly what it says it does.

What does this have to do with your question? What I'm doing here is introducing these notions of formal proof and exhaustive testing not because it's practical, but rather to connect the idea of "covering the entire space of possible inputs" with the ability to reason about code. In mathematics we have this notion of continuity, whereby we say a function is continuous if the outputs transition smoothly from one value to another if the inputs transition smoothly from one value to another. Now just because these transitions are smooth doesn't mean that outputs don't move around in an absolutely wild and unpredictable way, but for a lot of functions you can make strong statements that outputs definitely don't do that. You could have a function where you prove that it it's monotonically increasing, and the increase in the output is proportional to the increase in the input (y = 5x, for instance), so you'll never see weird or erratic behavior in the output for a steady increase in the input.

See where I'm going with this? If you write methods that behave like simple mathematical functions that are easy to reason about because they are constrained in particular ways, then we don't need to exhaustively test every possible combination of inputs. We can say, for example, that if you put in a 1 and get a 5, and you put in a 100 and get a 500, that's good enough to assume if we put in something between 1 and 100 we'll get something between 5 and 500. But you can only say this if your function behaves like y = 5x and isn't trying to tell you angles of Foucault's pendulum or some chaotic process.

This was the problem with the simple code we wrote in the first example above. Given a simple requirement, we decided to tackle the entire class of inputs and wound up with an output that has significant areas of discontinuity (int overflow). We could solve that problem by returning a long, and now we can say that, hey, it's now a simple method we can reason about. Problem solved! Right? Right???

Not really. Clients ruin everything.

The problem is still not solved if what clients really need is an int. Remember, we're writing this method according to some contract not just to occupy our time; presumably we have callers we are trying to support. If we're going to change the contract by returning a long instead of an int, we had better be darn sure that change does not diminish the utility of the contract!

If it does, and clients actually need an int, then what they're going to do is cast that result to an int. If they screw this up by not checking for overflow, then we have not really solved a problem, we just relocated it. Even if they don't screw it up and they do all the correct bounds checking, we are putting extra work on each and every client that we could centralize in one place … and that's the whole point of doing this work in the first place, right? I mean ,couldn't callers just do the multiplication themselves too? Why ever provide any API that does anything?

So there's no escape. As a provider of an API, your job is to provide a contract that meets the need of the caller, and do it as correctly as possible. That's a good API.

But as we see from the above two examples, when we did a seemingly innocuous thing, we introduced unexpected behaviors into our implementation. It's really, really easy to do because it's really, really hard to write code that's really, really easy to reason about.

And, finally, at long last, we go way back up to the top of this post and reread what I wrote there: Good practices are good not because they make it possible to do the right thing, but because they make it impossible to do the wrong thing. Ideally. In practice, the best you can do is make it harder to do bad things, and easier to do right things.

And that's why goto is bad. There is nothing you can do with a goto that you can't also do with other programming constructs minus the big ol' footgun that goto hands you because these alternatives all come with additional restrictions on how control flow is handled that make them easier to reason about.

[removed]

Your submission has been removed for the following reason(s):

Loaded questions, or ones based on a false premise, are not allowed on ELI5 (Rule 6).

If you would like this removal reviewed, please read the detailed rules first. If you believe this was removed erroneously, please use this form first. If you believe this was removed erroneously, please use this form and we will review your submission.

[removed]

The first thing to do is to make sure this is actually true. Mental associations have a big effect on taste - see those experiments where 'experts' are fooled into thinking white wine with red dye in it is red wine, or cheap wine in an expensive bottle is good wine.

So, do a blind taste test, and see if you can still tell them apart.

For me personally: Ape man strong, ape man protect woman, woman trust ape man

(D/s is about freely giving up power and I can only do so with a partner I trust completely, so it adds another level of intimacy. Plus being manhandled is kinda hot. And it plays into the fantasy of "being put in my place", but that's just my personal thing)

(And, as some have already said, it's not necessarily "most women", it's just more known/socially acceptable for women to be into being dominated)

[removed]

Where is this "Vast Majority" came from again? Most women I know hate being dominated by their partner, they want to be their partner's equal...

[removed]

https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf

You do realize that in the ocean, when ice forms, that the ice is salt free because the ice is 'expelled' from the molecules that form the ice, and the lattice structure?

Ice by definition is essentially salt free.

When you make ice cream you rotate a bowl inside of another bowl, and there is fiction between these bowl. This friction creates energy, and when you put ice in between these bowls it will "grind" the ice, which helps the ice melt more quickly.

[removed]

I have 2 bags of 3 apples each + 1 additional apple. That's always 7 apples Rewriting the equation doesn't magically produce 2 extra apples

[removed]

Some women.

Some men.

Saying 'a vast majority' is complete bullshit. So is your projection of your personal feelings onto men as a whole.

In shorr, different people, male AND female, like different stuff.

If you sit too much, you don't get enough physical activity. Without physical activity, your muscles and bones weaken, your heart weakens, your circulation and blood pressure get affected, your metabolism activity gets reduced in multiple ways, you burn less energy thus you're more prone to getting fat, you lose flexibility / mobility in your joints... So you get into this whole web of interconnected causes and effects that negatively affect your health.

Physical activity, on the other hand, helps maintain or develop bone and muscle strength, you train your cardiovascular system, you activate processes in your metabolism that help keep your body running efficiently, hormones get produced.

It is a naming convention. Entirely just syntax up help denote things. Also fun thing, Prefix and postfix notation do not have this confusion. With these you can also write them out in trees to help show even better exactly what is going on. It's used a lot in discrete mathematics to describe different tree traversals.

Parentheses very quickly become unreadable when you have too many of them.

3(5x^3+2)^2 becomes 3*(((5*(x^3))+2)^2) without order of operations to do the implicit grouping for you. It's not incomprehensible, but it's much harder to read. Longer equations would be awful.

If it is equivalent, then please give me the exact value of 0.75 x 0.44, only using addition.

It’s because you’re not really multiplying. You’re repeat adding.

1 + 2 x 3 is really 1 + 2 +2 + 2.

Now if you throw some parentheses around the one and the two, you change the story.

(1 + 2) x 3 is really (1 + 2) + (1 + 2) + (1 + 2) which is indeed 9