nrand48 ?!?!?!?!

[Skybuck Flying]

I am beginning to see why microsoft did not include this nrand SHIT !!!!

1. The documentation is SHIT

2. The implementation is SHIT

=D

IN OTHER WORDS UNIX IS SHIT !

IF THESE FUCKING IDIOTS CANT EVEN MAKE A FUCKING RANDOM FUNCTION AND
DOCUMENT IT WELL SO THAT PEOPLE CAN UNDERSTAND IT

THEN WHAT CAN THESE STUPID UNIX FUCKHEADS DO RIGHT ????

Lol, Thank you

I'll leave the rest of my calm post in which I wrote before this rant LOL

Though I think the RANT is more important

Ok,

I am at a total loss now

3 Different results actually 4... and the documentation ain't helping.

1. Different results on linux/knoppix
2. Different results on windows xp
2.1 Different results when using brackets
2.2 Different results if state48 is changed/initialized ???

How is one supposed to use nrand48( ??? ) ?????????????

With some parameters ???

The documentation is not clear about this or the function is mal functioning


I think the documentation says nrand48 can be used without initialising
anything ???

"
The erand48(), nrand48() and jrand48() functions do not require an
initialisation entry point to be called first.
"

???

int main()
{
uint16 state48[3];

//state48[0] = 0;
//state48[1] = 0;
//state48[2] = 0;


printf("%d \n", nrand48(state48) );
printf("%d \n", nrand48(state48) );
printf("%d \n", nrand48(state48) );
printf("%d \n", nrand48(state48) );
printf("%d \n", nrand48(state48) );

// the windows xp / visual c/c++ 6.0 output is:
// source version 0.01 - version 0.03:
// without brackets:

// 1288336289
// 893806678
// 810173679
// 37620279
// 474250687

// source version 0.04:
// with brackets:

// 257717153
// 323532094
// 23385569
// 378241935
// 2040867715

// the linux/knoppix 3.1 kdev ??? output is:
// source version 0.03:

// default nrand48:
// 1367402799
// 1703755632
// 1875357054
// 1202986045
// 1604074163



return 0;
}

Sigh,


It would be nice if nrand48 and the test program produced the same results
on

1. Linux/Knoppix
2. Windows XP

Isn't it supposed to produce the same output ?

If Yes,

Then possibly test program flawed
Then possibly nrand48 routine flawed

If no

Then quite with unix shit and move on =D replace it/use it whatever...

NONONO can't do that...

I need a good nrand48() function to make sure the program works like it was
designed.

Though seeing a coder not using ( ( ( ) ) ) to make the calculations more
robust starts to make me wonder about the coder's quality level.

If I ever design a programming language I'll make damn sure that this code
can't compile ever

a = f << b | c >> d * e / k; // or any other code like it

Only this will be allowed:

a = ( ( f << b ) | ( c >> d ) * e ) / k; // or whatever way it was ment to
do the calculations as long as 2 operands are nicely wrapped in ()

All math people can go up a tree

As you can see I am getting pretttttttty fed up with nrand48, C, C
programmers and the fricking heat inside and outside this fricking
appartment

At this point I fucking lost it and made the fucking RANT LOL
YESSSSSSSssssssssssssssssssssssssssssssssssssssssssssssssssssss

Bye,
Skybuck

 

[Goran Larsson]

IN OTHER WORDS UNIX IS SHIT !

Why are you complaining about UNIX when you have trouble with GNU (Gnu
is Not Unix) software, Linux software and MS Windows software? Why
blame UNIX?

How is one supposed to use nrand48( ??? ) ?????????????

With some parameters ???

Yes. One argument (a pointer to an array containing a 48 bit Xi) that
the nrand48 function can use to store state data between calls. If you
need the same random sequence each time you need to initialize this
array with a known Xi.

I think the documentation says nrand48 can be used without initialising
anything ???

Yes, but then your random sequence depends on the initial Xi.

It would be nice if nrand48 and the test program produced the same results
on

1. Linux/Knoppix
2. Windows XP

