array to generate words
IanH
cant figure out what im doing wrong, can anyone help?
import javax.swing.*;
public class random
{
public static void main (String args[])
{
String text[];
text = new String[5];
string increment;
int number = 0;
text[number++] = "Monday";
text[number++] = "Tuesday";
text[number++] = "Wednesday";
text[number++] = "Thursday";
text[number++] = "Friday";
increment = Math.floor(Math.random() * number);
JOptionPane.showMessageDialog(null, increment);
}
}
Oliver Wong
"IanH" <hill_...@yahoo.co.uk> wrote in message
news:1141323325.6...@v46g2000cwv.googlegroups.com...
Did you try actually running your program? What output does it produce?
Is this the desired output? If not, where would the source of the erroneous
output be coming from? For example, fi the program is printing out "Canada",
"America", "Germany", etc. instead of days of the week, I'd be looking at
the parts of my code which contain names of countries, and ask myself how
did that get into the data flow leading to the message dialog.
What is it outputting, and where might that data becoming from?
- Oliver
IanH
I know its not outputting correctly, the output is numbers instead of
the days of the week. Is this to do with number++, not sure new to java
so appreciate suggestions.
Oliver Wong
Well, you can try an experiment. Remove all the number++, replacing them
with something else (perhaps 0 or something), and see if that affects the
output.
Another technique would be to pretend to be the computer, and read the
source code and try to decide what you would do at each step if you were the
computer, to try to spot the problem.
- Oliver
James Westby
JOptionPane.showMessageDialog(null, text[increment]);
James
Rhino
Strings and want to choose one of them at random and display that String. If
that is right, the following untested code should do the job:
/* Create random number generator. */
Random random = new Random();
/* Choose an integer between 0 and the size of the array; effectively
chooses the index of one element of the array. */
int randomIndex = Math.abs(random.nextInt()%text.length);
/* Display the randomly-chosen day. */
JOptionPane.showMessageDialog(null, "The random day is " + text[randomInt]);
--
Rhino
IanH
Rhino
"Rhino" <no.offline.c...@nospam.com> wrote in message
news:71HNf.4706$972.2...@news20.bellglobal.com...
JOptionPane.showMessageDialog(null, "The random day is " +
text[randomIndex]);
--
Rhino
IanH
I have a problem with the Random random = new random, am i supposed to
have a class created for this?
Daniel Dyer
<no.offline.c...@nospam.com> wrote:
> If I understand you correctly, you are populating the 'text' array with
> five
> Strings and want to choose one of them at random and display that
> String. If
> that is right, the following untested code should do the job:
>
> /* Create random number generator. */
> Random random = new Random();
> /* Choose an integer between 0 and the size of the array; effectively
> chooses the index of one element of the array. */
> int randomIndex = Math.abs(random.nextInt()%text.length);
> /* Display the randomly-chosen day. */
> JOptionPane.showMessageDialog(null, "The random day is "
> + text[randomInt]);
The randomIndex would be better to use the nextInt method that takes a
parameter:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/Random.html#nextInt(int)
The main reason in this case is because it's simpler, but you should also
be aware that performing modulo arithmetic on random numbers introduces
bias.
Dan.
--
Daniel Dyer
http://www.dandyer.co.uk
Rhino
> Thanks Rhino
>
> I have a problem with the Random random = new random, am i supposed to
> have a class created for this?
>
your class. The full name of the class is java.util.Random.
--
Rhino
Rhino
"Daniel Dyer" <d...@dannospamformepleasedyer.co.uk> wrote in message
news:op.s5swa...@dougal.craggy...
--
Rhino
IanH
Roedy Green
<no.offline.c...@nospam.com> wrote, quoted or indirectly
quoted someone who said :
> Math.abs(random.nextInt()%text.length);
Don't do that. There are much better ways. See
http://mindprod.com/jgloss/pseudorandom.html#STRINGS
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
Roedy Green
quoted or indirectly quoted someone who said :
>I have a problem with the Random random = new random, am i supposed to
>have a class created for this?
see sample code at
http://mindprod.com/jgloss/pseudorandom.html#STRINGS
The example that generates a random fruit could be modified trivially
to create a day of the week just by substituting the fruit names with
names of days of the week.
Daniel Dyer
<my_email_is_post...@munged.invalid> wrote:
> On Thu, 2 Mar 2006 13:43:16 -0500, "Rhino"
> <no.offline.c...@nospam.com> wrote, quoted or indirectly
> quoted someone who said :
>
>> Math.abs(random.nextInt()%text.length);
>
> Don't do that. There are much better ways. See
> http://mindprod.com/jgloss/pseudorandom.html#STRINGS
Roedy, that's a very thorough page. There's one piece of information that
might be useful to add, though not at all relevant to the original
discussion in this thread is a note about performance.
I have found that the SecureRandom class is considerably slower under
Linux than it is on Windows (my benchmarks take about 8 times as long to
complete on the same hardware), and even on Windows it's significantly
slower than any other Java RNG implementation. This makes it unusable for
any simulations that require a large quantity of statistically sound
random numbers. With java.util.Random failing to produce statistically
random output, any non-trivial use of random numbers in Java needs to use
a non-core RNG implementation.
Roedy Green
<d...@dannospamformepleasedyer.co.uk> wrote, quoted or indirectly
quoted someone who said :
>I have found that the SecureRandom class is considerably slower under
>Linux than it is on Windows
noted.
Filip Larsen
> I have found that the SecureRandom class is considerably slower under
> Linux than it is on Windows (my benchmarks take about 8 times as long
to
> complete on the same hardware), and even on Windows it's significantly
> slower than any other Java RNG implementation.
If I remember correctly, the SecureRandom potentially uses a lot of time
during initialization to "collect entropi". Can you possibly state
whether or not generator initialization is included in the factor 8 you
mention above?
Chris Uppal
> With java.util.Random failing to produce statistically
> random output, any non-trivial use of random numbers in Java needs to use
> a non-core RNG implementation.
Searching for:
"mersenne twister" java
produces lots of promising-looking hits. (Not limited to implementations of
that particular PRNG)
-- chris
Daniel Dyer
I have produced my own direct Java port of the original C and the
peformance is quite impressive even though I have made no attempt to
optimise it. The throughput is better than java.util.Random and the
output is much more random according to the Diehard tests.
Daniel Dyer
wrote:
That's a good point and something I should have considered. My benchmark
does not include the time taken to instantiate the SecureRandom object,
but I guess it's possible that the entropy gathering is deferred until the
first request is made (I haven't looked at the SecureRandom source). I'll
try it again later but make a few requests before I start timing and see
what the difference is. The benchmark generates 1 million random ints, 1
million random doubles and 1 million Gaussians. For SecureRandom it takes
less than 4 seconds under Windows and about 30 seconds under Linux on my
laptop. If the SecureRandom is getting its entropy from /dev/random it
shouldn't take 26 seconds. My guess, and that's all it is, is that it
something to do with the SHA-1 implementation in the Linux version of
JCE. I have written an RNG that uses the AES block cipher and seeds
itself from /dev/random and it completes the benchmark in under 2 seconds
under Linux.
Chris Uppal
[me:]
> > Searching for:
> > "mersenne twister" java
> > produces lots of promising-looking hits. (Not limited to
> > implementations of that particular PRNG)
> I have produced my own direct Java port of the original C
Blimey, that was quick ;-)
> and the
> peformance is quite impressive even though I have made no attempt to
> optimise it. The throughput is better than java.util.Random and the
> output is much more random according to the Diehard tests.
How does using something like RC4 compare for speed/quality ?
-- chris
Daniel Dyer
<chris...@metagnostic.REMOVE-THIS.org> wrote:
> Daniel Dyer wrote:
>
> [me:]
>> > Searching for:
>> > "mersenne twister" java
>> > produces lots of promising-looking hits. (Not limited to
>> > implementations of that particular PRNG)
>
>> I have produced my own direct Java port of the original C
>
> Blimey, that was quick ;-)
I meant previously :)
The C code, and therefore my Java port also, is a whole bunch of magic
numbers and bit manipulations. I've no idea how it actually works.
>
>> and the
>> peformance is quite impressive even though I have made no attempt to
>> optimise it. The throughput is better than java.util.Random and the
>> output is much more random according to the Diehard tests.
>
> How does using something like RC4 compare for speed/quality ?
I've used AES. The quality is the same according to Diehard, but the
Mersenne Twister is about 3 times faster. The AES implementation is still
twice as fast as SecureRandom though. I read somewhere that a non-linear
generator like AES is preferable to a linear generator like the Mersenne
Twister for certain types of simulation, though I don't know the details.
Filip Larsen
> My benchmark
> does not include the time taken to instantiate the SecureRandom
object,
> but I guess it's possible that the entropy gathering is deferred until
the
> first request is made (I haven't looked at the SecureRandom source).
I'll
> try it again later but make a few requests before I start timing and
see
> what the difference is. The benchmark generates 1 million random
ints, 1
> million random doubles and 1 million Gaussians. For SecureRandom it
takes
> less than 4 seconds under Windows and about 30 seconds under Linux on
my
> laptop.
Doing that test with Java 1.4.2, I get the relative speed of Random to
the SecureRandom (Sun provider) at around 3 to 8 depending on OS and
whether -server or -client is used. Best was server on Windows where
SecureRandom ran the test only 3 times as slow as Random (3062 ms vs.
1047 ms). Worst was client on Windows with a factor 8 (5078 ms vs. 625
ms). In the Linux test the ratios were between 6.5 (server) to 8
(client). The Linux hardware was different but the test ran in times
comparable to the Windows test. Instantiation and warm-up of Sun's
SecureRandom took around 200-800 ms in all cases.
So my guess would be that the 30 seconds you see on Linux must be an
issue not related to the actual generation of numbers. Perhaps the
generator is not seeding from /dev/random or perhaps its a different
provider with a non-performing implementation?
Regards,
--
Filip Larsen
briti...@gmail.com
algorithm or provider to use. When I re-run the tests specifying to
use the "SHA1PRNG" algorithm with the Sun provider, I get the same
results as you on both Windows and Linux, using Java 1.5.0_06.
I checked what implementation was being used on Linux by default and it
is still the Sun provider but it uses an algorithm called "NativePRNG",
which appears to be much slower than the non-native default. So my
previous advice about performance on Linux should be qualified with
this information.
SecureRandom is still slow, even on Windows, it's just not necessarily
as slow as I stated.
Daniel Dyer
Just to avoid any confusion, this post is from me. I went looking for the
thread on Google Groups and posted the reply on there. I thought it would
be clever enough to use the name I gave it in the "From" field.
Oliver Wong
"Chris Uppal" <chris...@metagnostic.REMOVE-THIS.org> wrote in message
news:44097849$1$1176$bed6...@news.gradwell.net...
Note thought that while Mersenne Twister produces a nice sequence of
random numbers for simulations, it is not cryptographically secure; that is,
an attacker can easily[*] recognize an MT-generated sequence, and predict
the next elements.
Use MT for games and simulations, but not for encryption, passwords,
etc.
- Oliver
[*] Where "easily" means "relative to random number generators which ARE
considered cryptographically secure".
Chris Uppal
> Note thought that while Mersenne Twister produces a nice sequence of
> random numbers for simulations, it is not cryptographically secure; that
> is, an attacker can easily[*] recognize an MT-generated sequence, and
> predict the next elements.
That why I (idly) asked Daniel if he'd tested the performance of RC4 used as a
PRNG. It should be pretty fast, but I haven't got around to measuring it
myself. OTOH, I don't know how well RC4 approximates to "random" -- it could
be very non-random but still secure (e.g. if it doubled-up every output byte
;-)
-- chris
Daniel Dyer
wrote:
>
> "Chris Uppal" <chris...@metagnostic.REMOVE-THIS.org> wrote in message
> news:44097849$1$1176$bed6...@news.gradwell.net...
>> Daniel Dyer wrote:
>>
>>> With java.util.Random failing to produce statistically
>>> random output, any non-trivial use of random numbers in Java needs to
>>> use
>>> a non-core RNG implementation.
>>
>> Searching for:
>> "mersenne twister" java
>> produces lots of promising-looking hits. (Not limited to
>> implementations of
>> that particular PRNG)
>
> Note thought that while Mersenne Twister produces a nice sequence of
> random numbers for simulations, it is not cryptographically secure; that
> is, an attacker can easily[*] recognize an MT-generated sequence, and
> predict the next elements.
>
> Use MT for games and simulations, but not for encryption, passwords,
> etc.
>
Indeed. Away from work one of my interests is evolutionary algorithms.
The Mersenne Twister is excellent for these because of its statistical
qualities and blinding speed. At work I'm mostly involved in the online
gambling industry. We don't use algorithms like the Mersenne Twister for
these for precisely the reason you mention. Although it's very unlikely,
if an attacker could observe all of the random output of the RNG for a
long enough sequence, they could relatively easily reverse engineer the
seed and predict all future output of the RNG, thus losing our clients
lots of money.