When a learner can reproduce a familiar example but a small variation causes confusion, the problem is usually an incomplete model rather than a lack of effort. The fastest useful response is to expose the hidden state and test one boundary at a time.

JavaScript Intl.NumberFormat turns a numeric value into a locale-sensitive display string according to a resolved locale and a precise option set. It is a formatter, not a parser or a currency converter. Mastery means separating the stored number from its presentation, predicting interacting digit and rounding options, inspecting resolvedOptions and formatToParts, and testing version-sensitive features in the target runtime. This guide begins with that mechanism, then develops it through worked traces, deliberate mistakes, explained practice and transfer decisions.

The aim is independent reasoning. A learner should be able to predict behaviour, locate the earliest wrong assumption, use a safe diagnostic procedure and defend a design choice in a new project.

Punggol families can use the guide in short sessions around homework, CCAs and rest. The activities are proposed learning exercises, not claims about a physical branch, timetable, class size, fee, school relationship or guaranteed result.

Use disposable data and repositories, preserve backups, and check version-sensitive details against the official source. Current documentation settles a technical contract; observation and explanation turn that contract into usable knowledge.

Intl.NumberFormat formats an existing mathematical value; it does not convert currencies or change the underlying number. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is showing SGD and USD symbols around the same number and calling that exchange conversion. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Separate value calculation, currency identity and final display into three steps.

For the Formatting is presentation, not arithmetic chapter on JavaScript Intl.NumberFormat, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on showing SGD and USD symbols around the same number and calling that exchange conversion. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const value=12.5; new Intl.NumberFormat('en-SG',{style:'currency',currency:'SGD'}).format(value)

Four purposeful transfer cases

Case 1: canteen budget. Predict the rule using Singapore-dollar amounts and percentages. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: library dashboard. Contrast the rule using loan counts in several interface locales. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: CCA fundraiser. Stress-test the rule using currency totals, targets and compact summaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: science display. Explain the rule using measurements with unit labels and controlled precision. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers showing SGD and USD symbols around the same number and calling that exchange conversion.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Separate value calculation, currency identity and final display into three steps.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.NumberFormat syntax. For this chapter, useful prompts are: “What did you expect from Formatting is presentation, not arithmetic?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing showing SGD and USD symbols around the same number and calling that exchange conversion be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny family planner with cost ranges and accounting-style negatives. Include one ordinary case, one boundary and one deliberate failure caused by showing SGD and USD symbols around the same number and calling that exchange conversion. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Formatting is presentation, not arithmetic, separate the documented JavaScript Intl.NumberFormat mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

The runtime canonicalises requested locales and resolves a supported locale using the selected locale-matching policy. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is assuming the first requested language tag is always used exactly. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Call supportedLocalesOf and inspect resolvedOptions().locale in the target runtime.

For the Locale negotiation chooses an available locale chapter on JavaScript Intl.NumberFormat, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on assuming the first requested language tag is always used exactly. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const nf=new Intl.NumberFormat(['ban','id','en-SG']);
nf.resolvedOptions().locale

Four purposeful transfer cases

Case 1: CCA fundraiser. Contrast the rule using currency totals, targets and compact summaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: science display. Stress-test the rule using measurements with unit labels and controlled precision. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: revision tracker. Explain the rule using scores, ratios and percentage progress. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: family planner. Transfer the rule using cost ranges and accounting-style negatives. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers assuming the first requested language tag is always used exactly.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Call supportedLocalesOf and inspect resolvedOptions().locale in the target runtime.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.NumberFormat syntax. For this chapter, useful prompts are: “What did you expect from Locale negotiation chooses an available locale?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing assuming the first requested language tag is always used exactly be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny travel exercise with the same number formatted for several requested locales. Include one ordinary case, one boundary and one deliberate failure caused by assuming the first requested language tag is always used exactly. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Locale negotiation chooses an available locale, separate the documented JavaScript Intl.NumberFormat mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

