What's a "short" decimal? For Swift, it is one that handles up to 14 places past the decimal point. In baseball terms, Floats are handy for calculating Kershaw's WHIP, Bob Gibson's ERA, Tony Gwynn's batting average, or Kevin Youkilis' OBP. Floats are good at handling numbers of that kind of length.
Unfortunately, Floats are not good at handling larger, finer numbers. Even more unfortunate, it's rare to find these kinds of numbers in baseball which rarely goes four places past the decimal point. How large and fine am I talking? I'm talking numbers like:
3.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093844609550582231725359408128481117450284102701938521105559644622948954930381964428810975665933446128475648233786783165271201909145648566923460348610454326648213393607260249141273724587006606315588174881520920962829254091715364367892590360011330530548820466521384146951941511609433057270365759591953092186117
Doubles can handle numbers that large and fine much better than the Float data type can. In fact, Swift prefers if we assign our fractions and decimals to Double and does so by default if we do not assign them. Why? Because Doubles can handle a larger and finer numerical output they are also a safer way to deal with numbers. It's like saying, we know Billy Hamilton can steal bases, but if Game 7 of the World Series depended on swiping second, we might go with Alexi Casilla instead (87.917% success rate versus Hamilton's 80.110% good for #1 all-time).
What do I mean by safe? Remember when we talked about uncertain numerical outcomes? Same idea. If we assign two numbers to be Floats, divide them, and the result turns out to be a Double, the program will not run, and then we're in trouble.
As we can see, Gibson's ERA in 1968 was 36.19866835764088% better than Doc's in 1985 which is pretty impressive considering how microscopic their ERAs were for those years. Now, if we had assigned both to be Floats how would that look?


Ah ha! See! The Float result, 0.3619866, isn't as precise as the Double result, 0.36119866835764088 because Floats cannot handle such large and fine numbers. Score one for Doubles!
Doubles score another win in our favor when Swift assigns fractions and decimals to the Double data type by default if we do not assign them in advance. Here's an example:


Ah ha! See! The Float result, 0.3619866, isn't as precise as the Double result, 0.36119866835764088 because Floats cannot handle such large and fine numbers. Score one for Doubles!
Doubles score another win in our favor when Swift assigns fractions and decimals to the Double data type by default if we do not assign them in advance. Here's an example:

If we take a closer look, we can see that because we have not assigned any specific data types to either bobGibson1968Innings or bobGibson1968EarnedRuns, either Float or Double, that Swift has assigned both to be Doubles:

You'll notice as you learn to code that like shedding training wheels, you'll shed assigning specific data types. How can you get away with this? Like in the example directly above, Swift covers your butt by either assigning decimals to be Doubles by default or by recognizing Strings as anything between two quotation marks or integers as whole numbers. This is helpful as it keeps your programs running rather than stopping to ask what data types these are and gumming up the works.
On Deck: Who's On First With The Boolean Data Type