Unless you initialize Xi (the array you call state48) the algorithm
will start with different Xi values depending on what undefined junk is
present in state48 (you have made it an auto variable so it will have
undefined junk in it when it is created).

Isn't it supposed to produce the same output ?

With the same Xi it should. It does on my systems, but I use a real
UNIX system, not the kind of wannabe systems that you appear to use.

If the implementations you are using use different internal parameters
then you could use lcong48() to change them before calling nrand48().

 

[Jens.Toerring]

I am beginning to see why microsoft did not include this nrand SHIT !!!!

MS probably never tried to because that functions have been declared
obsolete since years and years and years. From the way you sound they
probably were already declared deprecated before you were born. My
Linux documentation explicitely says

These functions are declared obsolete by SVID 3, which
states that rand(3) should be used instead.

You are the only one insisting on using it.

1. The documentation is SHIT

Have you read it? It can't keep from getting the feeling that you didn't.
Have you already figured out how to use the "man" command under UNIX?

2. The implementation is SHIT

No, it works exactly as it should. It's only you making a mess out
of it when you try to move it to another system without properly
understanding what's going on.

How is one supposed to use nrand48( ??? ) ?????????????

With some parameters ???

The documentation is not clear about this or the function is mal functioning

Exactly as described in the documentation. You call it with an array
of 3 unsigned short int values which contain values for storing the
intermediate state of the function between calls.

I think the documentation says nrand48 can be used without initialising
anything ???

No, you do that by setting initial values for the 3 values in the
array you call 'state48'.

int main()
{
uint16 state48[3];

//state48[0] = 0;
//state48[1] = 0;
//state48[2] = 0;

That way the state48 array is uninitialized, holding some completely
random values when you start the program. The values have even a
good chance to be different on each invocation of the program,
resulting in a different sequence of numbers in each run.

Make that

unsigned short int state48[ 3 ] = { 0, 0, 0 };

in order to start with a well-defined initial value.

printf("%d \n", nrand48(state48) );
printf("%d \n", nrand48(state48) );
printf("%d \n", nrand48(state48) );
printf("%d \n", nrand48(state48) );
printf("%d \n", nrand48(state48) );

<bogus resultts snipped>

Guess what: I get (with state48 initialized with 0) on my Linux box::

0
2116118
89401895
379337186
782977366
196130996

and on IRIX, i.e. using a different architecture, a different OS,
a different compiler, a different libc:

0
2116118
89401895
379337186
782977366
196130996

and on OSF1, i.e. another different architecture, another different OS,
another different compiler and another different libc:

0
2116118
89401895
379337186
782977366
196130996

So you see: three different, independend implementations of the function
and all giving the same results. I'm sorry, but since I'm just a "STUPID
UNIX FUCKHEAD" I can't deliver any results for an MS system...

return 0;
}

It would be nice if nrand48 and the test program produced the same results

Well, wouldn't it?

Isn't it supposed to produce the same output ?

If Yes,

Then possibly test program flawed
Then possibly nrand48 routine flawed

Probably both.

I need a good nrand48() function to make sure the program works like it was
designed.

The way you try to do it (i.e. by copying some rather cryptic internal
code from some implementation you don't seem to understand instead of
trying to understand the algorithm and doing a clean new implementation)
obviously makes everything unnecessarily complicated and results in
nearly unreadable code.

Look, the following took me less than 10 minutes to put together.
And it gives exactly the same results as using the nrand48() function
coming from the glibc when comparing results for the first ten million
calls (which of course is no proof that the implementation is correct
but seems to be good enough for me at the moment):

#include <stdio.h>
#include <stdlib.h>

static long int n48( unsigned short int xsub[ 3 ] );

int main( void )
{
int i;
unsigned short xsubi[ 3 ] = { 0, 0, 0 };

for ( i = 0; i < 5; i++ )
printf( "%ld\n", n48( xsubi ) );
return EXIT_SUCCESS;
}

static long int n48( unsigned short int xsub[ 3 ] )
{
static unsigned long long a = 0x5DEECE66DULL;
static unsigned long long c = 0xBULL;
unsigned long long X = ( ( unsigned long long ) xsub[ 2 ] << 32 ) |
( ( unsigned long long ) xsub[ 1 ] << 16 ) |
( unsigned long long ) xsub[ 0 ];

X = X * a + c;

xsub[ 0 ] = X & 0xFFFF;
xsub[ 1 ] = ( X >> 16 ) & 0xFFFF;
xsub[ 2 ] = ( X >> 32 ) & 0xFFFF;

return ( X >> 17 ) & 0x7FFFFFFFUL;
}

All you need to do is replace the "unsigned long long" stuff by uint64
(or whatever) because your compiler does not seem to know about "long
long" and you thus have to use some special magic to get at the correct
types. But don't blame this on C, it's just something our compiler re-
quires. You may also have to remove the "ULL" bit after the constants
or replace it with something your compiler understands.

Though seeing a coder not using ( ( ( ) ) ) to make the calculations more
robust starts to make me wonder about the coder's quality level.

They don't make calculations anymore robust. If you put some where they
aren't required you may just make the code a bit easier to read for an
unexperienced programmer. Why don't you at least take the time to look up
a simple table of operator precendences in C and find out where they are
needed? Or don't you understand the code at all you're trying to write?

Regards, Jens

 

[Skybuck Flying]

Well Thank You For This Calm And Clear Explanation.

See How Simple That Was ?

Compare That With This:

http://www.opengroup.org/onlinepubs/007908799/xsh/drand48.html

Then Anybody Reading My Aggreviated Response Will Understand Why It Was
Aggreviated

Well At Least When You Look At It From My Perspective:

"I Don't Give A F**K How NRand48 Works, I Just Want To Be Able To Use It"
=DDDDDD LOL

All I Needed To Know Is:

NRand48( Some F***ED Parameter )

The parameter passed to NRand48 is used to generate the random value. The
parameter passed to NRand48 is also updated/changed so that the next time
the function is called with the modified parameter the next random value
will be produced and returned.

Something like that would be just fine, sigh.

But noooooooooooooooooooooooooooooooooooooooooooooooooooooooo

MUST BE STUPID LIKE HOMER SIMPSONS.... MUST MAKE COMPLEX STATEMENTS... MUST
THINK LIKE ROBOT HAHAHA.

BYEEEEeeeee I am not even putting my name under this *****

 

[Emmanuel Delahaye]

I am beginning to see why microsoft did not include this nrand SHIT !!!!

Get your pills...

 

[Emmanuel Delahaye]

MUST BE STUPID LIKE HOMER SIMPSONS....

Hey, don't say a word on my Heroe! BTW it's 'Simpson'.

 

[Skybuck Flying]

Why are you complaining about UNIX when you have trouble with GNU (Gnu
is Not Unix) software, Linux software and MS Windows software? Why
blame UNIX?

nrand is from unix ?!?

Notice on top of website:

http://www.opengroup.org/onlinepubs/007908799/xsh/drand48.html

"
The Single UNIX ® Specification, Version 2

Copyright © 1997 The Open Group

 

[Skybuck Flying]

Get your pills...

I dont need em I have a pepsi lol completely off topic.

 

[Goran Larsson]

nrand is from unix ?!?

Perhaps, but that has nothing to do with your problems.

Notice on top of website:

http://www.opengroup.org/onlinepubs/007908799/xsh/drand48.html

A well written and easy to understand description of a family of
old functions that can be used to generate random numbers.

Don't blame this document if you have trouble making your program
work using an implementation provided by Microsoft.

 

[Skybuck Flying]

I am beginning to see why microsoft did not include this nrand SHIT !!!!

MS probably never tried to because that functions have been declared
obsolete since years and years and years. From the way you sound they
probably were already declared deprecated before you were born. My
Linux documentation explicitely says

These functions are declared obsolete by SVID 3, which
states that rand(3) should be used instead.

You are the only one insisting on using it.

1. The documentation is SHIT

Have you read it? It can't keep from getting the feeling that you didn't.
Have you already figured out how to use the "man" command under UNIX?

2. The implementation is SHIT

No, it works exactly as it should. It's only you making a mess out
of it when you try to move it to another system without properly
understanding what's going on.

How is one supposed to use nrand48( ??? ) ?????????????

With some parameters ???

The documentation is not clear about this or the function is mal functioning

Exactly as described in the documentation. You call it with an array
of 3 unsigned short int values which contain values for storing the
intermediate state of the function between calls.

I think the documentation says nrand48 can be used without initialising
anything ???

No, you do that by setting initial values for the 3 values in the
array you call 'state48'.

int main()
{
uint16 state48[3];

//state48[0] = 0;
//state48[1] = 0;
//state48[2] = 0;

That way the state48 array is uninitialized, holding some completely
random values when you start the program. The values have even a
good chance to be different on each invocation of the program,
resulting in a different sequence of numbers in each run.

Make that

unsigned short int state48[ 3 ] = { 0, 0, 0 };

in order to start with a well-defined initial value.

printf("%d \n", nrand48(state48) );
printf("%d \n", nrand48(state48) );
printf("%d \n", nrand48(state48) );
printf("%d \n", nrand48(state48) );
printf("%d \n", nrand48(state48) );

<bogus resultts snipped>

Guess what: I get (with state48 initialized with 0) on my Linux box::

0
2116118
89401895
379337186
782977366
196130996

and on IRIX, i.e. using a different architecture, a different OS,
a different compiler, a different libc:

0
2116118
89401895
379337186
782977366
196130996

and on OSF1, i.e. another different architecture, another different OS,
another different compiler and another different libc:

0
2116118
89401895
379337186
782977366
196130996

So you see: three different, independend implementations of the function
and all giving the same results. I'm sorry, but since I'm just a "STUPID
UNIX FUCKHEAD" I can't deliver any results for an MS system...

These are my results from a windows xp system and visual c/c++ 6.0

// results with brackets and initialization:

// 0
// 2116118
// 946866115
// 123371805
// 54936900

// results without brackets and initialization:

// 0
// 2116118
// 89401895
// 379337186
// 782977366

SIGH

I WAS HOPING TO SAY: "THANK GOD FOR THAT, I'M DONE WITH NRAND48"

BUT NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO

NOW THE BIG QUESTION IS ABOUT THE BRACKETS VS THE NON BRACKETS ?!

In other words in function:

sint32 drand48_iterate( uint16 xsubi[3], struct drand48_data *buffer )

X = (uint64) (xsubi[2] << 32) | (uint32) (xsubi[1] << 16) | xsubi[0];

VERSUS

X = (uint64) xsubi[2] << 32 | (uint32) xsubi[1] << 16 | xsubi[0];

and in function:

sint32 nrand48_r ( uint16 xsubi[3], struct drand48_data *buffer, sint32
*result )

*result = (xsubi[2] << 15) | (xsubi[1] >> 1);

VERSUS

*result = xsubi[2] << 15 | xsubi[1] >> 1;

BUTTTTTTTTTTTTTTTTTTTTTT

This is not unix source

This is not linux source

THIS IS GNUWIN32 SOURCE !

SO APPERENTLY OPEN SOURCE SUX UNLESS YOU COUNT ME WITH IT =D

SO APPERENTLY I HAVE FOUND A BUG

I WAS GOING TO SAY:
"SO APPERENTLY I HAVE FOUND A BUG IN GNUWIN32"

BUTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT

THE CODE WITHOUT THE BRACKETS PRODUCES THE SAME SHIT AS YOUR SHIT.

SO ALL THE ABOVE STATEMENTS ARE GARBAGE AND HAVE TO BE REPLACED POTENTIALLY
WITH THIS STATEMENT:

"UNIX, LINUX AND GNUWIN32 ALLLLLLLL SUCK"

IF IT TURNS OUT THAT I HAVE INDEEEEED FOUND A VERY VERY VERY STUPID BUG.

SO NOW THE QUESTION BECOMES:

"WHAT WAS THE CODERS ORGINAL INTENT ?"

OR IN OTHER WORDS:

"WHICH PRECENDENCE OF OPERATORS DID THE ORIGINAL CODER PREFER"

THE ORIGINAL CODER MIGHT HAVE BE WRONG ABOUT THE PRECENDENCE OF THE
OPERATORS !

THE ORIGINAL CODER COULD HAVE PREVENTED ANY DOUBTS AND POSSIBLE BUGS BY
USING (what I call brackets)

( ( ( ( ) ) ) )

BUUUUUUUUTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT

THE SAD PART IS...

THE ANSWER TO THIS QUESTION IS

*** IRRELEVANT ***

SINCE THE LDPC CODE WAS WRITTEN WITH THIS POSSIBLY BOGUS/BUGGY NRAND48 CODE.

SO THE ONLY VALUE THAT IS ADDED BY KNOWING THE ANSWER TO THE QUESTION IS:

IF THE NON BRACKET CODE IS CORRECT

THEN EVERYTHING IS JUST FINE AND SKYBUCK CAN CRAWL BACK INTO HIS
STINKING HOLE WHERE HE CAME FROM LOL.

IF THE NON BRACKET CODE IS INCORRECT THE WHOLE FRICKING UNIT, LINUX,
GNUWIN32 COMMUNITY AND ALL OTHER FRICKING STINKING FUCKINGS USES HAVE BEEN
SLEEEEEEEEPPPPPPPPINGGGGGGG FOR GOD KNOWS HOW FRICKING LONG.

************* !!! ******************

SO SUDDENLY THE ANSWER TO THE QUESTION BECOMES VERY ENTERTAINING !

SINCE *SOME* PEOPLE LIKE TO SAY: "OPEN SOURCE IS BETTER" nag nag nag.

CONTINUEING TO SAY BULLSHIT LIKE: "MORE EYES LOOK AT IT" slips slips slips
hahahahaha.

IF IT WASN'T FOR ME IN THE CASE THAT THIS CODE IS BUGGGGGGED THEN YOU PEOPLE
WOULD STTTTIlllll be sleeeping.

AND I AS SORRY AS I AM FOR IT... I AM NOT AN OPEN SOURCE DUDE... JUST SO
BILL G. CAN'T STEAL MY AWESOME EARTH FRICKING SHAKING CODE LOL.

ALSO THIS WOULD BE A GREEEEEEAAAATTTTTTTTT EXAMPLE OF HOW FLAWED THE CONCEPT
OF OPEN SOURCE IS LOL.

THE POINT ??????????????????????

THE POINT BEING !!!!!!!

IT'S NOT THE NUMBER OF EYES THAT LOOK AT IT....

IT'S NOT THE POSSIBILITY OF LOOKING AT THE SOURCE...

NO NO NO NO NO NO NO NO NO AND NOOOOOOOOOooooooooooooooooo

IT'S NOT ABOUT THAT !

IT'S ABOUT ****** => QUALITY <= ******

SO IT'S ABOUT THE *** QUALITY *** OF THE EYES THAT LOOK AT IT =DDD

LET'S BE HONEST

People talk about *** commercial quality *** <- that does mean something
doesn't it.


************** !!! *************

Now let's get to the chase...

Is the *non bracket* code flawed ?

BIG QUESTION !

Hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm

What makes it even more interesting... is that you stated that you
implemented your own idea/algorithm ????????

And yet you seems to produce the supposedbly bugged output ????!!!!???

WOW WACKY !

That could mean a couple of things:

1. You're fricking lieing your ass of... and just copy & paste the idea or
the code and just altered it a bit.

2. You made the exact same stupid mistake.

3. It's not a bug at all and it's supposed to work like that ?!?!?!

4. ALLLLLL DIFFERENT IMPLEMENTATIONS ARE FLAWED ?!?!?!?!

4. Would mean we have a WHOLE BUNCH OF FUCKING STUPID C programmers ?!

AND THE MUST STUPIDEST FUCKING SHIT OF ALL IS....

THAT THESE STUPID PEOPLE THAT MAKE THE LANGUAGES COULD HAVE SAFED ME FROM
TYPING ALL THIS STUPID TEXT BY JUST GETTING RID OF OPERATORS PRECEDENCE....
damn... which is kinda frustrating because first it looked like a good
idea... but it turned out the be a bad idea... at least occurding to me
There is no way anybody could have tough of that... or maybe that s not
true... Since I always liked using brackets... even in high school when
doing math ! so I guess these compiler/language makes are stupid after
all including all math people expect those that like working with brackets
like me

Welll even if the code is GOOD.... then I AM STILL FUCKED...

SINCE I BELIEVED THE BRACKETS WERE SUPPOSED TO BE LIKE THIS:

X = (uint64) (xsubi[2] << 32) | (uint32) (xsubi[1] << 16) | xsubi[0];

AND I AM NOT THE ONLY ONE !!!

SOMEBODY ELSE POSTED THE EXACT SAME LINE OF CODE:

X = (uint64) (xsubi[2] << 32) | (uint32) (xsubi[1] << 16) | xsubi[0];

HE ALSO THOUGHT THE BRACKETS SHOULD BE PLACED LIKE THAT !

I REST MY CASE !

IT'S INTUITIVE TO PLACE THE BRACKETS LIKE THAT ! YES

THAT IS HOW THE CODE LOOKS LIKE....

THAT IS WHAT I THINK THE ORIGINAL CODERS INTENT WAS !

LET'S GO BACK A BIT without the brackets and explore alternatives

X = (uint64) xsubi[2] << 32 | (uint32) xsubi[1] << 16 | xsubi[0];

Alternatives:

1. X = (uint64) xsubi[2] << (32 | (uint32) xsubi[1] ) << (16 | xsubi[0]);

Let's go back to the intuive one first:

X = (uint64) xsubi[2] << 32 | (uint32) xsubi[1] << 16 | xsubi[0];

this seems like the intent is to shift the bits to make a larger 48 bit
integer.

In other words:

Shift "the 16 bits located in xsubi[2]" 32 bits to the left.

Shift "the 16 bits located in xsubi[1]" 16 bits to the left.

"the 16 bits located in xsubi[0]" can stay were they are.

Add all these bits together... and voila !!! the result is a nice juicy 48
bit value !

THAT SOUNDS PRETTY FUCKING REASONABLE FOR A FUNCTION CALLED

NRAND48 !!!!!!! WITH DOCUMENTATION SPECIFIEING 48 BIT ARITHMETIC !

Ok.... LET S GET BACK TO REALITY !!!

THE REALITY IS THIS FUCKED UP CODE:

X = (uint64) xsubi[2] << 32 | (uint32) xsubi[1] << 16 | xsubi[0];

Now the big stinking question is:

What the **** is C's operator precendence.. since apperently the original
coder as well as all other fricking c coders apperently don;'t know.... OR
something really weird is going....

SINCE HOW THE **** IS IT POSSIBLE THAT ALL IMPLEMENATIONS GIVE THE EXACT
SAME BUT IN MY EYES WRONG RESULT ?!

SINCE MY BRACKETED CODE GIVES DIFFERENT RESULTS !

AND I THINK THE BRACKETED CODE MAKES MORE SENSE !

NOW I AM GOING TO STOP RIGHT HERE !!!!

SINCE I WILL LET YOU GUYS DO THE WORK FOR THIS LINE OF CODE:

X = (uint64) xsubi[2] << 32 | (uint32) xsubi[1] << 16 | xsubi[0];

SINCE I HAVE ABSOLUTELY NO IDEA HOW TO INTERPRET THIS.

I AM NOT A FUCKING ROBOT !

I DO NOT KNOW C'S OPERATOR PRECENDENCE !

AND I DON'T WANT TO KNOW !!!! EVER !!!!!

AND I AM SERIOUSLY BEGINNING TO WONDER WHICH PROGRAMMER DOES ???? expect
ofcourse the FUCKING compiler writers !!! THEY KNOW I'LL BET !

SO THIS HAS OTHER IMPLICATIONS AS WELL IF I AM RIGHT !

APPERENTLY MOST PROGRAMMERS ARE NOT AWARE OF C'S OPERATOR PRECENDENCE OR ANY
OTHER LANGUAGE OPERATOR PRECEDENCE !!!!!!

I WOULD CALL THAT A SERIOUS AND DANGERS PHENOMENON !

IT"S EVEN SO SERIOUS IT NEEDS PEOPLE TO START THINKING DIFFERENTLY ABOUT
LANGUAGES AND OPERATOR PRECENDENCE

MY ADVICE WOULD BE:: LOOSE IT !!!!!!! Use brackets instead <--- always
!!!!

Ok now I am going to stop writing.

Remember... All this text applies when I am right and the non bracketed code
is flawed... which would mean all other code producing the same results must
also be flawed !

Bye,
Skybuck.





























Bye,
Skybuck.

 

[Skybuck Flying]

Perhaps, but that has nothing to do with your problems.


A well written and easy to understand description of a family of
old functions that can be used to generate random numbers.

Don't blame this document if you have trouble making your program
work using an implementation provided by Microsoft.

Lol get real microsoft has nothing to do with it.

 

[Jens.Toerring]

<plonk>

 

[Eric Enright]

Skybuck Flying wrote:

I DO NOT KNOW C'S OPERATOR PRECENDENCE !

AND I DON'T WANT TO KNOW !!!! EVER !!!!!

AND I AM SERIOUSLY BEGINNING TO WONDER WHICH PROGRAMMER DOES ???? expect
ofcourse the FUCKING compiler writers !!! THEY KNOW I'LL BET !

SO THIS HAS OTHER IMPLICATIONS AS WELL IF I AM RIGHT !

APPERENTLY MOST PROGRAMMERS ARE NOT AWARE OF C'S OPERATOR PRECENDENCE OR ANY
OTHER LANGUAGE OPERATOR PRECEDENCE !!!!!!

You are not right. I'm only twenty-one (which I suspect is
about 2 << 3 | 1 years older than you) and understand operator
precedence off by heart just fine. I'm /quite/ far from writing
my own compiler

