[FRIAM] hidden

uǝlƃ ☣ gepropella at gmail.com
Wed May 20 11:39:41 EDT 2020


On 5/19/20 4:55 PM, Jon Zingale wrote:
> Doing so could be one meaningful way to interpret /tracing a thought/.

Yes. While I don't fully grok the expansions from fibers to bundles/sheaf, what it evokes in my head seems coherent.

> With regards to the discussion about our holographic surface, I could use more
> clarification on the lossy/lossless property. I assume we agree that sorting is
> not dual to shuffling. For instance, defining the type of a shuffling algorithm
> does not require Ord <http://zvon.org/other/haskell/Outputprelude/Ord_c.html> to be a class constraint, where it /is/ required for sorting.

I think whether shuffle is yet another ordering depends on what we mean by "random". But I don't want to devolve into metaphysical conversations about free will and whatnot. So, if we assume shuffle is ordered, just ordered mysteriously, then we can talk about loss sans metaphysics.

> If we are claiming that the information found on our holographic surface is
> complete, I would like to think we are claiming it to be lossless‡. At the end
> of the day, it may be the case that we will never know the ontological status of
> information reversibility through a black hole. Am I wrong about this? If our
> holographic surface isn't reversible, is hashing perhaps a better analogy?

To do complete justice to the steelman of the EricC/Nick claim, I think we do have to assert no loss. And invertibility of the transform(s) is the right way to think. But I *also* think, if we tried hard enough, we could get EricC/Nick to admit to some loss with the caveat that what's lost in that lossy transform is *irrelevant* somehow (EricC's use of "invalid" and yammerings about Wittgenstein >8^D). And since my point isn't to inadvertently create a *strawman* of their claim by making the steelman too ... well, steely, I'd like to allow for a lossy transform as well as a lossless transform. And, by extension, I'd like to allow both invertible and uninvertible transforms.

That may well be important if the steelman turns out to be nothing *more* than metaphor. If all I'm doing is laying out a metaphor for privacy, then I'll lose interest pretty quick because what I'm *trying* to do is classify privacy. I want string comprehension to be in the same class as behaviorism. I don't want to draw super-flawed analogies between them.

But the distinction ([non]invertibility) might very well help evaluate the believability of the steelman.

> If in the limit of behavioral investigation we find no more semantic ambiguity than
> the semantic ambiguities we experience when attempting to understand an others
> language, [...]

I don't think it is. I think there is a no-go lurking that is associated by EricS's recent mention of the student laughing because the insight was "at his elbow". And it's (somehow) associated with Necker cubes, paradigm shifts, and even a "loss of innocence" you see in people who've become cynical, the difference between work and play, "flow", etc. It's related (somehow) to the opportunity costs of using decoder X instead of decoder Y. As SteveS pointed out, one's participation in the landscape *changes* the landscape.

This is fundamental to the steelman we're building. It's not merely epiphenomenal. By decoding the surface of the ... [ahem] ... "patient", you are *manipulating* the patient. You can see this directly in your worry about [ab]using Frank as our privacy touchstone.

I wanted to set the stage for this in the formulation of 1st order privacy (by obscurity) by laying out the thing to decode side-by-side with the decoder, evoking a UTM where the tape contains both the computation and the description of the machine that can do the computation ... but I thought that would interfere with my main targets EricC and Nick. If they reject the steelman, then this becomes a tangent project of numbers, groups, and codes ... which is cool, but not what I intended [†].

[†] I'd love to sit in on a read of Gentry's paper, though it'd all be over my head.


-- 
☣ uǝlƃ



More information about the Friam mailing list