# REPRESENTING BINARY NUMBERS NATURALLY.

What is the Problem?
-------------------
In Computer Science, we have various ways to represent numbers.

However,we have to choose the best way to represent numbers.This is especially true in strongly typed high level abstract languages like C/C++/Java etc.Futhermore, computer sciencient developed a binary number system called two complement;it is used to perform arthematic on binary numbers which can be transferred to other systems.This include decimal(base 10), hexadecimal(base 16), octal(base 8) etc.Two complement enables us to represent negative numbers with a signifance of the right most bit being a 1.

Is there a data structure and algorithm extension of two complement that handle overflow in such way that is indiscremnint of the type of data(binary number type) provided not occupy memory thier should not?

For example,and 8 ,and 16 bit can be stored together under one class(blueprint for an object) and support the performing of operations that will not result any overflow. The importance of this data structure is that binary number should apper naturally looking and be more effient as if their were represented as regular numbers , not taking memory their should not occupy.

Sorry, guy, but comp.lang.c is not the place to discuss this
sort of thing. Why don't you try comp.theory ?

(Followups set to comp.theory)

On Mon, 26 Sep 2022 04:31:32 -0700, Prometheus wrote:

> # REPRESENTING BINARY NUMBERS NATURALLY.
>
> What is the Problem?
> -------------------
> In Computer Science, we have various ways to represent numbers.
>
> However,we have to choose the best way to represent numbers.This is
> especially true in strongly typed high level abstract languages like
> C/C++/Java etc.Futhermore, computer sciencient developed a binary number
> system called two complement;it is used to perform arthematic on binary
> numbers which can be transferred to other systems.This include
> decimal(base 10), hexadecimal(base 16), octal(base 8) etc.Two complement
> enables us to represent negative numbers with a signifance of the right
> most bit being a 1.
>
> Is there a data structure and algorithm extension of two complement that
> handle overflow in such way that is indiscremnint of the type of
> data(binary number type) provided not occupy memory thier should not?
>
> For example,and 8 ,and 16 bit can be stored together under one
> class(blueprint for an object) and support the performing of operations
> that will not result any overflow. The importance of this data structure
> is that binary number should apper naturally looking and be more effient
> as if their were represented as regular numbers , not taking memory
> their should not occupy.

--
Lew Pitcher
"In Skills, We Trust"

On 26/09/2022 12:31, Prometheus wrote:
> # REPRESENTING BINARY NUMBERS NATURALLY.
>
> What is the Problem?
> -------------------
> In Computer Science, we have various ways to represent numbers.
>
> However,we have to choose the best way to represent numbers.This is especially true in strongly typed high level abstract languages like C/C++/Java etc.Futhermore, computer sciencient developed a binary number system called two complement;it is used to perform arthematic on binary numbers which can be transferred to other systems.This include decimal(base 10), hexadecimal(base 16), octal(base 8) etc.Two complement enables us to represent negative numbers with a signifance of the right most bit being a 1.
>
> Is there a data structure and algorithm extension of two complement that handle overflow in such way that is indiscremnint of the type of data(binary number type) provided not occupy memory thier should not?
>
> For example,and 8 ,and 16 bit can be stored together under one class(blueprint for an object) and support the performing of operations that will not result any overflow. The importance of this data structure is that binary number should apper naturally looking and be more effient as if their were represented as regular numbers , not taking memory their should not occupy.

8-bit and 16-bit integers will usually occupy one byte and two bytes
respectively. They're not going to use any more memory than that, on any
sane byte-addressed machine, which is nearly all of them these days.

Overflow (both signed and unsigned) can be usually detected by processor
flags, but this is up to the language to take care of.

In C, unsigned overflow is legal behaviour, and signed overflow is
undefined.

For anything different, you need to program it yourself. Or some C
compilers have options to detect and trap signed overflow.

Do you have a particular problem to solve, or are writing an article
about the subject, or just quoting one?

