Double Clock Experiment

C

CoreyWhite

The following experiment is a demonstration of TIME TRAVEL. When
writing this program, and testing it out I found that sometimes the
program would engage itself in time travel but other times it would
not. After careful testing and reprogramming I have optimized the code
so it should work every time, however I recommend that you leave the
room while it is running and think of something else. It takes about 5
minuets to run so it is better if you don't stare at a blank screen.

Here is how the double clock experiment operates:

The program loops like this:

LOOP

wait

a = a + time

wait

b = b + time

GOTO LOOP

c = time

Then it checks to see if the differance between a and b, is correct
compared to c. In normal physics it should be, but if the program time
travels then the output will be different. To show you what I mean
let me give you an example of the program in operation:

wait 10

a = a + time 10

wait 10

b = b + time 20

wait 10

a = a + time 30

wait 10

b = b + time 40

wait 10

a = a + time 50

wait 10

b = b+ time 60
-

Now A = 90 & B = 120

-imediately check time-

C = time 60

Using logic we can deduce that A should be exactly C / 2 smaller than
B, but when you run the program the time differance can vary
considerably in either direction. On top of that, the time it takes to
run the program is not constant either. What conclusions can we draw
from this?

I'll show you some example output and then give you the source:

Time A: 146124514
Time B: 146270790
Time C: 293157

C / 2 = 146578.5
Actual Difference 145276

Time A was 1302.6 ticks into the future, or maybe time b was 1302.6
ticks into the past.

Here is some more real output:

Time A: 144371012
Time B: 144515341
Time C: 289188
C / 2 = 144594
real difference: 144329

time A was 265 ticks into the future, or time b was 265 ticks into the
past.

I wish I had an atomic clock to experiment with, but here is the
source:

#include <sys/types.h>
#include <time.h>
#include <unistd.h>
#include <stdio.h>
#include <math.h>

int main()
{

clock_t c0, c1, c2; /* clock_t is defined on <time.h> and
<sys/types.h> as int */
long count;


printf ("using UNIX function clock to measure CPU time ... \n");

for (count = 0; count < 1000; count++){

for(int cnt1 =0; cnt1 < 100000; cnt1++){
c1 = clock();
}

c0 = c0 + clock();

for(int cnt2 =0; cnt2 < 100000; cnt2++){
c1 = clock();
}

c2 = c2 + clock();

}

c1 = clock();



printf ("\tend (CPU); %d\n", (int) c0);
printf ("\tend (CPU2); %d\n", (int) c2);
printf ("\tend (NOW); %d\n", (int) c1);
return 0;

}
 
B

Bill Hobba

The following experiment is a demonstration of TIME TRAVEL. When
writing this program, and testing it out I found that sometimes the
program would engage itself in time travel but other times it would
not.

Take your meds - better still triple the dose and take them.

Rest of troll junk snipped.

Bill
 
C

CoreyWhite

Take your meds - better still triple the dose and take them.

So because you think I need medication that makes me wrong?
Why do you even bother posting if you aren't intelligent enough to
offer an opinion about why I am wrong?
 
O

Old Wolf

The following experiment is a demonstration of TIME TRAVEL. When
writing this program, and testing it out I found that sometimes the
program would engage itself in time travel but other times it would
not.

I answered this last week, didn't you read it?
I'll re-post for your benefit:
wait 10
a = a + time 10
wait 10
b = b + time 20
wait 10
a = a + time 30
wait 10
b = b + time 40
wait 10
a = a + time 50
wait 10
b = b+ time 60
Now A = 90 & B = 120
-imediately check time-
C = time 60

Using logic we can deduce that A should be exactly C / 2
smaller than B,

Only if "time" was exactly 0 before the first wait.
but when you run the program the time differance can vary
considerably in either direction. On top of that, the time it takes to
run the program is not constant either.

NAME
clock - Determine processor time

DESCRIPTION
The clock() function returns an approximation of processor time
used by the program.

