Я одобряю ответ Пола Фишера, но я все равно хотел бы предложить свой, отчасти потому, что чувствую, что у меня есть комментарии, которые нужно добавить более чем в 600 символов. ;)
Мне нравится, что в его ответе как минимум сделан упор на упрощение работы для пользователя и на облегчение для программиста. Я считаю, что мы должны поставить пользователей на первое место в максимально возможной степени. В идеале вы должны сделать макет различных решений и попросить реальных пользователей строительной индустрии (которые имеют дело с имперскими единицами) попробовать их и дать обратную связь, но сейчас вы спрашиваете нас, а не реальных пользователей, так. ..
Я также склоняюсь к интерфейсу с двумя полями. Лично я бы заставил парсер обрабатывать как десятичный, так и дробный ввод (допуская либо «11 .25», либо «11 1/4»). Вы должны будете выяснить, что делать, когда они выбирают что-то, что не является двоичной дробью, например 5/7 (когда они, вероятно, имели в виду 5/8, например).
Что касается хранения, я думаю, вы могли бы идти с миллиметрами, если это поплавок. Было бы удобнее хранить дюймы, потому что если все ваши значения кратны 64-м дюймам, у вас не должно быть проблем с округлением. Я согласен с Паксом в том, что важно иметь возможность вернуть его пользователю в имперских единицах, в комплекте с уменьшенными долями. (Может быть, это большое предположение, которое я делаю в отношении строительной индустрии. Насколько я знаю, они нормализуют все до 64-х и счастливее видеть «11 16/64», чем «11 1/4»!)