*To*: debian-devel@lists.debian.org*Subject*: Re: Stupid Arithmetic Tricks*From*: Erich Schubert <erich@debian.org>*Date*: Fri, 29 Mar 2002 12:57:45 +0100*Message-id*: <20020329115744.GD2275@marvin.xmldesign.de>*In-reply-to*: <20020328173156.GP19063@deadbeast.net>*References*: <20020328020840.GA4665@x8b4e53d6.dhcp.okstate.edu> <20020328173156.GP19063@deadbeast.net>

> You're using (IMO) the wrong technique. Your brain is not a pencil and > paper, so don't try to make it work that way. My approach to doing that > kind of problem in my head is something like: Well, you always must be aware that our brain has a few very special features: we can guess very fast - and find similar problems fast. Always keep these two things in mind, that'll help often ;) > Well, that's 70 3 times, minus 1 cent 3 times. Well, you found a nice similar problem here ;) Some other thing would be to decompose 69 into 3 * 23, giving us 9*23 which ist 230-23 thus 207. This is some other way of finding similar problems. Learn to love single digits. The nine is especially great in decimal systems ;) 19 is nice, too. In fact i even know some easy tests if a number can be divided by x*10+9 which might help sometimes. > If you need to be careful, you can validate your result just by doing > the "ones" digit of the original multiplication. We know that nine > times three is 27, and my answer ends in a seven, so I can be reasonably > sure I did it correctly. Depends on how you work. Checking if the number can be divided by some factor is very very helpful, too. So keep in mind how to check if some number can be divided by some basic factors like 2,3,4,5,6,8,9,10,11,12. (for the seven i recommend knowing the multiples of it ;) 207 can be easily checked by calculating 2+0+7 = 9, which shows that this result is some x * 9 - and 207 is uneven, thus ruling out 22*9 and 24*9, so i can be pretty sure about it being 9*23 ;) When working with matrices, do learn your verification algorithms, learn the valid transformations you can do etc. Same goes for all other structures. You absolutely must be able to recognize things like (a+b)^2 written as a^2+2ab+b^2. Learn to recognize and pull out common factors. Learn how to substitute in formulas. Sometimes it'll help a lot to calculate the algebraic sign separately, while not caring for it when calculating the numerical value. A very neat way of verifying your formulas is - especially in physics - if the result has the expected unit. This can also be done in mathematics and computer science in quite a few cases. Add some imaginary units to your values, and check if the result will be properly dependant on the unit selection... > If I'm given a long column of one or two-digit numbers to add up (on > paper), I go down the ones column and strike out all complementary pairs Well, that's the trick how Gauss is said to have surprised his teacher... because he was so fast in calculating, his teacher gave him the task to add up all numbers from 1 to 100. Gauss just formed pairs that sum up to one hundred... some story often told in school here. Basically you apply some sorting before calculating. You'll soon start striking out 12, 32, 56, too. Know your nine there, too... > Now, since you can probably mop the floor with me when it comes to diff > eq's, I'll defer to yours as the greater mathematical talent. I thought > I was pretty good at math until I hit that brick wall. I phear people > who can look at one and "just know" which solution technique to apply. I think a very good trick is to do reverse engineering... Start with the solutions, and make diff eq's from them. That way you should be able to understand the details that give hints about the solution. You should also always keep your basic algorithm knowledge in mind. Lot's of these algorithms are quite simple; but if you know them by heart you'll be able to make use of them much more often. One algo i like particulary much is "topological sort". Simple, but can give you major speed gains. You can also _very_ often use QuickSort in real life. And it most probably will be the fastest way to sort: you can _guess_ the pivots very well. So if you have to sort a few numbers, guess the pivot, then start underlining/highlighting/etc. values to divide them into two groups (you can of course do this with multiple pivots...) that way you'll get the number of values down quite fast. You can even do this, if you have to sort a few numbers without the help of any tools. Just set a limit. Count how many numbers are below your limit, and sort these first. then raise your limit etc. And do practise. Avoid using the calculator for everything. Spend a few seconds for everydays simple calculations - you'll gain much on difficult ones, even when using the calculator for them: you'll learn lot's of tricks for "optimizing" the calculation even with the calculator. Playing with numbers will give you some feeling for all this stuff... For example, take the very special number 142857. Multiply it with (1,2,3,4,5,6) and compare the results. Amazing, isn't it? Now where does that come from? Have a look at 142857*7 - and calculate 1/7 ... next number with similar properties is the cycle of 1/19 i think. Greetings, Erich -- To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

**Follow-Ups**:**Re: Stupid Arithmetic Tricks***From:*mdanish@andrew.cmu.edu

**References**:**Re: ITP: mencal -- A menstruation calendar***From:*David Starner <starner@okstate.edu>

**Stupid Arithmetic Tricks***From:*Branden Robinson <branden@debian.org>

- Prev by Date:
**Re: Debian's problems, Debian's future** - Next by Date:
**rsync vs. diff for updating the Packages lists.** - Previous by thread:
**Re: Stupid Arithmetic Tricks** - Next by thread:
**Re: Stupid Arithmetic Tricks** - Index(es):