With no style option, NumberFormat uses decimal formatting with locale data and default digit rules. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is reading grouping or punctuation as part of the numeric value. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Compare format output with the original number and resolved options.

For the Decimal style is the default chapter on JavaScript Intl.NumberFormat, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on reading grouping or punctuation as part of the numeric value. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

new Intl.NumberFormat('en-SG').format(1234567.89)

Four purposeful transfer cases

Case 1: revision tracker. Stress-test the rule using scores, ratios and percentage progress. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: family planner. Explain the rule using cost ranges and accounting-style negatives. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: travel exercise. Transfer the rule using the same number formatted for several requested locales. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: compatibility lab. Predict the rule using feature detection, resolved options and exact part arrays. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers reading grouping or punctuation as part of the numeric value.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Compare format output with the original number and resolved options.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.NumberFormat syntax. For this chapter, useful prompts are: “What did you expect from Decimal style is the default?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing reading grouping or punctuation as part of the numeric value be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny compatibility lab with feature detection, resolved options and exact part arrays. Include one ordinary case, one boundary and one deliberate failure caused by reading grouping or punctuation as part of the numeric value. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Decimal style is the default, separate the documented JavaScript Intl.NumberFormat mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Percent formatting represents the numeric input as a percentage, so 0.25 displays as twenty-five percent in ordinary settings. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is passing 25 when the stored ratio is 0.25 and accidentally displaying 2,500 percent. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Write whether the domain stores a ratio or percentage points before formatting.

For the Percent style scales for display chapter on JavaScript Intl.NumberFormat, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on passing 25 when the stored ratio is 0.25 and accidentally displaying 2,500 percent. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

new Intl.NumberFormat('en-SG',{style:'percent'}).format(0.25)

Four purposeful transfer cases

Case 1: travel exercise. Explain the rule using the same number formatted for several requested locales. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: compatibility lab. Transfer the rule using feature detection, resolved options and exact part arrays. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: canteen budget. Predict the rule using Singapore-dollar amounts and percentages. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: library dashboard. Contrast the rule using loan counts in several interface locales. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers passing 25 when the stored ratio is 0.25 and accidentally displaying 2,500 percent.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Write whether the domain stores a ratio or percentage points before formatting.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.NumberFormat syntax. For this chapter, useful prompts are: “What did you expect from Percent style scales for display?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing passing 25 when the stored ratio is 0.25 and accidentally displaying 2,500 percent be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny canteen budget with Singapore-dollar amounts and percentages. Include one ordinary case, one boundary and one deliberate failure caused by passing 25 when the stored ratio is 0.25 and accidentally displaying 2,500 percent. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Percent style scales for display, separate the documented JavaScript Intl.NumberFormat mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Currency style requires a well-formed currency option, and the code controls currency-specific defaults such as ordinary minor-unit digits. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is inferring currency from the locale or treating the symbol as unambiguous. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Store an ISO currency code with the amount and pass it explicitly.

For the Currency requires an explicit code chapter on JavaScript Intl.NumberFormat, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on inferring currency from the locale or treating the symbol as unambiguous. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

new Intl.NumberFormat('en-SG',{style:'currency',currency:'SGD'}).format(18)

Four purposeful transfer cases

Case 1: canteen budget. Transfer the rule using Singapore-dollar amounts and percentages. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: library dashboard. Predict the rule using loan counts in several interface locales. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: CCA fundraiser. Contrast the rule using currency totals, targets and compact summaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: science display. Stress-test the rule using measurements with unit labels and controlled precision. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers inferring currency from the locale or treating the symbol as unambiguous.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Store an ISO currency code with the amount and pass it explicitly.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.NumberFormat syntax. For this chapter, useful prompts are: “What did you expect from Currency requires an explicit code?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing inferring currency from the locale or treating the symbol as unambiguous be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny library dashboard with loan counts in several interface locales. Include one ordinary case, one boundary and one deliberate failure caused by inferring currency from the locale or treating the symbol as unambiguous. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Currency requires an explicit code, separate the documented JavaScript Intl.NumberFormat mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

