You would think, however, that the "1/2" works fine in the text field used for a standard North American address... At least with Amazon and 99% of ecommerce sites there's two separate freeform text entry fields for street address. It's not like these are fields that require a precise integer.
This should enable the actual human making the delivery to see the same thing printed on the label, and visually match it to whatever is labeled "1/2" on the building.
> It's not like these are fields that require a precise integer.
If you are treating the street address as more than a string something is wrong. Its supposed to be a string by design unless you are trying to be efficient by storing ints as ints but then you shouldnt be evaluating them from user input and if you are... Treat it as a raw string.
IIRC Google Maps used to interpolate between points with known addresses on streets to estimate where other numeric addresses were along the street, when they didn't have exact points for them. So there's at least one legitimate example of not treating an address as a string.
With some knowledge of the ordering scheme, you can determine relative locations and route drivers without storing every address on a street. I think it's very easy to imagine a cases where have "1/3" as your street number could cause problems (0.33333333... out of memory) or just dealing with floating point conversion and typing can lead to seemingly random bugs.
Accepting non-integers should be fine, as long as there's no delimiter or reversions to numbers ( e.g.- 321A Main St.), but I could see it being a problem with delimiters. It greatly expands the solution space for recognition tasks.
Is 321 N Main Street: 321 Main St. Unit N or 321 North Main St?
Is 321/A Main St: 321 Main St Unit A, 321-A(ths) Main St, 32 Main St. Unit 1 or A, 3214 Main St (A/4 character recognition failure), 321 Main St (A is escaped by /), 321 AMAIN St., 32 Main St Unit VA.
Where does it switch from a unit number to an address? 321A21B Main St could be read at least a dozen different ways, especially if we allow for recognition errors. Can't we at least agree that a physical building has an integer value and anything inside the building becomes a separate field (Unit, Suite, Floor, Cabana Room, etc)? No one's pumping money into post office modernization and we're not going to see Unicode or Emoji address support, so can't we simply agree on a few rules?
This should enable the actual human making the delivery to see the same thing printed on the label, and visually match it to whatever is labeled "1/2" on the building.