> I wanted to know if it's possible we write a program in Linux that uses
> the proposed method to produce tru random numbers.

For sure this is possible - the question is:
"Do we need such a program?". You have to always keep
in mind that performance also is an issue. If you want
to go for it: High Performance Oscillators can be found
in the Digital Sound Processing Scene. They are used
for Synthesizers (tone creation and modulation). Most
of them use kinds of interpolation, but interpolation
doesn't necessarily prevent randomization.

BTW: Are "true" random number generators possible? Ain't
an "Algorithm" inherently repetitive? Well I'm getting
philosophical.

Hesham wrote:
> Hi all
>
> I'm a newbie and maybe my question is not related to this newsgroup,
> please let me know if that's the case. Anyway, I read this article:
> http://www.psigenics.com/Research/Papers/US06862605.pdf
> I wanted to know if it's possible we write a program in Linux that uses
> the proposed method to produce tru random numbers.

The proposed method is a piece of analog hardware. How do you propose
to code that up on a discrete machine?

Did you bother to read even just the Abstract?

``The relative jitter between the two oscillatory signals contains a
calculable amount
of entropy that is extracted by the processor to produce a sequence
of true
random numbers.''

If you have such a device on your target board, you can write a driver
for it.

Paul Hilbert wrote:

> BTW: Are "true" random number generators possible?

Yes.

> Ain't
> an "Algorithm" inherently repetitive?

That just means you can't generate true random numbers from an
algorithm unless there's some truly random input. Real-world computers
are not Turing machines.

> Well I'm getting
> philosophical.

Maybe a little.

DS

> Paul Hilbert wrote:
>
>> BTW: Are "true" random number generators possible?
>
> Yes.
>
>> Ain't
>> an "Algorithm" inherently repetitive?
>
> That just means you can't generate true random numbers from an
> algorithm unless there's some truly random input. Real-world computers
> are not Turing machines.