currencyDisplay selects symbol, narrowSymbol, code or name without changing the numeric amount. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is using a symbol alone where several currencies could be confused. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Choose code or name when clarity matters more than compactness.

For the currencyDisplay controls the label form chapter on JavaScript Intl.NumberFormat, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using a symbol alone where several currencies could be confused. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

new Intl.NumberFormat('en-SG',{style:'currency',currency:'USD',currencyDisplay:'code'}).format(20)

Four purposeful transfer cases

Case 1: CCA fundraiser. Predict the rule using currency totals, targets and compact summaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: science display. Contrast the rule using measurements with unit labels and controlled precision. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: revision tracker. Stress-test the rule using scores, ratios and percentage progress. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: family planner. Explain the rule using cost ranges and accounting-style negatives. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers using a symbol alone where several currencies could be confused.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Choose code or name when clarity matters more than compactness.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.NumberFormat syntax. For this chapter, useful prompts are: “What did you expect from currencyDisplay controls the label form?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using a symbol alone where several currencies could be confused be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny CCA fundraiser with currency totals, targets and compact summaries. Include one ordinary case, one boundary and one deliberate failure caused by using a symbol alone where several currencies could be confused. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For currencyDisplay controls the label form, separate the documented JavaScript Intl.NumberFormat mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Unit formatting requires a sanctioned unit identifier and can use long, short or narrow display forms. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is using a unit formatter to convert kilometres into metres. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Convert the numeric value separately, then format it with the correct unit.

For the Unit style names a measurement chapter on JavaScript Intl.NumberFormat, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using a unit formatter to convert kilometres into metres. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

new Intl.NumberFormat('en-SG',{style:'unit',unit:'kilometer-per-hour',unitDisplay:'long'}).format(12)

Four purposeful transfer cases

Case 1: revision tracker. Contrast the rule using scores, ratios and percentage progress. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: family planner. Stress-test the rule using cost ranges and accounting-style negatives. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: travel exercise. Explain the rule using the same number formatted for several requested locales. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: compatibility lab. Transfer the rule using feature detection, resolved options and exact part arrays. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers using a unit formatter to convert kilometres into metres.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Convert the numeric value separately, then format it with the correct unit.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.NumberFormat syntax. For this chapter, useful prompts are: “What did you expect from Unit style names a measurement?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using a unit formatter to convert kilometres into metres be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny science display with measurements with unit labels and controlled precision. Include one ordinary case, one boundary and one deliberate failure caused by using a unit formatter to convert kilometres into metres. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Unit style names a measurement, separate the documented JavaScript Intl.NumberFormat mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

minimumFractionDigits and maximumFractionDigits are resolved together, and specifying one can affect the default of the other. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is setting only one digit option and assuming every other default stays unrelated. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Inspect resolvedOptions and test values below, at and above the intended precision.

For the Fraction-digit defaults interact chapter on JavaScript Intl.NumberFormat, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on setting only one digit option and assuming every other default stays unrelated. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const nf=new Intl.NumberFormat('en-SG',{minimumFractionDigits:2});
nf.resolvedOptions()

Four purposeful transfer cases

Case 1: travel exercise. Stress-test the rule using the same number formatted for several requested locales. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: compatibility lab. Explain the rule using feature detection, resolved options and exact part arrays. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: canteen budget. Transfer the rule using Singapore-dollar amounts and percentages. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: library dashboard. Predict the rule using loan counts in several interface locales. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers setting only one digit option and assuming every other default stays unrelated.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Inspect resolvedOptions and test values below, at and above the intended precision.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.NumberFormat syntax. For this chapter, useful prompts are: “What did you expect from Fraction-digit defaults interact?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing setting only one digit option and assuming every other default stays unrelated be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny revision tracker with scores, ratios and percentage progress. Include one ordinary case, one boundary and one deliberate failure caused by setting only one digit option and assuming every other default stays unrelated. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Fraction-digit defaults interact, separate the documented JavaScript Intl.NumberFormat mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Significant-digit options count meaningful digits across the whole number instead of fixed places after the decimal point. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is mixing significant and fraction constraints without deciding which precision model owns the output. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State whether the requirement concerns measurement significance or decimal places.

