News for hackers. Stuff that matters.

A comment on How do black holes destroy information and why is that a problem?. Parent comment

Re:How do black holes destroy information and why is that a ... by myaccount80 on Monday August 26, 2019 @04:43AM (#20798271)
It is not reversible because you’re ereasing information. If you want to have a reversible addition you are not allowed to destroy the information.

The same happens if you apply the standard AND operator to two bits because the output is only one bit, therefore it is impossible to figure out the two input bits. To have a reversible AND operator you can define it like this: f(x1, x2, b) = (x1, x2, b XOR (x1 AND x2)). E.g: f(1,1,0) = (1,1,1). From this output you can get back to the input. This way you can implement a NOT gate as well, and all others gates. At the end you can implement addition using bits and your summation becomes reversible :) You can see that with this definition we are not ereasing any information, hence it becomes reversible.

[ Parent | on HN ]
Re:How do black holes destroy information and why is that a ... by fizx on Monday August 26, 2019 @11:17AM (#20800555)
Quantum computing is reversible in this way. Rabbit hole starts here:

https://en.wikipedia.org/wiki/Ancilla_bit

[ Parent | on HN ]
Re:How do black holes destroy information and why is that a ... by gigatexal on Monday August 26, 2019 @12:14PM (#20801017)
Famous last words...

After reading: “oh my god it’s full of stars!”

[ Parent | on HN ]
Re:How do black holes destroy information and why is that a ... by codernyc16 on Monday August 26, 2019 @06:32AM (#20798649)
You’d have to do that for all results, not just one. This is basically what an event sourced system does: you store all the events and fold your state, so you can “play back” to any point in time. You could theoretically reverse from the end, but I haven’t seen it done.
[ Parent | on HN ]
Re:How do black holes destroy information and why is that a ... by setr on Monday August 26, 2019 @10:55AM (#20800361)
Urbit ;-)
[ Parent | on HN ]
Re:How do black holes destroy information and why is that a ... by Zenst on Monday August 26, 2019 @10:10AM (#20799980)
A transactional database would tick that box, events are stored and can rollback to a point in time.
[ Parent | on HN ]
Re:How do black holes destroy information and why is that a ... by acoma on Monday August 26, 2019 @10:33AM (#20800179)
Not quite. Dropping a column or updating a row is typically irreversible.
[ Parent | on HN ]
Re:How do black holes destroy information and why is that a ... by Zenst on Monday August 26, 2019 @11:39AM (#20800729)
That does depend upon the database, but can be done in some without resorting to a backup.
[ Parent | on HN ]
Re:How do black holes destroy information and why is that a ... by continuational on Monday August 26, 2019 @01:09PM (#20801617)
In PostgreSQL, schema changes are transactional.
[ Parent | on HN ]
Re:How do black holes destroy information and why is that a ... by anarazel on Monday August 26, 2019 @02:20PM (#20802343)
> In PostgreSQL, schema changes are transactional.

With a few exceptions (that refuse to run in an explicit transaction): E.g. {CREATE, DROP} DATABASE, {CREATE, DROP} TABLESPACE, {CREATE INDEX, DROP INDEX, REINDEX} CONCURRENTLY, REINDEX {SCHEMA, SYSTEM, DATABASE}.

[ Parent | on HN ]
Re:How do black holes destroy information and why is that a ... by zcrackerz on Monday August 26, 2019 @02:49PM (#20802553)
Also, try adding a value to an enum via ALTER TYPE ... ADD VALUE
[ Parent | on HN ]
Re:How do black holes destroy information and why is that a ... by anarazel on Monday August 26, 2019 @02:58PM (#20802613)
Not anymore ;). Well, at least in the upcoming PG 12.

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...

  commit 212fab9926b2f0f04b0187568e7124b70e8deee5
  Author: Thomas Munro <[email protected]>
  Date:   2018-10-09 12:51:01 +1300
  
      Relax transactional restrictions on ALTER TYPE ... ADD VALUE (redux).
There's still some restrictions:

> This patch removes that restriction, and instead insists that an uncommitted enum value can't be referenced unless it belongs to an enum type created in the same transaction as the value.

[ Parent | on HN ]