well to get specific - ain't oscillators inherently repetitive?
I'm quite sure I am the one who misses the one - general - idea.
Computers are enhanced turing mashines combined with a stack, aren't they?
That doesn't make them go beyond algorithmic. Or in other words - what are
the non-algorithmic parts of the idea of random number generation?
Where's the randomization coming from? AFAIK there's no evidence for
random behaviour in the entire universe - there's only chaos, nothing
random (that's in fact what I meant with "philosophical").

Randomization as I see its implementation is only nearing towards perfect
chaos (unreproducability because of too many factors).

> Hesham wrote:
>> Hi all
>>
>> I'm a newbie and maybe my question is not related to this newsgroup,
>> please let me know if that's the case. Anyway, I read this article:
>> http://www.psigenics.com/Research/Papers/US06862605.pdf
>> I wanted to know if it's possible we write a program in Linux that uses
>> the proposed method to produce tru random numbers.
>
> The proposed method is a piece of analog hardware. How do you propose
> to code that up on a discrete machine?

I disagree. Hardware oscillators are not nearer towards perfect ones than
software implementations. Software synthesis shows, that hardware
oscillators ain't significantly faster than emulated ones. As far as I can
see, this method is some kind of frequency modulation - I just can't see
what's random in it. You can take millions of repetitive patterns and let
them modify each other - the result is always repetitive.

Paul Hilbert wrote:

> I disagree. Hardware oscillators are not nearer towards perfect ones than
> software implementations.

Huh?

> Software synthesis shows, that hardware
> oscillators ain't significantly faster than emulated ones.

What does speed have to do with anything?

> As far as I can
> see, this method is some kind of frequency modulation - I just can't see
> what's random in it. You can take millions of repetitive patterns and let
> them modify each other - the result is always repetitive.

The patters are not repetitive, they are truly random. They are to some
extent due to microscopic zone temperature variations inside the
crystals but they are also to some extent due to even smaller quantum
effects.

Oscillators are not repetitive. If you record the period of a
real-world hardware oscillator to sufficient resolution, it will be
truly chaotic and will never repeat.

Modern computers can record timing to a level of a better than
hundred-millionth of a second by reading the TSC (instruction cycle
counter). Many hardware effects show truly random behavior on this
scale, for example disk read delays due to turbulence affecting the
short-term rotation rate of a hard drive spindle or clock skew between
the oscillator on its network card and the PLL generating the CPU clock
due to microscopic zone temperature variations.

Real world computers are not Turing machines.

DS

2006-10-4, 20:48(-07), David Schwartz:
[...]
> The patters are not repetitive, they are truly random. They are to some
> extent due to microscopic zone temperature variations inside the
> crystals but they are also to some extent due to even smaller quantum
> effects.
>
> Oscillators are not repetitive. If you record the period of a
> real-world hardware oscillator to sufficient resolution, it will be
> truly chaotic and will never repeat.
[...]

For complement of information, one might want to read RFC 4086.
Most modern end user PCs have hardware random generators
builtin: a soundcard, a webcam (for the thermal noise again), or
even a hard disk (where the fluctuation of the spin speed due to
chaotic air flow can also be taken as a source of randomness).

--
Stéphane

Paul Hilbert wrote:
> > The proposed method is a piece of analog hardware. How do you propose
> > to code that up on a discrete machine?
>
> I disagree. Hardware oscillators are not nearer towards perfect ones than
> software implementations. Software synthesis shows, that hardware
> oscillators ain't significantly faster than emulated ones.

Troll or moron?

Software runs on a computer, whose clock signal is generated by an
oscillator.

Any oscillator simulator you run will necessarily have a much longer
period than that of the clock cycle of the machine that it's running
on. And in fact, the more numerically accurate it is, the more cycles
it will require to do its job.

No matter how accurate it is, it's inescapable that it is performing a
discrete simulation.

> Paul Hilbert wrote:
>> > The proposed method is a piece of analog hardware. How do you propose
>> > to code that up on a discrete machine?
>>
>> I disagree. Hardware oscillators are not nearer towards perfect ones than
>> software implementations. Software synthesis shows, that hardware
>> oscillators ain't significantly faster than emulated ones.
>
> Troll or moron?
>
> Software runs on a computer, whose clock signal is generated by an
> oscillator.
>
> Any oscillator simulator you run will necessarily have a much longer
> period than that of the clock cycle of the machine that it's running
> on. And in fact, the more numerically accurate it is, the more cycles
> it will require to do its job.
>
> No matter how accurate it is, it's inescapable that it is performing a
> discrete simulation.

I talked about no "significant" improvement in speed. I also said,
that I think *I* am the one who misses some elementary point(s).
So for your confidence:

I'm - in your words - generally to be described as a "moron".

I thought about apologizing for my interest but it may be the best to
keep quiet.

On Thu, 5 Oct 2006 00:33:57 +0000 (UTC)
"Paul Hilbert" wrote:

> well to get specific - ain't oscillators inherently repetitive?
> I'm quite sure I am the one who misses the one - general - idea.
> Computers are enhanced turing mashines combined with a stack, aren't
> they?
>
Easier to work with? yes. Enhanced? I don't think so. As matter of fact
a real life computer can't compute all the algorithms a turing machine
can. The memory on a real computer may be large, but it's not infinite
like the turing machine tape.

> That doesn't make them go beyond algorithmic. Or in other words - what
> are the non-algorithmic parts of the idea of random number generation?
> Where's the randomization coming from? AFAIK there's no evidence for
> random behaviour in the entire universe - there's only chaos, nothing
> random (that's in fact what I meant with "philosophical").
>
Well, I'm no physics expert, but aren't the eletron behaviour quite
random? After all we can predict it's speed or it's position, but not
both. I think that means that they're somewhat random.

Maybe a more pratical idea of random would be that a random thing is
something nobody can predict. That is, given the limited set of tools we
have today, we cannot precisely predict the outcome of some event.
Keeping in mind that the algorithm that will enable you to figure out
that outcome, must be fast enough so it doesn't find it out only after
the event has already happened. There's no difference between a true
random event or a event that no one can predict. In the end the result
is the same.

> Randomization as I see its implementation is only nearing towards
> perfect chaos (unreproducability because of too many factors).
>
Maybe, but there are so many factors that we aren't even sure if we can
actually mesure them all. Let's not forget that physics is only a trial
to make some sense on the universe we live. It doesn't mean that, only
because we can predict lots of things, everything is predictable. Well,
this is getting highly offtopic, and highly speculative. I'm not sure
anyone here have actually taken the time to study this kinda thing.