Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

typo in obtheory #16

Open
band opened this issue Jan 8, 2019 · 10 comments
Open

typo in obtheory #16

band opened this issue Jan 8, 2019 · 10 comments

Comments

@band
Copy link

band commented Jan 8, 2019

In Section 1. Logical Notation

I think "p ⇔ q read p if-and-only-if q, true when true both are true or"
should be
p ⇔ q read p if-and-only-if q, true when both are true or"

("true when true both" has an extra "true" ?)

orcmid added a commit that referenced this issue Jan 8, 2019
@orcmid
Copy link
Owner

orcmid commented Jan 8, 2019

Thanks Bill. I have repaired the obtheory.txt file and will close this once the web article is also updated as part of a pending cleanup.

@orcmid
Copy link
Owner

orcmid commented Feb 20, 2019

The web page was updated on 2018-01-18 to display obtheory.txt 0.2.5 notation definitions having the correcction.

@orcmid orcmid closed this as completed Feb 20, 2019
@band
Copy link
Author

band commented May 9, 2019

Another typo in obtheory (Q: shall I just put all typos into this issue?):

Lines 33,34:
* There are two selector functions, ob.a(z) and ob.b(z) that given
any ob and determine an ob as their result.

"given any ob determine an ob ...." -- the "and" does not belong there.

@orcmid
Copy link
Owner

orcmid commented May 9, 2019

Another typo in obtheory (Q: shall I just put all typos into this issue?):

Is in ob.txt, not obtheory.txt. I moved it to new open issue #19.

Thank you for these -- they become invisible to the author :)

@band
Copy link
Author

band commented May 9, 2019

Doh! Sorry about the mixup; I am switching back and forth between the two documents.

orcmid added a commit that referenced this issue May 10, 2019
Resolve issue #16 typo and issue #20 enclosure explanation, thanks to review by @band.  Further smoothing of the text at the same time.
@band
Copy link
Author

band commented May 19, 2019

Another typo? I'm just reading ahead and came across this in lines 228-229 (Section 4. Notes and References):

Representations of strings that have
other strings as their beads was also introduced by Doug Ross and

should "beads" be "heads"?

@orcmid
Copy link
Owner

orcmid commented May 20, 2019

Another typo? I'm just reading ahead and came across this in lines 228-229 (Section 4. Notes and References):
Representations of strings that have
other strings as their beads was also introduced by Doug Ross and
should "beads" be "heads"?

Nope, beads. Think about a string data format in which any bead of the string is a single character or is a string imbedded (not concatenated) at that point. The head of a such a string is a single string bead, and that may be either a single character or an embedded-string.

A list structure is easier to think of in this regard. Think of a linked list in which any element of a non-empty list is a literal symbol or the enclosure of such a list structure. :)

That's the counterpart oMiser idiom for nesting strings as beads within a superior string.

@orcmid
Copy link
Owner

orcmid commented May 20, 2019

@band I just noticed a difference between head/tail and first/rest. In the normal formulation of strings, the head of a string is another string, as is the tail of the string. First/Rest has first be the first element (e.g., a character) and rest is of the same type (i.e, a list form). Some systems require that all elements of a list be of the same type and I suppose one can interpret a string (typically) as a list of characters or an equivalent array/vector. This gets into (intended) interpretation and representation goodies.

PS: This figures into the semantics of concatenation. Concatenation takes two things of the same type to make a new one with one stringed after the other. In list processing, this is the interpretation of append. Pairing (e.g., CONS or ob.c) is not the same thing most of the time.

@orcmid orcmid reopened this May 20, 2019
@band
Copy link
Author

band commented May 20, 2019

OK. I had an intuition that I needed to read more before saying "typo?".

I was also thinking about Lisp atoms and lists after reading your comment. And I agree that the intended use of a list for representation is an interesting question. Jumping up several levels, the idea of using a relational database to house the information in an address book is also a representation question. Is this right? Is "I have atoms and lists, but want to, say, parse, English sentences" also in this representation and interpretation arena?


Also, I do see that pairing with ob.c allows for collections of mixed ob's in one unit.

@orcmid
Copy link
Owner

orcmid commented May 22, 2019

... Jumping up several levels, the idea of using a relational database to house the information in an address book is also a representation question. Is this right? Is "I have atoms and lists, but want to, say, parse, English sentences" also in this representation and interpretation arena?

The TL;DR: Yes

It is turtles everywhere.

As @band pointed out in a phone conversation, what gets nailed down to create stable levels involves ontological commitment. We grant being to some level, have no doubt of it, and then move upward and/or downward in the creation of connected stable tiers. I find that (apart from over-use of "paradigm") the treatment in Plato and the Nerd is very informative and useful in this regard.

orcmid added a commit that referenced this issue May 23, 2019
Use this place for some reconciliation of interpretation, representation, manifestation and ontological commitment, as per Issue #16 commentary and the blog characterization
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants