Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Control Flow

2 (2.2%)

Arrays, Strings, Pointers, and References

8 (9%)

Functions

4 (4.5%)

Basic object-oriented programming

30 (33.7%)

A bit more advanced OOP (Composition, Operator overloading, Inheritance, Virtual Functions)

18 (20.2%)

Templates

8 (9%)

Other (Explain)

4 (4.5%)

Working with files?  (Streams)

15 (16.9%)

Total Members Voted: 89

[Supermikhail]

Double post for no reason:

Anyone know of a reasonably good but mostly fast pseudorandom algorithm that "reseeds" instantly?
I'm not looking for Seed->get->get->get, but for a Seed->get, Seed->get, Seed->get kind of thing.

My current one yields... boring results. The textures are fine but my landscape is just sleep-inducing.

Don't you think that a pseudorandom algorithm isn't what you want? Pseudorandom kind of implies generating a string of numbers, which is where time is going to be wasted in your case.
I know that Delphi has a nice thing like "initialization randomize" which is going to make your random take numbers out of the system clock, but I don't... think I've met that elsewhere. Although, that might be where Pseudorandom Generators take their seeds, I don't know anything about them.

[Siquo]

No, I want seeded pseudorandom.

If you start the application, it creates a texture from a seed.
The next time you start it, I want that exact texture again.

[Virex]

If you've got a good pseudorandom algorithm then seed->get->get->get should be exactly as random as seed->get->seed->get->seed->get, save for the situation in which you want the first seed to be the same and the rest to differ (in which seed->get->seed->get->get ought to work). Are you sure you're not just looking for a pseudorandom function with a different kind of distribution? For that matter, what are you trying to do anyway that you'll need to reseed things over and over again?

[Siquo]

If you've got a good pseudorandom algorithm then seed->get->get->get should be exactly as random as seed->get->seed->get->seed->get, save for the situation in which you want the first seed to be the same and the rest to differ (in which seed->get->seed->get->get ought to work). Are you sure you're not just looking for a pseudorandom function with a different kind of distribution? For that matter, what are you trying to do anyway that you'll need to reseed things over and over again?

It's not just about results, it's about speed, too.
I'm using a lot of x,y coordinates as seeds (using a x*512+y+seed, for instance). I'm thinking I should just pick a seed, then map an x-by-y array, and use that until I'm done with it. Pre-calculate the random numbers, and then start transformations... That should speed up trix.

[Shades]

I'm thinking I should just pick a seed, then map an x-by-y array, and use that until I'm done with it.

This. It's almost never worth reseeding unless you have a specific reason to do so as it doesn't actually gain you anything and just burns cycles. Syncing with another system is one of the few times you might need to, why are you reseeding?

[Supermikhail]

Err. About Java drawing again (in hope for helpful hints). I've figured out it might be a good idea to import these things:

Code: [Select]

import java.awt.Color;
import java.awt.Dimension;
import java.awt.Graphics;
import java.awt.Graphics2D;
import java.awt.Point;
import java.awt.event.MouseEvent;
import java.awt.event.MouseMotionListener;
import java.awt.image.BufferedImage;
and either JComponent or Canvas. Both of which should be extended to incude BufferedImage and taught to render it via a Graphics2D object (but I haven't been able to determine how it knows where to draw and how to output the drawing to the screen). Then I need to have a TopComponent extended to have a canvas, and I will probably want to have a timer, but how the program know to render them to the screen, has escaped me so far.

[Siquo]

This. It's almost never worth reseeding unless you have a specific reason to do so as it doesn't actually gain you anything and just burns cycles. Syncing with another system is one of the few times you might need to, why are you reseeding?

Suppose I have a material. Its colour, weight, texture, hardness, shinyness all of those things are determined randomly, from a "seed" that's in that material. Now I do this for an x number of materials, etc, and don't store the results. Maybe I should.

Also I've been using some highly inefficient perlin noise copy-pasta that seeds all the effing time, about 32 times seeding per pixel, for a 512x512 texture. That has to be rewritten anyway.

[Supermikhail]

Suppose I have a material. Its colour, weight, texture, hardness, shinyness all of those things are determined randomly, from a "seed" that's in that material. Now I do this for an x number of materials, etc, and don't store the results. Maybe I should.

Oooh. I don't know if that's appropriate here, but please pretty please tell more about your project!

[Virex]

This. It's almost never worth reseeding unless you have a specific reason to do so as it doesn't actually gain you anything and just burns cycles. Syncing with another system is one of the few times you might need to, why are you reseeding?

Suppose I have a material. Its colour, weight, texture, hardness, shinyness all of those things are determined randomly, from a "seed" that's in that material. Now I do this for an x number of materials, etc, and don't store the results. Maybe I should.

Also I've been using some highly inefficient perlin noise copy-pasta that seeds all the effing time, about 32 times seeding per pixel, for a 512x512 texture. That has to be rewritten anyway.

That only matters if you're going to create the materials in a non-constant order, because if the order is constant, then you could just run trough the string of values created by the random number generator and use each of them sequentially. Another option would be to take a hash function with 2 inputs and feed it an identifier for the material and a random number generated beforehand which acts like a seed (of course hash functions come pretty close to psuedorandom functions, so that may not count).


Edit: A linear congruential generator is probably the cheapest random number generator one can implement, so if you're anal for performance and not to picky about the randomness of your numbers, look into that.
Edit2: Multiply with carry looks promising as well.

[Siquo]

The order is random: I'm doing everything "on the fly". Or trying, at least. Therefore anal on performance, yes.
I'll look into those, thanks. I'll have to optimise the way I use them first, but then I can try out a few and see what results they give.

[Virex]

Have you tried profiling your application yet? It may be that you're optimizing in the wrong place, since generating random numbers isn't that expensive.

[Siquo]

I'm doing something even worse: optimising before it's done.

It runs like a charm now (just the texturegenerating is slow, but I also know why), so I'm not really begging for cpu cycles. So far. It's ambitious.

[lordnincompoop]

How do I make a function call another function then close itself?

I was thinking of chaining rooms together this way:

Code: [Select]

void room3();

void room2();

void room1();

void main()
{
room1()
}

void room1()
{
char x;
cin >> x;
if (x == "n")
room2();
else if (x == "s")
room3();
}

void room2()
{
char x;
cin >> x;
if (x == "n")
room3();
else if (x == "s")
room1();
}

void room3()
{
char x;
cin >> x;
if (x == "n")
room1();
else if (x == "s")
room2();
}

But this would make the program allocate more and more memory for each move, eventually causing it to take up incredible amounts of space. What should I do?

[Virex]

Look up if your compiler does Tail recursion. If it does, you're fine (gcc does it IIRC); you won't run out of stack space this way. Else, you're probably screwed. anyway, best way is to test it: Run a non-tail recursive function until it breaks (by taking a tail recursive function and adding something to the end of it, past the last call), then run a tail recursive function for some time more then it took the normal function to break (make sure to build in a termination clause or else your computer will hang)


Oh and remember to set your compiler to optimize for speed (some may not do tail recursion in the most conservative cases). Debug version should not make a difference (or maybe it does for imperative languages?), but if you get a stack overflow when you really shouldn't, consider compiling to distribution version and see if that hangs too, just to be sure.

[lordnincompoop]

If I'm getting it right, this

Code: [Select]

unsigned int f( unsigned int a ) {
   if ( a == 0 ) {
      return a;
   }
   return f( a - 1 );   // tail recursion
}

Is tail recursion. Would this work even if the return statement calls another function (say, int g())?

And if I chain, say a hundred of these (non-recursively) would that cause any trouble?