Random Number Generator on CNC Machine Controller
Cedric Silvester
machine controller (a GE Fanuc 15i, if anyone cares). I have at my
disposal a time of day clock, in milliseconds since midnight, and a
full complement of math functions (trig, bit-wise operators, basic
arithmetic, exponentiation, etc.). I'm hoping I can seed an algorithm
with the TOD clock and get back a random number from 0 to 1.
The reason? I like to 'burn-in' a machine by letting it run for many
hours (typically 48), moving all axes slides randomly through their
full range, plus randomly turn on the spindle, pumps, valves, etc.
But it seems CNC manufacturers don't think an RND() function is
useful...
Thanks in advance!
-------------------------------------------------------------------
Cedric Silvester
Remove NOSPAM from email address for correct address
-------------------------------------------------------------------
cda...@libero.it
it's not easyer for u to write down a program that outputs a CNC code
with G00, G02, G03 with random values ? (except for the G02,G03 codes
that need some circular interpolations)
And then tell to the Fanuc CNC to start all the code again.
Isn't the Fanuc able to understand the GOTO commands ?
For example (in pseudocode):
for (i==0;i<200;i++)
{
print_a_10_label();
print_non random_G00_G02_G03_command_to_a_file(); //taken maybe
from a table, maybe indexed using time
print_another_non_random_G00_G02_G03_command();
.....
.....
print_a_goto10_code();
}
It's not exactly state of the art method, but it should work...
bye
[rIO]
--
Posted from 195.120.117.194 by way of smtp5.libero.it [193.70.192.55]
via Mailgate.ORG Server - http://www.Mailgate.ORG
GianLuigi Piacentini
could try algorithm ran0 from the Numerical Recipes.
I'm quoting the algorithm name from the book, but I have head that code
may be downloaded from their site.
Alternatively (and less random, but I think it should be fine for your
purpose):
jran= mod(jran*ia+ic,im)
ran= float(jran)/float(im) ! for a number between 0 and 1, and
j= jlo+((jhi-jlo+1)*jran)/im ! for an integer between jlo and jhi
Several values for im, ia, ic will produce a good randomic sequence,
you can try the following values
im= 81000 ia= 421 ic= 17117, or
im= 714025 ia= 4096 ic= 150889
The above was taken from Numerical Recipes, too.
Hoping this helps.
Gigi
r=
Cedric Silvester
exactly what I was looking for. I just finished downloading the
chapter on random code, so I think I'll have something working soon.
Best Regards!
-------------------------------------------------------------------
Ben Blish
One really efficient and reasonably useful rdm generator is to take a 16 bit
unsigned number, initialize it to 625 (or any odd number, really), then
multiply by five. Take only the upper byte of the 16 bits as your random
number; works amazingly well. Each time you use it, multiply the entire thing
by five. After a few iterations, it gets pretty wild.
There are few pseudo-rdm generators that are as efficient as that,
resource-wise, frankly. ;-)
Anyway, just an idea for you.
--Ben
On Fri, 20 Oct 2000 04:29:10 GMT, csil...@cgocable.net (Cedric Silvester)
wrote:
Tom Duff
> One really efficient and reasonably useful rdm generator is to take a 16 bit
> unsigned number, initialize it to 625 (or any odd number, really), then
> multiply by five. Take only the upper byte of the 16 bits as your random
> number; works amazingly well. Each time you use it, multiply the entire thing
> by five. After a few iterations, it gets pretty wild.
This generator is almost useless for any purpose
beyond personal amusement. Here is a program
implementing it:
#include <stdio.h>
int rnd(void){
static int rv=625;
rv*=5;
return (rv>>8)&0xff;
}
main(void){
int i;
for(i=0;i!=1000;i++) printf("%d %d\n", rnd(), rnd());
return 0;
}
If you feed its output to gnuplot, you get something that
looks roughly like this:
| + + + + +
| + + + + +
| + + + + +
| + + + + +
| + + + + +
| + + + + +
| + + + + +
| + + + + +
| + + + + +
| + + + + +
| + + + + +
| + + + + +
| + + + + +
| + + + + +
| + + + + +
|+ + + + +
|+ + + + +
|+ + + + +
+ + + + +
+-----------------------------------
If the generator is really making independant
random numbers, there should be not pattern
in this plot. Instead, what we see is
5 lovely lines, each with slope 5. This means
that successive outputs of the generator are
highly correlated. Don't use this generator
for anything important.
--
Tom Duff. I love jingling and droning!
Mohammad Tehrani
> int rnd(void){
> static int rv=625;
>
> rv*=5;
> return (rv>>8)&0xff;
>
rv>>8 shifts the bits to the right but I was wondering what &0xff do??
Ben Blish
wrong side of the bed, skipped the thinking process altogether, and
ill-advisedly posted for all the world to see:
>This generator is almost useless for any purpose
>beyond personal amusement.
Aside from an amazingly strong temptation to characterize your reply as it so
strongly deserves, my reaction to this is to simply start by saying that it's a
very simple generator and its use is appropriate for many classes of simple
things - which is *exactly* the kind of issue this thread was opened with.
Aside from that, you're just plain wrong. It's not useless, as it's seen many,
many commercial USES in the time I've known about it (about 20 years), and it
has served admirably in those roles. Which takes the above statement by you and
firmly places it in the category of... hey! ---> USELESS STATEMENTS!
>If you feed its output to gnuplot, you get something that
>looks roughly like this:
You can get correlations out of any pseudo random sequence if you sequence the
calls right. As I'm sure you well know. If you take the random generator that's
standard in the C lib, you can *easily* get patterns on a bitmap if you simply
call it in a nice, regular fashion that is related to the generator's internal
cycles, which MANY image resolutions are, just as the output res you used in
gnuplot was for this one. You can get patterns out of the Perlin noise
generator everyone raves about without half trying (because it's based on the C
random generator, at least in part) and you can probably get patterns out of
almost any pseudo random generator. Correlated output - even fairly highly
correlated output - is NOT a killer for many applications - surprise, surprise,
eh? The question is always, for practical use, "is it correlated to what I'm
trying to do?" Not... "Is it correlated to a cobbled-up gnuplot example".
[clippage of above mentioned cobbled-up gnuplot]
>If the generator is really making independant
>random numbers, there should be not pattern
>in this plot.
If it was making independent random numbers, it wouldn't be pseudo random. Duh.
And if you sequence a plot - any plot - image, graph, whatever - to an internal
cyclic pattern in a generator, you're going to get correlations. Again, duh.
And if you don't expect a simple little multiply-based generator to generate
easily detected correlations when you apply a steady sample rate to it,
well.... DUH!
> Instead, what we see is
>5 lovely lines, each with slope 5. This means
>that successive outputs of the generator are
>highly correlated. Don't use this generator
>for anything important.
It makes little difference in many applications. Also, how you call and use
this generator - or any generator - makes a huge difference in how the output
correlates (or does not) to what you are doing. You can call it using it's own
output as a modifer or a sequencer; you can call it odd numbers of times; you
can reseed it; you can, if you have the opportunity, interfere with it using
user input timings; you can xor it into a stream of data you already have; you
can do all sorts of things. It's reseedable and repeatable if you want to use
it that way, and it's proved *most* useful to me over many years - 20, in fact
- of programming in tight spaces. It is, in point of fact, a very useful
building block.
I rather think you completely missed the point of the original post. He was
short on resources by his own description, and had something very simple to do.
Not "unimportant", but simple. This might well work fine for him. Or not; it
was presented in the spirit of "here's something that has worked (emphasis on
WORKED) for me, maybe it'll work for you, uses few resources, here it is." Your
heavy handed characterization is out of line and uncalled for, not to mention
pompous as heck and wrong on several counts to boot.
Perhaps you should try and restrain yourself. What works in real applications
isn't always defined by academic- or rote-inspired preconceptions of
"goodness," and your proclivity, demonstrated here, to depend on a graph to
determine the usability of something of this order won't serve you a fraction
as well as thinking things through in relation to the application at hand,
instead.
The bottom line: It works. In important roles. It's certainly not useless.
Despite your graph, or perhaps because of it, who knows. And who cares? What
real world programming is about is solving problems, and no matter if you (or
your plotting utilities) like it or not, this little gem performs quite well.
You'll just have to get over it. And oh yeah... it IS amusing to work with. You
at least got that part right. ;-)
--Ben
Stephen H. Westin
> On Wed, 25 Oct 2000 11:30:21 -0700, Tom Duff <t...@pixar.com> climbed out of the
> wrong side of the bed, skipped the thinking process altogether, and
> ill-advisedly posted for all the world to see:
>
> >This generator is almost useless for any purpose
> >beyond personal amusement.
<snip>
> >If you feed its output to gnuplot, you get something that
> >looks roughly like this:
>
> You can get correlations out of any pseudo random sequence if you
> sequence the calls right. As I'm sure you well know. If you take the
> random generator that's standard in the C lib, you can *easily* get
> patterns on a bitmap if you simply call it in a nice, regular
> fashion that is related to the generator's internal cycles, which
> MANY image resolutions are, just as the output res you used in
> gnuplot was for this one.
Which is to say, random() also falls into the class of "pseudorandom
generators you don't want to use". I believe drand48() exists for just
this reason, and folks who rely on good random number generators
usually code their own. Microsoft, of course, doesn't know the
difference, and only provides the lame random().
> >If the generator is really making independant
> >random numbers, there should be not pattern
> >in this plot.
>
> If it was making independent random numbers, it wouldn't be pseudo
> random. Duh. And if you sequence a plot - any plot - image, graph,
> whatever - to an internal cyclic pattern in a generator, you're
> going to get correlations. Again, duh.
Except, of course, that different generators have vastly different
periods. Some are incredibly long: so long that they are never seen in
practice. A 32-bit linear congruential generator can be built with a
period of 2^32, for example. There are, of course, other tests for
generators.
I think you need to find a volume of Knuth Volume 2 and read up on the
subject. There really isn't much excuse to be using a really bad
pseudorandom generator.
--
-Stephen H. Westin
Any information or opinions in this message are mine: they do not
represent the position of Cornell University or any of its sponsors.
Tom Duff
>
> On Wed, 25 Oct 2000 11:30:21 -0700, Tom Duff <t...@pixar.com> climbed out of the
> wrong side of the bed, skipped the thinking process altogether, and
> ill-advisedly posted for all the world to see:
>
> >This generator is almost useless for any purpose
> >beyond personal amusement.
>
> calls right.
Have you read sections 3.2.1.3 and 3.2.2 B of D.E. Knuth, Art of Computer
Programming?
> Correlated output - even fairly highly
> correlated output - is NOT a killer for many applications - surprise, surprise,
> eh? The question is always, for practical use, "is it correlated to what I'm
> trying to do?" Not... "Is it correlated to a cobbled-up gnuplot example".
> And if you don't expect a simple little multiply-based generator to generate
> easily detected correlations when you apply a steady sample rate to it,
> well.... DUH!
On the contrary, I, following the acknowledged experts in this subject, *do*
expect a simple multiplicateive generator to be free of these correlations.
For example, if you change the multiplier in your generator from 5 to 777,
the correlation problem is greatly ameliorated. (There's no science in the
choice of 777 -- I just tried a couple of easy-to-type numbers.)
> I rather think you completely missed the point of the original post. He was
> short on resources by his own description, and had something very simple to do.
Something very simple -- running the control parameters to a multi-dimensional
mechanism through their full range -- for which this generator is singularly
unsuited, as indicated by the plot you so distained.
--
Tom Duff. Ways and Means.
Ben Blish
Westin) wrote:
>I think you need to find a volume of Knuth Volume 2 and read up on the
>subject. There really isn't much excuse to be using a really bad
>pseudorandom generator.
I think, that depsite my trying to cover all the bases, you still missed my
point. I'll be more concise, just for you: I don't NEED to "read up". My apps
work great. Even ones that use this little fellow. And the lib generator in C.
I'm making money. I'm doing fine.
The point being, my approach is PRACTICAL, not academic. If it's good enough,
it's good enough, and that's the end of it. When it's not good enough, then
it's time to dig deeper. That time has not yet arrived.
If digging for its own sake amuses you, by all means, dig all you want. I have
better things to do. Like get work done to spec/target and make money.
The person I responded to was looking to get something done. I handed him
something useful. The fellow from Pixar jumped in and dumped a bunch of obvious
crap on the group, in an attempt to discredit the code snippet. He was wrong
then, he's still wrong. And as for what I need to do... You have no more case
or cause to tell me that than I do for you.
:-)
--Ben
Stephen H. Westin
> On 25 Oct 2000 17:36:46 -0400, westin*nos...@graphics.cornell.edu (Stephen H.
> Westin) wrote:
> >I think you need to find a volume of Knuth Volume 2 and read up on the
> >subject. There really isn't much excuse to be using a really bad
> >pseudorandom generator.
>
> I think, that depsite my trying to cover all the bases, you still
> missed my point. I'll be more concise, just for you: I don't NEED to
> "read up".
If you used the C library's random() as an example of a random number
generator, you probably do need to "read up".
> My apps work great. Even ones that use this little fellow. And the
> lib generator in C. I'm making money. I'm doing fine.
>
> The point being, my approach is PRACTICAL, not academic. If it's good enough,
> it's good enough, and that's the end of it. When it's not good enough, then
> it's time to dig deeper. That time has not yet arrived.
>
> If digging for its own sake amuses you, by all means, dig all you
> want. I have better things to do. Like get work done to spec/target
> and make money.
Let's just say that I've been bit often enough by the "I hope this
works" approach to appreciate those who know the fundamentals.
> The person I responded to was looking to get something done. I
> handed him something useful. The fellow from Pixar jumped in and
> dumped a bunch of obvious crap on the group, in an attempt to
> discredit the code snippet. He was wrong then, he's still wrong.
What a shame that Pixar has never figured out how to make money
:). One of the foundations of their success is not being afraid to
build solid technology. MUch of which depends on pseudorandom number
generation.
And one could argue that the "obvious crap" is posting a poor
pseudorandom generator and claiming that it's good.
> And as for what I need to do... You have no more case
> or cause to tell me that than I do for you.
So, given two alternative implementations of similar complexity, you
choose to use the one that is demonstably inferior, simply because you
love your ignorance.
Ben Blish
>Have you read sections 3.2.1.3 and 3.2.2 B of D.E. Knuth, Art of Computer
>Programming?
In fact, I have. Also other things that bear on this in interesting ways, such
as Hamming's Coding and Information Theory and Ulichney's Digital Halftoning.
Being mostly a graphics guy - though a different kind of graphics guy than you
- these days, that's kind of my angle. Sorry I can't live down to what appears
to have been your expectations. Just because someone suggests something simple,
doesn't mean they ARE simple.
>On the contrary, I, following the acknowledged experts in this subject, *do*
>expect a simple multiplicateive generator to be free of these correlations.
Perhaps you expect too much. <shrug>. Why use a stick of dynamite to kill an
insect? Even if you have one handy? Even if it was free? If the critter is
dead, it's dead, the job's done.
>For example, if you change the multiplier in your generator from 5 to 777,
>the correlation problem is greatly ameliorated. (There's no science in the
>choice of 777 -- I just tried a couple of easy-to-type numbers.)
That's a fine suggestion for some cases, and if that's what you had posted in
reply to my suggestion originally, why, you'd have been being helpful and I,
and perhaps the original poster, would have been grateful. But instead, you
decided that you'd bandy about phrases like "useless" and "for amusement only"
and "don't use for anything important" all of which were unmitigated baloney.
Multiplying by 777 is a lovely suggestion, and I hope the original poster sees
it. It might well be useful.
Might? Yes, MIGHT. Because, unlike your choice of 777, there *was* some science
the choice of 5. When you went from 5 to 777, you eliminated the preferred
doubleshift and add mechanism for its iteration, and in many venues - quite
possibly inside a CNC controller - you've taken a very efficient mechanism -
just a few clocks even in a very limited micro - and hosed it by presuming that
the only key low level issue was the multiplier. And CNC controllers are VERY
much real-time machines, so this could easily be an issue. Whoops. :-)
Sure, on a machine with a fast 16x16 mulitply, so what. But on many micros,
it's *not* so what. Some micros have 8x16 multiplies. Some don't have any. And
since part of my programming experience includes writing code for
microcontroller centered CNC machines (whoops again... surprise! ;-), I
actually had this in mind when I posted my little snippet. If you're not short
on resources, computing and/or memory, none of this applies, for instance, if
you have a Pentium under your thumb. Or a MIPs-based machine, eh? But, as the
next quoted section said...
>> I rather think you completely missed the point of the original post. He was
>> short on resources by his own description, and had something very simple to do.
...and there you have it.
>Something very simple -- running the control parameters to a multi-dimensional
>mechanism through their full range -- for which this generator is singularly
>unsuited, as indicated by the plot you so distained.
No. Your plot doesn't indicate anything of the sort. You're completely wrong
when you make that presumption, and that's because you're hardly applying
yourself to the problem - you're just concentrating on the idea of random
number generators in general and how they have to be fabulous, or they are no
good. No wonder you can't see why it could be made to work fine in that venue.
The numbers don't have to be (and in fact, you'd be nuts to try to make them
serve as) the parameters to the controls themselves; they just need to be
parameters to higher level things that do full range movements and sets of
movements and the interpolations of those movements, all of which are pretty
standard components within a typical CNC machine's code complement. That's how
they move. Move from here, to here; interpolate in this manner or that manner
(circular, etc.) along the way. Or not.
The poster didn't say they were missing control implementations, instead it was
indicated they were missing a nonlinear source of movement stimulation. You
don't want to feed raw random numbers to an axis controller... that's not
appropriate for testing CNC machines in any kind of real world manner, and it's
not healthy for your average servomechanism actuator, either. Cutting heads
have mass and you *must* control them with more finesse than just poking a
number at a stepper motor or other linear actuator. Further, such an approach
is unlikely (no matter what random number generator you use) to get any
particular axis out to the extents of it's travel, one at a time or *certainly*
at the same time which is very definitely a potential situtation for a cutting
head or an ESD wire. What you're talking about isn't what has to happen here
for the unit to be well stressed. What I'm tlaking about, though, is. And then
there are feedback inputs from the scale sensors to be considered... they could
get into the act too in a stress test, though you'd rather hope you could count
on them in actual use. I had all this in mind. It all bears on the suitability
of my suggestion.
Bottom line, if you'd said:
"Here's an enhancement that can decrease correlation at (XYZ[abc]... {some CNC
machines have more than 3d involved} sample rate, and besides, you change the
correlation for every time the generator is implemented in any repetitive
sequence... but I digress): yadda yadda) then you'd have been right in the
spirit, or at least what I imagine is the spirit, of the algs group, or at a
minimum, in the spirit of what I posted, which was only intended to be helpful.
We might have had a fine time tossing issues like compute efficiency, available
resources, the cpu involved, the ranges needed, etc. around. We could have dug
into the issue of what the sample rate was, even. Instead, you were abusive
right off the bat. If you hadn't been, it would have been fine. Would have
avoided all the mean stuff you posted, and you'd look more like "that blending
guy" than some guy who posted a bunch of insulting nonsense to me. I have no
obligation to accept that kind of abuse directed at my contributions, and
neither does anyone else. Sometimes - like this time - I'd rather reply for a
while than let someone slide by. I don't do it for the onlookers - I'm speaking
only to you. If I have something to say to them, I will. I have.
Tom, you've got some fame, and some very nice accomplishments. Perhaps now
would be a good time to add grace to your online persona.
--Ben
Cedric Silvester
I didn't mean to set off such a heated discussion, but I guess this
_is_ Usenet.
As you point out, this might be Good Enough for my purposes. I'll
code it up and give it a shot as soon as I can get some time on a
machine.
> One really efficient and reasonably useful rdm generator is to take a 16 bit
> unsigned number, initialize it to 625 (or any odd number, really), then
> multiply by five. Take only the upper byte of the 16 bits as your random
> number; works amazingly well. Each time you use it, multiply the entire thing
> by five. After a few iterations, it gets pretty wild.
>
> There are few pseudo-rdm generators that are as efficient as that,
> resource-wise, frankly. ;-)
>
> Anyway, just an idea for you.
>
> --Ben
>
> On Fri, 20 Oct 2000 04:29:10 GMT, csil...@cgocable.net (Cedric Silvester)
> wrote:
>
Dave Eberly
news:39f767b8...@news.montanavision.net...
Stephen and Tom are right in what they say. Until you really
understand something about random number generators,
do not waste your time posting as if you are an expert in this
and they are not. You are not. They are.
--
Dave Eberly
ebe...@magic-software.com
http://www.magic-software.com
Mark VandeWettering
>On Wed, 25 Oct 2000 11:30:21 -0700, Tom Duff <t...@pixar.com> climbed
>out of the wrong side of the bed, skipped the thinking process
>altogether, and ill-advisedly posted for all the world to see:
>>This generator is almost useless for any purpose
>>beyond personal amusement.
>
>Aside from an amazingly strong temptation to characterize your reply as it so
>strongly deserves, my reaction to this is to simply start by saying that it's a
>very simple generator and its use is appropriate for many classes of simple
>things - which is *exactly* the kind of issue this thread was opened with.
Uh, Tom may be grumpy and bend some peoples' ego, but I wouldn't
be so quick to dismiss his observations. The proposed algorithm
wasn't just simple: it was essentially illiterate. Linear congruential
generators are simple and fairly well understood, and the example
presented was a particularly ill chosen example of that type of
generator. Appropriate choices of values (5 is certainly a very
poor multiplier, and 256 not a particularly stellar modulus) would
yield much better results. As that is not unlikely to cost any
more to implement, it is hard to understand why you would propose
it.
>You can get correlations out of any pseudo random sequence if you sequence the
>calls right. As I'm sure you well know. If you take the random generator that's
>standard in the C lib, you can *easily* get patterns on a bitmap if you simply
>call it in a nice, regular fashion that is related to the generator's internal
>cycles, which MANY image resolutions are, just as the output res you used in
>gnuplot was for this one.
This is not correct. Tom was examining _sequential_ outputs to
your generator, which show strong (actually constant) deltas. This
isn't finding correlations by "sequencing calls right". Most decent
generators at least have cycles which are prime, which typical image
resolutions are not.
>You can get patterns out of the Perlin noise generator everyone
>raves about without half trying (because it's based on the C random
>generator, at least in part) and you can probably get patterns out
>of almost any pseudo random generator. Correlated output - even
>fairly highly correlated output - is NOT a killer for many applications
>- surprise, surprise, eh? The question is always, for practical
>use, "is it correlated to what I'm trying to do?" Not... "Is it
>correlated to a cobbled-up gnuplot example".
Correlations in Perlin noise are virtually always caused by poor
hash functions, not by bad generators.
>If it was making independent random numbers, it wouldn't be pseudo
>random. Duh. And if you sequence a plot - any plot - image, graph,
>whatever - to an internal cyclic pattern in a generator, you're
>going to get correlations. Again, duh. And if you don't expect a
>simple little multiply-based generator to generate easily detected
>correlations when you apply a steady sample rate to it, well....
>DUH!
And of course the point is that changing this bad generator into a better
one is just about picking some better constants. Double duh.
>It makes little difference in many applications. Also, how you call and use
>this generator - or any generator - makes a huge difference in how the output
>correlates (or does not) to what you are doing. You can call it using it's own
>output as a modifer or a sequencer; you can call it odd numbers of times; you
>can reseed it; you can, if you have the opportunity, interfere with it using
>user input timings; you can xor it into a stream of data you already have; you
>can do all sorts of things. It's reseedable and repeatable if you want to use
>it that way, and it's proved *most* useful to me over many years - 20, in fact
>- of programming in tight spaces. It is, in point of fact, a very useful
>building block.
Or you could just use a better constant and get better values out.
>I rather think you completely missed the point of the original post. He was
>short on resources by his own description, and had something very simple to do.
>Not "unimportant", but simple. This might well work fine for him. Or not; it
>was presented in the spirit of "here's something that has worked (emphasis on
>WORKED) for me, maybe it'll work for you, uses few resources, here it is." Your
>heavy handed characterization is out of line and uncalled for, not to mention
>pompous as heck and wrong on several counts to boot.
No, Tom was not wrong. Not in the least.
>Perhaps you should try and restrain yourself. What works in real
>applications isn't always defined by academic- or rote-inspired
>preconceptions of "goodness," and your proclivity, demonstrated
>here, to depend on a graph to determine the usability of something
>of this order won't serve you a fraction as well as thinking things
>through in relation to the application at hand, instead.
I'll stifle comment lest I too be branded with that `pompous' label.
>The bottom line: It works. In important roles. It's certainly not
>useless. Despite your graph, or perhaps because of it, who knows.
>And who cares? What real world programming is about is solving
>problems, and no matter if you (or your plotting utilities) like
>it or not, this little gem performs quite well.
Gem? I'm not even sure its rock.
Mark
>--Ben
--
This signature has eight As, two Cs, three Ds, thirty Es, eight Fs, seven
Gs, nine Hs, fourteen Is, four Ks, two Ls, four Ms, nineteen Ns, thirteen Os,
two Ps, fifteen Rs, thirty one Ss, twenty four Ts, seven Us, six Vs, seven
Ws, two Xs, and four Ys. Mark VandeWettering <ma...@telescopemaking.org>
Stephen H. Westin
> Stephen and Tom are right in what they say.
Gee, thanks.
> Until you really
> understand something about random number generators,
> do not waste your time posting as if you are an expert in this
> and they are not. You are not. They are.
Nope, I'm not. But I've hung around enough with the people who really
do know. I would count Tom among those.
Tim Lister
"Anyone who considers arithmetical methods
of producing random digits is, of course,
in a state of sin"
- JOHN VON NEUMANN (1951)
anyway, it looks to me like you're talking about different things:
* One disputant seemed to be talking about numerical control systems,
some which have very limited precision, and his experience found a
method that *worked* in his situation ...
* The critics pointed out that it was a very poor algorithm for a
modern computer, which is a very different pot of lobsters.
i'll stick with Odd John :-)
(unless, of course, the disputant sincerely believes it is a good
algorithm for general usage, in which case he is a fucking moron, and
you nice boys go right ahead and kick the shit out of him.)
regards,
tal
===========
[Tim Lister, EYE CANDY web spinning, NSW 2042, Australia]
[Phone: 61 2 9557 4050]
[mailto: eye-...@webspinning.org]
[WWW: http://www.maxtal.com.au/~tal/eyecandy ]
[committee member of AWPA: http://www.awpa.asn.au/ ]
"He walks the streets like an ordinary man"
Tom Duff
> >For example, if you change the multiplier in your generator from 5 to 777,
> >the correlation problem is greatly ameliorated. (There's no science in the
> >choice of 777 -- I just tried a couple of easy-to-type numbers.)
>
> It might well be useful.
> Might? Yes, MIGHT. Because, unlike your choice of 777, there *was* some science
> the choice of 5. When you went from 5 to 777, you eliminated the preferred
If you had read the original poster's message you would have seen that this
isn't
an issue -- he said he had available a full range of arithmetic functions.
Presumably
he didn't mean that he had them but was unwilling to use them. In any case,
if you were really interested in producing a decent solution with just a shift
and an add, you'd have picked 33, which is optimal over the set of 2-bit
numbers.
--
Tom Duff. Old Timey Bop -- it's better than it sounds.
jim
Cedric Silvester wrote:
> The reason? I like to 'burn-in' a machine by letting it run for many
> hours (typically 48), moving all axes slides randomly through their
> full range, plus randomly turn on the spindle, pumps, valves, etc.
> But it seems CNC manufacturers don't think an RND() function is
> useful...
>
Hi Cedric
This must be a dumb question with so many respondants striving so hard
for the perfect random number generator. But why would you imagine that
your machine would benefit from performing these machine functions in a
random manner rather than a systematic one. I program and run CNC's so
this is not just an idle question.
-Jim