C# help

Don't know C#, so syntax may not be right

private void button1_Click(object sender, EventArgs e)
{

int days = int.Parse(txtd.Text);
int totalCents = 0;

for (int a=1; a<=days; a++)
{
totalCents += Math.Pow(2, (a - 1);
rtb.AppendText("Day " + a + " Pennies " + Math.Pow(2, (a - 1)) + "\n");
}

rtb.AppendText("Total Pennies " + totalCents + "\n");

}

>>208334
Protip: this is adding together binary numbers that start with 1 and are then 0s all the way down.

So day 1 is 1, day 2 is 10, day 3 is 100, etc.

This means the total for day 1 is 1, day 1-2 is 11, day 1-3 is 111, day 1-4 is 1111, etc.

Which means you don't need to add up the total at all. The total on day 4 is just the amount on day 5, minus 1.

Why is this relevant? Asymptotic run time. If I just ask you how much the total is on day 200, then your program is adding each day on, it needs to add up 200 times, so it takes 200 times as long as it took to give the total for day 1.

Whereas total=(2^(n+1))-1 takes the same time no matter the value of n.

I'm pretty new to programming and started C recently. I don't know if this will help you but this is what I came up with.

#include <stdio.h>

int main(void)
{

int days, i;
double current_pay = 0.01;
double sum = 0.00;

printf("Enter amount of days Susan will work: ");
scanf("%d", &days);

printf("DAY\tPAYMENT\n");

for(i = 1; i <= days; i++){
if (i < 2)
current_pay += current_pay - 0.01;
else
current_pay+=current_pay;

sum += current_pay;

printf("%d\t%.2lf\n",i, current_pay);
}

printf("The total amount Susan made throughout %d days was $%.2lf\n", days, sum);

return 0;
}

>>208334
I don't know C#, but here's the solution in C:
[code]
#include <stdio.h>

int main (void)
{
int i, days, pay = 1;

printf("Enter the number of days: ");
scanf("%d", &days);

for (i = 1; i < days; ++i) {
pay += pay * 2;
}

return 0;
}
[/code]

File: slide_19[1].jpg (58KB, 960x720px) Image search: [Google]

58KB, 960x720px

>>208473
>double
You're dealing with a rational number, so you should use an integer type, for instance a long long.

Doubles only have a 52-bit mantissa, so after day 52 they'll start to produce results which are approximate, i.e. incorrect.

Plus integer math is faster all-round.

In general, when you're dealing with discrete quantities (i.e. dollars, sheep, etc.) you should use an integer multiple of the smallest amount there can be (i.e. pennies), and then do the conversion into fixed-point only when you actually display the quantity.


* yeah, a 64-bit long long won't last much longer, but it will be precise right up until it fails.

>>208481
I'm not that advanced yet, but I think I know what you're saying. Is this better?

#include <stdio.h>

int main(void)
{

int days, i;
signed long long current_pay = 1;
signed long long sum = 0;

printf("Enter amount of days Susan will work: ");
scanf("%d", &days);

printf("DAY\tPENNIES\n");

for(i = 1; i <= days; i++){
if (i < 2)
current_pay += current_pay - 1;
else
current_pay+=current_pay;

sum += current_pay;

printf("%d\t%lli\n",i, current_pay);
}

printf("The total amount Susan made throughout %d days was $%.2lf\n", days, sum * 0.01);

return 0;
}

>>208484
meant to use unsigned there, oh well.

>>208493
You're using C, so you need to get in the habit of doing bounds-checking by hand. C doesn't do it for you, it just overflows.

Regardless of whether you're using signed or unsigned, you need to be checking for overflow, because saying she gets -1¢ on day 64 is only slightly more bad than saying she gets no more money from day 65 onwards.

Oh, boi

>>208481
>Doubles only have a 52-bit mantissa, so after day 52 they'll start to produce results which are approximate

go to wikipedia and learn what mantissa is. There is even nice formula for that.

>>208481
>52-bit mantissa, so after day 52

Lol, wtF?


>>208481
>Plus integer math is faster all-round.

a) it does not matter
b) it is not always true e.g. SIMD

>>208481
> do the conversion into fixed-point only when you actually display the quantity

So you want to display $2,123123123 to the end user? You supply calculator for free?

File: image.jpg (79KB, 750x420px) Image search: [Google]

79KB, 750x420px

>>208529
You seem confused about how floating point works. I suggest you read https://en.m.wikipedia.org/wiki/Double-precision_floating-point_format .

>after day 52
>Lol, wtF?
Keep up here. The sum is (2^n+1)-1, where n is the number of days. This number is not representable in IEEE floating point beyond 2^52, so if you're summing (like every algorithm in this thread so far) you will sum wrong because your sum (which is an integer) is no-longer representable to the nearest integer.

>>208529
>So you want to display $2,123123123 to the end user? You supply calculator for free?
You put the decimal point in with sprintf, my ESL friend.