Velocity Reviews > Redirect to STDOUT Problem

# Redirect to STDOUT Problem

Default User
Guest
Posts: n/a

 05-13-2008
Jordan Glassman wrote:

> Ben,

Please don't top-post. Your replies belong following or interspersed
with properly trimmed quotes. See the majority of other posts in the
newsgroup, or:
<http://www.caliburn.nl/topposting.html>

Jordan Glassman
Guest
Posts: n/a

 05-13-2008
> Please don't top-post.

Lesson learned...

Default User
Guest
Posts: n/a

 05-13-2008
Jordan Glassman wrote:

> > Please don't top-post.

>
> Lesson learned...

Thanks!

Brian

viza
Guest
Posts: n/a

 05-13-2008
On May 13, 5:03 am, Richard Heathfield <(E-Mail Removed)> wrote:
> Jordan Glassman said:

> > if((((float)rand()/(float)RAND_MAX)) > 0.5)

>
> In C, the normal way to do (pseudo) random numbers selected from N
> possibilities (in the range 0 to N-1) is to get a value in the half-open
> range [0, 1) like this:
>
> rand() / (RAND_MAX + 1.0)
>
> and then multiply by N to get a value in the half-open range [0, N).
> It seems that you want a value in the half-open range [0, 1) so you can
> omit the multiplication step:
>
> if(rand() / (RAND_MAX + 1.0) > 0.5)

In this case, why not just use:

if( rand() & 1 )

If RAND_MAX is odd (which it usually is) then this is perfect, and
doesn't need an FPU.

If RAND_MAX is even, then it gets very close to perfect as long as
RAND_MAX is large. Remember that the float method isn't perfect
either.

If your rand() isn't evenly distributed, then you are screwed whatever
you do.

viza

Walter Roberson
Guest
Posts: n/a

 05-13-2008
In article <(E-Mail Removed)>,
viza <(E-Mail Removed)> wrote:
>On May 13, 5:03 am, Richard Heathfield <(E-Mail Removed)> wrote:
>> Jordan Glassman said:

>> > if((((float)rand()/(float)RAND_MAX)) > 0.5)

>In this case, why not just use:

>if( rand() & 1 )

>If RAND_MAX is odd (which it usually is) then this is perfect, and
>doesn't need an FPU.

The low bit of rand() is often not very random at all -- often alternating
between 0 and 1 each time. It's a problem with linear congruential
pseudo-random numbers, at least if you take the bottom bits of the
new seed as being the random value. (Some implementations make sure
they never output the bottom bits to reduce this problem, but
C doesn't make any such promises.)
--
"Man's life is but a jest,
A dream, a shadow, bubble, air, a vapor at the best."
-- George Walter Thornbury

Richard Tobin
Guest
Posts: n/a

 05-13-2008
In article <g0cuqm\$ael\$(E-Mail Removed)>,
Walter Roberson <(E-Mail Removed)-cnrc.gc.ca> wrote:

>The low bit of rand() is often not very random at all -- often alternating
>between 0 and 1 each time.

This used to be true, 20-something years ago. Surely modern
implementations don't have the same problem?

-- Richard
--
:wq

Walter Roberson
Guest
Posts: n/a

 05-13-2008
In article <g0d2i5\$26j0\$(E-Mail Removed)>,
Richard Tobin <(E-Mail Removed)> wrote:
>In article <g0cuqm\$ael\$(E-Mail Removed)>,
>Walter Roberson <(E-Mail Removed)-cnrc.gc.ca> wrote:

>>The low bit of rand() is often not very random at all -- often alternating
>>between 0 and 1 each time.

>This used to be true, 20-something years ago. Surely modern
>implementations don't have the same problem?

Remember, the C89 standard was 20-something years ago, but conforming
more modern implementations (C99) are still pretty uncommon

To be fair: the C89 sample implementation works with an
unsigned long int seed, and the value returned is divided by 64K and
is mod 32768 (e.g., shift right 16 bits and mask out all but the
bottom 15 bits). With that sample algorithm, the bottom bit of rand()
should have a cycle of 64K (which would, I -suspect-, be composed
of two half-cycles of 32K each, bitwise negations of each other.)
--
"The shallow murmur, but the deep are dumb." -- Sir Walter Raleigh

lawrence.jones@siemens.com
Guest
Posts: n/a

 05-14-2008
Richard Tobin <(E-Mail Removed)> wrote:
> In article <g0cuqm\$ael\$(E-Mail Removed)>,
> Walter Roberson <(E-Mail Removed)-cnrc.gc.ca> wrote:
>
>>The low bit of rand() is often not very random at all -- often alternating
>>between 0 and 1 each time.

>
> This used to be true, 20-something years ago. Surely modern
> implementations don't have the same problem?

I only know of *one* implementation that had that problem, and that was
more like 30 years ago. (Someone at UCB "enhanced" a perfectly good
16-bit rand() to return 32 bit values by simply returning the entire
internal state rather than just the high-order 16 bits.)

-- Larry Jones

I wonder what's on TV now. -- Calvin

Szabolcs Borsanyi
Guest
Posts: n/a

 05-14-2008
> produces a blinking cursor, an empty file named "output," and a
> program that runs forever. *With no redirect, the output is normal.

As I see your problem has been solved. I got similar behaviour
when I did not wait for the program to completely finish.
Without redirection I saw the results immediately, but
redirection sometimes implies a buffering and the buffer
is lost if the program terminates abnormally.

> Below is the printf statement used to generate output.
>
> printf("B=%4.2f E=%8.4f m=%8.4f Cv=%5.2f \
> Chi=%5.2f\n",beta,(energy/n2),(moment/n2), \
> (summe2-summe*summe)/n2, \
> (summm2-summm*summm)/n2);

Sorry for this remark, but, this last lines made me
suspicious: This is a 2dimensional ising model,
Cv is the specific heat, which is the energy density fluctuation,
so I expect a standard deviation there.
Don't you then miss an other 1/n2 no normalise summe and summm?
I can be completely wrong, but you might want to check this.

Szabolcs