For the Significant digits express a different precision rule chapter on JavaScript Intl.NumberFormat, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on mixing significant and fraction constraints without deciding which precision model owns the output. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

new Intl.NumberFormat('en-SG',{maximumSignificantDigits:3}).format(12345)

Four purposeful transfer cases

Case 1: canteen budget. Explain the rule using Singapore-dollar amounts and percentages. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: library dashboard. Transfer the rule using loan counts in several interface locales. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: CCA fundraiser. Predict the rule using currency totals, targets and compact summaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: science display. Contrast the rule using measurements with unit labels and controlled precision. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers mixing significant and fraction constraints without deciding which precision model owns the output.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State whether the requirement concerns measurement significance or decimal places.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.NumberFormat syntax. For this chapter, useful prompts are: “What did you expect from Significant digits express a different precision rule?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing mixing significant and fraction constraints without deciding which precision model owns the output be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny family planner with cost ranges and accounting-style negatives. Include one ordinary case, one boundary and one deliberate failure caused by mixing significant and fraction constraints without deciding which precision model owns the output. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Significant digits express a different precision rule, separate the documented JavaScript Intl.NumberFormat mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

When both significant- and fraction-digit settings are present, roundingPriority helps determine which family governs the result. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is assuming both constraints are simply applied one after another. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Create boundary values and compare auto, morePrecision and lessPrecision where the runtime supports them.

For the Rounding priority resolves competing digit families chapter on JavaScript Intl.NumberFormat, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on assuming both constraints are simply applied one after another. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

new Intl.NumberFormat('en-SG',{maximumFractionDigits:2,maximumSignificantDigits:3,roundingPriority:'auto'})

Four purposeful transfer cases

Case 1: CCA fundraiser. Transfer the rule using currency totals, targets and compact summaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: science display. Predict the rule using measurements with unit labels and controlled precision. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: revision tracker. Contrast the rule using scores, ratios and percentage progress. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: family planner. Stress-test the rule using cost ranges and accounting-style negatives. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers assuming both constraints are simply applied one after another.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Create boundary values and compare auto, morePrecision and lessPrecision where the runtime supports them.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.NumberFormat syntax. For this chapter, useful prompts are: “What did you expect from Rounding priority resolves competing digit families?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing assuming both constraints are simply applied one after another be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny travel exercise with the same number formatted for several requested locales. Include one ordinary case, one boundary and one deliberate failure caused by assuming both constraints are simply applied one after another. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Rounding priority resolves competing digit families, separate the documented JavaScript Intl.NumberFormat mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Current ECMA-402 defines roundingMode and roundingIncrement, but deployed runtimes may differ in support and accepted combinations. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is publishing an exact cash-rounding claim without testing the target engine. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Feature-test with resolvedOptions and a value that distinguishes the modes.

For the Rounding mode and increment are compatibility-sensitive chapter on JavaScript Intl.NumberFormat, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on publishing an exact cash-rounding claim without testing the target engine. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const nf=new Intl.NumberFormat('en-SG',{maximumFractionDigits:2,roundingMode:'halfExpand'});

Four purposeful transfer cases

Case 1: revision tracker. Predict the rule using scores, ratios and percentage progress. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: family planner. Contrast the rule using cost ranges and accounting-style negatives. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: travel exercise. Stress-test the rule using the same number formatted for several requested locales. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: compatibility lab. Explain the rule using feature detection, resolved options and exact part arrays. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers publishing an exact cash-rounding claim without testing the target engine.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Feature-test with resolvedOptions and a value that distinguishes the modes.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.NumberFormat syntax. For this chapter, useful prompts are: “What did you expect from Rounding mode and increment are compatibility-sensitive?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing publishing an exact cash-rounding claim without testing the target engine be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny compatibility lab with feature detection, resolved options and exact part arrays. Include one ordinary case, one boundary and one deliberate failure caused by publishing an exact cash-rounding claim without testing the target engine. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Rounding mode and increment are compatibility-sensitive, separate the documented JavaScript Intl.NumberFormat mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

