- Are there any asm-instructions to support OOP - 6 Updates
- Transforming "C" into a Turing equivalent language 001 [Providing unlimited memory access to C] - 5 Updates
- Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (Machine equivalence) - 1 Update
- Preprocessor output into Class processor - 2 Updates
| boltar@nuttyella.co.uk: Aug 30 04:04PM On Sat, 29 Aug 2020 18:48:53 +0000 (UTC) >Suppose you only show every 24th frame of the movie at 1-second intervals. >Which means the movie is now 1 Hz. Rather obviously you will see huge >jumps every second, when the camera pans horizontally. Thats not the kind of jerkiness I was talking about which if you had half a working braincell you'd have understood. When an HD video codec can't keep up with movement, particularly panning, you often see very noticable jerking that is unconnected to and much lower than the framerate. Presumably its playing catchup everytime a full frame is sent in the stream rather than a difference frame. |
| Stephen Fuld <sfuld@alumni.cmu.edu.invalid>: Aug 30 09:56AM -0700 On 8/29/2020 10:31 AM, David Brown wrote: > I have only heard of this in America, where large bundles of cash > apparently don't cause the same concern to the authorities as they would > in many places in Europe. I did a little searching research. No, the authorities in America do care, but there is apparently a loop hole. https://money.usnews.com/banking/articles/if-you-deposit-a-lot-of-cash-does-your-bank-report-it-to-the-government If an individual deposits $10,000 or more, or even makes a series of deposits totaling that much during a reasonable amount of time, the bank does report it to the IRS (part of the US Treasury Department). This even applies to things like money orders, etc. But the "loop hole" is that this isn't done for business. The reason for that is to not cause problems for those small businesses such as food trucks, small restaurants, barber shops, hair and nail salons, etc. that routinely accept cash for small retail services, and might easily want to deposit that much cash over a modest amount of time. In those cases, the business itself is required by law to report the deposits. The problem occurs, of course, if the business breaks the law and doesn't report it. And a "business", whose real purpose is breaking the law anyway, wouldn't care about breaking another one. :-( I suppose there are ways to fix this, but apparently none have been tried, or if tried haven't worked. :-( > the USA - who are legally entitled to pay by cash if they want. When > the shop buys cables from the manufacturer in Mexico, it can use normal > international bank transfers, because all the money is now "clean". Yes, I get all that. I'm sorry if I messed up the terminology in previous posts and caused confusion. -- - Stephen Fuld (e-mail address disguised to prevent spam) |
| Juha Nieminen <nospam@thanks.invalid>: Aug 30 05:11PM > Thats not the kind of jerkiness I was talking about which if you had half > a working braincell you'd have understood. Notice how you are the only one here throwing insults at people. I wonder why that is. |
| "Öö Tiib" <ootiib@hot.ee>: Aug 30 11:01AM -0700 On Sunday, 30 August 2020 20:11:21 UTC+3, Juha Nieminen wrote: > > a working braincell you'd have understood. > Notice how you are the only one here throwing insults at people. > I wonder why that is. People who try to pointlessly insult or belittle others do it usually because of inferiority complex and a lack of self-respect. |
| David Brown <david.brown@hesbynett.no>: Aug 30 10:03PM +0200 On 30/08/2020 18:56, Stephen Fuld wrote: > law anyway, wouldn't care about breaking another one. :-( > I suppose there are ways to fix this, but apparently none have been > tried, or if tried haven't worked. :-( Generally with loopholes there is always someone interested in having the loopholes remain. (Although I suppose the old maxim about "never attribute to malice that which can equally well be explained by incompetence" might also apply.) >> international bank transfers, because all the money is now "clean". > Yes, I get all that. I'm sorry if I messed up the terminology in > previous posts and caused confusion. No problem. I think it's fair to say (or at least hope) that this is not a topic many of us here (me included) know much about, or need to know much about. |
| Stefan Monnier <monnier@iro.umontreal.ca>: Aug 30 05:44PM -0400 > Given the human eye generally only notices flicker below about 30hz any > greater refresh rate is simply game developer willy waving. That reminds me of the "vision boosters": that's how we used to call some popular hazelnut cookies (https://produits.migros.ch/batons-aux-noisettes) back in my undergrad computer lab, because they made you "see faster". More specifically, being pretty hard cookies, when you ate them while staring at the (CRT) screen of our beloved DEC Alpha workstations you'd notice the "tearing" of the 60Hz (or was it 70Hz?) redraw. Stefan |
| olcott <NoOne@NoWhere.com>: Aug 30 01:55PM -0500 The end goal of this sequence of posts is to show that the basic "C" programming language (without the "C" libraries) can be fully mapped to an abstract model of computation that is equivalent to a Turing machine in such a way that any Turing complete computation can be written in the "C" programming language. When "C" is mapped to an abstract model of computation that can provide an arbitrary number of arbitrary length linked lists, then "C" acquires Turing complete memory access. This is computationally the same as providing "C" with an unlimited number of Turing machine tapes. When we define this abstract memory access such that it can be concretely implemented on machines with finite memory and this concrete implementation automatically scales to any increase in physical memory then the memory access aspect of the concrete implementation is computationally identical to the abstract Turing complete machine. Such a virtual machine would provide Turing complete memory access to "C" because the memory access aspect would behave exactly the same across the Turing complete abstract machine and the concrete machine for all computations not requiring more memory than the concrete machine has. The virtual machine code that the "C" programs would be translated into would be a Turing equivalent language. Thus the machine description language would have identical execution on the concrete physical machine as it would on the abstract Turing equivalent machine. The input, output, state changes, and moves of the Tape head would be identical between the two machines for any computation not requiring more memory that the physical machine actually has. -- Copyright 2020 Pete Olcott |
| Kaz Kylheku <793-849-0957@kylheku.com>: Aug 30 07:19PM > an abstract model of computation that is equivalent to a Turing machine > in such a way that any Turing complete computation can be written in the > "C" programming language. Turing's infinite tape can be mapped to the <stdio.h> facility. The possible symbols on that tape can be mapped to characters, and the operations and positioning can be mapped to the available library operations. > When "C" is mapped to an abstract model of computation that can provide > an arbitrary number of arbitrary length linked lists, then "C" acquires In the absence of I/O, the C storage model is finite, and therefore not Turing complete. However, perhaps not quite. I had a discussion with this with someone who convinced me of the following: in C we can allocate automatic storage (informally, "local variables on the stack") via recursion. If we do this without taking the address of anything, then pointers do not appear in the program, and thus, in the abstract sense, we don't run into the issue of pointers being of finite width. With that restriction, we have no random access (the program cannot access material in existing activation frames without returning to them). Therefore what we have is a push-down automaton (PDA). A PDA is strictly less powerful than a Turing machine. It contains an infinity in that it can push down as far as it needs to, but there are some computations that can't be carried out with a universal push down machine. > implementation automatically scales to any increase in physical memory > then the memory access aspect of the concrete implementation is > computationally identical to the abstract Turing complete machine. This scaling is impossible in general because: - an expression like sizeof (void *) is a compile-time constant. - pointers are embedded in data structures where not only is there no room to grow them wider, programs are not prepared to have the offsets of members change at run-time to accomodate. > "C" because the memory access aspect would behave exactly the same > across the Turing complete abstract machine and the concrete machine for > all computations not requiring more memory than the concrete machine has. The problem is that the amount of memory has to be known in advance. So that is to say, for a given C program and its input case, we have to know how much memory it will need. Then choose an instance of the abstract machine which will fit. Then instantiate the machine, translate the program, and execute it on the intended input. Why that is a problem is that that knowing how much capacity to provision for a given instance is equivalent to the halting problem. You're much better off chasing Turing completeness via the stdio stream route. -- TXR Programming Lanuage: http://nongnu.org/txr Music DIY Mailing List: http://www.kylheku.com/diy ADA MP-1 Mailing List: http://www.kylheku.com/mp1 |
| olcott <NoOne@NoWhere.com>: Aug 30 02:57PM -0500 On 8/30/2020 2:19 PM, Kaz Kylheku wrote: > taking the address of anything, then pointers do not appear in > the program, and thus, in the abstract sense, we don't run into the > issue of pointers being of finite width. With that restriction, we have Good point that I had not considered. > no random access (the program cannot access material in existing > activation frames without returning to them). Therefore what we have is > a push-down automaton (PDA). A PDA is strictly less powerful than a This immediately occurred to me. > provision for a given instance is equivalent to the halting problem. > You're much better off chasing Turing completeness via the stdio > stream route. The only thing that we need is the capability to create an unlimited number of unlimited length linked-lists. There is no need to know the memory requirements in advance. We could give it a subset of the std::list interface. Unlimited length integers could be space delimited numeric digits, ASCII, Hex, or some other base. This can be leveraged to provide a pointer to the top of an unlimited heap. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Aug 30 03:02PM -0500 On 8/30/2020 2:41 PM, Kaz Kylheku wrote: > Our "meta implementation" which scales itself lazily when the program > hits a limit looks like could be a UTM. > But, so what? This is all focused on leveraging my credibility for my halt decider written in "C" and implemented as x86 machine code. I want to make totally sure in advance that my correct halt decider is not dismissed as inapplicable to Turing machines. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Aug 30 04:19PM -0500 On 8/30/2020 3:36 PM, Ben Bacarisse wrote: > Hmm... Modern C has threads and therefore more than one stack. A PDA > with two stacks is Turing complete so there may be a way after all. > Nice one! There you go teamwork. Between you and Kaz. Now the key of how do you make an unlimited depth stack? is directly addressed by the other key implementation detail: How do you provide a linked-list of unlimited depth that automatically scales to whatever memory is available. This problem has just been simplified by you and Kaz in that we now only need two of these. Also with the piece added by Kaz we have a much simpler interface: push and pop(). A two stack based machine might be a cleaner implementation because it would never have to do garbage collection. It may provide a more cumbersome model of computation than a RAM machine though. If this is the case then it is much more difficult to map "C" to the two-stack machine. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Aug 30 03:19PM -0500 On 8/30/2020 3:10 PM, David Kleinecke wrote: >> Equivalent inputs deriving equivalent outputs for all computations >> define equivalent machines (Turing or otherwise). > You might call this "black box equivalence". Bingo, you got it !!! > Note the implication that the machine always halts. > We cannot say that two boxes that both never halt for some input > have the same output for that input. Or we could construe not halting as an empty set of output. As long as the two machines produced equivalent output when they halted or failed to halt on equivalent input the two machines are black box equivalent. -- Copyright 2020 Pete Olcott |
| boltar@nuttyella.co.uk: Aug 30 03:59PM On Sat, 29 Aug 2020 19:24:16 +0200 >devices for less than half a dollar - there are rarely good reasons for >starting new projects with brain-dead 8-bit CISC microcontrollers. The Power consumption in battery powered devices is a very good reason. |
| David Brown <david.brown@hesbynett.no>: Aug 30 09:59PM +0200 >> devices for less than half a dollar - there are rarely good reasons for >> starting new projects with brain-dead 8-bit CISC microcontrollers. The > Power consumption in battery powered devices is a very good reason. No, it is not. These kind of badly outdated cpu architectures are nowhere close to state of the art of low power consumption. A Cortex-M0+ device (32-bit) will use much less power than a PIC or an 8051 for the same task. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment