The double slit experiment violates causality, which means physics violates causality.
Why do you believe the double slit experiment violates causality? It violates locality, but not causality. No slit, no interference.
I'm crazy enough to believe I have found a path to unification that is actually quite simple: add a new relativity principle that states that laws of physics must be the same irrespective of the measurement instrument we use. Here is a parallel:
- Special relativity states that the laws of physics must be the same irrespective of your state of motion. So a complete description of an experiment must include which referential you are using. There is no absolute space, no absolute time, no aether. And we need to add new transformation laws from one referential to the next, which are Lorentz transforms.
- General relativity states that the laws of physics must be the same irrespective of acceleration. So a complete description of an experiment must include accelerations, including gravitation. There is no flat space-time anymore, but something that is curved by gravitation fields. So we need to add new transformations from one curved space-time to another, use tensor math, covariant and contravariant quadrivectors, etc.
- My still incomplete theory of incomplete measurements (TIM) states that the laws of physics must be the same irrespective of the measurement instruments used. So a complete description of an experiment must include which instruments were used, including calibration and range. Just because two instruments are calibrated to coincide on a given range cannot be used to postulate that they match at any scale. Space, time, mass and other measurements are no longer continuous, but discrete (because all our physical instruments give discrete results). We need to add new transformation when going from one physical instrument to another, which correspond almost exactly to renormalisation in quantum mechanics, but give an explanation as to their origin.
The TIM focuses on what I learn about a system using a physical measurement instrument. This starts by defining what an instrument is:
- It's a portion of the universe (i.e. it's not "outside the matrix")
- which has an input and an output (e.g. the probe and the display of a voltmeter)
- where changes in the state at the input yield a change in the state of the output (change in voltage result in changes on the display)
- which ideally depend only on the input (the voltmeter picks the voltage at the probe, not somewhere else)
- and change the output (nothing being said about the change in the input, since even macro-scale experiments can be destructive)
- the change in the output being mapped to a mathematical representation (often a real number) through a calibration
The instrument gives me knowledge about the state at the input. Since the instrument has a limited number of states in the output, my knowledge of the system through this instrument at any given time is described by a probability for each of the possible states. If I have N states, the probabilities p_1...p_N are all positive, and their sum is 1. So the knowledge state can be represented by a unit vector in dimension N.
For example, if I care about "is there a particle here", the possible measurements are "yes" and "no". The knowledge state is therefore represented by a unit complex number. If now you want to answer that on a plate with 1 million possible positions, you have a field of 1 million complex numbers, with the additional constraint that the particle must be at only one position (which is expressed as the sum of the probabilities for all "yes" being 1). That field is remarkably similar to the wave function, and this reasoning explains why it is complex-valued, why it is a probability of presence, and why it collapses when you know where the particle is.
But the primary difference with QM and GTR is that space-time is no longer continuous. It is discrete, and the discretization depends on the instrument being used. Because it is discrete, there are never any theoretical infinities in the sums you compute (these infinities being the reason why QM and GTR are considered fundamentally incompatible).
Here is a layman view of the incompatibility between QM and GTR. Imagine ants that try to define the laws of physics on earth. They setup rules, e.g. their anthill is only at one place in the universe, so the sum of the probability to find the anthill over all of space-time is 1. But if they now start realising that the earth surface is not flat but curved, now the method above does not work. If you go to infinity along the surface of earth, you "count" the anthill multiple times, so your integral, instead of being normalized, diverges to infinity. It is only an analogy, but it is an interesting one.
that thorium reactor is fission, not fusion. Not exactly interchangeable.
Obviously, which is why I wrote thorium / fusion, with a slash. You want the combo. Jumpstarting a fusion-only reactor from the wireless power line? That takes forever! Last time I checked, you need at least two to three frigging minutes!
A thorium reactor, on the other hand, is a good little backup, underpowered, sure, but largely enough to fire up a Fusion Drive 6G almost instantly. Also, many small thorium generators fit in your pocket, whereas even the latest Mr Fusion are big enough that you need a car to haul them around. So when I want a senso-holomovie on the beach, I always carry a little thorium booster with me, just drop it n the seawater for a few seconds, and I'm good to go!
Also, I forgot something essential in my list. You probably want a temporal adjustment controller. I just realized mine is on the fritz, and I'm no longer sure which year I'm in. Can you imagine if you make a mistake and talk about recent technology to, say, early 21st century Slashdotters? That would be cruel.
Um
How would you otherwise teleport when the martians attack and the grid is down? Plus, I think that if you have a quantum teleporter, having at least a couple of terawatts locally is basic construction code in most places.
Here is my quick list:
- 80' holographic TV with 360 channels 4D surround sound
- Two parking spots for the hovercars
- A quantum teleporter (ask for the free subscription to Andromeda Quantum Tours Weekly)
- A six terawatt home battery and thorium / fusion nuclear reactor (don't go for the cheap Tesla stuff, nuclear is what you need)
- A robosquid and a set of batteries
- Six packs of pills for instant beer
- An iPhone9 with the Apple Watch, Apple Pay, Apple ID, Apple Travel, iThink, assortment of overpriced cases, cables and chargers
- At least one DNA decoder / recoder per room
- A 65536-qbit game console for the kid
This one is somewhat specialised, but may still be worth sharing. Back then, I was working on HP ECUTEST, a refrigerator-sized machine that simulated all electrical inputs and outputs for a car engine control unit (ECU). Basically, it was "The Matrix" for an ECU: you plugged the car's brain into it, and it couldn't tell it wasn't in a real car.
The customer wanted a way to create defects on the ECU pins, e.g. short them to the ground. Problem is that an injector signal is 60 amps or so for a diesel engine, and an ignition coil signal is easily 500V. Try shorting this with a low-cost relay, and your relay gets fried pretty fast. But then, we were emitting the "cogwheel" signal that the ECU used to know the position of the engine, A pretty complicated signal in its own right, that varies in shape, amplitude and frequency as engine speed increases. Generating that signal was a story in itself.
Anyway, we wrote software that would synchronise the flipping of the relays to create defects with the rotation of the engine, so that we knew that at the moment we were switching the relay, there was little current and little voltage in the corresponding circuit. Of course, you can imagine how many relays it cost to make the stupid software work as it was supposed to. Well, actually, not that many, all things considered, but the hardware guy who had to replace the relays still cursed me whenever I goofed up.
Did a similar thing back at engineering school, with an old IBM 4341. That machine was a big time-shared computer with tons of students. Someone noticed that your account got a temporary priority bump whenever you had a screen refresh. So in order to speed up compiles and other things, we had a variety of contraptions that would hit the page-up/page-down keys to force the screen to update continuously.
There is a story I remember reading once, but can't seem to find anymore. It was about some space probe that was regularly shutting down. The space engineers finally figured out that it had lost a panel, so the sun light could enter inside and that was enough to corrupt the memory that was hit by sun rays. So NASA modified the program so that it "walk around" physical memory, copying its code and data around memory so as to avoid solar rays. I don't know if that story is true, but if it is, it looks like a good candidate to me.
The HP28C had an infrared output, e.g. For printers, but no input. a friend of mine published a book explaining how to connect an IR diode to trigger some unconnected keyboard lines in the calculator. That made it possible to upload programs to the calculator faster. Of course you also needed the matching hack on a PC to send programs. The 48 had IR in both directions.
If you are a developer and want to go beyond Powerpoint, Tao3D (http://tao3d.sourceforge.net) is a valid open-source option. It takes time to master, but it's a much more effective way to tell a complicated story.
First up, can I suggest adding the word "visualisation" to your standard blurb?
Good idea, done. It was hidden in the middle. Renaming Tao Presentations to Tao3D is similarly an attempt to avoid the misconceptions about "presentations".
I'm talking about a visual confusion. The reason I keep using the word "opaque" is that when I look at the code, the intended (semantic) behaviour is obscured.
Are you sure this has nothing to do with you not being familiar with the language?
You've suggested several times that having effectively only one syntactic structure in the language makes it more consistent, but my object with regards to consistency is precisely the contrary: that the syntactic rule is inconsistent because there is no clear mapping of syntax->semantics.
Maybe the word you are looking for is not "consistency" then. "Consistent" means there are no exceptions to the rule, which is easier to achieve when there are few rules. In C++, f(x,y) may be a macro invocation, a function call, a constructor, and there are different rules in all three cases. In HTML, the "a" tag refers to its URL as "href", but the "img" tag calls it "src". Consistency with the "real world" also matters. In SmallTalk, 2+3*5 is 25, not 17, so SmallTalk is consistent with itself (everything is an object, etc), but not with the rest of the world.
Something helped me immensely in your last post: you put a few code examples. I think that code examples help me figure out what you really mean or what you care about much better.
So ":=" is the assignment operator, but in all your examples you've sugared it over, and basically obscured the logic of your code...?
Why do you call this "sugaring over" now, and not "building an abstraction" (from your previous posts)?
The abstraction for attributes, used consistently, is: each attribute has a name from the real-world, you set the attribute "attr" with "attr value", you get the value of the attribute with "attr", and attributes apply to things that are evaluated later. Not obscure, and consistent, both internally and externally (e.g. with OpenGL).
I don't think it's more practical, because it massively less readable.If I use object.setColor("green"), it's easy to read the intended meaning.
Can't agree on that one. It's totally unreadable (ask any 10 years old kid without a deep training in JavaScript). And for productive programmers, it has the following useless characters: "object.set()".
I would prefer the abstraction object.color = "green" because getter/setter is usually implemented by convention rather than rule (leaving things open to programmer error).
There, you went down three steps down the abstraction ladder. Why not MOV $green.str0, color[object] while you are at it?
But your solution offers less clarity than either.
I have trouble arguing if you tell me that object.color = "green" is a better abstraction than color "green". It's terribly inefficient when you have multiple shapes and multiple attributes, and I have proven with rotation that it does not work for some complex attributes.
You're talking about the computer.
No, I'm talking about the abstraction level, meaning you hide what is irrelevant.
Imperative is superior to declarative only in terms of optimisability
Also in terms of expressive power, in terms of the ability to build abstractions incrementally, in terms of
a declarative language should be easier to code in, because you only have to worry about the behaviour, not the execution.
But behaviour is infinitely more complex than execution. Execution is generally defined as a simple step-by-step sequence of operations. Behaviour, by contrast, is arbitrary. For HTML, is requires understanding how a multi-million lines programs like a browser interprets the data.
A well-written declarative language would be quicker to write in than a similarly well-written imperative language.
Please prove it by showing a well-written declarative language.
Why can't I just declare which functions should be memoised over recursive calls, rather than faffing with (set!
Because as the person writing the algorithm, you know when and how to cache data. Fibonacci is an overly simplistic example to decide what to do.
As I say, it's only problematic when it doesn't look like a command.
OK, but why doesn't color "red" look like a command to you?
Sorry, I confused the "with" iteration as a pattern over a discontinuous range of values. This is what I mean by opaque -- there is minimal visual distinction between a function definition and a function call, making it difficult to read and reason about code quickly.
I think that I understand your point. You definitely need to learn what a function definition looks like to understand the language, I'll grant you that.
My point isn't that the DNA functions aren't discontinuous, it's that a discontinuous function is still a single unit, and not comparable to a polymorphic operator.
Not in Tao3D, no. In C++, you have a discontinuity based on the type of the arguments. In XL and Tao3D too, but that type is much finer-grained, i.e. you can have a type that takes only odd integer, or a type that contains only the value 1.
If we start down the LoC line, we get to the point where we're declaring obfuscated Perl code as the best thing since sliced bread. If we use characters as our metric, you're penalising explicit variable and function naming. The characters metric also automatically penalises against things like using explicit assignment operators (which really do add to the understandability and maintainability of code), and LoC automatically tends to favour semantic whitespace (as end-block delimiters are often given their own lines to enhance readability).
And you really think that it's the way I got a 28x factor? I believe that you are ignoring the core of my argument here. We are comparing well-written code against well-written code, and there is a 20+ times code reduction. I used that to highlight that the improvements I see in Tao3D are not just in my imagination or the result of me being the author of the language.
By the way, I wrote an article with the actual code explained for this specific example.
All I'm saying is that for most practical purposes, the idea that the item persists and that redraws are implicit is a useful abstraction.
Yes, and conceptually, that's how you see the code in the DNA example until about 3 minutes into the video, when the abstraction is broken by the use of random numbers that are not identical from draw to draw.
Because there is no existing entity.
That's not the answer -- I said "an", not "the". I was questioning the choice, not the consequences. Yes, I know you went on to justify that choice, but starting off the paragraph this way risks confusing things.
And I really mean there is no existing entity at all, that's the whole point. You don't need to name entities. As a matter of fact, it's only in the second iteration of the Tao3D development that there were any entities at all. In the first prototype, it was direct execution, straight to OpenGL. If there were any entities, they were in the graphic card's memory, inaccessible to the program (at least, at a reasonable cost).
But the real explanation here isn't about ID clashes, is it? It's about keeping memory manageable for massive datasets -- no computer on Earth would be able to maintain persistent objects for every star in the known universe in memory.
It's more about offering a simpler way to describe things. An entity means you need to name the entity. When I draw on a sheet of paper, I don't need to name everything I'm drawing.
As above, that's an objective metric, but it doesn't indicate objective superiority.
If the programs are similar in what they do, in readability, in naming conventions, and if the LOC factor is 20+, then yes, it does.
It's not a fallacy, it's a reality. It's about perception and expectation.
Yes, I agree with that. Visualisation is a good application. But deep inside, it's really a programming language. You can do visualisation, virtual reality, image processing, etc. While your data visualisation comment is very true, Tao3D can equally well do batch processing on a number of images.
But a PowerPoint file is just an XML document, which means that PowerPoint is a language, even if no-one in their right mind would try to edit the source directly.
It's a data-only language. So it's not a true programming language
I thought this was for quick mockups, and therefore I felt it should abstract away a lot of the 3D stuff.
And it's important for me that it can do quick mockups, where 99% of the 3D stuff is abstracted. When I write a "slide", I happily forget about the hundreds of 3D objects and animations created by the theme behind my back. Now, I talk about a "slide", and that's what I focus on.
(Even "Hello World" examples are usually a terrible start for a coder in a new language, because it's easier to just type echo "Hello world!" at the shell prompt.)
Here is the Hello World in Tao3D. It's not the shorter you can do, though. The shortest one would be text "Hello World". It does abstract quite a bit of 3D stuff in the process, by the way, like creating polygonal outlines and textures to render the characters.
Well, for a start, I wouldn't use the slide format in the introductory video. Seriously, that is extremely misleading. Or maybe use it later on, once there's (eg) a rotating model of a simple product (a bicycle wheel, maybe), so that you're clearly showing the presentation tools as an extension
You mean, like in the DNA strand example? Or in the clock tutorial? Some videos start in presentation mode, others don't. Some start with existing code, others don't.
Data visualisation. "Presentation" implies passivity. This is not fallacy, it's a natural consequence of years of death-by-PowerPoint.
I do not see your stargazing app as a "presentation", because a presentation is not typically an end-product.
OK. It's called Tao3D now, not Tao Presentations, that's a start
Kleeneness is next to Godelness.
