|
You can't force people to care, that's the truth.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
harold aptroot wrote: You already wrote papers about this..
Ah...well then that makes some of the rest more clear then.
|
|
|
|
|
Message Closed
modified 19-May-23 21:28pm.
|
|
|
|
|
polcott wrote: Whether or not these insights apply to the actual halting problem is a next level review that must be done by a qualified computer scientist.
The code you have provided is a demonstration of something that has already been demonstrated mathematically. Doesn't matter how you phrase your posts that remains true.
Lets say you create a interpreter which changes the context in which the problem runs. For example it halts every single time a specific instruction is called. Certainly provable that it halts then. But that is a different problem than the one you posted.
So your choices are
1. Find your own problem and prove anything you want about it. You must fully define the problem space.
2. Find a way to invalidate the existing Turing proof using the context in which it was presented. You do not get to change that context - if you want to change the context then see item #1.
Note that step #1 even being fully correct will say nothing about the Turing proof.
|
|
|
|
|
Message Closed
modified 19-May-23 21:27pm.
|
|
|
|
|
polcott wrote: cannot possibly terminate normally.
Nigel Molesworth* wrote: As any fule kno.
*The curse of St. Custard's
|
|
|
|
|
Message Closed
modified 19-May-23 21:26pm.
|
|
|
|
|
polcott wrote: If I was actually wrong someone could point out a mistake.
I can't speak for anyone else but I am certainly not going to attempt to teach you an entire class on Turing Machine mathematics.
And I already suggested that you take exactly that sort of class.
I found one that teaches it. I know there are others.
Models of Computation[^]
|
|
|
|
|
Latest update: the bug is gone after I run cmd console, instead of the new Terminal console. Case closed. Thanks everybody for checking and testing.
I found a cout bug with Visual C++ 2022 on Windows 11. VC++ 2019 does not have this bug. When I try to debug, the problem goes away. I have produced a small repo that reproduces the issue. Please help me check so that I can report this bug to Microsoft. Thanks.
modified 12-May-23 8:10am.
|
|
|
|
|
I cannot confirm the bug. Everything works in the order expected.
Microsoft (R) C/C++ Optimizing Compiler Version 19.35.32217.1 for x86
on
Windows 11 Pro
Version 22H2 (OS Build 22621.1555)
|
|
|
|
|
Thanks. Your Visual C++ and Windows edition is the same as mine. Did you run it a few times? The bug has 50% chance of reproducing when run normally (meaning not debugging).
|
|
|
|
|
Only about 30 times, and it never happened even once.
|
|
|
|
|
The bug is gone after I followed Richard's suggestion to run the old cmd console. Thanks for testing.
|
|
|
|
|
I was using CMD Prompt and Powershell in Terminal with no issues at all, in both Debug and Release builds.
|
|
|
|
|
It looks like nobody is encountering this issue except me. Thanks again. You can stop testing.
|
|
|
|
|
Its working fine here on Windows 10, VS 17.5.5, so I would suspect the Windows 11 terminal - can you try running it in a cmd.exe window instead?
|
|
|
|
|
My c:\windows\system32\cmd.exe is already the new Windows 11 terminal. I am not sure where the old cmd.exe is.
|
|
|
|
|
If the Terminal in Windows 11 is the same as the one in 10 then you can configure it to run cmd, Powershell, Linux shell etc.
|
|
|
|
|
Thanks for your suggestion. I have configured it to run the normal cmd window by right-clicking the tab area and choosing "Settings" in the pop-up menu and selecting accordingly. The bug is gone.
|
|
|
|
|
Very interesting. What program was it running before your change?
|
|
|
|
|
Before my change to the old normal cmd, the new Terminal console has a tabbed interface and was slower than cmd window. I did not change my code. Now it is running fine.
|
|
|
|
|
Mine also has a tabbed interface, so I have three tabs: cmd , PowerShell and Linux under WSL. It seems just as fast as anything else. I can only assume there is another interface that is the default in the 11 version. Unfortunately (or maybe not) my PC does not support Windows 11.
|
|
|
|
|
Richard MacCutchan wrote: Terminal in Windows
I am not familiar with that. Presumably it is the following which one must install specifically, at least in Windows 10?
An overview on Windows Terminal | Microsoft Learn[^]
So you use that normally? I am curious why do you consider that ideal rather than going directly to either cmd or a linux shell?
|
|
|
|
|
jschell wrote: why do you consider that ideal rather than going directly to either cmd or a linux shell? I did not claim it is ideal, it is just another tool that I find useful at times. I run cmd, Powershell and Linux in "normal" windows also.
|
|
|
|
|
Using the cmd.exe window, the bug is gone.
|
|
|
|