My secret? /listening/

You would do well to actually listen to and take the
advice/education the other people in this group have attempted
to give you.

 

[Richard Bos]

I dont need em I have a pepsi lol completely off topic.

Then get off the bloody saccharinated, caffeinated drinks. You sound
like a thirteen year old with ADHD.

Richard

 

[Skybuck Flying]

Well,

After writing that long post.. I already realized what was wrong.

The word typecast in itself gives clues to what is wrong.

A typecast is a way to make something another type

What we wanted to do is something intuitive:

sint32 a;
sint64 r;

This is what we wanted to do:

r = ( sint64 ) ( a << 16 );

This would mean:

Typecast everything between ( ) to 64 bits !

So it's like a typecast and operationcast thing

Just everything !

But that's not what happens.

Something counter-intuitive happens:

( As well in C as in Delphi )

First the 32 bit shift operation is done

a << 16

and then later the result is turned into 64 bit...

Which is ofcourse useless since that would happen anyway.

So to make it work in C or Delphi... the type has to be first cast...

That's ofcourse easily forgotton as time passess on.

r = ( sint64 ) ( a ) << 16;

This should work.

Now a is first converted to 64 bits and then the shift operation will be 64
bits.

I proofed that this works in Delphi.

However proofing it in C remains a challenge... my Visual C/C++ 6.0 Help
ain't working

