On 7/20/2024 3:21 AM, Mikko wrote:
On 2024-07-19 14:08:24 +0000, olcott said:
When we use your incorrect reasoning we would conclude
that Infinite_Loop() is not an infinite loop because it
only repeats until aborted and is aborted.
You and your HHH can reason or at least conclude correctly about
Infinite_Loop but not about DDD. Possibly because it prefers to
say "no", which is correct about Infinte_loop but not about DDD.
*Because this is true I don't understand how you are not simply lying*
int main
{
DDD();
}
Calls HHH(DDD) that must abort the emulation of its input
or {HHH, emulated DDD and executed DDD} never stop running.
On 7/21/2024 4:34 AM, Mikko wrote:
On 2024-07-20 13:11:03 +0000, olcott said:
On 7/20/2024 3:21 AM, Mikko wrote:
On 2024-07-19 14:08:24 +0000, olcott said:
When we use your incorrect reasoning we would conclude
that Infinite_Loop() is not an infinite loop because it
only repeats until aborted and is aborted.
You and your HHH can reason or at least conclude correctly about
Infinite_Loop but not about DDD. Possibly because it prefers to
say "no", which is correct about Infinte_loop but not about DDD.
*Because this is true I don't understand how you are not simply lying*
int main
{
DDD();
}
Calls HHH(DDD) that must abort the emulation of its input
or {HHH, emulated DDD and executed DDD} never stop running.
You are the lying one.
If HHH(DDD) abrots its simulation and returns true it is correct as a
halt decider for DDD really halts.
(b) We know that a decider is not allowed to report on the behavior computation that itself is contained within. Deciders only take finite
string inputs. They do not take executing processes as inputs. Thus HHH
is not allowed to report on the behavior of this int main() { DDD(); }.
Even the Linz proof makes this same mistake
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Although embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ cannot possibly correctly report on
its own behavior because its input does the opposite of whatever
it reports embedded_H is only allowed to report on the behavior
that its input specifies.
Turing machines never take actual Turing machines as inputs.
They only take finite strings as inputs and an actual executing
Turing machine is not itself a finite string.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
Since we ourselves can directly see that UTM based embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
must abort the simulation of its input otherwise this input would
never stop running we know that the criteria have been met.
On 7/23/2024 1:32 AM, 0 wrote:
On 2024-07-22 13:46:21 +0000, olcott said:In this case we have two x86utm machines that are identical
On 7/22/2024 2:57 AM, Mikko wrote:
On 2024-07-21 13:34:40 +0000, olcott said:
On 7/21/2024 4:34 AM, Mikko wrote:
On 2024-07-20 13:11:03 +0000, olcott said:
On 7/20/2024 3:21 AM, Mikko wrote:
On 2024-07-19 14:08:24 +0000, olcott said:
When we use your incorrect reasoning we would conclude
that Infinite_Loop() is not an infinite loop because it
only repeats until aborted and is aborted.
You and your HHH can reason or at least conclude correctly about >>>>>>>> Infinite_Loop but not about DDD. Possibly because it prefers to >>>>>>>> say "no", which is correct about Infinte_loop but not about DDD. >>>>>>>>
*Because this is true I don't understand how you are not simply
lying*
int main
{
DDD();
}
Calls HHH(DDD) that must abort the emulation of its input
or {HHH, emulated DDD and executed DDD} never stop running.
You are the lying one.
If HHH(DDD) abrots its simulation and returns true it is correct as a >>>>>> halt decider for DDD really halts.
(b) We know that a decider is not allowed to report on the behavior
computation that itself is contained within.
No, we don't. There is no such prohibition.
Turing machines never take actual Turing machines as inputs.
They only take finite strings as inputs and an actual executing
Turing machine is not itself a finite string.
The definition of a Turing machine does not say that a Turing machine
is not a finite string. It is an abstract mathematical object without
a specification of its exact nature. It could be a set or a finite
string. Its exact nature is not relevant to the theory of computation,
which only cares about certain properties of Turing machines.
Therefore It is not allowed to report on its own behavior.
Anyway, that does not follow. The theory of Turing machines does not
prohibit anything.
Another different TM can take the TM description of this
machine and thus accurately report on its actual behavior.
If a Turing machine can take a description of a TM as its input
or as a part of its input it can also take its own description.
Every Turing machine can be given its own description as input
but a Turing machine may interprete it as something else.
except that DDD calls HHH and DDD does not call HHH1.
It is empirically proven that this changes their behavior
and the behavior of DDD.
On 7/24/2024 10:29 PM, Mike Terry wrote:
On 23/07/2024 14:31, olcott wrote:
On 7/23/2024 1:32 AM, 0 wrote:
On 2024-07-22 13:46:21 +0000, olcott said:In this case we have two x86utm machines that are identical
On 7/22/2024 2:57 AM, Mikko wrote:
On 2024-07-21 13:34:40 +0000, olcott said:
On 7/21/2024 4:34 AM, Mikko wrote:
On 2024-07-20 13:11:03 +0000, olcott said:
On 7/20/2024 3:21 AM, Mikko wrote:
On 2024-07-19 14:08:24 +0000, olcott said:
When we use your incorrect reasoning we would conclude
that Infinite_Loop() is not an infinite loop because it
only repeats until aborted and is aborted.
You and your HHH can reason or at least conclude correctly about >>>>>>>>>> Infinite_Loop but not about DDD. Possibly because it prefers to >>>>>>>>>> say "no", which is correct about Infinte_loop but not about DDD. >>>>>>>>>>
*Because this is true I don't understand how you are not simply >>>>>>>>> lying*
int main
{
DDD();
}
Calls HHH(DDD) that must abort the emulation of its input
or {HHH, emulated DDD and executed DDD} never stop running.
You are the lying one.
If HHH(DDD) abrots its simulation and returns true it is correct >>>>>>>> as a
halt decider for DDD really halts.
(b) We know that a decider is not allowed to report on the behavior >>>>>>> computation that itself is contained within.
No, we don't. There is no such prohibition.
Turing machines never take actual Turing machines as inputs.
They only take finite strings as inputs and an actual executing
Turing machine is not itself a finite string.
The definition of a Turing machine does not say that a Turing machine
is not a finite string. It is an abstract mathematical object without
a specification of its exact nature. It could be a set or a finite
string. Its exact nature is not relevant to the theory of computation, >>>> which only cares about certain properties of Turing machines.
Therefore It is not allowed to report on its own behavior.
Anyway, that does not follow. The theory of Turing machines does not
prohibit anything.
Another different TM can take the TM description of this
machine and thus accurately report on its actual behavior.
If a Turing machine can take a description of a TM as its input
or as a part of its input it can also take its own description.
Every Turing machine can be given its own description as input
but a Turing machine may interprete it as something else.
except that DDD calls HHH and DDD does not call HHH1.
It is empirically proven that this changes their behavior
and the behavior of DDD.
You say a lot about things that are "empirically proven" and without
exception they are never "proven" at all.
It is empirically proven according to the semantics of the
x86 machine code of DDD that DDD correctly emulated by HHH
has different behavior than DDD correctly emulated by HHH1.
_DDD()
[00002177] 55 push ebp
[00002178] 8bec mov ebp,esp
[0000217a] 6877210000 push 00002177
[0000217f] e853f4ffff call 000015d7
[00002184] 83c404 add esp,+04
[00002187] 5d pop ebp
[00002188] c3 ret
Size in bytes:(0018) [00002188]
_main()
[00002197] 55 push ebp
[00002198] 8bec mov ebp,esp
[0000219a] 6877210000 push 00002177
[0000219f] e863f3ffff call 00001507
[000021a4] 83c404 add esp,+04
[000021a7] 33c0 xor eax,eax
[000021a9] 5d pop ebp
[000021aa] c3 ret
Size in bytes:(0020) [000021aa]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= [00002197][001037fb][00000000] 55 push ebp [00002198][001037fb][00000000] 8bec mov ebp,esp [0000219a][001037f7][00002177] 6877210000 push 00002177 ; push DDD [0000219f][001037f3][000021a4] e863f3ffff call 00001507 ; call HHH1
New slave_stack at:10389f
Begin Local Halt Decider Simulation Execution Trace Stored at:1138a7 [00002177][00113897][0011389b] 55 push ebp [00002178][00113897][0011389b] 8bec mov ebp,esp [0000217a][00113893][00002177] 6877210000 push 00002177 ; push DDD [0000217f][0011388f][00002184] e853f4ffff call 000015d7 ; call HHH
New slave_stack at:14e2c7
Begin Local Halt Decider Simulation Execution Trace Stored at:15e2cf [00002177][0015e2bf][0015e2c3] 55 push ebp [00002178][0015e2bf][0015e2c3] 8bec mov ebp,esp [0000217a][0015e2bb][00002177] 6877210000 push 00002177 ; push DDD [0000217f][0015e2b7][00002184] e853f4ffff call 000015d7 ; call HHH
New slave_stack at:198cef
[00002177][001a8ce7][001a8ceb] 55 push ebp [00002178][001a8ce7][001a8ceb] 8bec mov ebp,esp [0000217a][001a8ce3][00002177] 6877210000 push 00002177 ; push DDD [0000217f][001a8cdf][00002184] e853f4ffff call 000015d7 ; call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[00002184][00113897][0011389b] 83c404 add esp,+04 [00002187][0011389b][000015bc] 5d pop ebp [00002188][0011389f][0003a980] c3 ret [000021a4][001037fb][00000000] 83c404 add esp,+04 [000021a7][001037fb][00000000] 33c0 xor eax,eax [000021a9][001037ff][00000018] 5d pop ebp [000021aa][00103803][00000000] c3 ret
Number of Instructions Executed(352831) == 5266 Pages
You previously claimed that H and H1 behaviours were different as
evidence that "copies of routines" don't necessarily produce the same
behaviour as the original routine, due to magical pathelogical
relationships. But if the copies are done properly of course they
will produce the same behaviour, because the x86 language is
deterministic. I'm assuming you're not just cheating and using the
mutable global data trick! or similar...
If you care study the code that I just provided
(and don't just ignore this and assume that I must be wrong)
you can see that when DDD is correctly emulated by HHH that
DDD does correctly have different behavior than DDD correctly
emulated by HHH1.
You could have seen this three years ago yet everyone simply
assumes that I must be wrong thus makes sure to ignore the
verified facts that N steps of DDD are correctly emulated by
HHH and M steps of DDD are correctly emulated by HHH1.
They guess that these steps are wrong entirely on the basis
of not bothering to check.
So what had you messed up with H/H1? H and H1 internally both used
their /own/ addresses for comparisons with simulated code addresses. So
They do not do this. When HHH emulates itself emulating DDD is has no
idea that it is emulating itself. Likewise for when HHH1 emulates DDD
calling HHH(DDD) it does not know that it is not emulating itself.
they are not copies of each other - if they were, H1 would have used
H's address (effectively this address is like a const global variable,
and
That is the same as saying the identical twins have the exact same body
not two different bodies in two different locations.
HHH1 and HHH are essentially identical and the only reason why
DDD correctly emulated by HHH has different behavior than DDD
correctly emulated by HHH1 is that DDD does call HHH in recursive
emulation and DDD does not call HHH1 in recursive emulation.
Trying to get away with saying that an identical copy of a function
must be at the same address is just like saying that identical
twin people must have the exact same body not two different bodies.
both H/H1 need to use the same one if they are claimed to use the same
algorithm).
You are trying to get away with saying that these
two do not implement the same algorithm:
int sum(int x, int y){ return x + y; }
int compute_sum(int x, int y){ return x + y; }
If you had implemented the copy correctly, BOTH H AND H1 WOULD
CALCULATE THE SAME BEHAVIOUR for (D,D) input (or any other input). So
this turned
When DDD calls HHH in recursive emulation
(as I have proven that it does**) and DDD does not call HHH1
in recursive simulation (as I have proven that it does not**)
then DDD will have different behavior.
**According to the semantics of the x86 machine code
provided above.
out to be just a case of naff programming on your part - nothing
"magical" about pathelogical relationships between H/D which aren't
present for H1/D; just naff coding. [H1 using a different algorithm
meant it never matched H's abort decision, so effectively reverted to
UTM behaviour that simulated (D,D) to completion, including the final
return.]
Both HHH and HHH1 use the same algorithm. The input to HHH(DDD)
must be aborted to prevent the non-halting behavior of HHH, and DDD.
The input to HHH1(DDD) need not be aborted because the input to
HHH(DDD) already has been aborted.
The DDD of HHH(DDD) is in the different process state of needing
to be aborted than the DDD of HHH1(DDD) of *not* needing to be
aborted.
DDD needing to be aborted before any DDD has been aborted is
like being hungry before one has eaten.
DDD not needing to be aborted after some DDD has been aborted
is like *not* being hungry after one has eaten.
Now you're claiming the same for HHH/HHH1 ? What duffer coding errors
have you made this time?
That you said that a copy of a function must be at the same
physical machine address is as stupidly wrong as saying that
identical twins must have the exact same physical body.
It looks like you are now no better than the rest and happy
to say stupidly wrong things as long as they can keep you
in rebuttal mode.
Seriously - if the code of HHH and HHH1 is supposedly the same (and no
cheap cheats such as mutable global/static cheats, and so on) THEN WHY
WOULD THE BEHAVIOUR OF HHH and HHH1 differ when evaluating an input?
*What have you messed up this time?*
I don't believe that someone of your intelligence and knowledge
could possibly actually fail to understand that the behavior of
function DDD emulated by a function that it calls in recursive
emulation would not be different than the behavior of this same
function DDD emulated by a function that it does not call in
recursive emulation.
Like everyone else you are trying to get away with disagreeing
with the semantics of the x86 code that I provided.
Instead of carefully studying this code to see that it does
correctly do exactly what I say that it does you assume that
there is something hidden that changes the behavior, even
though the behavior is verifiably never changed.
It's your code so you should be the one to explain anomalies like this
at the coding level. Why /exactly/ does HHH1 produce a different
result to HHH?
Why does finite recursion halt and infinite recursion not halt?
HHH does see recursive emulation that will never stop unless aborted.
HHH1 does not see this. If the reason that you don't see this is that
you simply don't understand the x86 language well enough then say that
you lack sufficient x86 skills instead of denigrating my work on the
basis of your own ignorance.
Also you might state more clearly what the different behaviour is,
e.g. "HHH reports DDD() never halts, while HHH1 reports that it halts"
or whatever.
HHH does see recursive emulation that will never stop unless aborted.
HHH1 does not see this, because HHH has already aborted its DDD. When
any one call of infinite recursion has been aborted then it is infinite recursion that abnormally terminates.
When your program gets stuck in an infinite loop and you yank the power
cord from the wall it is incorrect to say that the infinite loop halted.
Regards,
Mike.
On 7/25/2024 4:03 PM, Mike Terry wrote:
On 25/07/2024 14:56, olcott wrote:
On 7/24/2024 10:29 PM, Mike Terry wrote:
On 23/07/2024 14:31, olcott wrote:
On 7/23/2024 1:32 AM, 0 wrote:
On 2024-07-22 13:46:21 +0000, olcott said:In this case we have two x86utm machines that are identical
On 7/22/2024 2:57 AM, Mikko wrote:
On 2024-07-21 13:34:40 +0000, olcott said:
On 7/21/2024 4:34 AM, Mikko wrote:
On 2024-07-20 13:11:03 +0000, olcott said:
On 7/20/2024 3:21 AM, Mikko wrote:You are the lying one.
On 2024-07-19 14:08:24 +0000, olcott said:
When we use your incorrect reasoning we would conclude >>>>>>>>>>>>> that Infinite_Loop() is not an infinite loop because it >>>>>>>>>>>>> only repeats until aborted and is aborted.
You and your HHH can reason or at least conclude correctly >>>>>>>>>>>> about
Infinite_Loop but not about DDD. Possibly because it prefers to >>>>>>>>>>>> say "no", which is correct about Infinte_loop but not about >>>>>>>>>>>> DDD.
*Because this is true I don't understand how you are not >>>>>>>>>>> simply lying*
int main
{
DDD();
}
Calls HHH(DDD) that must abort the emulation of its input >>>>>>>>>>> or {HHH, emulated DDD and executed DDD} never stop running. >>>>>>>>>>
If HHH(DDD) abrots its simulation and returns true it is
correct as a
halt decider for DDD really halts.
(b) We know that a decider is not allowed to report on the
behavior
computation that itself is contained within.
No, we don't. There is no such prohibition.
Turing machines never take actual Turing machines as inputs.
They only take finite strings as inputs and an actual executing
Turing machine is not itself a finite string.
The definition of a Turing machine does not say that a Turing machine >>>>>> is not a finite string. It is an abstract mathematical object without >>>>>> a specification of its exact nature. It could be a set or a finite >>>>>> string. Its exact nature is not relevant to the theory of
computation,
which only cares about certain properties of Turing machines.
Therefore It is not allowed to report on its own behavior.
Anyway, that does not follow. The theory of Turing machines does not >>>>>> prohibit anything.
Another different TM can take the TM description of this
machine and thus accurately report on its actual behavior.
If a Turing machine can take a description of a TM as its input
or as a part of its input it can also take its own description.
Every Turing machine can be given its own description as input
but a Turing machine may interprete it as something else.
except that DDD calls HHH and DDD does not call HHH1.
It is empirically proven that this changes their behavior
and the behavior of DDD.
You say a lot about things that are "empirically proven" and without
exception they are never "proven" at all.
It is empirically proven according to the semantics of the
x86 machine code of DDD that DDD correctly emulated by HHH
has different behavior than DDD correctly emulated by HHH1.
Perhaps your actual code does behave differently!
OK great, we are making headway.
The questions are:
a) are HHH and HHH1 "identical copies", in the TM machine sense of
incorporating
the algorithm of one TM inside another TM? (As Linz incorporates H
inside H^, meaning that the behaviours of H and embedded_H MUST
be identical for any
input.)
[You claim HHH and HHH1 /are/ proper copies, and yet give
different results for
input (D), which is impossible.]
They are identical in the that have identical x86 machine
code except for the x86 quirk that function calls are to
a relative rather than absolute address. So when HHH calls
the same function that HHH1 calls the machine code is not
the same. The only other case where the machine code of
HHH1 and HHH is not identical is the way for slave instances
of HHH to pass its execution trace up to the master.
Although it seems that I have been correct all along about the
idea that slave instances can pass their execution trace up to
the master without breaking computability this is not the way
it has been actually encoded.
Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk>
On 3/1/2024 12:41 PM, Mike Terry wrote:
Obviously a simulator has access to the internal state
(tape contents etc.) of the simulated machine. No problem there.
b) If the two behaviours HHH/HHH1 are indeed different, WHAT
precisely is the coding
difference that accounts for that different behaviour? (Like,
with your H/H1 the
difference was that H used H's address as part of its algorithm,
while H1 used H1's
address.)
*I have said this about 500 times in the last three years*
DDD calls HHH(DDD) in recursive simulation and does
not call HHH1(DDD) in recursive simulation.
_DDD()
[00002177] 55 push ebp
[00002178] 8bec mov ebp,esp
[0000217a] 6877210000 push 00002177
[0000217f] e853f4ffff call 000015d7
[00002184] 83c404 add esp,+04
[00002187] 5d pop ebp
[00002188] c3 ret
Size in bytes:(0018) [00002188]
_main()
[00002197] 55 push ebp
[00002198] 8bec mov ebp,esp
[0000219a] 6877210000 push 00002177
[0000219f] e863f3ffff call 00001507
[000021a4] 83c404 add esp,+04
[000021a7] 33c0 xor eax,eax
[000021a9] 5d pop ebp
[000021aa] c3 ret
Size in bytes:(0020) [000021aa]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00002197][001037fb][00000000] 55 push ebp
[00002198][001037fb][00000000] 8bec mov ebp,esp
[0000219a][001037f7][00002177] 6877210000 push 00002177 ; push DDD
[0000219f][001037f3][000021a4] e863f3ffff call 00001507 ; call HHH1
New slave_stack at:10389f
Begin Local Halt Decider Simulation Execution Trace Stored at:1138a7 >>> [00002177][00113897][0011389b] 55 push ebp
[00002178][00113897][0011389b] 8bec mov ebp,esp
[0000217a][00113893][00002177] 6877210000 push 00002177 ; push DDD
[0000217f][0011388f][00002184] e853f4ffff call 000015d7 ; call HHH
New slave_stack at:14e2c7
Begin Local Halt Decider Simulation Execution Trace Stored at:15e2cf >>> [00002177][0015e2bf][0015e2c3] 55 push ebp
[00002178][0015e2bf][0015e2c3] 8bec mov ebp,esp
[0000217a][0015e2bb][00002177] 6877210000 push 00002177 ; push DDD
[0000217f][0015e2b7][00002184] e853f4ffff call 000015d7 ; call HHH
New slave_stack at:198cef
[00002177][001a8ce7][001a8ceb] 55 push ebp
[00002178][001a8ce7][001a8ceb] 8bec mov ebp,esp
[0000217a][001a8ce3][00002177] 6877210000 push 00002177 ; push DDD
[0000217f][001a8cdf][00002184] e853f4ffff call 000015d7 ; call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[00002184][00113897][0011389b] 83c404 add esp,+04
[00002187][0011389b][000015bc] 5d pop ebp
[00002188][0011389f][0003a980] c3 ret
[000021a4][001037fb][00000000] 83c404 add esp,+04
[000021a7][001037fb][00000000] 33c0 xor eax,eax
[000021a9][001037ff][00000018] 5d pop ebp
[000021aa][00103803][00000000] c3 ret
Number of Instructions Executed(352831) == 5266 Pages
that seems to be a (partial) trace of HHH1(D). It's not clear exactly
what's happening - for example, who produces the message "Local Halt
Decider: Infinite Recursion Detected Simulation Stopped"? It might be
outer HHH1 or one of the inner HHH's. And what result did HHH1 report?
It is supposed to be the outer most (thus directly executed) HHH.
And more to the point what did HHH(D) do, and what is the difference?
*I have said this about 500 times in the last three years*
DDD calls HHH(DDD) in recursive simulation and does
not call HHH1(DDD) in recursive simulation.
When a function unconditionally calls itself this is infinite
recursion.
When a function unconditionally calls its own simulator this is
infinite recursive simulation. HHH sees this as infinite recursion
because HHH does not know that DDD is calling itself.
AND WHAT CODING within HHH/HHH1 ACCOUNTS FOR THAT DIFFERENCE?
You previously claimed that H and H1 behaviours were different as
evidence that "copies of routines" don't necessarily produce the
same behaviour as the original routine, due to magical pathelogical
relationships. But if the copies are done properly of course they
will produce the same behaviour, because the x86 language is
deterministic. I'm assuming you're not just cheating and using the
mutable global data trick! or similar...
If you care study the code that I just provided
(and don't just ignore this and assume that I must be wrong)
you can see that when DDD is correctly emulated by HHH that
DDD does correctly have different behavior than DDD correctly
emulated by HHH1.
All I see above is a partial trace of HHH1(DDD). No behaviour is
traced for HHH1, and there is no comparison with HHH(DDD).
If you simply freaking assume that both HHH and HHH1 are x86
emulators you don't really need to know one damn thing else
to know the key essence of what HHH and HHH1 does.
Suggestion: make a post starting afresh with both traces, and a
statement of how the behaviours differ,
If you can't read annotated x86 code then you will never get it.
If can then you should have already gotten it three years ago yet
simply did not bother to pay attention.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 493 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 170:33:32 |
| Calls: | 9,704 |
| Calls today: | 4 |
| Files: | 13,736 |
| Messages: | 6,178,354 |