Need experts suggestion

[Richard Tobin]

The (strong and weak) laws of large numbers are theorems relating
expected gain to actual gain, and show that if certain facts are true
of the distribution of results then your actual gain will almost
certainly tend to the expectation. But these laws do not apply to
lotteries of the kind under discussion, since the number of trials
available is nowhere near large enough.

[/QUOTE]

Then they're using a different definition of "expected" than I learned,
and your probabilistic "actual gain" corresponds _exactly_ to what
I learned the term "expected value" to describe.

The expected gain is defined as the sum (or integral) of the
probabilities multiplied by the corresponding gains.

The use of the word "expected" suggests that it's somehow the value
you'd expect in the long run, but that definition above doesn't say
anything about that. It's not an average over all your trials, it's a
weighted average over all possibilities.

The laws of large numbers relate these two concepts. Obviously
they're still probabilistic, because there is no guarantee that you
will not win every time. They show that as you do more trials, the
chance of your actual gain being far from the expected gain tends to
zero.

In the case of a lottery, the numbers of entries you can make is
nowhere near high enough for these laws to apply. So you have no
basis for using the expected gain as a criterion for deciding whether
to gamble.

-- Richard

 

[Keith Thompson]

It's debatable, but I think that's correct. For
example, consider

#include <stdio.h>
int main(void) {
printf ("Hello, world!\n");
/* No U.B. prior to this point */
return 1 / 0;
}