Maybe I should go back to Visual C/C++ 5.0 but then again... I rarely use
it anyway

So it's not worth the extra space *** <- me almost out of space *** <-
me should get new pc anyway **

Here is the good DelPHI pogram and the broken C program.

#include <stdio.h>

/*

// Delphi 7 Program:

program Project1;

{$APPTYPE CONSOLE}

uses
SysUtils;

var
a : integer;

r1 : int64;
r2 : int64;
r3 : int64;

MaxR : int64;

begin

a := maxint;

r1 := a shl 16;
r2 := int64( a shl 16 );
r3 := int64( a ) shl 16;

writeln( 'r1: ', r1 );
writeln( 'r2: ', r2 );
writeln( 'r3: ', r3 );

MaxR := High(Int64);

writeln( 'MaxR: ', MaxR );

readln;

// output:
// r1: -65536
// r2: -65536
// r3: 140737488289792
// MaxR: 9223372036854775807

end.


*/


int main()
{

// doesn't ansi c support int8, int16, int32 etc ?
// is so what are the correct ansi c types ???!!!???!?!?!?!

// these types are microsoft/visual c/c++ 6.0 specific:
__int32 a;

__int64 r1;
__int64 r2;
__int64 r3;

//__int64 MaxR;

// a = maxint; // ?

// a = (__int32)(2*1024*1024*1024); // integral constant overlflow ?

a = 0x0FFFFF;

r1 = a << 16;
r2 = (__int64) ( a << 16 );
r3 = (__int64) ( a ) << 16;

printf( "r1: %d \n", r1 );
printf( "r2: %d \n", r2 );
printf( "r3: %d \n", r3 ); // ??????

// MaxR = High(__int64); // ?

// printf( "MaxR: %d", MaxR );


// readln; ?

// delphi 7 output:
// r1: -65536
// r2: -65536
// r3: 140737488289792
// MaxR: 9223372036854775807

return 0;
}

