Types of data: numbers, text, images, time · Working with Data

Almost every dataset you will touch in this course — and in your working life as a builder — is some combination of four basic types: numbers, text, images, and time. They behave differently. They go wrong differently. They get cleaned differently. They get fed to models differently. Spending fifteen minutes learning how to recognise each one saves weeks of confusion later, when a column that looks numeric turns out to be a date string with a typo, or a column that looks textual turns out to be a tiny image encoded badly.

Numbers

The most familiar shape. Counts, amounts, ratios, scores. A loan amount, a temperature reading, a NEPSE close, an exam score, a number of children in a household.

Two important sub-distinctions inside “numbers”:

Continuous vs. discrete. A temperature can be 22.3°C; an exam score is usually a whole number; a count is always a whole number. Discrete values look numeric but sometimes behave like categories — a Likert scale 1-5 is “numbers” mathematically but is really five categories pretending. Tell them apart by asking: does the difference between 3 and 4 mean the same thing as the difference between 4 and 5? For temperature, yes. For a “satisfaction rating”, debatable.

Ratios vs. intervals. Some numbers have a meaningful zero (height, weight, NPR), others don’t (Celsius temperature). The difference matters when you scale data for models — multiplying NPR by 2 has meaning; multiplying 20°C by 2 does not.

How numbers go wrong:

Wrong unit (rupees vs. lakhs vs. crores — the same column has all three)
Wrong precision (some rows are integers, some have 6 decimal places)
Missing as zero (a zero where the value was actually unknown — disastrous)
Bad outliers (a 124°C temperature that is really a sensor failure)

Text

The shape that has grown the fastest in importance, thanks to language models. Names, addresses, free-form comments, product descriptions, news articles, transcripts of conversations.

Text is the messiest single data type. A single column of “city names” in a Nepali dataset can contain:

Kathmandu, KATHMANDU, kathmandu (case)
Kathmandu, Kathmandu, Nepal, KTM (variants)
काठमाडौं, कान्तिपुर (Devanagari, including the older name)
Kathmandu , Kathmandu (trailing/leading whitespace)
Empty strings, the literal word “unknown”, NA, N/A, null

All of these are the same place. None of them are the same string. Cleaning text — and especially Nepali text — is most of Chapter 3.

Images

Photographs of receipts, scans of citizenship cards, screenshots of NEPSE quotes, satellite tiles of paddy fields, X-rays. Pixels arranged in a grid, with three numbers per pixel (red, green, blue) — or one number per pixel for grayscale.

For most builders most of the time, image data does not arrive as raw numbers. It arrives as files: receipt-2026-06-23.jpg, xray-001.png. You load them with a library (PIL / Pillow, or OpenCV) and the library hides the raw pixel arrays behind a friendly interface.

Image data has its own ways of going wrong:

Resolution mismatch. Some receipts are 4000×3000, some are 480×640. Most models need a fixed input size.
Orientation. Phone cameras embed orientation metadata that some libraries respect and some don’t. The same image displays right-side-up in one tool and upside-down in another.
Lighting and quality. Half the dataset is well-lit indoor scans; half is poorly-lit outdoor phone snaps. The model trained on one struggles on the other.
Personally identifying content. A receipt photo includes the cashier’s face. A scanned citizenship card shows everything. Sensitive even when you do not intend it to be.

We touched on images briefly in Course 01 (Tesseract OCR). Course 02 will not go deep into image-heavy modelling — that lives in Course 03. But knowing the shape exists matters when planning a project.

Time

The most under-respected data type. Timestamps, durations, dates, recurrences.

Time is harder than it looks because it has structure that other types do not:

Multiple calendars. Nepali datasets mix Bikram Sambat (BS) and AD dates regularly. A column that says 2080-04-15 could mean either — and the right answer depends on context. 2080 BS = 2023 AD (approximately). If you assume the wrong calendar, all your time-based analysis is off by ~57 years.
Time zones. Nepal is at UTC+05:45 — one of the only places on earth at a 45-minute offset. APIs sometimes return UTC times. If you treat them as Nepal time, you are off by nearly six hours, which is enough to put events on the wrong day.
Granularity. “When did this happen?” can mean date, day-of-week, hour, minute, second. Choose the granularity your problem actually needs; don’t store more than that.
Gaps and ordering. A time-series with missing days is treacherous. A naïve average across days is wrong if half the days are missing.

A real Nepali example with all four

A single month of Khalti statements gives you all four:

Numbers: transaction amounts in NPR.
Text: vendor names, sometimes Devanagari, sometimes Roman, sometimes both — and inconsistent across rows for the same vendor.
Images: scanned receipt attachments for some rows (jpg/png files referenced by name).
Time: transaction timestamps in Nepal time, with edge cases for ones initiated late at night that settle the next day.

A serious project on this data — say, “summarise where my money went this month” — has to touch all four types. The numbers need unit-checking. The vendor names need normalisation. The receipt images may need OCR. The timestamps need careful handling around day boundaries and timezone. None of those is the model. All of them are the work.

Check your understanding

Quick check

—

A column in a Nepali survey dataset contains the value `2080-04-15`. Without more context, what is the most accurate thing to say about it?

It is unambiguously a date in 2080 AD.
It could be either Bikram Sambat or AD; the right interpretation depends on context, and assuming the wrong one introduces a ~57-year error in any time-based analysis.
Dates always default to AD in Python.
The dataset is broken because dates should be in ISO format.

Quick check

—

You are designing the schema for a new dataset of Khalti-style transactions. Which combination of types best describes a single row in the dataset?

A single text field containing all the information for the row.
A number (amount), a text field (vendor name), a timestamp (when), and optionally an image reference (receipt photo) — i.e. the row touches all four major data types this section described.
Only numbers and image references.
Only time and text; numbers are derived later.

What comes next

You have the four shapes in mind. The next section walks through a dataset’s life — the journey from “this number was written down by a clerk in Birgunj” to “this number is now a feature in a trained model.” Understanding that journey is the difference between treating data as raw material and treating it as a faithful representation of something real. Both views are useful. Neither is the whole truth.