Physics, coding and black metal.

Vyssiikkaa, koodausta ja bläck metallia.

Apparently also politics when it doesn’t devolve into screaming into aether.

  • 0 Posts
  • 33 Comments
Joined 1 year ago
cake
Cake day: June 13th, 2023

help-circle

  • My simple uncontroversial claims

    None of these is uncontroversial, C isn’t even well-defined. I’d argue that B is correct only if A is correct. And A cannot be correct, since it leads to multitude of cotnradictions, one of which I’m going to demonstrate.

    It appears from context to be the first: the claim that indeterminism means events are not explained by their causes. But that’s just the definition of indeterminism

    No, it most definitely is not. If you used this as a definition, I’m fairly certain that most physicists would absolutely not agree with your B.

    If you deny that indeterminism means things aren’t determined by observable causes, then what does it mean?

    Indeterminism means that if an experiment is repeated with the same parameters, there are no guarantees to get the same result. Nothing more than that.

    Your definition implies that there needs to be a cause in the first place. And that is bordering on begging the question, because with that definition you are guaranteed to reach a point where there is something “unexplainable” (since there are infinite amount of layers), which can always be attributed to whatever supernatural thing you choose. There is absolutely no need for this to be the case.

    In fact, you yourself quoted the textbook

    the outcome is intrinsically random.

    Emphasis mine. That means, there is no cause, it’s an intrinsic property of the theory, especially in Copenhagen interpretation, which is the status quo. As your definition implies a cause, it cannot apply here. There are other contradictions, but this one is simple and I only need one to show that the premise is flawed, and your other points rely on that.

    you have not substantiated your claims with anything.

    My only claim is that you are incorrect. There aren’t really too many papers written about that. (I hope) I’ve shown your premise to be false because of faulty definitions, what more would you need? None of the stuff you quoted is supporting you, and in fact contradicts you, unless we specifically assume that other people use the definition you’ve given, which, again, is already shown to be erroneous.



  • Go on then: what definition do they use?

    Natural means pretty much “element of the physical universe, identified by observation”.

    You’re claiming in another comment to this thread that you have M.Sc., you should be aware of this, please stop wasting everyone’s time.

    Slapping “quantum” in front of something generally makes it involve indeterminism (excepting the many-worlds interpretation)

    Indeterminism is by no means non-natural, and it does not make things any less observable. We can observe quantum states just fine.

    And as for

    Yeah all the Bell stuff

    “All the Bell stuff” doesn’t have anything to do with “Didn’t some quantum nondeterminism prove the existence of effects without a natural cause?”

    And no, it didn’t. AFAIK there are exactly zero physicists who argue that.

    You made a ludicrous claim, and are unable or unwilling to back it up even a bit, yet somehow you feel continuing this without anything to show is a good use of anyone’s time. If you are not going to make an actual argument, I do not see value in continuing this conversation, as all it does is make this thread more difficult to read for others who most likely are not very interested watching yet another internet argument sidethread.


  • There have been plenty of discoveries opposed by religion X. Those historically do not have significant impact on prevalence of such a religion.

    I do think answers explaining why any answer to the original question suffers from logical fallacies are equally good to those that do try to get to the OP’s intent, and I think it is good to have both. I do think the literal answers are more “straight” (and I tend to go to the literate mode when talking about science), so that’s what I went up with.




  • If they were, it has nothing to do with nature being supernatural. It just means that nature’s state is not locally real. That does not tie into religion in any objective way.

    In addition, both of those articles are (slightly) wrong. There was a lenghty discussion about how in r/physics when they came out. The tl;dr is that it boils down to:

    • locality
    • realism
    • independence of measurement

    Pick two.

    But that has no relevance to religion other than you can make either philosophical or religious argument out of anything.







  • This is front and centre on the homepage…

    I stand corrected.

    It makes assumptions about the native architecture for the sake of performance, but it’s still portable because you can implement all that behaviour in a VM if necessary. The important thing is that the behaviour is well defined.

    It doesn’t have to be native architecture, just the execution environment (i.e. you can emulate it).

    But I don’t see why by that logic any turing-complete language wouldn’t be in the group “portable”, including any hardware-specific assembly. Because you can always implement a translator that has well defined-behaviour? e.g. is 6502 assembly now portable that C64 and NES emulators are commonplace? (And there even is transpiler from x86 asm to 6502 asm). I do not think many of us see this as a good definition for portability since it makes the concept meaningless, except in cases where the translation layer is not feasible due to available processing power or memory.

    It’s not perfect but I don’t think the situation is any worse than in Java, C#, Lua, etc. If your hardware has non-standard floats you’re going to have a bad time with any VM.

    I mostly agree here. But I think portable language is not the same thing as a portable VM, and that portability of a language target is different from VM portability.




  • Good opener!

    These toolchain are created for experts to create industrial-level compilers. Even if you think you got a syntactic design concept that is such hot shit that you can’t wait to get it bootstrapped, even if hell, it proves Rice’s theorem wrong, please, write a simple interpreter for it to prove your syntax works. In fact, I think one way you can test your language’s design is to have it mooch off an established VM like JVM, CPython’s VM or CLR.

    I agree in principle, but mooching off established VMs will affect your overall language design since and significantly push you towards language “grammar” those VMs are built to deal with. Syntax is pretty irrelevant early on and should be made easy to change anyways.

    But if you wanna ‘learn’ compiler design, I beg you to roll your own backend. You don’t need SSA or any of that shit. You don’t need to super-optimize the output at first try. Just make a tree-rewrite optimizer and that’s that.

    I don’t think I really agree with this. Of course, if your goal is just to learn how everything works, rollng your own is the best option. But if you want to do more than that I think not taking advantage of tools available (such as LLVM) is suboptimal at best. It might be fine if you are unemployed or can slack off enough to spend copious amounts of time on your language, but you will spend your time on rewriting tiny details over and over that might be fun to make, but it won’t help with getting your language into usable state. There’s plenty of optimisations you can (and should) do even before you pass on anything to LLVM if the goal is to think about those.

    Same is true with LP generators. From Yacc to ANTLR, they just make the experience harder and less rewarding. I know hand-rolling LP is hard in a language like C, in which case, don’t fucking use it lol. There’s honestly no inherent worth in using C in 2024 for compiler design.

    I’m not sure I got your point correctly here, but if I did, I heavily disagree. Like it or not, unless you plan to write everything from hardware up from scratch in your language, you need to adhere to a lot of C stuff. Whatever your system C ABI is, that is the layer your language needs to be able to talk to. And that, for better or worse, requires to take C heavily into account.

    But there’s still use for C in being the subject of your compiler. It’s a very simple, straightforward and more importantly, standardized language, you don’t need to write a runtime for it, because when it comes to both UNIX and Windows, runtime is OS itself! Just make sure you add a syscall interface and then C runtimes like glibc and CRT can be easily strapped.

    Heavily disagree with C being either simple or straightforward, but totally agree with the important part that it is standardised.

    I know my point about using LP generators is preaching to the choir and most people despise them — but I just don’t understand why people love to use IRs/ILs when doing so teaches you shit.

    I recommend beginning to design your language with the IR – your IR.

    Anyways tell me what you think about my ‘take’ on this. Of course I am not saying you are ‘less knowledgeable’ for using LLM or MLIR, I’m just saying, they don’t teach you stuff.

    Still, some people just use LLVM and MLIR as a final ‘portable’ interface, having done the optimization on graphs and trees. i think there should be some sort of ‘retargatble assembly’ language. Like something with fixed number of registers which… oh wait that’s just a VM!

    I mean, you answer your own questions here. People love to use IRs/ILs because things like LLVM IR are the closest thing we have to portable assembly we have, and it makes it simpler to get into running state. Most compilers have their own internal IR (maybe even more than one) anyways, regardless or not if they use something like LLVM. Understanding how LLVM/MLIR/whatever IR is designed is pretty important before you start rolling your own if you want it to be useful.

    Also you don’t need to necessarily translate to a super super low-level language. Just target C. GNU C to be exact. Cyclone does that, in fact, I am planning to bootstrap my functional language, which I named ‘Xeph’, based on Zephyr ASDL, into GNU C as a test. Or I might use JVM. I dunno. JVM languages are big these days.

    Targeting C is completely valid. Though I see no reason to use GNU C – just use the actual standardised versions. And I think what you target should be part of your language design and suit what your language’s purpose is, not stuff to pick at random whenever.

    PS: Do you guys know any cool VMs I can target beside CPython and JVM? Something with AoT perhaps?

    Besides BEAM VM that was already mentioned, Lua VM is pretty interesting to target (not AoT though) if that’s your thing.



  • I guess that list could be helpful for some, but for me (and IMO, music production in general), it’s woefully inadequate to the point of hilarity.

    Pro audio has been a complete mess in Linux for ages, and it’s not even close to where it should be in order to be generally usable. Every 7-8 years or so when my old music computer starts to die I try and check if it has made substantial improvement, but apart from Musescore actually being good, it is hard to find any tangible progress from 15 years ago. Pipewire gives me some hope, but it’s far from production-ready in Pro audio world. And I’m not really going to get rid of all the VST stuff I’ve bought in the last 20 years (all of which still works out of the box on a new computer!)

    In addition, making music is the one hobby I have to get me away from tinkering with computers. I am not interested if I could make my Linux setup equally good if I spent weeks tinkering on it, when it’s literally easier for me to work for a week and buy a Macbook Air (or whatever crappy windows PC), where I get all of my old work ready for action in under a day, and I can trust that everything I do will just work, and work well at that. And it does it while allowing me to work remotely with other musicians since we can all use the same stuff.

    I’m pretty sure I’ll be in my grave before FOSS Pro Audio ever gets there, unfortunately.

    Edit: Ironically, the one FOSS thing I would love to use in my audio stuff is Guitarix, which is then the thing that doesn’t interop well with anything else. And I would love to have easy way to do all that I do on (Win/Mac Os) on Linux, but 20 years of disappointment is pretty hard to overcome at this point.