1. ## Russian Peasent

So ive moved on(temporarily) from my other hw assignment onto the other one. THis one calls for a multiplication program that uses the russian peasent idea of multiplication (http://mathforum.org/dr.math/faq/faq.peasant.html)... Instead of x*y. anyways, ive think i got it, but im getting a compiler error for this code
Code:
```#include <FPT.h>
int main()
{
double x,y,a,b;
x=inD();
y=inD();
b=1;
while(floor(y/2)!=1){

if((fmod((x)/2))!=0){
if(b==1){
a=x;
}
else{
x=x*2;
y=(y/2);
a=x+x;
}
}
else{
x=x*2;
y=(y/2);

}```
I get an error for the line containing the fmod if statement.

2. To use the fmod function, you would need to include <math.h>. Of course, then you would find that fmod takes two arguments.

The fun part is that you can't use the Russian peasant method to multiply two floating-point numbers together; the number that you are successively halving must be an integer.

Nothing happens with b, and if a is supposed to be your answer you are not updating it very well.

3. Well we are assuming that you can only input whole numbers. And when else would i need to update my answer?

4. You wouldn't need to update it anywhere else (it should only update in the odd case, which is exactly where you have it). The problems are:
1. fmod((x)/2))!=0 isn't syntactically correct.
2. a=x+x is an ... interesting idea, but has no relationship to the Russian peasant method.
3. I won't argue about a and b being doubles, since they could get large, I guess (well, a can; b is completely unused in this whole thing, but I can think of a way to use it), but why not let x and y be ints? That would solve a couple problems in one shot and a couple billion isn't so bad for an input limit.

5. well isnt it only adding the x's together when the number is odd? so therefore i need to add the old x to the new x thus upping the answer each time the right side of the column is odd.

6. If by "old x" you mean "the answer" (which I assume you do, since you got it right after the word "upping") then you're absolutely correct. Now take a minute to realize how very very far away that is from "x+x".

7. Numbers in one column must be doubled, the other halved. If you ever skip this part the answer will be wrong. Rows with even numbers in the halving column are not part of the answer but are still part of the calculation.

8. ok so here is my updated code... but something is still wrong... i input 3 for x and 3 for y and get 0.
Code:
```#include <FPT.h>
int main()
{
double x,y,a;
x=inD();
y=inD();
b=1;
while(floor(y/2)!=1){

if(fmod(x,2)!=0){
if(b==1){
a=x;
b=0;
}
else{
x=x*2;
y=(y/2);
a=x+x;
}
}
else{
x=x*2;
y=(y/2);

}
}
outD(a);
}```

9. So if I do this by hand (and I am going to fix your indentation for the sake of me, tabstop and citizen).

Code:
```#include <FPT.h>
int main()
{
double x,y,a;
x=inD();
y=inD();
b=1;

while(floor(y/2)!=1){

if(fmod(x,2)!=0){
if(b==1){
a=x;
b=0;
}
else{
x=x*2;
y=(y/2);
a=x+x;
}
}
else{
x=x*2;
y=(y/2);
}
}
outD(a);
}```
I am inputting 3 and 3

3/2 != 1
fmod(3,2) != 0
b == 1 so a = x and b = 0
loop

fmod(3,2) == 1
b != 1
x=6;
y=1.5;
a=12;
loop

fmod(6,2) == 0
b != 1
x=12
y=0.75
loop

hmmmmm Why not just have it output more of what it is doing? Why are you doing this, anyway? What is your objective?

10. It's a lab assignment to just test our knowledge. Its just multliplying two numbers together. And i dont get what you suggested.. sorry lol. Im just confused as to why it doenst work

11. I am just wondering if it may be helpful to you to insert lines like outD(y) and outD(x) in each iteration so you can specifically see what each variable is doing (or use a debugger--which is what I would do).

12. I think you've made this way way way way way way way way way way more complicated then it actually in fact is. This is your algorithm, yes?
1. Set answer to 0 (which you've cleverly named "a").
3. Double x.
4. Halve y, discarding remainders (this is an important part that you seem to have skipped).
5. Go back to step 2 unless y is 0, in which case stop.

The "do something different in the first case" is probably unnecessary, and you certainly need to truncate y/2 (since y is a double, we're not doing integer division).

13. Jesus God... thank you tabstop, I was really not following what the ultimate objective was. And I was far too demotivated to scroll back up to the original post. Why not just use integers? Before you spout off anything about needing precision don't forget that 15 = 1.5 * 10. Thus you can simply work with y*10 and adjust your algorithm accordingly. Though, I would merely do this because its more intuitive to me. But do whatever you want... For that matter you could use bitshifts or something instead of y*10. But the point is basically the same.

14. by discarding remainders, can i use the "floor" function in order to satisfy it.. so floor(y/2)?

15. Wait, are you needing to round or discard remainders? If you are just needing to discard remainders you should just switch y over to an int anyway. Then you would not need to floor().