<Je***********@physik.fu-berlin.de> wrote in message
news:2l************@uni-berlin.de...
Skybuck Flying <no****@hotmail.com> wrote: 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.
<more stupid rant snipped>
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"
BUTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT TTTTTTT
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)
( ( ( ( ) ) ) )
BUUUUUUUUTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT TTTT
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 :P
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 ! :P so I guess these compiler/language makes are stupid after
all including all math people expect those that like working with brackets
like me ;) :D
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 fuck 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 FUCK 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.