CONFORMING TO
ANSI C. POSIX requires that CLOCKS_PER_SEC equals 1000000
independent of the actual resolution.

1) Your program takes time to start up
2) Your program takes time to do all of its other processing
besides calling the clock function
3) The operating system may take varying amounts of time
to execute the clock() function
4) The results of clock() are only an approximation
5) If you run this for more than 2148 seconds then you get
an integer overflow.

Who'd a thunk it?

NB. clock() is not an ANSI C function, if you want to debate its
behaviour further, then post in a group such as comp.unix.programmer
 
O

Old Wolf

Old said:
NB. clock() is not an ANSI C function, if you want to debate its
behaviour further, then post in a group such as comp.unix.programmer

Sorry -- clock() is an ANSI C function, but its behaviour is
implementation-defined (ie. what it returns exactly depends
on what system you are running it on).
So if you want knowledgable answers about why clock() is
returning what it is, should ask on a NG dedicated to your
platform (such as the one I mentioned above).
 
T

Thad Smith

The following experiment is a demonstration of TIME TRAVEL.

Not really. It is a demonstration of limited resolution of the system
timer and effects of interrupts on timing accuracy.

This is off-topic in comp.lang.c and probably the two sci.physics groups.
Then it checks to see if the differance between a and b, is correct
compared to c. In normal physics it should be, but if the program time
travels then the output will be different.

The physics is holding up well, but you might need to increasing you
understanding of working with limited measurement resolution and elapsed
time not accounted for with a simple model.
 
C

CoreyWhite

Thad said:
Not really. It is a demonstration of limited resolution of the system
timer and effects of interrupts on timing accuracy.
This is off-topic in comp.lang.c and probably the two sci.physics groups.



The physics is holding up well, but you might need to increasing you
understanding of working with limited measurement resolution and elapsed
time not accounted for with a simple model.



If you had a more objective way of measuring time then you could tell
me which of the final times in the program was the better of the two
aproximations. Because there is no more objective way to measure time
than this, both aproximations are equally accurate. In a subjective
way they are both entirely real since whatever we use to measure time
will not be perfectly accurate.
 
B

Bill Hobba

So because you think I need medication that makes me wrong?

When a person claims something totally absurd they will be diagnosed as
delusional. Either that, or, and it is much more likely in your case, they
are a malicious troll.
Why do you even bother posting if you aren't intelligent enough to
offer an opinion about why I am wrong?

Because you are obviously a troll and replying to trolls is simply a matter
of either ignoring them or responding with what amuses you just like you are
posting to be amused. And do not reply with the usual crank/troll rot of
how do you know I am wrong etc etc which is simply a ruse to engage someone
to get your jollies - I have seen it all before. One does not need to
deliver a dissertation to know flat earthers are idiots. But to take your
challenge at face value someone on another of your 'deadly serious' posts
already was 'silly' enough to actually attempt a serious reply:
http://groups.google.com/group/alt.sci.physics.new-theories/msg/a89bcfca61f557c0
I only hope he did it in full knowledge of what you are - an idiot troll.

Bill
 
P

pete

The following experiment is a demonstration of TIME TRAVEL. When
writing this program, and testing it out I found that sometimes the
program would engage itself in time travel but other times it would
not. After careful testing and reprogramming I have optimized the code
so it should work every time, however I recommend that you leave the
room while it is running and think of something else. It takes about 5
minuets to run so it is better if you don't stare at a blank screen.

Here is how the double clock experiment operates:

The program loops like this:

LOOP

wait

a = a + time

wait

b = b + time

GOTO LOOP

c = time

Then it checks to see if the differance between a and b, is correct
compared to c. In normal physics it should be, but if the program time
travels then the output will be different. To show you what I mean
let me give you an example of the program in operation:

wait 10

a = a + time 10

wait 10

b = b + time 20

wait 10

a = a + time 30

wait 10

b = b + time 40

