Another great basics topic, which came up in the comments from last fridays “logic” post, is the
\ndifference between syntax and semantics. This is an important distinction, made in logic, math, and
\ncomputer science.<\/p>\n
The short version of it is: syntax is what a language looks like<\/em>; semantics is what <\/p>\n In terms of logic, the syntax is a description of what a valid statement looks like: what the pieces of a statement are, and all of the different ways that the pieces can get put together to The semantics are the meanings<\/em> of the statements – and the rules that tell you how to So, for example, I can show you a simple statement: Now, suppose I tell you “P” is a predicate with two parameters, that says the second<\/em> One of the interesting things about logic inference rules is that they are semantics independent<\/em> – given a set of statements in FOPL, I don’t need to know<\/em> what the predicates mean, or what objects are represented by the primitives. I can still perform inferences, Another great basics topic, which came up in the comments from last fridays “logic” post, is the difference between syntax and semantics. This is an important distinction, made in logic, math, and computer science. The short version of it is: syntax is what a language looks like; semantics is what a language means. It’s basically […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[74,33],"tags":[],"class_list":["post-293","post","type-post","status-publish","format-standard","hentry","category-basics","category-logic"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p4lzZS-4J","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/posts\/293","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/comments?post=293"}],"version-history":[{"count":0,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/posts\/293\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/media?parent=293"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/categories?post=293"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/tags?post=293"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\na language means<\/em>. It’s basically the distinction between numerals (syntax) and
\nnumbers (semantics).<\/p>\n
\nform valid statements. The way that they’re put together also imply how you can take them apart – that is, if you know that a predicate is a predicate name, followed by parens containing arguments to the predicate separated by commas, then given a valid predicate, you can say what the predicate name is, and what the arguments to the predicate in that statement are.<\/p>\n
\ntake a syntactically valid statement, and figure out what it means. So, for example, it includes rules that describe how to find out what object\/entity is referred to by a particular primitive name, and what kind of property is meant by a particular predicate.<\/p>\nP(\"m\",\"f\")<\/code>. Just by looking at it, you now that it’s a simple predicate statement over two primitives. You can tell that the
\nname<\/em> of the predicate is “P”, and that the two arguments to the predicate are “m” and “f”. But what does it mean<\/em>? That, you can’t find out until I tell you what the semantics<\/em> of the statement are.<\/p>\n
\nparameter is a parent of the first; that “m” is me; and that “f” is my father, then you can see that the meaning of the statement is “My father is one of my parents”.<\/p>\n
\ngenerating new<\/em> true statements without knowing what they mean. But after I’ve got the
\nresult of the inferences, if you tell me what the predicates mean and what the primitives represent, the statements that I inferred will<\/em> be true – even though I didn’t know what I was reasoning about when I did the inference.<\/p>\n","protected":false},"excerpt":{"rendered":"