I64 vs F64

You finished Introductory. Easy will not re-teach hello. We sharpen types: I64 for integers, F64 for floating-point. Choosing the right type is how you keep meaning honest.

I64 is a 64-bit integer. Counts, indexes, flags, and whole quantities live here. F64 is a floating-point type for fractional magnitudes — approximations of real numbers with the usual binary floating tradeoffs.

The still binds a=3 as I64 and b=3.5 as F64. Same digit three, different kinds of three. Saying the type aloud when you declare is how you stop mixing them by accident.

Mixing carelessly truncates or loses precision. Stuffing 3.9 into an integer path can drop the fraction. Doing money-like math in binary floats surprises people who expected decimal pennies. Know which world you are in.

Promotion and conversion exist in C-family languages. Explicit casts document intent; silent mixes hide bugs. Prefer clarity while learning: keep integer work in I64 and fractional work in F64 until you mean to convert.

Name variables after meaning: count, ratio, price_cents (integer cents!) — not x1, x2. Types and names together form a tiny specification.

TempleOS/HolyC type letters (I64, F64, U8, U0) make width and kind visible in the name. That visibility is a teaching gift compared with plain int that means different things on different machines historically.

When debugging wrong numeric results, ask type first: did I use F64 where I needed exact integer modular arithmetic? Did I use I64 where I needed a fraction? Type bugs look like logic bugs until you check declarations.

Easy continues into switch, arrays, strings, heap notes, bits, enums, includes, JIT feel, and a parameterized utility. Types are the foundation under all of that.

Hold I64 vs F64 as a behavior, not a vocabulary flashcard. Ask: what inputs matter, what action runs, what is visible afterward? If you cannot fill those three slots, you are skimming. Write them in a margin before the quizzes.

When something fails around I64 vs F64, change one thing. Read the error or the wrong output. Return to the still. Do not rewrite the whole example when one token is wrong. Calm retries beat dramatic rewrites.

Compare I64 vs F64 with the nearest habit you know from C, Python, or plain English — and name the difference out loud. HolyC's teaching value is often the delta: familiar family, different ergonomics.

Open-book checks for I64 vs F64 reward careful reading of this page, not trivia about the website chrome. The right answer is a claim we actually made. Near-miss choices sound technical; they fail because they invert the lesson.

Before the still, predict. After the still, compare. That predict-compare loop is how I64 vs F64 becomes muscle memory. Passive rereading without prediction is how you forget by tomorrow.

Say a one-sentence teaching version of I64 vs F64 you could give a friend. If the sentence needs five caveats, your mental model is still foggy — tighten it. Precision in speech precedes precision in code.

As you continue, I64 vs F64 will reappear inside larger programs. Functions wrap it. Branches choose it. Loops repeat it. Learning it cold now prevents cargo-cult pasting later.

Keep a scratch note for I64 vs F64: one worked example, one failure you fixed, one sentence of definition. That tiny notebook beats highlighting the same paragraph five times.

If you are tired, stop at the still for I64 vs F64 and trace tokens with a finger: type, keyword, operator, semicolon. Rushing past tokens is how mysteries are born. Slow eyes make fast programmers.

Wrong answers on I64 vs F64 quizzes are teachers too. Read the explain line. Relate it back to the still. A corrected misconception sticks harder than a lucky first guess.

Emulators, archives, and dialect notes may disagree on edges around I64 vs F64. We teach the classic shape on this page. When you port elsewhere, read that environment's docs and adjust — without abandoning the core idea.

Finally for I64 vs F64: write the still from memory on paper, then uncover the page and diff. Memory retrieval is the study method that survives the weekend.

Worked example mindset for I64 vs F64: shrink the idea until you can execute it on a napkin. If the napkin proof fails, the full program will not save you. Enlarge only after the tiny case is honest.

Common confusion near I64 vs F64: mixing the name of the idea with a neighboring idea from C or Python. Write one contrast sentence — "this is X, not Y" — and keep it beside the still. Contrast sentences prevent weeks of soft bugs.

Practice drill for I64 vs F64: change one literal in the still by a small delta, recompute the expected result by hand, then confirm. Single-delta drills expose off-by-ones and wrong-type assumptions faster than rereading the same paragraph.

Teaching standard for I64 vs F64: you should be able to explain precondition, action, and postcondition without looking. If any of those three is fuzzy, that fuzzy slot is the real lesson hiding inside the lesson.

I64 a = 3;
F64 b = 3.5;

First line: I64 a bound to 3. Second: F64 b bound to 3.5. Two declarations, two kinds of quantity. Trace the types before the values.

Pitfalls: writing 3.5 into an I64 without thinking; using floats for exact currency; forgetting which name is which type; assuming I64 and F64 compare with no surprises; treating types as optional decoration.

Types chosen on purpose. Next: switch — many-way branch.