wait 10

a = a + time 50

wait 10

b = b+ time 60
-

Now A = 90 & B = 120

-imediately check time-

C = time 60

Using logic we can deduce that A should be exactly C / 2 smaller than
B, but when you run the program the time differance can vary
considerably in either direction. On top of that, the time it takes to
run the program is not constant either. What conclusions can we draw
from this?

I'll show you some example output and then give you the source:

Time A: 146124514
Time B: 146270790
Time C: 293157

C / 2 = 146578.5
Actual Difference 145276

Time A was 1302.6 ticks into the future, or maybe time b was 1302.6
ticks into the past.

Here is some more real output:

Time A: 144371012
Time B: 144515341
Time C: 289188
C / 2 = 144594
real difference: 144329

time A was 265 ticks into the future, or time b was 265 ticks into the
past.

I wish I had an atomic clock to experiment with, but here is the
source:

#include <sys/types.h>
#include <time.h>
#include <unistd.h>
#include <stdio.h>
#include <math.h>

int main()
{

clock_t c0, c1, c2; /* clock_t is defined on <time.h> and
<sys/types.h> as int */
long count;

printf ("using UNIX function clock to measure CPU time ... \n");

for (count = 0; count < 1000; count++){

for(int cnt1 =0; cnt1 < 100000; cnt1++){
c1 = clock();
}

c0 = c0 + clock();

c0 has no initial value.
for(int cnt2 =0; cnt2 < 100000; cnt2++){
c1 = clock();
}

c2 = c2 + clock();

c2 has no initial value.
This code is undefined.
This is not a C program.
This is a bunch of gibberish.
 
C

CoreyWhite

comparing me to a flat earther is like comparing you to hitler. By
insulting me instead of looking at the issue you are showing your
disrespect for logic.
 
B

Bill Hobba

comparing me to a flat earther is like comparing you to hitler. By
insulting me instead of looking at the issue you are showing your
disrespect for logic.

Flat earthers can fully logically substantiate their position as well and
you can not prove them wrong. But anyone with an actual brain recognizes it
as unreasonable rubbish. The same with a claim 'The following experiment is
a demonstration of TIME TRAVEL' and the even sillier word salads of your
other posts.

Stating clearly what you are serves two purposes - first it turns the table
on you by providing me with some amusement; the same kind of amusement you
want to get by engaging others in silly semantics. And secondly;
demonstrating to less experienced posters how to deal with your ilk. The
next step after a few posts outlining what is going on I have done is simply
to ignore you until engaging you again takes my fancy. So for now

Bye
Bill
 
A

Aristos

CoreyWhite scripsit:
Because there is no more objective way to measure time
than this, both aproximations are equally accurate. In a subjective
way they are both entirely real since whatever we use to measure time
will not be perfectly accurate.



That is a non sequitur, a logical fallacy. You can't make up accuracy
and precision just because you possess no better tools.

There are plenty of more accurate ways to measure time than your CPU's
clock... the oscillation of atoms, for instance.
 
S

slebetman

The following experiment is a demonstration of TIME TRAVEL. When
writing this program, and testing it out I found that sometimes the
program would engage itself in time travel but other times it would
not. After careful testing and reprogramming I have optimized the code
so it should work every time, however I recommend that you leave the
room while it is running and think of something else. It takes about 5
minuets to run so it is better if you don't stare at a blank screen.

Here is how the double clock experiment operates:

The program loops like this:

LOOP

wait

a = a + time

wait

b = b + time

GOTO LOOP

c = time

Then it checks to see if the differance between a and b, is correct
compared to c. In normal physics it should be, but if the program time
travels then the output will be different. To show you what I mean
let me give you an example of the program in operation:

wait 10

a = a + time 10

wait 10

b = b + time 20

wait 10

a = a + time 30

wait 10

b = b + time 40

wait 10

a = a + time 50

wait 10

b = b+ time 60
-

Now A = 90 & B = 120

-imediately check time-

C = time 60

Using logic we can deduce that A should be exactly C / 2 smaller than
B, but when you run the program the time differance can vary
considerably in either direction. On top of that, the time it takes to
run the program is not constant either. What conclusions can we draw
from this?

I'll show you some example output and then give you the source:

Time A: 146124514
Time B: 146270790
Time C: 293157

C / 2 = 146578.5
Actual Difference 145276

Time A was 1302.6 ticks into the future, or maybe time b was 1302.6
ticks into the past.

Here is some more real output:

Time A: 144371012
Time B: 144515341
Time C: 289188
C / 2 = 144594
real difference: 144329

time A was 265 ticks into the future, or time b was 265 ticks into the
past.

I wish I had an atomic clock to experiment with, but here is the
source:

#include <sys/types.h>
#include <time.h>
#include <unistd.h>
#include <stdio.h>
#include <math.h>

int main()
{

clock_t c0, c1, c2; /* clock_t is defined on <time.h> and
<sys/types.h> as int */
long count;


printf ("using UNIX function clock to measure CPU time ... \n");

for (count = 0; count < 1000; count++){

for(int cnt1 =0; cnt1 < 100000; cnt1++){
c1 = clock();
}

c0 = c0 + clock();

for(int cnt2 =0; cnt2 < 100000; cnt2++){
c1 = clock();
}

c2 = c2 + clock();

}

c1 = clock();



printf ("\tend (CPU); %d\n", (int) c0);
printf ("\tend (CPU2); %d\n", (int) c2);
printf ("\tend (NOW); %d\n", (int) c1);
return 0;

}

The problem is you're running a program that expects perfect
measurement of time on a general purpose OS where time measurement is
only approximate. I ran your code on an embedded platform running a
real-time non-preemptive OS with interrupts turned off but replaced
your clock() with reading from a free running hardware counter (1kHz -
much finer resolution than a typical Unix tick). The result I got is
exactly what you expected:

First run:

end (CPU); 5002992
end (CPU2); 5008000
end (NOW); 10016

Second run:

end (CPU); 5002992
end (CPU2); 5008000
end (NOW); 10016

As you can see, both runs produced identical results. This is because
the system I'm running on is perfectly deterministic - no matter how
many times I run it I will get the same result. Also, you'll notice
that NOW/2 = 5008 which is the exact difference between CPU2 and CPU
times. This is what you get when nothing interferes with your
"experiment" - no interrupts, no task switching etc. which causes time
readings to be approximated. It also helps a little that my CPU is a
simple microcontroller with no pipelining or branch prediction or
out-or-order execution or instruction caching which may cause code to
take different amounts of time to execute depending on the CPU state.
 
R

Richard Bos

The following experiment is a demonstration of TIME TRAVEL. When
writing this program, and testing it out I found that sometimes the
program would engage itself in time travel but other times it would
not.

Your dog is slobbering on the thiotimoline.

Also, you know Sweet Fanny Adams about either programming, physics, or
sanity.

Richard
 
G

Guest

Hi CoreyWhite, Win_XP is running lots of code you don't know about,
see: SysInternals.COM/Utilities/ProcessExplorer.html

....and you yourself introduce lags.

So the tics your code reports is effected by all sorts of mysterious activity.

As I told you before...

How, on God's green earth, could your CPU keep more accurate time
than the Nation_Institute_of_Standards_and_Technology in Colorado ? !

Being Bose-Einstein condensates, the masers they use are _Very_ cold,
and a powerful vacuum and cooling system must be employed.

Remember the SI standard of speed of light is defined for an _Ideal_ vacuum,
and no place in nature actually has, or could ever have, such a vacuum.
It's merely approximated... fudge factors have to be included.
 
H

Hexenmeister

<yawn>
Androcles

| The following experiment is a demonstration of TIME TRAVEL. When
| writing this program, and testing it out I found that sometimes the
| program would engage itself in time travel but other times it would
| not. After careful testing and reprogramming I have optimized the code
| so it should work every time, however I recommend that you leave the
| room while it is running and think of something else. It takes about 5
| minuets to run so it is better if you don't stare at a blank screen.
|
| Here is how the double clock experiment operates:
|
| The program loops like this:
|
| LOOP
|
| wait
|
| a = a + time
|
| wait
|
| b = b + time
|
| GOTO LOOP
|
| c = time
|
| Then it checks to see if the differance between a and b, is correct
| compared to c. In normal physics it should be, but if the program time
| travels then the output will be different. To show you what I mean
| let me give you an example of the program in operation:
|
| wait 10
|
| a = a + time 10
|
| wait 10
|
| b = b + time 20
|
| wait 10
|
| a = a + time 30
|
| wait 10
|
| b = b + time 40
|
| wait 10
|
| a = a + time 50
|
| wait 10
|
| b = b+ time 60
| -
|
| Now A = 90 & B = 120
|
| -imediately check time-
|
| C = time 60
|
| Using logic we can deduce that A should be exactly C / 2 smaller than
| B, but when you run the program the time differance can vary
| considerably in either direction. On top of that, the time it takes to
| run the program is not constant either. What conclusions can we draw
| from this?
|
| I'll show you some example output and then give you the source:
|
| Time A: 146124514
| Time B: 146270790
| Time C: 293157
|
| C / 2 = 146578.5
| Actual Difference 145276
|
| Time A was 1302.6 ticks into the future, or maybe time b was 1302.6
| ticks into the past.
|
| Here is some more real output:
|
| Time A: 144371012
| Time B: 144515341
| Time C: 289188
| C / 2 = 144594
| real difference: 144329
|
| time A was 265 ticks into the future, or time b was 265 ticks into the
| past.
|
| I wish I had an atomic clock to experiment with, but here is the
| source:
|
| #include <sys/types.h>
| #include <time.h>
| #include <unistd.h>
| #include <stdio.h>
| #include <math.h>
|
| int main()
| {
|
| clock_t c0, c1, c2; /* clock_t is defined on <time.h> and
| <sys/types.h> as int */
| long count;
|
|
| printf ("using UNIX function clock to measure CPU time ... \n");
|
| for (count = 0; count < 1000; count++){
|
| for(int cnt1 =0; cnt1 < 100000; cnt1++){
| c1 = clock();
| }
|
| c0 = c0 + clock();
|
| for(int cnt2 =0; cnt2 < 100000; cnt2++){
| c1 = clock();
| }
|
| c2 = c2 + clock();
|
| }
|
| c1 = clock();
|
|
|
| printf ("\tend (CPU); %d\n", (int) c0);
| printf ("\tend (CPU2); %d\n", (int) c2);
| printf ("\tend (NOW); %d\n", (int) c1);
| return 0;
|
| }
|
 
A

AllYou!

So because you think I need medication that makes me wrong?
Why do you even bother posting if you aren't intelligent enough to
offer an opinion about why I am wrong?

He's pandering. He's got some heroes here in this NG, and because
that's their style and he knows your post is the kind of thing THEY
would trash, he tries to beat them to the punch. In doing so, he
hopes to show that he's almost as smart as they are, but in any case,
he hopes it shows that he's one among them.

It's as transparent as it gets, and oh so pathetic.


"Cranks are usually big on using adjectives like 'real' as if it had
some actual meaning."
---Hobba

"SR has nothing to do with 'perception', is has to do with time and
distances as indicated by real apparatus eg rulers and clocks."
---- Hobba
 
G

Greg Neill

comparing me to a flat earther is like comparing you to hitler. By
insulting me instead of looking at the issue you are showing your
disrespect for logic.

Godwin's Law is invoked. Thread is finished.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,770
Messages
2,569,583
Members
45,075
Latest member
MakersCBDBloodSupport

Latest Threads

Top