Talk:Import–export (logic)

Philosophy Low‑importance

	Philosophy portal This article is within the scope of WikiProject Philosophy, a collaborative effort to improve the coverage of content related to philosophy on Wikipedia. If you would like to support the project, please visit the project page, where you can get more details on how you can help, and where you can join the general discussion about philosophy content on Wikipedia.PhilosophyWikipedia:WikiProject PhilosophyTemplate:WikiProject PhilosophyPhilosophy
Low	This article has been rated as Low-importance on the project's importance scale.

Requested move 16 August 2021

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: Moved to Import–export (logic). It seems there is strong agreement on all of the following points: 1) this topic is not primary for "Import-Export" or similar formulations. 2) RS usage does not compel us to capitalize "Export". 3) an en-dash is the most appropriate separator for the title terms. (non-admin closure) Colin M (talk) 22:07, 5 September 2021 (UTC)[reply]

Import-Export (logic) → ? – The primary topic here is something on Import and export or Exim Bank. This logical term is notable, but I don't see Import-Export as a common name for it in a source review, and am not sure what the common name is. User:力 (power~enwiki, π, ν) 18:14, 16 August 2021 (UTC)[reply]

I'm fairly sure Import-Export is the only term for it aside from a few minor variations (e.g. "IE", "Import/Export"). Botterweg14 (talk) 19:49, 16 August 2021 (UTC)[reply]

~~Move to Import-export (logic)Import-export (logic)~~. Without disambiguation, the term is primarily a concept of international trade. Per MOS:HYPHENCAPS and MOS:TITLECAPS, the 'E' should be lowercased. (I notice lowercased "import-export" in a section heading of this cited source.) I also wonder if the hyphen should be an en dash or a slash. —⁠ ⁠BarrelProof (talk) 22:37, 16 August 2021 (UTC)[reply]

I've gone ahead and moved it. I've retained the caps since it's a proper name and the dash since that's how I usually see it printed, but I don't have strong feelings about that. Botterweg14 (talk) 23:09, 16 August 2021 (UTC)[reply]

I don't think it's a proper name. —⁠ ⁠BarrelProof (talk) 00:23, 17 August 2021 (UTC)[reply]

Move to Import–export (logic) (with an en dash, per discussion below). Hyphen version struck through above. —⁠ ⁠BarrelProof (talk) 23:10, 31 August 2021 (UTC)[reply]

Support ~~Import-export (logic)~~ Import–export (logic) - also not seeing it as a proper name. I was able to pull up the first three sources (Sider, Egre/Rott, Gillies) and the 1st and 3rd of those use lowercase, with the 2nd using one instance of each. The page should not have been moved prior to closure of this discussion, but it's a small difference regardless. ASUKITE 20:48, 24 August 2021 (UTC)[reply]
- Any thoughts on Import–export (logic) or Import/export (logic)? —⁠ ⁠BarrelProof (talk) 19:47, 26 August 2021 (UTC)[reply]

Good point, I always have trouble noticing dash types and italics. this section of the manual of style says we should not use a hyphen. I would support Import–export (logic). Redirecting Import-Export (logic) there will cover the hyphen. MOS:SLASH says to avoid slashes joining two words, but doesn't mention article titles specifically. I've always preferred dashes as slashes serve a different purpose outside mainspace but I'm not opposed to them. ASUKITE 00:08, 27 August 2021 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Bad logic in discussion section

The article states that some approaches reject import-export (P ↦ (Q ↦ R)) ↔ ((P ∧ Q) ↦ R) as a general principle (e.g. for natural language conditionals) motivated by cases such as

1. If you strike the match and it lights, it will light. ("intuitively true")
2. If the match lights, it will light if you strike it. ("intuitively false")

of which the first is described as "intuitively true", while the second is described as "intuitively false" because the match might light for some other reason that being struck. But this is wrong on multiple levels. Firstly this is not an example of import-export (as described above and in the article) at all; the second statement is a non sequitur, unrelated to the first by (P ↦ (Q ↦ R)) ↔ ((P ∧ Q) ↦ R) or by any other valid form of deduction. Secondly, the second sentence is indeed "intuitively false", but not for the implied reason that the match could light from another cause (statement 2 never said "If the match lights, it must have been struck", nor can such a statement be validly deduced from either statement 2 or 1 or a combination of both), rather because the consequent is itself an implication ("it will light IF you strike it") which does not intuitively follow from the antecedent ("If the match lights, then..."). Formally, if define P as "You strike the match", and Q as "the match lights", then the two statements are equivalent to:

1. (P ∧ Q) ↦ Q ("If (P)you strike the match (∧)and (Q)it lights, (↦) (Q)it will light.")
2. Q ↦ (P ↦ Q') ("If (Q)the match lights, (↦) [ (↦) (Q')it will light if (P)you strike it ].")

The first is in fact a tautology regardless of what P and Q are, by definition of the logical conjunction (∧ or "AND"). Application of the import-export rule to the first statement does not yield the second, but rather (P ↦ (Q ↦ Q)) (or "if you strike the match, then [it will light IF it lights]"), which is trivially true since Q ↦ Q is a tautology. Statement 2 is not supported in any way (import-export or otherwise) by statement 1, and is intuitively false for this particular P and Q, since in the bare fact of the match being lit (Q) by unspecified cause does not imply either that the match must have been struck (though statement 2 never said that!) or that it would reliably light in response IF it were struck (what statement 2 actually claims); the match could have been lit due to having been struck, or could be lit due to some other cause after having previously failed to light from upon being struck (bad match?), or could be lit as a result of some other cause without ever having been struck (and we may never know the counterfactual of whether that particular match would have lit upon striking if it had been struck without already being alight).

Lastly, by strict material implication statement 2 would be true if read as "If the match is now lit, then if it has been struck it will now be lit", although this is again a tautology which is true purely by the definition of material implication (which does not imply the existence or nature of any causal relation), since P ↦ Q is equivalent to ¬(P ∧ ¬Q), which is automatically satisfied no matter the value of P so long as Q is true. However, if statement 2 is read unambiguously as "If the match is now lit, then in general if is struck then it will light upon being struck" (Q ↦ (P ↦ Q'), Q ≠ Q'), which is subtly but critically different and is probably the more intuitive reading of the statement as presented in the article, then this statement is both intuitively and materially not true, as described above. The distinction rests on whether the event Q' is interpreted as merely the match being lit in general (Q = Q'), or more specifically as the match being becoming lit promptly after (and presumably as a result of) being struck (Q ≠ Q').

But in any case, neither interpretation of statement 2 is in any related to statement 1 by import-export (or any other rule of logic), so this example really has nothing to do with import-export and is not in any way an example of a problem or inconsistency related to import-export.