notation can select standard, scientific, engineering or compact forms while preserving the underlying value. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is treating compact text such as 1.2K as a precise serialisation format. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use compact notation for display and retain the original number for computation and storage.

For the Notation changes the scale presentation chapter on JavaScript Intl.NumberFormat, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on treating compact text such as 1.2K as a precise serialisation format. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

new Intl.NumberFormat('en',{notation:'compact',compactDisplay:'short'}).format(1200)

Four purposeful transfer cases

Case 1: travel exercise. Contrast the rule using the same number formatted for several requested locales. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: compatibility lab. Stress-test the rule using feature detection, resolved options and exact part arrays. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: canteen budget. Explain the rule using Singapore-dollar amounts and percentages. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: library dashboard. Transfer the rule using loan counts in several interface locales. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers treating compact text such as 1.2K as a precise serialisation format.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Use compact notation for display and retain the original number for computation and storage.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.NumberFormat syntax. For this chapter, useful prompts are: “What did you expect from Notation changes the scale presentation?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing treating compact text such as 1.2K as a precise serialisation format be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny canteen budget with Singapore-dollar amounts and percentages. Include one ordinary case, one boundary and one deliberate failure caused by treating compact text such as 1.2K as a precise serialisation format. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Notation changes the scale presentation, separate the documented JavaScript Intl.NumberFormat mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

signDisplay controls when signs appear, while currencySign accounting may use a locale-specific accounting pattern for negative currency. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is assuming every locale uses parentheses for accounting negatives. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Test positive, negative, zero and negative zero in each supported locale.

For the Sign display and accounting are policy choices chapter on JavaScript Intl.NumberFormat, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on assuming every locale uses parentheses for accounting negatives. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

new Intl.NumberFormat('en-SG',{style:'currency',currency:'SGD',currencySign:'accounting'}).format(-25)

Four purposeful transfer cases

Case 1: canteen budget. Stress-test the rule using Singapore-dollar amounts and percentages. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: library dashboard. Explain the rule using loan counts in several interface locales. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: CCA fundraiser. Transfer the rule using currency totals, targets and compact summaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: science display. Predict the rule using measurements with unit labels and controlled precision. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers assuming every locale uses parentheses for accounting negatives.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Test positive, negative, zero and negative zero in each supported locale.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.NumberFormat syntax. For this chapter, useful prompts are: “What did you expect from Sign display and accounting are policy choices?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing assuming every locale uses parentheses for accounting negatives be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny library dashboard with loan counts in several interface locales. Include one ordinary case, one boundary and one deliberate failure caused by assuming every locale uses parentheses for accounting negatives. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Sign display and accounting are policy choices, separate the documented JavaScript Intl.NumberFormat mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

useGrouping controls grouping behaviour, but separator characters and group sizes come from the resolved locale. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is splitting a formatted number on comma to recover digits. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use formatToParts for presentation logic and keep raw numbers for data logic.

For the Grouping belongs to locale data and options chapter on JavaScript Intl.NumberFormat, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on splitting a formatted number on comma to recover digits. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

new Intl.NumberFormat('en-SG',{useGrouping:'always'}).format(1234567)

Four purposeful transfer cases

Case 1: CCA fundraiser. Explain the rule using currency totals, targets and compact summaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: science display. Transfer the rule using measurements with unit labels and controlled precision. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: revision tracker. Predict the rule using scores, ratios and percentage progress. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: family planner. Contrast the rule using cost ranges and accounting-style negatives. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers splitting a formatted number on comma to recover digits.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Use formatToParts for presentation logic and keep raw numbers for data logic.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.NumberFormat syntax. For this chapter, useful prompts are: “What did you expect from Grouping belongs to locale data and options?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing splitting a formatted number on comma to recover digits be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny CCA fundraiser with currency totals, targets and compact summaries. Include one ordinary case, one boundary and one deliberate failure caused by splitting a formatted number on comma to recover digits. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Grouping belongs to locale data and options, separate the documented JavaScript Intl.NumberFormat mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

