Joined: 9/12/2014
Posts: 536
Location: Waterford, MI
It was actually misunderstood. She only has 20 dollar bills in a safe. She counts them like this: 4 20s according to her makes 100. As she counts this way, it ends up being 2180. So she counts 4 20 dollar bills and puts in her calculator 100 instead of 80 which was the mistake made. And when she was done, she ended up with 2180 under the belief that 4 20 dollar bills make 100 dollars. Realizing that 4 20 dollar bills doesn't make 100 dollars, what does she actually have?
Masterjun
He/Him
Site Developer, Skilled player (1970)
Joined: 10/12/2010
Posts: 1179
Location: Germany
She actually counted $2200 by counting 22 of the (4*$20) bill packs, but then realized she just bought that calculator for $20, so she subtracted another $20, making the calculator say $2180. So she had 22*(4*$20) = $1760 but then bought the $20 calculator and now has $1740.
Warning: Might glitch to credits I will finish this ACE soon as possible (or will I?)
Editor, Skilled player (1938)
Joined: 6/15/2005
Posts: 3244
I'm pretty sure the answer is 2160 dollars. Explanation: The problem only says that (according to her) 4 of the 20-dollar bills makes 100. It does NOT say that (according to her) 4 of the 20-dollar bills makes 100, another 4 of the 20-dollar bills makes 100, another 4 makes 100, ... This interpretation is reinforced in the statement of the question: - "Jane was counting her savings with the belief that 4 20s make 100": Exactly, she believes that 4 of the 20s makes 100. - "So every time she finds 4 20 dollar bills, she adds 100 to her calculator.": She finds 4 20s exactly once: the first (and only) time the count reaches 4 20s. - "However, she realized that 5 20s make 100 and not 4.": Yes, she realized that 5 of the 20s she had makes 100 and not 4. - "She counts them like this: 4 20s according to her makes 100.": Yes, the first (and only) time she counts 4 20s, to her it makes 100. - "So she counts 4 20 dollar bills and puts in her calculator 100 instead of 80 which was the mistake made.": Exactly what it says. - "And when she was done, she ended up with 2180 under the belief that 4 20 dollar bills make 100 dollars.": Yes, she ended up with 2180 because she believed that 4 of the 20s made 100 dollars. So her initial calculation was 20 dollars too high. So she actually has 2160 dollars.
Skilled player (1532)
Joined: 7/25/2007
Posts: 299
Location: UK
If her savings are in $10, $50 or $100 bills anyway, then there would be no error occurring. There's not enough information in the problem to have any meaningful solution.
Editor, Skilled player (1938)
Joined: 6/15/2005
Posts: 3244
Flip wrote:
If her savings are in $10, $50 or $100 bills anyway, then there would be no error occurring.
Masterjun already tried that; InfamousKnight apparently responded that there are only $20 bills involved. This is clearly a lateral thinking problem. I came up with my solution after reading InfamousKnight's two posts as literally as possible. There might be other valid solutions, but I believe (unless InfamousKnight says otherwise) that if there is a single intended solution, then mine is the one intended.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
InfamousKnight wrote:
She only has 20 dollar bills in a safe. She counts them like this: 4 20s according to her makes 100. As she counts this way, it ends up being 2180.
Is this some kind of trick question? If 4 bills are worth 100, it's impossible to arrive at a sum that's not a multiple of 25, which 2180 clearly is not. The only way to end up, after counting to 2100, with that final $80, is to count $20 four times. But this would mean that she has now changed the meaning of 4 bills to mean $80 rather than $100. If this problem has a "logical" solution, it's probably a trick question that misleads the reader by not stating things clearly enough.
Player (96)
Joined: 12/12/2013
Posts: 376
Location: Russia
Interesting task that popped up in discord:
This is for the Nightfire TAS. Basically I'm starting at the black dot in and I need to get to the yellow point. Which of the lines would be the best to take? I need to jump from A (the ledge i'm walking along) to B (the edge of the platform i'm going to land on) The speed is constant and the jump length is always the same. basically the line connecting A to B is always the same length
Addition from me: velocity same for move and jump. So, you need to find trajectory that connects start point with target point, and distance traveled between borders is less than length of jump L.
Editor, Skilled player (1938)
Joined: 6/15/2005
Posts: 3244
r57shell wrote:
This is for the Nightfire TAS. Basically I'm starting at the black dot in and I need to get to the yellow point. Which of the lines would be the best to take? I need to jump from A (the ledge i'm walking along) to B (the edge of the platform i'm going to land on) The speed is constant and the jump length is always the same. basically the line connecting A to B is always the same length
Let's say D1 (starting point's distance from horizontal edge), D2 (ending point's distance from horizontal edge), R (jump length), W (ending point's distance from vertical edge) and x (horizontal distance of the landing point for the jump) are given above, and we want to find x that minimizes total distance. In short: Using calculus, we get the following equation: 2x2(W-x)2+D2x2=R2(W-x)2. For the special case D2=0 (ending point lies on the horizontal edge), clearly x=R/sqrt(2) minimizes the distance, and indeed solving the above equation can be done easily and gives x=R/sqrt(2). However, in general, this is a quartic equation, which I would just solve using WolframAlpha (example is given with D2=8, W=10, R=3). In general, if D2 is not too big compared to W, then the optimal x should be around R/sqrt(2).
Player (96)
Joined: 12/12/2013
Posts: 376
Location: Russia
I can confirm this equation. But I, myself, was solving case when both: start and target is not aligned on the edge. And, it looks like this task is ugly, in the way that it doesn't have analytic solution, or at least no 'neat' analytic solution :( And, btw, better approximation is having angle same with vector from start to target except very long distances along edge.
Joined: 1/14/2016
Posts: 98
Is the line of the jump not parallel to the line connecting the start and end points?
Masterjun
He/Him
Site Developer, Skilled player (1970)
Joined: 10/12/2010
Posts: 1179
Location: Germany
InfamousKnight wrote:
She only has 20 dollar bills in a safe. She counts them like this: 4 20s according to her makes 100. As she counts this way, it ends up being 2180. So she counts 4 20 dollar bills and puts in her calculator 100 instead of 80 which was the mistake made. And when she was done, she ended up with 2180 under the belief that 4 20 dollar bills make 100 dollars. Realizing that 4 20 dollar bills doesn't make 100 dollars, what does she actually have?
I asked for the solution to this puzzle, so here it is: <InfamousKnight> The answer is 1810 <Masterjun> we need an explanation about how only 20 dollar bills can add up to $1810, that's quite the interesting puzzle indeed <InfamousKnight> Oh, that was actually an about guess. Its probably more like 1820 <Masterjun> so another explanation needed is how to get from the information in the puzzle to that answer <Masterjun> like, why isn't the answer 1800 or 1840 <InfamousKnight> I dont know :/
Warning: Might glitch to credits I will finish this ACE soon as possible (or will I?)
Player (96)
Joined: 12/12/2013
Posts: 376
Location: Russia
Chanoyu wrote:
Is the line of the jump not parallel to the line connecting the start and end points?
This is same what I said:
r57shell wrote:
And, btw, better approximation is having angle same with vector from start to target except very long distances along edge.
It's better in some cases, but it's not the best. In case if you got it same way as I did, I'll describe a bit better. I got it taking into assumption that shortest distance is lowest effort. This thing is taken from physics, for example light travels shortest distance in some meaning (Principle of least action). So, to reduce effort (energy/action), you would like to get from jump maximum profit. And this leads to idea to move along same direction. Why it doesn't work? Because restrictions are awkward. You need to reach edge, and from there you can move fixed distance in any direction. This never happens in physics. You can't cut corners. You could solve this task using string with sliding ring holders along the edges. This should work. By the way, origami approach also doesn't work, because it gives obviously wrong solution with corner in the middle of the jump :D
Joined: 1/14/2016
Posts: 98
Reading comprehension is hard, apparently. How I got to it, is that the fastest route is a straight line form start to finish. If that's impossible, then you want the straightest line, and that requires a jump parallel to the straight line.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
I'm trying to understand long division (for a project), and it's extremely puzzling. The last time I did long division was a really long time ago, so I don't remember anything about it, so I'm trying to find out once again how it's done. What puzzles me to no end is that long division seems to be a circular method. Not as in being recursive, but as in being self-contradictory: In order to divide two large numbers you need to... be able to divide two large numbers. It requires what it's trying to accomplish. Which makes no sense to me. For example, suppose you wanted to calculate the quotient and remainder of something like 123456789/98765432. The instructions say: Take digits from the dividend until you get a number that's larger than the divisor. In this case that would be the entirety of 123456789. Now the next step is... "compute the greatest multiple of 98765432 that's less than or equal to 123456789". Which is the very definition of division. In other words, in order to know what 123456789/98765432 is, I need to know what 123456789/98765432 is. Well, duh! So in order to do division you need... division. What a beautifully circular method.
Joined: 1/14/2016
Posts: 98
I think for a typical long division, your divisor is way smaller than your dividend, and usually two digits or so. Then the method cuts up the big division in smaller parts. For your example it doesn't do much, though it still works. And, in long division you do not need to compute the greatest multiple. You can choose to just subtract the divisor of the dividend one by one, it's just more effective to subtract the most you can. This, at least, is how I first learned it at school. Subtracting the greatest multiple at once was an advanced technique, since it requires you to compute more in your head.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Is there a method for dividing two large numbers (and also getting the remainder) using only division (of a number of any size) by a single-digit value, as well as additions/subtractions/multiplications as needed? (And obviously I mean something faster than a mere "subtract the divisor from the dividend until the result is smaller than the divisor", which could require trillions of subtractions for a large enough dividend and small enough divisor.)
Masterjun
He/Him
Site Developer, Skilled player (1970)
Joined: 10/12/2010
Posts: 1179
Location: Germany
When it says "compute the greatest multiple of 98765432 that's less than or equal to 123456789", it actually means an integer multiple. In other words, the division is turned into multiple integer divisions, which are easy because they compute the result digit by digit, thus only allowing for 1 of 10 possible digits per step. With big divisors, it makes sense to write down the first 9 multiples:
*1  98765432
*2 197530864
*3 296296296
*4 395061728
*5 493827160
*6 592592592
*7 691358024
*8 790123456
*9 888888888
With this, you no longer need to "compute" the greatest usable multiple, instead you simply check by looking at the numbers. So now you can do the long division, which now requires nothing more than comparisons and subtractions:
123456789:98765432 = 1.2499...
 98765432     <------/ ||||
 --------              ||||
 24691357              ||||
 197530864    <--------/|||
 ---------              |||
  49382706              |||
  395061728   <---------/||
  ---------              ||
   98765332              ||
   888888888  <----------/|
   ---------              |
    98764432              |
    888888888 <-----------/
    ...
