Talk:Quantum INTERCAL

Mmh. Outputting a quantum bit to anything but another quantum computer would observe it, thereby setting it to either 0 or 1 as it's output, rather than outputting both 0 and 1. Also, Quantum INTERCAL doesn't seem to allow angles, which are essential to quantum computing. Without angles, it's just nondeterministic computing. --Ihope127 20:58, 22 Aug 2006 (UTC)

Going by the CLC-INTERCAL documentation, this looks more like an unusual form of multithreading than true quantum behaviour. Personally, I prefer the Threaded INTERCAL multithreading method, particularly when computed COME FROMs are used. ais523 15:08, 24 Aug 2006 (UTC)

The documentation is only applicable to running CLC-INTERCAL on a non-quantum computer, where a special emulator is necessary; it just happens that the emulator is buggy and does not properly emulate a quantum computer. The fact that there isn't a CLC-INTERCAL distribution for a quantum computer is just a minor detail. Anyway, this is my excuse and I'm sticking to it Uilebheist 18:18, 24 Aug 2006 (UTC)

It still doesn't mention angles, does it? --Ihope127 17:32, 25 Aug 2006 (UTC)

Right, provide reasons to mention angles. Your statement above should be reason enough to avoid them in INTERCAL. Do you know INTERCAL is supposed to do things differently from everybody else? Uilebheist 11:09, 26 Aug 2006 (UTC)

To clarify the above, the documentation only states that a "classical" bit is converted into a quantum bit, which starts in a superposition of states. No other property of this superposition (such as amplitudes, or any phase difference between quantum wave functions) is directly specified, but nothing stops the rest of your program providing a constraint in which some quantum states are allowed and other forbidden (in fact, at least one of the examples provided relies on this). If you have more than one quantum bit, you can assume entanglement (which of course does not need to be explicitely requested) depending on how the bits are created, and this may help providing constraints on the resulting quantum state. Now, it may be that the real meaning of your objection is that you can prove that this form of constraint-based specification is not expressive enough, which is probably the case, but please post your proof, not a request to uncritically copy another language. Uilebheist 13:07, 26 Aug 2006 (UTC)

Well, if the emulator is buggy, and the spec is also buggy, then someone has to fix one or the other. --Ihope127 17:53, 20 Oct 2006 (UTC)

A better emulator is work in progress and I may finish it one of these years. But it won't mention angles anywhere so if you really have a reason for them, why do you not provide it? I'm waiting. Uilebheist 13:04, 21 Oct 2006 (UTC)

Well, a probability amplitude can be expressed in terms of "real and imaginary" rather than "probability and angle", so you don't need to call anything an angle. However, if you gave everything just a probability with no angle, phase shift gates would do nothing, and the Hadamard gate would simply randomize whatever you gave to it. You would still have entanglement, but no interference. --Ihope127 16:37, 21 Oct 2006 (UTC)

Which is precisely my point. No need to specify the amplitudes the same way as everybody else. I just need to find some unusual way to do it. Which may take some time... (but I will accept suggestions as long as I see no evidence of the same method having been used elsewhere) Uilebheist 13:35, 22 Oct 2006 (UTC)