The format getter caches and returns a function bound to its NumberFormat instance, so it can be passed to map. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is calling the accessor with a different this value to change its locale. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Construct a new formatter for a new policy instead of rebinding the function.

For the The format accessor returns a bound function chapter on JavaScript Intl.NumberFormat, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on calling the accessor with a different this value to change its locale. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const format=new Intl.NumberFormat('en-SG').format;
[1,2,3].map(format)

Four purposeful transfer cases

Case 1: revision tracker. Transfer the rule using scores, ratios and percentage progress. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: family planner. Predict the rule using cost ranges and accounting-style negatives. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: travel exercise. Contrast the rule using the same number formatted for several requested locales. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: compatibility lab. Stress-test the rule using feature detection, resolved options and exact part arrays. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers calling the accessor with a different this value to change its locale.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Construct a new formatter for a new policy instead of rebinding the function.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.NumberFormat syntax. For this chapter, useful prompts are: “What did you expect from The format accessor returns a bound function?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing calling the accessor with a different this value to change its locale be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny science display with measurements with unit labels and controlled precision. Include one ordinary case, one boundary and one deliberate failure caused by calling the accessor with a different this value to change its locale. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For The format accessor returns a bound function, separate the documented JavaScript Intl.NumberFormat mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

formatToParts returns ordered records such as integer, group, decimal, fraction, currency or unit so interfaces can style parts without parsing punctuation. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is using a regular expression that assumes one separator and symbol position. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Inspect part types and preserve their returned order.

For the formatToParts exposes semantic pieces chapter on JavaScript Intl.NumberFormat, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using a regular expression that assumes one separator and symbol position. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

new Intl.NumberFormat('en-SG',{style:'currency',currency:'SGD'}).formatToParts(1234.5)

Four purposeful transfer cases

Case 1: travel exercise. Predict the rule using the same number formatted for several requested locales. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: compatibility lab. Contrast the rule using feature detection, resolved options and exact part arrays. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: canteen budget. Stress-test the rule using Singapore-dollar amounts and percentages. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: library dashboard. Explain the rule using loan counts in several interface locales. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers using a regular expression that assumes one separator and symbol position.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Inspect part types and preserve their returned order.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.NumberFormat syntax. For this chapter, useful prompts are: “What did you expect from formatToParts exposes semantic pieces?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using a regular expression that assumes one separator and symbol position be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny revision tracker with scores, ratios and percentage progress. Include one ordinary case, one boundary and one deliberate failure caused by using a regular expression that assumes one separator and symbol position. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For formatToParts exposes semantic pieces, separate the documented JavaScript Intl.NumberFormat mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

formatRange and formatRangeToParts format two endpoints with locale-aware collapsing, but availability must be checked in the target environment. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is joining two independently formatted strings with a hard-coded hyphen and claiming equivalent locale behaviour. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Feature-detect the methods, test equal and unequal endpoints and provide a clear fallback.

For the Number ranges need runtime verification chapter on JavaScript Intl.NumberFormat, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on joining two independently formatted strings with a hard-coded hyphen and claiming equivalent locale behaviour. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const nf=new Intl.NumberFormat('en-SG');
if(typeof nf.formatRange==='function') nf.formatRange(10,20);

Four purposeful transfer cases

