But this exact example is different, because the critical step of mutation is missing.

The initial line is the same, but:

    a = b = random.random()
    a += 1
    a == b # False

Only because floats are immutable and thus an implicit copy is made and lists are mutable so the same mutable instance is pointed to by both names.

This talk still applies despite its age: https://youtu.be/_AEJHKGk9ns?si=q5HjMOM9QS3_bFzH

But the semantics of python is that variables contain references to lists and lists are mutable while constants are not.

You seem to have forgotten the point of your comment, which was to offer an analogous case where surely one wouldn't expect two different values ... but the fact that lists have reference semantics and numbers (not just "constants") have value semantics (that's the issue, not mutability--variables containing numbers are mutable in Python--they don't contain a reference to an unmutable number ... numbers are always copied into the cell) makes all the difference in the world. If one actually does analogize from your example, then one might well expect changing a to not change b since it doesn't in your example ... they might not realize that lists have reference semantics and thus think that a = b = [] copies an empty list to a and copies an empty list to b. That's how it works in Perl with `@a = @b = ();` ... changing @a does not change @b.

On top of all that, the OP made clear in the first paragraph that they didn't have the expectation that you ascribed to them ... they did understand that [] has reference semantics and changing a changes b all along ... but they apparently occasionally have a lapse in their mental model where they forget that (or perhaps they introduced the bug by naively/blindly converting some Perl code ... I've seen that happen.)

I won't offer corrections of additional errors or respond further in any other way.

Science never proves a positive.

You can only disprove.

The only way to prove a positive if there is a finite number of possibilities and you have disproven all but one. But even then, someone could conceivably come up with an alternate description that preserves the current understanding but makes additional predictions or is a simpler model making the same.

As Feyman said: "We can never know if we are right, we can only be certain if we are wrong".

This is just sleight of hand. It's true that science can never be certain about anything, not to the same level as mathematics.

But otherwise, there is nothing special about positive or negative statements. You can express any positive statement as the negation of a negative statement, so to the extent that science can "disprove negatives", it can equivalently "prove positives".

I don't think that's true regardless of whether you or Feynman or anyone else says it.

For example:

Every continuous symmetry of action in a physical system with conservative forces has a corresponding conservation law. (Noether's Theorem)

There must be two antipodal points on Earth with exactly the same temperature and barometric pressure (as a result of the Borsuk-Ulam Theorem)

As far as I know these are absolutely proved positively because they are mathematical consequences of the properties of continuous functions etc. I'm not a scientist, but there are thousands of things like this where we are definitely absolutely certain we are right because of the possibility of a mathematical direct proof.

You can prove Noether's Theorem in a mathematical sense, but you cannot conclusively prove that a specific physical force is conservative or that a specific physical symmetry of action is continuous.

Likewise, we assume at an operational level that temperature and barometric pressure are continuous functions (as assumed in Borsuk-Ulam), but it's not something you can conclusively prove aobut reality.

Sure but that doesn’t matter for my examples. The parent of my comment said “science never proves a positive” and I gave a couple of examples of proving implications. Proving “If A then certainly B” is definitively proving a positive whether or not we can prove A.

I guess this comes down to what you mean by "science". Some would say that science is the process of testing hypotheses about reality. Mathematical facts exist in an abstract sense apart from reality, and so mathematics is not really science to those people.

There's an argument that you are still doing science if you construct a logical proof showing that "if the world is like X, then it will behave like Y". A lot of theoretical physics is like this, and people call that science. But I think there's truth to what OP is saying in that science does not conclusively positively prove things about reality.

but you can use that exact logic to say the inverse; that nothing can be disproved, because you can never be sure youve disproved every alternative

If you are more into doing this locally than using a Webservice, have a look at astroplan based on astropy.

https://astroplan.readthedocs.io/en/stable/

If it disagrees with experiment, it's wrong.

https://youtu.be/EYPapE-3FRw?si=LjSNyltYaVUY5bzX

But on any modern CPU, clock speed won't be constant. It's not compile time constant, nor a runtime constant. Its variable over time. You'd have to record the clock speed over time and the ticks, so why not just record actual time?

The CPU clock varies, but all modern CPUs have some counter that is incremented at a constant frequency, like the Time Stamp Counter (TSC) on Intel/AMD CPUs.

When discussing hardware clock ticks used for time measurement, the ticks from TSC or similar counters are meant and not ticks from some counter that counts cycles of the CPU clock, like provided by the performance counters.

The variable CPU clock frequency can be measured by computing the ratio between the ticks accumulated by the corresponding performance counter and the ticks accumulated by the TSC (or similar counter), for which the clock frequency is constant and known.

You missed this key part of my earlier comment:

> (invariant cycles)

All major CPUs have had invariant cycle counters for decades at this point. It is a runtime constant.

Would this argument still apply if I need to store a uuidv4 anyway in the table?

And I'd likely want a unique constraint on that?

Fraktur is often associated with the German far right, because it's a mostly German thing that nationalists can hang on to.

Funnily enough, it was Goebbels who banned it and required everyone to change to Latin scripts.

Got to hand it to them - Fraktur is an annoying font. It looks cool, though.

The book is quite old actually, not sure if "this day and age" still applies to it

Completely new tunnel, but it will be connected to LHC, as they will use LHC to pre accelerate the particles.

Almost all accelerators built at CERN are still active and are a chain of pre-accelerator for LHC now:

https://en.wikipedia.org/wiki/Large_Hadron_Collider#/media/F...

wow. Amazing map. Just imagine Half Life map with it... :)

That seems like insane engineering

They integrate with radicale since May this year for card- and caldav

https://opencloud.eu/en/news/opencloud-calendar-and-contact-...

The post, at least, seems to have no word about a web interface, though? I'm aware of a number of CalDAV/CardDAV servers, but they all seem to be designed for a workflow where you only access the calendar from a mobile app. Conversely, standalone web calendars like the fullcalendar.io thing linked in a sibling post make no mention of any support for CalDAV or other ways to synchronise with phones and calendar apps.

It's the integration of both that makes Google (and, I guess, Nextcloud) useful: you can add an event on your computer (which is where most of the scheduling and planning happens), and then inspect and be alerted of it on your phone (which is with you when you are in a random location and need to be reminded of an event).

Even if there does exist a standalone JS calendar application that can sync with CalDAV, you would be left with an awkward setup when self-hosting, since now for no obvious reason you need to have two services on the same machine (the database and the frontend) that maintain a copy of the same state and need to sync with each other constantly.