ploeh / numsense Goto Github PK

A .NET library for parsing natural-language numerals ("forty-two") to integers, and converting the other way as well

License: MIT License

F# 95.68% C# 4.24% Batchfile 0.02% Shell 0.07%

numsense's Introduction

Numsense

A .NET library for parsing natural-language numerals ("forty-two") to integers, and converting the other way as well. While written in F#, it can be used from both F# and C#:

F#:

> let englishNumeral = Numeral.toEnglish 42;;
val englishNumeral : string = "forty-two"

> let i = Numeral.tryParseEnglish "one-thousand-three-hundred-thirty-seven";;
val i : int option = Some 1337

C#:

var englishNumeral = Numeral.English.ToNumeral(42);
// englishNumeral is "forty-two"

int i;
var success = Numeral.English.TryParse(
    "one-thousand-three-hundred-thirty-seven",
    out i);
// success is true, and i is 1337

Languages

Other languages than English are supported as well:

> let danishNumeral = Numeral.toDanish 9;;
val danishNumeral : string = "ni"

If you don't see your favourite language, please consider submitting a pull request.

NuGet

Numsense is available via NuGet: Numsense.

Versioning

Numsense follows Semantic Versioning 2.0.0.

numsense's People

Contributors

Stargazers

Watchers

numsense's Issues

CLA formatting

I think Disclaimer section should stand on its own, right?

Logo

Numsense should have a logo, to be used as icon for its NuGet package, etc.

Packages directory

Has it been submitted by accident or on purpose? The zipped repo is already 45MB, which is not the best.

tryParseEnglish "twentytwenty" returns 40

tryParseEnglish "twentytwenty" returns Some 40, which is surprising to say the least. It was never an explicit test case, though, but is a fairly standard idiom in the language, particularly when referring to years:

nineteen eighty-four (1984)
twenty-sixteen (2016)
fourteen fifty-three (1453)

There are two potential ways to address such numbers:

If they are unambiguous, a better result from tryParseEnglish "twentytwenty" would be Some 2020. While I suspect that they are unambiguous, anyone can, and is welcome to, prove me wrong with only a single counter-example.
If such numerals are ambiguous, the correct return value would be None.

NuGet package

The Build.fsx script ought to build a NuGet package.

Once a NuGet package is created, I'll publish it on nuget.org.

tryParseDanish "tyvetyve" returns 40

tryParseDanish "tyvetyve" returns Some 40, which is surprising to say the least. It was never an explicit test case, though, but is a fairly standard idiom in the language, particularly when referring to years:

nitten-fireogfirs (1984)
tyve-seksten (2016)
atten-fireogtres (1864)

There are two potential ways to address such numbers:

If they are unambiguous, a better result from tryParseDanish "tyvetyve" would be Some 2020. While I suspect that they are unambiguous, anyone can, and is welcome to, prove me wrong with only a single counter-example.
If such numerals are ambiguous, the correct return value would be None.

Long ints? Floats?

Should the individual converters really be provided as public classes?

In the mean of minimization of the public surface of the library, should the individual converters really be provided as public classes?

I mean, the normal way to access it would be through the Numeral class, right?