PureBasic Forums - English

A long time ago I started to use PB pseudorandom generation for various things.
Today I started to afraid, that it will change one day, and my numbers also changes with it.

Is it possible to know how PB random works, so with that I might be able to replicate it with code... To get the same numbers I get today.
(also I would need a getcurrentseed comand, so this knowledge would be convenient)

Sorry, this might not be very interesting to most of you, just to me.

Hi miso
I think for PB current seed Maybe mk-soft or StarGate has an answer
Better to ask Fred

Seems to me you would like to know how "default" RandomSeed works
It's not very clear… Hungarian must be an interesting language
Anyway, just in case:

RASHAD wrote: Tue May 13, 2025 2:49 pm

Code: Select all

	RandomSeed(timeGetTime_())

Is that windows?

Yes, I was not clear enough. (also mistyped a part of the first post) Sorry. I already use the pseudorandom numbers for content generation with selected seeds.
I want to keep those contents, thats why I'm interested in how PB generates their number.

These days I'm able to write a random generator, but it will generate a different content, as it will work in a different way than the PB internal.
(I was silly to not consider that.)

Piero wrote: Tue May 13, 2025 2:56 pm

RASHAD wrote: Tue May 13, 2025 2:49 pm

Code: Select all

	RandomSeed(timeGetTime_())

Is that windows?

calm down

I will post the code if you like.

Kiffi wrote: Tue May 13, 2025 3:01 pmcalm down

Fred wrote: Tue May 13, 2025 3:30 pm I will post the code if you like.

That would be awesome!

miso wrote: Tue May 13, 2025 2:30 pmToday I started to afraid, that it will change one day, and my numbers also changes with it.

You can rest easy with this. The Random() and RandomSeed() commands have not changed their behavior since the very early years of PureBasic, even through an entire rewrite of the code and the switch/expansion to support 64bit values.

We are aware that changing them would break existing PB programs so we will avoid that. I see no reason why we would change it in the future. If we want a new algorithm, we can add it as a new command or through a new flag so the existing behavior can remain unchanged.

miso wrote: Tue May 13, 2025 2:30 pmIs it possible to know how PB random works, so with that I might be able to replicate it with code... To get the same numbers I get today.
(also I would need a getcurrentseed comand, so this knowledge would be convenient)

It is not to most easy to understand code. You'd have to read the paper with the theory behind it to really follow it, I think. The original was an ASM code which we could no longer use due to licensing issues so I wrote it from scratch in C based on the paper that the original author wrote. I then tweaked the code to match the output of the original implementation exactly.

The good thing is that Random with RandomSeek creates the same numbers on all three OS.
I also use this to test the validity of my network functions for data exchange

Thank you Freak!

I'm glad to hear this.
I'm already aware a lot of random generation algorithms, but ASM code would not help me at all, as I'm noob in it.

As a second thought, I can always create a dll/so/dylib with an older PB release, if something happens
in the future. (and I will know that instantly)

Thank you for the information!
I feel relieved

mk-soft wrote: Tue May 13, 2025 6:08 pm The good thing is that Random with RandomSeek creates the same numbers on all three OS.
I also use this to test the validity of my network functions for data exchange

Important info, thanks. I assumed it, but could not test in all three OS.

By finding the right generator/seed, you can compress (a big video?) 10000000%

I don't have to save a lot of data (of a game, maps, npc names, stats, starnames in a big galaxy, sounds, 3d meshes, etc), if I can save only a seed that generates it.
As mk-soft wrote, you can validate network requests. You can ruin files, if you want, and get them back with the valid seed 1 byte after an other, while
never having a full key in your memory/executable file. The usecases are countless.