Case 1: canteen budget. Contrast the rule using Singapore-dollar amounts and percentages. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: library dashboard. Stress-test the rule using loan counts in several interface locales. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: CCA fundraiser. Explain the rule using currency totals, targets and compact summaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: science display. Transfer the rule using measurements with unit labels and controlled precision. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers joining two independently formatted strings with a hard-coded hyphen and claiming equivalent locale behaviour.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Feature-detect the methods, test equal and unequal endpoints and provide a clear fallback.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.NumberFormat syntax. For this chapter, useful prompts are: “What did you expect from Number ranges need runtime verification?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing joining two independently formatted strings with a hard-coded hyphen and claiming equivalent locale behaviour be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny family planner with cost ranges and accounting-style negatives. Include one ordinary case, one boundary and one deliberate failure caused by joining two independently formatted strings with a hard-coded hyphen and claiming equivalent locale behaviour. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Number ranges need runtime verification, separate the documented JavaScript Intl.NumberFormat mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

resolvedOptions reports the locale, numbering system and relevant options computed during initialisation. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is debugging only the output string when defaults are interacting. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Log requested options beside resolvedOptions and a small value matrix.

For the resolvedOptions reveals the effective contract chapter on JavaScript Intl.NumberFormat, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on debugging only the output string when defaults are interacting. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const nf=new Intl.NumberFormat('en-SG',{style:'percent'});
nf.resolvedOptions()

Four purposeful transfer cases

Case 1: CCA fundraiser. Stress-test the rule using currency totals, targets and compact summaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: science display. Explain the rule using measurements with unit labels and controlled precision. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: revision tracker. Transfer the rule using scores, ratios and percentage progress. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: family planner. Predict the rule using cost ranges and accounting-style negatives. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers debugging only the output string when defaults are interacting.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Log requested options beside resolvedOptions and a small value matrix.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.NumberFormat syntax. For this chapter, useful prompts are: “What did you expect from resolvedOptions reveals the effective contract?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing debugging only the output string when defaults are interacting be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny travel exercise with the same number formatted for several requested locales. Include one ordinary case, one boundary and one deliberate failure caused by debugging only the output string when defaults are interacting. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For resolvedOptions reveals the effective contract, separate the documented JavaScript Intl.NumberFormat mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

NaN, Infinity and negative zero receive locale-sensitive representations and may need domain validation before display. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is allowing an invalid calculation to appear as polished output. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Validate domain constraints before formatting and separately test Object.is(value,-0).

For the Special numeric values deserve explicit decisions chapter on JavaScript Intl.NumberFormat, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on allowing an invalid calculation to appear as polished output. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const nf=new Intl.NumberFormat('en-SG',{signDisplay:'auto'});
[nf.format(NaN),nf.format(Infinity),nf.format(-0)]

Four purposeful transfer cases

Case 1: revision tracker. Explain the rule using scores, ratios and percentage progress. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: family planner. Transfer the rule using cost ranges and accounting-style negatives. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: travel exercise. Predict the rule using the same number formatted for several requested locales. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: compatibility lab. Contrast the rule using feature detection, resolved options and exact part arrays. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers allowing an invalid calculation to appear as polished output.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Validate domain constraints before formatting and separately test Object.is(value,-0).” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.NumberFormat syntax. For this chapter, useful prompts are: “What did you expect from Special numeric values deserve explicit decisions?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing allowing an invalid calculation to appear as polished output be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny compatibility lab with feature detection, resolved options and exact part arrays. Include one ordinary case, one boundary and one deliberate failure caused by allowing an invalid calculation to appear as polished output. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Special numeric values deserve explicit decisions, separate the documented JavaScript Intl.NumberFormat mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Intl.NumberFormat has no inverse parse method, and locale punctuation, spaces, signs and labels make ad-hoc reversal unsafe. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is removing commas and calling Number on every formatted string. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Accept structured numeric input, validate it and use formatting only at the display boundary.

For the Formatted text is not a general parser input chapter on JavaScript Intl.NumberFormat, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on removing commas and calling Number on every formatted string. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const raw=1250.5; const shown=new Intl.NumberFormat('fr-FR').format(raw);

Four purposeful transfer cases