Of course, the subtraction result can never be 98765432 or over (otherwise you chose the wrong multiple). So at some point the subtraction result repeats, meaning you found the repeating part of the decimal.
Warning: Might glitch to credits I will finish this ACE soon as possible (or will I?)
Player (42)
Joined: 12/27/2008
Posts: 873
Location: Germany
It's widely believed that the (asymptotically) fastest way to divide two large numbers is to reduce the problem to multiplication using Newton's method and doing enough multiplications to converge it. Multiplication of two large integers can be done in O(n log n) by reducing it to a Fast-Fourier-Transform. However, the details are extremely complex and the construction and proof of an actual algorithm that multiplies two integers in n*log n was done only recently. It's an academic algorithm, though, because it would take numbers much larger than those our computers can handle to make it faster than common fast multiplication ones. So, asymptotically, division is a bit slower than n log n, I don't remember the actual complexity. And this is a conjecture, because there's no proof that n log n is optimal for FFT. For practical purposes, algorithms like Barrett reduction should perform faster.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Masterjun wrote:
When it says "compute the greatest multiple of 98765432 that's less than or equal to 123456789", it actually means an integer multiple. In other words, the division is turned into multiple integer divisions, which are easy because they compute the result digit by digit, thus only allowing for 1 of 10 possible digits per step. With big divisors, it makes sense to write down the first 9 multiples
I suppose that works well enough for base 10. It doesn't work as well for larger bases (say, base 264). I wouldn't really need the theoretically fastest known division algorithm, just an algorithm that's decently efficient (more efficient than repeated subtraction until the dividend becomes smaller than the divisor). The only division algorithm I can find after extensive googling is the base-2 "long division" that's based on going through the dividend one bit at a time and subtracting the dividend from the remainder when it gets larger than it. It appears that unlike multiplication, there isn't any simple division algorithm that would deal with more than one bit at a time (not even if you have available short division, ie. dividing a number of any size by a single digit). I can only conclude that all those bignum libraries do division either by the base-2 method, or by magic. I find no other methods in existence (at least ones that are actually explained).
Player (36)
Joined: 9/11/2004
Posts: 2623
The most popular and mature bignum library has this documentation about their integer division algorithms: https://gmplib.org/manual/Division-Algorithms.html
Build a man a fire, warm him for a day, Set a man on fire, warm him for the rest of his life.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
I asked this on physicsforums.com (which has a math section), but gotten no answers so far, so I'll ask here as well. It's a bit long, so bear with me. The Karatsuba multiplication algorithm is a faster-than-O(n2) (approximately O(n1.58)) multiplication method of two large numbers. I have been working on a small project where I have implemented it (among other things), and I noticed something curious about it that I'm uncertain how to prove or disprove. In order to present the question, I first need to explain how the algorithm works (because the question pertains to one particular part of it). Let's represent the "digits" of a number (in whatever base we are using) with capital letters. Let's assume that we want to multiply, for example, two 10-digit numbers, let's call them AAAAABBBBB and CCCCCDDDDD. In order to calculate the result, we first calculate these partial results:
z0 = DDDDD * BBBBB = EEEEEEEEEE
z2 = CCCCC * AAAAA = GGGGGGGGGG
z1 = (AAAAA+BBBBB) * (CCCCC+DDDDD) - z2 - z0 = FFFFFFFFFFFF
(Those three multiplications can be calculated by calling this algorithm recursively, which is the idea with it, and where the time saving comes from, as the normal four multiplications that would be required with a normal long multiplication algorithm are reduced to three.) Note that z1 above is 2 digits longer than the others (this is always so regardless of the sizes of the input values). This is because the result of the two additions are 6 digits long (the most-significant digit may be 1) and thus the result of the multiplication is 12 digits long. (I believe, although I'm not certain, those two most-significant digits of the result are always zero after the two subtractions. However, I'm leaving them there because they are relevant to my actual question.) In order to get the final result we have to add those three partial results, using an offset of 5 digits as needed (ie. in practice "multiplied by the base to the power of 5). This can be most clearly visualized like this:
            AAAAABBBBB
          * CCCCCDDDDD
  --------------------
            EEEEEEEEEE = z0
+    FFFFFFFFFFFF      = z1
+ GGGGGGGGGG           = z2
  --------------------
  RRRRRRRRRRRRRRRRRRRR = result
From a programming implementation point of view a slight space optimization can be done by noting that z0 and z2 do not overlap in the result. This means that they can be calculated directly into the result (thus removing the need for one temporary object, which may be quite large, to hold the value of z2). In other words, the operation can be done like this:
            AAAAABBBBB
          * CCCCCDDDDD
  --------------------
  GGGGGGGGGGEEEEEEEEEE = z2,z0
+ 000FFFFFFFFFFFF      = z1
  --------------------
  RRRRRRRRRRRRRRRRRRRR = result
The zeros at the beginning of that z1 summand are there to indicate that, from a programmatical implementation point of view, when z1 is added to the result in this manner, after adding its most-significant digit, if there is any carry left, it needs to be added to the result (in practice with an "add zero with carry" operation). In other words, as long as there is a carry, it needs to be added to the next digit of the result, and so on, until there is no carry left. Except, and this is where my question comes in... if I leave out those "add zero with carry" operations completely, the result still seems to be correct. In other words, there never seems to be a carry left after adding the last (ie. most-significant) digit of z1. Note that since z1 is two digits longer than necessary, it's in practice already doing two "add zero with carry" operations. And, in fact, if I leave the most-significant digit of z1 out, it still gives the correct result. (If I leave the two most-significant digits out, then it sometimes gives an incorrect result, so at least one carry needs to be added.) I have tested with tens of millions of random input values to multiply, and it always gives the correct result, without those extra "add zero with carry" operations. However, I have the hunch that this is just coincidence. I have the hunch that it's simply the case that the situations where more than one "add zero with carry" is needed are extraordinarily rare, but they exist, and that if you don't do it, then you would get an incorrect result in those cases. I have tried to come up with input values that would cause an erroneous result, but I can't come up with anything. But it may just be my lack of figuring out how this works precisely. So I would like to present a conjecture: When z1 above (of a size that's two digits larger than z0 and z2) is added to the result, no more carries are left, with any input values. I don't know how to prove that. Disproving the conjecture would be relatively simple, though: Two values that multiplied in this manner give the wrong result, if those "add zero with carry" operations are not done. (I would be very grateful if someone could provide me with such numbers. Even better, a pattern of such numbers, so that I can generate them for any sizes. This would be a great addition to my testing code.)
Player (96)
Joined: 12/12/2013
Posts: 376
Location: Russia
I want to make it rigorous, so I'll start from simple facts. First fact. If a < b then a * c < b * c, for any positive real numbers a, b, c. Proof: if a < b then (a - b) < 0, thus a*c - b*c = (a - b) * c - negative times positive = negative, so a*c < b*c. Second fact. if a < c and b < d then a * b < c * d. Proof: Using first fact a * d < c * d, and using first fact second time a * b < a * d. So, a * b < a * d < c * d. Third fact. if a < basen and b < basen, then a * b < base2n Proof: basen * basen = base2n Using second fact: a * b < base2n where c = basen and d = basen. Straight from this third fact, you can prove that z0 and z1 have this size. Why they're not intersecting - conjunction of their size and multiplier. Regarding to z1 - this formula is to reduce multiplication count, but if you open brackets you'll get more useful for prove formula: AAAAA*DDDDD+BBBBB*CCCCC. Using fact three you can tell that if a, b, c, d < basen then a*d < base2n, and b*c < base2n, thus a*d+b*c < 2*base2n. This means, that it's either 0FFFFFFFFFF or 1FFFFFFFFFF, because 20000000000 is already = 2*base2n but it should be less. Now, this means, that if you consider those two digits as last full carry propagation, then yes, this is last. But, if you mean that it's last digit where you should propagate carry - no. Look at this example:
      100001
     *999999
------------
 99900000999 = z2,z0
+  100899
------------
100000899999
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
r57shell wrote:
      100001
     *999999
------------
 99900000999 = z2,z0
+  100899
------------
100000899999
Indeed. Using this pattern, if I make the multiplicand be all zeros except for the first and last "digits", which are set to 1, and the multiplier to be the maximum value (ie. all bits set), then it indeed gives the wrong result if I don't do the "add zeros with carry" step. The tests pass if I do that step. This is a great addition to my testbed. Thank you! (This is also great information for a documentation I have been writing about these types of "bignum" calculations.)
Player (36)
Joined: 9/11/2004
Posts: 2623
I'm looking into some PPL (probabilistic programming language) stuff, and as part of that I'm trying to come up with approximations of the results of various functions applied to distributions. For instance, let's say I want to apply the sigmoid function 1/(1+e-x) to a normally distributed random variable. We can solve for the cdf of this distribution by feeding the inverse of the sigmoid through the cdf of a normal distribution. From this we wind up with a reasonably complicated distribution on (0, 1). I'd like to estimate this distribution with a beta distribution, but I have no idea how to go about it. Although I have an expression of the pdf of the resulting distribution, I cannot even calculate the expectation value of it. Outside of SVI or Monte Carlo methods is there a way to calculate this?
Build a man a fire, warm him for a day, Set a man on fire, warm him for the rest of his life.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
OmnipotentEntity wrote:
The most popular and mature bignum library has this documentation about their integer division algorithms: https://gmplib.org/manual/Division-Algorithms.html
This: https://gmplib.org/manual/Basecase-Division.html alludes to a long division algorithm that can be done one "digit" (or hardware word) at a time, but the description is a bit too vague to fully understand. I wonder if there would be a more detailed explanation somewhere.