[Experimental] Replace FloatingPoint Formatter and add support Float80

[norio-nomura]

• Use SwiftDtoa.(h|cpp) for formatting FloatingPoint into String
• Support Float80 as ScalarConstructible and ScalarRepresentable

On Linux, Supporting Float80 requires Swift 4.2+, since swift_decompose_float80() does not exists on Swift 4.1 or earlier.
Is this a good opportunity to drop supporting Swift 4.0/4.1?

[norio-nomura]

On Linux, Supporting Float80 requires Swift 4.2+, since swift_decompose_float80() does not exists on Swift 4.1 or earlier.

Not only on Linux, but also Apple Platforms…

[norio-nomura]

I am not sure if we should adopt this.

Pros:

• Implementation is interesting
• Stop using NumberFormatter
• More accurate formatting result

Cons:

• The large source file to keep updating
• The licensing changes may be required
• "Float80 is ultimately a really rarely used feature at the end of the day"

[jpsim]

Agreed 😄

[jpsim]

This was really cool. I'm sad to see it go :/

[norio-nomura]

I will leave the branch for the time being. :)

[norio-nomura]

filed a request as SR-9610 to exporting swift_decompose_double(), swift_decompose_float(), swift_decompose_float80() and swift_format_exponential() from libswiftCore

[norio-nomura]

filed a request as SR-9610 to exporting swift_decompose_double(), swift_decompose_float(), swift_decompose_float80() and swift_format_exponential() from libswiftCore

It seems that "Swift Evolution Process" is necessary to realize that. But for me it feels that it requires too much effort. 🤔
How about creating SwiftDtoa as separated project and use them from Yams?

[jpsim]

Would it be an option to add Float80 support to NumberFormatter instead?

[norio-nomura]

I don't think NSNumber that is required by NumberFormatter.string(from:) is supporting Float80.

[jpsim]

I'm curious, other than being spec compliant with the YAML specification, is there a real world motivation for supporting Float80?

[norio-nomura]

is there a real world motivation for supporting Float80?

No.
But, sorry, I forgot that there is another motivation to introduce this.
While creating this PR, I found that formatting results of greatestFiniteMagnitude and leastNormalMagnitude on both of Double and Float are different from that using SwiftDtoa.
If we believe SwiftDtoa 's commit description, the current Yams implementation formatting Double and Float will be incorrect.

[norio-nomura]

I found that formatting results of greatestFiniteMagnitude and leastNormalMagnitude on both of Double and Float are different from that using SwiftDtoa.

opened #152 for indicating current formatting results.

[norio-nomura]

Diffs of formatting results: https://github.com/jpsim/Yams/compare/use-swift-dtoa#diff-0c522086aa5f2635d87e4f06bbea524dR51

[norio-nomura]

Diffs of formatting results: https://github.com/jpsim/Yams/compare/use-swift-dtoa#diff-0c522086aa5f2635d87e4f06bbea524dR51

Oops!: Correct link is here.

[jpsim]

It's really just a difference of significant digits printed

-1.79769313486232e+308
-2.2250738585072e-308
+1.7976931348623157e+308
+2.2250738585072014e-308

I guess if you're doing Yams for scientific computing (which is also basically the only reason to use Float80), then SwiftDtoa's implementation would be slightly better. I just don't think it's worth the extra complexity personally.

[norio-nomura]

I just don't think it's worth the extra complexity personally.

👍 Let's forget this until Float80 becomes Codable: SR-9607