Case 1: travel exercise. Transfer the rule using the same number formatted for several requested locales. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: compatibility lab. Predict the rule using feature detection, resolved options and exact part arrays. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: canteen budget. Contrast the rule using Singapore-dollar amounts and percentages. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: library dashboard. Stress-test the rule using loan counts in several interface locales. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers removing commas and calling Number on every formatted string.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Accept structured numeric input, validate it and use formatting only at the display boundary.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.NumberFormat syntax. For this chapter, useful prompts are: “What did you expect from Formatted text is not a general parser input?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing removing commas and calling Number on every formatted string be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny canteen budget with Singapore-dollar amounts and percentages. Include one ordinary case, one boundary and one deliberate failure caused by removing commas and calling Number on every formatted string. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Formatted text is not a general parser input, separate the documented JavaScript Intl.NumberFormat mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Start with evidence, not a label such as careless. Ask for one prediction and one trace. If the first transition is wrong, rebuild the model. If the model is sound but syntax fails, practise reference use. If routine cases are correct but boundaries fail, vary ties, defaults, unsupported inputs, ownership or missing paths. If explanations transfer, move to a small project.

Keep a weekly record with four lines: concept, prediction, observed difference and next test. Stop when fatigue replaces reasoning. A smaller case tomorrow is more useful than another hour of copying tonight.

Seek specialist help when cause and effect remain invisible after examples are reduced, when accessibility or data-loss implications are unclear, or when an important repository, database or application state may be at risk. Good support should make the learner’s reasoning more independent.

1. canteen budget: model, boundary and recovery

Create a small canteen budget using Singapore-dollar amounts and percentages. Combine “Formatting is presentation, not arithmetic” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

2. library dashboard: model, boundary and recovery

Create a small library dashboard using loan counts in several interface locales. Combine “Percent style scales for display” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

3. CCA fundraiser: model, boundary and recovery

Create a small CCA fundraiser using currency totals, targets and compact summaries. Combine “Unit style names a measurement” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

4. science display: model, boundary and recovery

Create a small science display using measurements with unit labels and controlled precision. Combine “Rounding priority resolves competing digit families” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

5. revision tracker: model, boundary and recovery

Create a small revision tracker using scores, ratios and percentage progress. Combine “Sign display and accounting are policy choices” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

6. family planner: model, boundary and recovery

Create a small family planner using cost ranges and accounting-style negatives. Combine “formatToParts exposes semantic pieces” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

7. travel exercise: model, boundary and recovery

Create a small travel exercise using the same number formatted for several requested locales. Combine “Special numeric values deserve explicit decisions” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

8. compatibility lab: model, boundary and recovery

Create a small compatibility lab using feature detection, resolved options and exact part arrays. Combine “Locale negotiation chooses an available locale” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

Frequently asked questions

How long should a practice session be?

Use one complete prediction–observation–explanation cycle while attention remains good. Ten to twenty focused minutes can be enough.

Should every option or function be memorised?

No. Memorise the governing distinctions and practise retrieving the official reference. Understanding means predicting and explaining, not reciting a parameter list.

What if the result is correct but the explanation is weak?

Treat it as partial success. Ask for a trace and change one boundary. A reliable model survives controlled variation.

Is the shortest solution the best?

Not automatically. Prefer the solution whose semantics, failure modes and maintenance cost are easiest to justify for the actual project.

When should official documentation be used?

Use it whenever syntax, supported types, SQL dialect behaviour or Git version details matter. Primary documentation settles the current contract.

How can a parent help without technical expertise?

Ask what was predicted, where the first difference appeared, what evidence matters and which smaller example could isolate it.

How do we test transfer?

Change the context, vocabulary and one boundary. Require the learner to identify the invariant before using a tool.

What should be saved after practice?

Keep the corrected rule, one trace, one boundary case and the next question. Avoid storing pages of unexplained output.

Can these exercises replace backups?

No. Use disposable examples and proper backups. Learning should not endanger schoolwork, repositories or personal data.

What counts as mastery?

The learner can predict, verify, diagnose, recover and justify a choice across more than one context, while knowing when to consult the current reference.

Official and supporting references

• Primary technical documentation for JavaScript Intl.NumberFormat
• eduKatePunggol: How Studying Works

Return to contents