If the compiler tries to replace `1 / 0' by a constant
value computed at compile time and while doing so detects the
division by zero, I believe it is within its rights to refuse
to accept the program. If it refuses the program, the program
will not run and will not produce output, so the division by
zero effectively cancels "earlier" side-effects.

It's not really debatable; it's stated in the standard in black and
white. C99 3.4.3:

3.4.3
undefined behavior

behavior, upon use of a nonportable or erroneous program construct
or of erroneous data, for which this International Standard
imposes no requirements

NOTE Possible undefined behavior ranges from ignoring the
situation completely with unpredictable results, to behaving
during translation or program execution in a documented manner
characteristic of the environment (with or without the issuance of
a diagnostic message), to terminating a translation or execution
(with the issuance of a diagnostic message).

EXAMPLE An example of undefined behavior is the behavior on
integer overflow.

One could conceivably debate this based on the fact that notes are
non-normative, but it would be a boring debate.

 

[Guest]

It's not really debatable; it's stated in the standard in black and
white. C99 3.4.3:

While that does cover Eric's example, it doesn't address this slightly
modified example:

#include <stdio.h>
int main(int argc, char *argv[]) {
printf ("Hello, world!\n");
/* No U.B. prior to this point */
return 0 / argc;
}

I don't think an implementation can legitimately refuse to compile
this. Is it allowed to compile this into the same code as

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[]) {
if(argc == 0)
abort();

printf ("Hello, world!\n");

return 0;
}

then?

 

[Flash Gordon]

Then they're using a different definition of "expected" than I learned,
and your probabilistic "actual gain" corresponds _exactly_ to what
I learned the term "expected value" to describe.

The expected gain is defined as the sum (or integral) of the
probabilities multiplied by the corresponding gains.

The use of the word "expected" suggests that it's somehow the value[/QUOTE]

In the case of a lottery, the numbers of entries you can make is
nowhere near high enough for these laws to apply. So you have no
basis for using the expected gain as a criterion for deciding whether
to gamble.

Actually, this argument is largely irrelevant to the UK national lottery
since the expected return is 50%. The reason for this is that first they
they take away half the money to pay costs and distribute, then from the
remaining 50% they pay out all the fixed 10UKP prizes, then they divide
what is left (i.e. under 50% of the money paid in) between the other
prizes. Even with a roll over (when money from the last draw is rolled
over to the next because no one won the jackpot) I believe (but could be
wrong) you still don't reach a 100% return of the money paid in for that
draw because the amount rolled over is not large enough, so the expected
return is still less than you pay in.

 

[Richard Bos]

While that does cover Eric's example, it doesn't address this slightly
modified example:

#include <stdio.h>
int main(int argc, char *argv[]) {
printf ("Hello, world!\n");
/* No U.B. prior to this point */
return 0 / argc;
}

I don't think an implementation can legitimately refuse to compile
this. Is it allowed to compile this into the same code as

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[]) {
if(argc =3D=3D 0)
abort();

printf ("Hello, world!\n");

return 0;
}

then?

Certainly. For example, it's allowed to compile it to object code that's
tantamount to this:

- compute 0/argc; push that value on the stack.
- empty the memory that used to be taken by argc, argv and the
argument retrieval code.
- load code for puts() into that empty memory.
- do puts("Hellow, world!");.
- push a value and return with it.

If the way this program is called does not invoke undefined behaviour,
this is a valid way to execute it. If the program is called with argc
equal to 0... it is equally valid, but it crashed before printing.

Richard

 

[Guest]

While that does cover Eric's example, it doesn't address this slightly
modified example:

#include <stdio.h>
int main(int argc, char *argv[]) {
printf ("Hello, world!\n");
/* No U.B. prior to this point */
return 0 / argc;
}

I don't think an implementation can legitimately refuse to compile
this. Is it allowed to compile this into the same code as

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[]) {
if(argc =3D=3D 0)
abort();

printf ("Hello, world!\n");

return 0;
}

then?

Certainly. For example, it's allowed to compile it to object code that's
tantamount to this:

- compute 0/argc; push that value on the stack.
- empty the memory that used to be taken by argc, argv and the
argument retrieval code.
- load code for puts() into that empty memory.
- do puts("Hellow, world!");.
- push a value and return with it.

If the way this program is called does not invoke undefined behaviour,
this is a valid way to execute it. If the program is called with argc
equal to 0... it is equally valid, but it crashed before printing.

Thanks, then I have one more question:

#include <stdlib.h>
int main(int argc, char *argv[]) {
exit(0);
/* No U.B. prior to this point */
return 0 / argc;
}

Here, the same transformation would be an invalid one, would it not? I
think so, but I'd like to be sure.

 

[Richard Bos]

While that does cover Eric's example, it doesn't address this slightly
modified example:

#include <stdio.h>
int main(int argc, char *argv[]) {
printf ("Hello, world!\n");
/* No U.B. prior to this point */
return 0 / argc;
}

I don't think an implementation can legitimately refuse to compile
this. Is it allowed to compile this into the same code as

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[]) {
if(argc =3D=3D 0)
abort();

printf ("Hello, world!\n");

return 0;
}

then?

Certainly. For example, it's allowed to compile it to object code that's
tantamount to this:

- compute 0/argc; push that value on the stack.
- empty the memory that used to be taken by argc, argv and the
argument retrieval code.
- load code for puts() into that empty memory.
- do puts("Hellow, world!");.
- push a value and return with it.

If the way this program is called does not invoke undefined behaviour,
this is a valid way to execute it. If the program is called with argc
equal to 0... it is equally valid, but it crashed before printing.

Thanks, then I have one more question:

#include <stdlib.h>
int main(int argc, char *argv[]) {
exit(0);
/* No U.B. prior to this point */
return 0 / argc;
}

Here, the same transformation would be an invalid one, would it not? I
think so, but I'd like to be sure.

Yes, because the UB is guaranteed not to be reached.

Richard

 

[Dietmar Schindler]

Dietmar Schindler wrote:


You're mistaken. I don't see the so-called "laws of physics" amongst
the C99 normative references.

And don't try to blame your hangover on the nasal demons. They
_really_ don't like that.

Thanks for your second paragraph; before reading it, I was about to take
your first one serious, but I now recognize the good advice in the last.

 

[Malcolm]

Then they're using a different definition of "expected" than I learned,
and your probabilistic "actual gain" corresponds _exactly_ to what
I learned the term "expected value" to describe.

The expected gain is defined as the sum (or integral) of the
probabilities multiplied by the corresponding gains.

The use of the word "expected" suggests that it's somehow the value
you'd expect in the long run, but that definition above doesn't say
anything about that. It's not an average over all your trials, it's a
weighted average over all possibilities.

The laws of large numbers relate these two concepts. Obviously
they're still probabilistic, because there is no guarantee that you
will not win every time. They show that as you do more trials, the
chance of your actual gain being far from the expected gain tends to
zero.

In the case of a lottery, the numbers of entries you can make is
nowhere near high enough for these laws to apply. So you have no
basis for using the expected gain as a criterion for deciding whether
to gamble.
[/QUOTE]
You've got it.
It's not worth buy lottery tickets even on the weeks when the jackpot
exceeds £14 million, because the chance of winning is too low to be humanly
meaningful, given that you can only buy a few thousand tickets at most.
The modal payoff is zero, and the proability of the mode is so high that
this is the value we need to focus on.