Bye,
Skybuck.

 

[Skybuck Flying]

Finally I have the same results with brackets.

I also understand for the time being (until I forget) how typecasting
works... (counter intuitive).

The following code with brackets gives the same results as without brackets:

// this should be the correct way to do things:
X = ( (uint64) (xsubi[2]) << 32 ) |
( (uint32) (xsubi[1]) << 16 ) |
( xsubi[0] );

// code without brackets:
// X = (uint64) xsubi[2] << 32 | (uint32) xsubi[1] << 16 | xsubi[0];


// windows xp visual c/c++ 6.0 results:

// finally good results with brackets at good location
// and stat48 initialized to zero:

// 0
// 2116118
// 89401895
// 379337186
// 782977366

Finally.

Thank you for taking part in this skybuck endavour heheheheh (and posting
your results )

Thanks to all othes for helping out

This newsgroup is not as bad and mean as I thought lol hahahahahahaha.

Finally I can say, I am DONE with nrand48() big sigh after a few days of
shitting around.

Who said OPEN SOURCE WAS CHEAP !

A few days fucking around is EXPENSIVE <- time is most valuable thing in
hopefully every human's life =D

Sigh... now the real challenge start of playing around with LDPC and
figuring it out

Bye,
Skybuck.

 

[Skybuck Flying]

<bonk> back in your face =D
| /|\
| |
\|/ |

<plonk>

Skybuck always bounces back Wieeeeeeeeeeeeeee

Be carefull to drop me =D KABOEM

 

[Richard Bos]

<bonk> back in your face =D
| /|\
| |
\|/ |


Skybuck always bounces back Wieeeeeeeeeeeeeee

Not from my moron-bucket, you don't. The way you react, you're simply
not worth the trouble of trying to help you.

*Plonk*, and you'll stay there.

Richard

 

[Skybuck Flying]

Not from my moron-bucket, you don't. The way you react, you're simply
not worth the trouble of trying to help you.

*Plonk*, and you'll stay there.

Lol, I am SkyBUCK I have a way with buckets hahahaha

 

[Keith Thompson]

Lol, I am SkyBUCK I have a way with buckets hahahaha

"Skybuck", perhaps you don't understand what "plonk" means. Richard
was publicly announcing that he's put you into his killfile. This
instructs his newsreader to ignore any article with your name on it.
As far as he's concerned, you no longer exist. He's not the first
person to do so, and I'm sure he won't be the last. It's not
something you have any control over.

I don't expect the following to do any good, but I'm going to give it
one last try.

"Skybuck", you're just annoying people. You've barged into a
newsgroup where we're trying to have intelligent technical
discussions, and you're behaving like a childish jerk. You insulted
people while you ask them for help. It's not funny, it's not cute,
it's not charming, it's just obnoxious.

You still have a chance to become an accepted member of this
community, if that's what you want. Stop swearing, stop shouting
(all-caps and multiple exclamation points are the written equivalent
of shouting), and calm down. (Such things might be acceptable in
moderation, but I doubt that you can manage that.)

If you're not willing to do that, please just go away. If you're
trying to get attention, you'll succeed briefly, but after a while
we'll simply ignore you.

Welcome, or good-bye.