On 9/27/2022 6:00 AM, Richard Damon wrote:
> On 9/26/22 11:49 PM, olcott wrote:
>> On 9/26/2022 10:29 PM, Richard Damon wrote:
>>> On 9/26/22 11:04 PM, olcott wrote:
>>>> On 9/26/2022 9:58 PM, Richard Damon wrote:
>>>>>
>>>>> On 9/26/22 10:41 PM, olcott wrote:
>>>>>> On 9/26/2022 9:23 PM, Richard Damon wrote:
>>>>>>> On 9/26/22 10:18 PM, olcott wrote:
>>>>>>>> On 9/26/2022 8:49 PM, Richard Damon wrote:
>>>>>>>>> On 9/26/22 9:26 PM, olcott wrote:
>>>>>>>>>> On 9/26/2022 8:15 PM, Richard Damon wrote:
>>>>>>>>>>> On 9/26/22 8:58 PM, olcott wrote:
>>>>>>>>>>>> On 9/26/2022 7:36 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 9/26/22 8:25 PM, olcott wrote:
>>>>>>>>>>>>>> On 9/26/2022 6:59 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 9/26/22 7:46 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 9/26/2022 6:12 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 9/26/22 2:03 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 9/26/2022 12:48 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>> On Mon, 26 Sep 2022 12:42:02 -0500
>>>>>>>>>>>>>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 9/26/2022 12:19 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>> On Mon, 26 Sep 2022 12:15:15 -0500
>>>>>>>>>>>>>>>>>>>>> olcott <none-ya@beez-waxes.com> wrote:
>>>>>>>>>>>>>>>>>>>>>> On 9/26/2022 11:05 AM, Kaz Kylheku wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 2022-09-26, Lew Pitcher
>>>>>>>>>>>>>>>>>>>>>>> <lew.pitcher@digitalfreehold.ca>
>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Sorry, guy, but comp.lang.c is not the place to
>>>>>>>>>>>>>>>>>>>>>>>> discuss this
>>>>>>>>>>>>>>>>>>>>>>>> sort of thing. Why don't you try comp.theory ?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Because Olcott postings will push you out of
>>>>>>>>>>>>>>>>>>>>>>> visibility?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> If people would give me a fair and honest review I
>>>>>>>>>>>>>>>>>>>>>> could quit
>>>>>>>>>>>>>>>>>>>>>> posting. You gave up on me before I could point
>>>>>>>>>>>>>>>>>>>>>> out the error with
>>>>>>>>>>>>>>>>>>>>>> the diagonalization argument that you relied on
>>>>>>>>>>>>>>>>>>>>>> for your rebuttal:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The diagonalization argument merely proves that no
>>>>>>>>>>>>>>>>>>>>>> value returned
>>>>>>>>>>>>>>>>>>>>>> to P from its call to H can possibly be correct.
>>>>>>>>>>>>>>>>>>>>>> This argument
>>>>>>>>>>>>>>>>>>>>>> totally ignores that the return value from H is
>>>>>>>>>>>>>>>>>>>>>> unreachable by its
>>>>>>>>>>>>>>>>>>>>>> simulated P caller when H is based on a simulating
>>>>>>>>>>>>>>>>>>>>>> halt decider.
>>>>>>>>>>>>>>>>>>>>>> This makes it impossible for P to do the opposite
>>>>>>>>>>>>>>>>>>>>>> of whatever H
>>>>>>>>>>>>>>>>>>>>>> decides.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Complete halt deciding system (Visual Studio Project)
>>>>>>>>>>>>>>>>>>>>>> (a) x86utm operating system
>>>>>>>>>>>>>>>>>>>>>> (b) complete x86 emulator
>>>>>>>>>>>>>>>>>>>>>> (c) Several halt deciders and their inputs
>>>>>>>>>>>>>>>>>>>>>> contained within Halt7.c
>>>>>>>>>>>>>>>>>>>>>> https://liarparadox.org/2022_09_07.zip
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> You keep making the same mistake again and again. H
>>>>>>>>>>>>>>>>>>>>> IS NOT SUPPOSED
>>>>>>>>>>>>>>>>>>>>> TO BE RECURSIVE.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> H(P,P) is not recursive.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Your H is recursive because P isn't recursive and yet
>>>>>>>>>>>>>>>>>>> you have to abort
>>>>>>>>>>>>>>>>>>> your infinite recursion: the recursion is caused by
>>>>>>>>>>>>>>>>>>> your H and not by
>>>>>>>>>>>>>>>>>>> P.  Nowhere in any halting problem proof does it
>>>>>>>>>>>>>>>>>>> state that the call to
>>>>>>>>>>>>>>>>>>> H by P is recursive in nature BECAUSE H IS NOT
>>>>>>>>>>>>>>>>>>> SUPPOSED TO EXECUTE P, H
>>>>>>>>>>>>>>>>>>> IS SUPPOSED TO *ANALYSE* P.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Nowhere in any HP proof (besides mine) is the idea of
>>>>>>>>>>>>>>>>>> a simulating halt decider (SHD) ever thought all the
>>>>>>>>>>>>>>>>>> way through.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Because the proof doesn't care at all how the decider
>>>>>>>>>>>>>>>>> got the answer,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Because the definition of a UTM specifies that the
>>>>>>>>>>>>>>>>>> correct simulation of a machine description provides
>>>>>>>>>>>>>>>>>> the actual behavior of the underlying machine whenever
>>>>>>>>>>>>>>>>>> any simulating halt decider must abort its simulation
>>>>>>>>>>>>>>>>>> to prevent infinite simulation it is necessarily
>>>>>>>>>>>>>>>>>> correct to report that this input does not halt.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Right, which means it CAN'T be a UTM, and thus *ITS*
>>>>>>>>>>>>>>>>> simulation does not define the "behavior of the input".
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The behavior of the correct simulation of the input is
>>>>>>>>>>>>>>>> its actual behavior. That H correctly predicts that its
>>>>>>>>>>>>>>>> correct simulation never stops running unless aborted
>>>>>>>>>>>>>>>> conclusively proves that this correctly simulated input
>>>>>>>>>>>>>>>> would never reach its own final state in 1 to ∞ steps of
>>>>>>>>>>>>>>>> correct simulation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But the behavior the halting problem is asking for is the
>>>>>>>>>>>>>>> behavior of the actual machine.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Only within the context that no one ever bothered to think
>>>>>>>>>>>>>> the application of a simulating halt decider all the way
>>>>>>>>>>>>>> through.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, the DEFINITION of a Halt Decider is to decide on the
>>>>>>>>>>>>> behavior of the Actual Machine.
>>>>>>>>>>>>>
>>>>>>>>>>>> That definition is made obsolete by a simulating halt decider.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Nope, the definition IS the definition.
>>>>>>>>>>>
>>>>>>>>>>> You don't get to change it.
>>>>>>>>>>>
>>>>>>>>>> I created a new concept that makes earlier ideas about this
>>>>>>>>>> obsolete:
>>>>>>>>>>
>>>>>>>>>> Because the definition of a UTM specifies that the correct
>>>>>>>>>> simulation of a machine description provides the actual
>>>>>>>>>> behavior of the underlying machine whenever any simulating
>>>>>>>>>> halt decider must abort its simulation to prevent infinite
>>>>>>>>>> simulation it is necessarily correct to report that this input
>>>>>>>>>> does not halt.
>>>>>>>>>>
>>>>>>>>>> Because the above is verified as correct on the basis of the
>>>>>>>>>> meaning of its words it is irrefutable.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Right, but H isn't a UTM, so its simulation doesn't matter.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Unless you can specify that material difference between the two,
>>>>>>>> that would seem to prove that you are technically incompetent.
>>>>>>>
>>>>>>> H doesn't correctly repoduce the behavior of a non-halting input.
>>>>>>>
>>>>>>> Thus, it isn't a UTM.
>>>>>>>
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>
>>>>>> When Ĥ is applied to ⟨Ĥ⟩      // subscripts indicate unique finite
>>>>>> strings
>>>>>> Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>
>>>>>> Then these steps would keep repeating: (unless their simulation is
>>>>>> aborted)
>>>>>
>>>>> Note, you say "unless their simulation is aborted" but your
>>>>> defiition of H DOES abort its simulation, thus this doesn't occur.
>>>>>
>>>>> FAIL.
>>>>>
>>>>>> Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>> Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>> Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then H2 simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>
>>>>>> This exact same behavior occurs when we replace H with a UTM.
>>>>>>
>>>>>
>>>>> But since H ISN'T a UTM, you can't assume that it is.
>>>>>
>>>>
>>>> H is designed to predict the result of 1 to ∞ correctly simulated
>>>> steps, thus predict the behavior of a UTM simulation.
>>>>
>>> Except it doesn't do that.
>>>
>> H does correctly predict the actual behavior of 1 to ∞ simulated steps
>> of P.
>>
>
> Nope, since we have shown that if H(P,P) returns 0, then P(P) will Halt.
>