Repository navigation
fix: read numeric KBB attribute values as numbers, not strings (#439) + 3.7.4 - #688
Merged
Merged
Conversation
CG::parseKBBLine stored every attribute value via addSval (string), so a KBB value written unquoted -- which is how num/float values are serialized -- was read back as the string "42" instead of the number 42. An unquoted value that is numeric is now stored via addVal (number); a double-quoted value (openDouble) is always kept as a string. This lets a KBB round-trip num/float vs string instead of flattening everything to strings. Verified by loading a KBB and checking attrtype(): count=42 -> num (attrtype 1), getnumval = 42 price=3 -> num color=red -> string (unquoted, non-numeric) label="12345" -> string (quoted stays string) No regression: emailaddress and telephone analyzers still load and extract. Bumps NLP_ENGINE_VERSION to 3.7.4. Note: the complementary write-side change lives in the analyzers' NLP++ KBFuncs library (SaveKB): string values must be written quoted (currently QuoteIfNeeded only quotes on space/punct, so a numeric-looking string is written unquoted). Tracked separately for the analyzers repo. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes the engine (read) half of #439:
.kbbattribute values that are numeric were being stored as strings.Root cause
CG::parseKBBLinestored every attribute value viaaddSval(string). But num/float values are serialized unquoted in a KBB, so on read they came back as the string"42"rather than the number42— the KBB round-trip flattened all types to strings.Fix (read side)
An unquoted value that is numeric is now stored via
addVal(number); a double-quoted value (openDouble) is always kept as a string. So:count=42(unquoted, numeric)price=3color=red(unquoted, non-numeric)label="12345"(quoted)Verified by loading a KBB and checking
attrtype()/getnumval(). No regression:emailaddressandtelephone(real.kbbcountry lists) still load and extract.The other half lives in the analyzers repo
The write side is NLP++ code —
SaveKBin theKBFuncs.nlplibrary (package-analyzers), not the engine. It already writes num/float unquoted, but string values go throughQuoteIfNeeded, which only quotes on space/punct — so a numeric-looking string like12345is written unquoted and would now read back as a number. For full round-trip fidelity,SaveKBshould quote string values always. That's a separate change in the analyzers repo (I can take it next).Per the maintainer decision on this issue, unquoted-numeric → number everywhere; existing KBs get the corrected typing (regenerate any that relied on the old string storage).
Bumps
NLP_ENGINE_VERSION→ 3.7.4.Fixes #439.
🤖 Generated with Claude Code