THANK YOU 800 FOLLOWERS. — Novels, illustrations, and essays on Steemit

 

In between such things, I'll finish all the serialized science fiction I've started. During the last month, I was finishing things up for print for April, and can get back to basically underpaid fiction scribbling on Steemit. ( I can't post things I send into print on Steemit, at least not for a while. Have to write something entirely different. Also don't feel like doxing myself at the moment . . . Would like to achieve a respectable number of reader before I do that . . . )

Been also learning more about how the platform works. You can read my previous post regarding where I think social networks and social media is going, where Steem and Steemit are going.

You can follow my comments, which is where I mostly discuss such things with others. Fun, positive discussion about rewards curves, some of the bidding and antibidding wars, trending page, and other things that cannot be mentioned in polite company. I'll try to keep that nonsense out of future posts. My rewards for talking about literature, for instance, are much greater. Much higher. That's good in way. Let's be positive, or at least pessimistically optimistic, like Shostakovich's tenth symphony.

Remember what's most important in such debates: All steem data is fair game for journals, so far as experimental economics is concerned, because the test subjects are playing for real valuables if they cash out. In that sense, Steemit is the largest social engineering experiment ever conducted. Thank you Hive account@ned and Hive account@dan for contributing to science. (Seriously, thank you guys. There is no way anybody in academia can get these kinds of sample sizes properly incentived. And as Vernon Smith argued any economics gameplay where the participants aren't playing for real money is spurious. He got a Nobel for that observation, among other things.) I'll have a few papers out shortly.

I'll get around to reviewing the books mentioned in my previous posts. Really.

What I want to do is cover Margaret Boden's 2006 book on AI, Stephen Wolfram's 2002 book, Ludwig Mises's Human Action, and Bob Coecke's 2017 book. That'll keep me busy.

ALSO . . .

I think I know how to create SMT-equivalents right now on any interface, without waiting for Steem Inc. From a paper a while back.

Once you're on the platform, you can create seal/unseal operations without encryption, with only encapsulation.

It's a know result. Not new, but nobody is using it.

Encapsulation in plain language is . . .

Suppose I have an object called M (me) and it sends a message〈 X 〉to V.

V outputs a message 〈 A 〉 to memory and sends me a message with the location.

Had instead M sent 〈 X 〉 to W, it'd get 〈 B 〉 back.

The algorithm that interprets 〈 X 〉 is inside the other objects, abstracted out, information lost, from the perspective of M.

Anyway, you only need seal/unseal for public key; that's what a key and it's inverse key realize.

V has a process that takes my messages; I don't see it.

I only see V; rather I work with interfaces.

That means you can change the program inside V, and nothing else in the application needs to change just because of that. Of course encapsulation makes life easier. By far. If you need to patch other parts of an application just because some small part of it changed, yet those parts do nothing different, you're going to run out of programming manpower pretty soon, as the projects becomes larger.

But it can also do other neat things. Apparently.

You should be able to pull off SMT-equivalents using it.

The author of the paper (in *Concurrent PROLOG, Volume 2, Cambridge: MIT Press, 1987) is well known. It's Daniel Bobrow when he was at Xerox.

I'll probably make a post about it.

If you are on one system (no encryption needed) with many users or actors, or one network that already has encryption between systems/users, you only need logic programming and encapsulation to realize seal/unseal for messages. That was the result.

Once you have a sealed message and ability to unseal it, you have token creation. And token destruction by just messaging all and sundry the complementary key or information. And making not of the act and collecting back messages confirming it.

Logic programming by the way is based around the following format:

A <--- X_1, . . . , X_m | Y_1 , . . . , Y_n ; n,m ≥ 0.

You type a goal A B C . . . and this creates a list of things to do. As things get done, they eliminate parts of the goal.

When nothing left, halt. Thus computation over time.

You should have side effects that you can read when done.

X's suggest what order to perform processes Y's based on some preliminary calculations, to make things more efficient. You might have the heuristics m=0, but that's probably not efficient.

More on all this later. Later.

ABOUT ME

I'm a scientist who writes fantasy and science fiction under various names.

The magazines which I currently most recommend:
Magazine of Fantasy and Science Fiction
Compelling Science Fiction
Writers of the Future

---

PRACTICAL THINKING — LATEST — RECENT — POPULAR
FISHING — thinking about tools and technology

©2018 tibra.
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License . . . . . .   Text, illustrations, and images: Hive account@tibra. #thealliance symbol is by courtesy of Hive account@enginewitty.