TYPE in WPS Spreadsheet: Identify Result Types without Mistaking Them for Formula Presence
Inspect WPS value-type codes, distinguish numeric text and logical results and audit mixed formulas without using TYPE as a formula-presence detector.
Verification status: See the evidence and test scope described in this guide. How formula examples are checked
Quick answer: TYPE returns a numeric code identifying a value’s type. WPS’s lesson gives 1 for numbers, 2 for text, 4 for logical values, 16 for errors and 64 for arrays. The code describes the resulting value, not the presence of a formula.
Availability and version history
- Introduced: documented by 2019-06-12 in WPS material; the first release is not established.
- Availability: current WPS Windows documentation identifies the function as built-in; the dedicated historical lesson has a blank edition field.
- Scope: exact supported builds and other WPS clients remain unverified.
- Checked: October 14, 2026. Documentation and independent examples; no native WPS execution.
Syntax and the documented code table
=TYPE(value)
Value may be a WPS worksheet value such as a number, text or logical result. The historical walkthrough explicitly lists these codes:
| Value category | TYPE code |
|---|---|
| Number | 1 |
| Text | 2 |
| Logical value | 4 |
| Error value | 16 |
| Array | 64 |
The source gives a text example producing two. Its array code does not by itself specify every array-entry, multi-cell reference or dynamic-output behavior. This guide’s worked formulas therefore use scalar values and do not assume that passing a range always produces 64.
A contradictory sentence in the historical source
One note says TYPE can determine whether a cell contains a formula, then immediately explains that it only identifies the result or value type and returns a formula’s result type. Those statements cannot establish a formula-presence test.
The current Windows page also describes identifying the type of a returned value. This guide follows that result-type contract. A literal number and a formula producing the same number can share code one; TYPE alone cannot distinguish their origins.
Example 1: classify a deliberately mixed column
Enter the values and formulas below in A2:A8. Put =TYPE(A2) in B2 and fill down.
| Cell | Input instruction | Expected value category | B, expected code |
|---|---|---|---|
| A2 | Type the number 23 | Number | 1 |
| A3 | Enter ="23" |
Text | 2 |
| A4 | Enter =TRUE() |
Logical TRUE | 4 |
| A5 | Enter =FALSE() |
Logical FALSE | 4 |
| A6 | Enter =NA() |
Actual error | 16 |
| A7 | Enter =10+13 |
Number | 1 |
| A8 | Enter ="" |
Empty text result | 2 |
A2 and A7 have the same resulting number and the same code, although only A7 was entered as an arithmetic formula. A3 looks numeric but is explicitly text. A8 is an empty text value, not a claim about the separate semantics of an untouched blank cell.
NA creates an actual #N/A error for the error-type control. Typing the characters “#N/A” as a quoted text result would instead create text and receive code two.
Example 2: report category counts
For B2:B8, independently expected counts are:
| Formula | Meaning | Expected count |
|---|---|---|
=COUNTIF(B2:B8,1) |
Numbers | 2 |
=COUNTIF(B2:B8,2) |
Text values | 2 |
=COUNTIF(B2:B8,4) |
Logical values | 2 |
=COUNTIF(B2:B8,16) |
Error values | 1 |
The counts total seven, matching the number of inspected scalar inputs. COUNTIF operates on the numeric TYPE codes, so source errors have already been classified rather than passed through as aggregation inputs.
Adding the codes themselves gives thirty, but that total has no useful type-count meaning. Codes are category identifiers, not weights or severity scores.
Advanced example: inspect how a formula changes its output type
Put numeric 72 in D2 and threshold 60 in E2. Compare these result formulas:
=IF(D2>=E2,1,0)
=IF(D2>=E2,TRUE(),FALSE())
=IF(D2>=E2,"Pass","Review")
The independently expected TYPE codes are 1, 4 and 2. The underlying threshold decision is the same, but the chosen return values have different types.
Changing D2 to 55 changes the three returned values to zero, logical FALSE and text Review. Their TYPE codes remain 1, 4 and 2. This is useful when a downstream formula expects a stable type regardless of which condition branch is selected.
IF chooses the values; TYPE reports their resulting categories. It does not determine whether the decision was correct.
Advanced example: distinguish an error category from an error identity
TYPE assigns code sixteen to the actual error produced by NA. ERROR.TYPE has a different purpose: its historical table assigns code seven to #N/A specifically.
For =TYPE(NA()), the expected code is 16. For =ERROR.TYPE(NA()), it is 7 under the separately documented ERROR.TYPE mapping. Do not substitute one code table for the other.
ISLOGICAL is another distinct test: it returns a Boolean answer about logical type, rather than TYPE’s numeric category four.
Boundaries and verification
The dated source explicitly names arrays but does not settle this guide’s unworked array-entry and reference-shape questions. Blank-cell coercion, new value kinds and current maximum code sets also remain unverified.
Use TYPE to inspect a result contract alongside the formula and source data. Do not turn an unsupported formula-presence claim into a validation rule. All new examples are independently modeled controls, with no native WPS execution.
References and verification
- WPS Academy: TYPE, 2019-06-12 (Chinese).
- Current WPS Windows TYPE introduction.
- Editorial testing standards.
Complete function-specific sources reviewed. Expected results are independently derived controls, not native application captures. Formulas use English names and comma separators; check the installed locale.