Random Seed behaviour across OS inconsistent?
BlitzPlus Forums/BlitzPlus Programming/Random Seed behaviour across OS inconsistent?
| ||
| Ran across an odd little observation today and I'm trying to work out whether it's my code that's messed or something else entirely. Basically, I'm trying to share information between a client and a server. I'm attempting to recreate a series of random numbers between said client and server. I'm using BlitzPlus to do this. When I do this between said client and server, both using WinXP, the series is recreated successfully -- this even works properly across separate physical computers. When I do this between client and server on WinME, it works fine as well. However, when I attempt to get a client on XP and a server on ME talking -- or vice versa -- the random sequence using the same seed is buggered up and won't replicate properly. Is this expected behavior? If so, is there any way around this? Again, this is using precisely the same version of Blitz+, just on different OS's. |
| ||
| Don't think it has anything to do with your code, not only different OS, different PC's may very well give different results. Maybe a way round that, would be that only one of the PC's generates the data and sends it to the other one(s). |
| ||
| One PC generating the sequence and transmitting it defeats the purpose entirely, unfortunately. If this is expected behaviour I'll have to gen my own, consistent randomization procedure based on seeds. Ugly, but if that's expected behaviour I've no other choice. :/ |
| ||
| Why the hell would random output be different on one computer, and then different on the next -- that's not possible with how a random generator works, the answer should be the same on every computer. This is deffinatly a Blitz issue. |
| ||
| Why the hell would random output be different on one computer, and then different on the next I'm taking a stab in the dark here, knowing nothing about which I speak (what else is new?) but I'm gonna go with - slightly different degrees of accuracy in floating point maths? Or am I an idiot? |
| ||
| In the reading I've been doing on the subject (in order to prepare myself in case I need to write one) a consistent random seeding procedure is necessary and commonly written for the same reasons I'm using it -- namely for cryptography and security. The fact that I'm getting unusual results is very strange indeed if that's the case, as these algorithms seem to be written specifically with an eye towards consistency and portability. |
| ||
| Morduun, I'm assuming you have a C compiler lurking around somewhere? If you do then you already have the source for a random number generator. Just find the code for rseed() and rand() and translate it into Blitz. That's what I would do. After all, the standard libraries are yours to do what you like with. |
| ||
| MG -- Yes, I can do that without difficulty; it just seems a shame to have to do it longhand when one would logically assume that Blitz's internals would otherwise handle this with aplomb. Some sort of verification that this is either (A) expected behavior and therefore I should trudge ahead with porting the code, or (B) no, this is a bug and will be fixed in a patch, would be nice -- not just for me, but for anyone else who's expecting Blitz's random number generation systems to be consistent. |
| ||
| Hi, Random sequences should be identical between 2 machines. Have you tried just printing a sequence of 10 numbers on both OS's and comparing results? Can you dump them here? If you're trying to do what I think you are (ie: produce identical game results based on identical random numbers and user input - ie: 'demo playback') its pretty hard, but good luck! |
| ||
| I'd hoped you'd say that, though it looks like that might mean there's a sneaky little sucker in there somewhere. ;) 10-number sequences from XP and ME follow, and speak for themselves; they're very similar but not identical. Code: SeedRnd 723122303
myFile = WriteFile("XPrand.txt")
For i = 1 To 10
x = Rand(0, 2147483647)
WriteLine myFile, x
Next
CloseFile myfile
EndP3/1G XP results: 402475453 1049528643 1376088714 1815118417 715725680 1589966466 548088846 1070404359 1019481149 407582393 P3/700 ME results: 402475456 1049528640 1376088704 1815118464 715725696 1589966464 548088832 1070404352 1019481152 407582400 VERY similar -- but not the same. |
| ||
| nice bug hunting dude! Mark, see the following for possible cause: http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/ddraw7/directdraw7/imover_7410.asp |
| ||
| Thanks Simon, though I'm the idiot that didn't think to just do a straight run of 10 random numbers to see the difference for myself until Mark asked for it. ;) Just nice to know that I'm not going =totally= insane. Or, er, at least not any more so than usual. |
| ||
| Don't tell me my theory was actually RIGHT?!? I think I need to go have a lie down... |
| ||
| *sigh* Apparently this fix didn't make it into the 1.34 update, so there's one more project frozen in place. :/ Mark, any idea when this'll be addressed? |
| ||
| Hi, We're looking into this one, but its a fairly complex issue... |
| ||
| I *think* this has something to do with float and/or real numbers, which differ on different machines because of float approximation. The workaround would be: use small random numbers ! If you see in the above list of numbers, the first 6 digit are all syncronized between the two lists, while the rest differ. This can have something to do with approximation, IMO. My Asteroids remake is also a demo playback (there are 3 different demos saved in .txt plan files), and works fine on all the pc I have tested so far. It uses indeed random numbers which are generated using the same seed, but the numbers I use for the seed are small, I mean, not with 9 digits !! So, my advice is: use small seeds ! ;) Sergio. |
| ||
| Not an option when you're using the random number generator for a cryptographic application, semar, but thanks for the thought. ;) I'd roll my own but one needs doubles to do it properly -- so for now I'm pretty much stuck. |
| ||
| I had always thought the algorithms for pseudo random number generation all use integers and never floats precisely to avoid such problems. If the built in blitz one uses floats then it's completly flawed from the very beginning (I would be very surprised if it was, a word of Mark about this wouls be interesting). The (few) algorithms I've seen use plain integers, and I guess generators for float numbers should be derived from these ones rather than using floats for their computations. |
| ||
| I just found a pieace of article showing what I thought: The real (float) version of a random generator (returns a float in the [0,1) or [0,1] range) is here: Rn = In/ float(m) for [0,1) Rn = In/ float(m-1) for [0,1] where m is the modulo for the method and In the integer random number. The division is the only floating point operation in all the process, so using this, for float random numbers the precision errors are really not a big issue, anf for integers it's not at all because then there's only integer operations. So the wierdest thing is morduun showed little differences with INTEGER random numbers. Mark, any comments? |
| ||
| Come on, morduun, you can't seriously say that Blitz not being able to have a (non)random number generator freezes your project! Just code your own for the time-being! Create your own functions for Rnd(), Rand() and SeedRnd() and use DATA statements to get the numbers you want. Then, when Blitz+ is updated to reflect the whole "random number" issue, you can just comment out your functions and voila! |
| ||
| Seth, I'm not interested in a workaround, thanks. Mark's agreed it's broken and is looking into it. I have no interest in wasting time writing redundant functions that will end up being unused. |
| ||
| What, you never use placeholders? |
| ||
| could you use a formula instead that gives close to random results like one that goes into chaos! |
| ||
| What, Seth, you never evaluate functionality to determine whether it will properly fulfill your needs or not? You simply press ahead and assume that the direction you've chosen to take will work regardless of whether functionality will support the application fully no matter how deeply integrated into said application the questionable functionality is? Perhaps you enjoy wasting your time doing such things. I do not. If this functionality cannot be supported I will have to rethink a significant portion of the application's underpinnings and I have no desire to press ahead simply assuming that it will be fixed. It's a complex problem. Mark understands it's important to me. I understand he's doing his best. 'Nuff said. |
| ||
| Well er heh as long as one enjoys wasting their time, then it's time well-spent! ;) Besides, I didn't say that I would press on using the flawed functionality, but rather than halting the entire production line for the sake of a loose pin I'd probably jam something in there to keep it going till I find that darn pin again.. Sounds questionable I agree, particularly with the given analogy, but I just didn't want you to have to halt your app simply for the sake of a random seed generator, and was providing alternatives to fill in until said seed generator becomes available. |
| ||
| Appreciate the sentiment Seth, and there =are= certain things that can (and are) move(ing) ahead a little, but cryptography is an intrinsic part of the app and I don't want to move ahead too much without making a firm decision on an approach I can go forward with. Recoding is my second-least favorite thing to do in programming (bughunting being my first-least favorite), and I'd rather set something aside for a while than spend time on bits that will just end up in the circular file. |
   |