tim wrote:
> > Of course, that doesn't say anything about what *most* compilers do.
>
> Doesn't matter in this case; I told /F not to worry about it having taken
> that all into account. Almost all C compilers do a piss-poor job of taking
> floating-point seriously, but it doesn't really matter for the purpose /F
> has in mind.
to make it clear for everyone: I'm planning to get rid of the last
remaining switch statement in unicodectype.c ("numerical value"),
and replace the doubles in there with rationals.
the problem here is that MAL's new test suite uses "str" on the
return value from that function, and it would a bit annoying if we
ended up with a Unicode test that might fail on platforms with
lousy floating point support...
:::
on the other hand, I'm not sure I think it's a really good idea to
have "numeric" return a floating point value. consider this:
>>> import unicodedata
>>> unicodedata.numeric(u"\N{VULGAR FRACTION ONE THIRD}")
0.33333333333333331
(the glyph looks like "1/3", and that's also what the numeric
property field in the Unicode database says)
:::
if I had access to the time machine, I'd change it to:
>>> unicodedata.numeric(u"\N{VULGAR FRACTION ONE THIRD}")
(1, 3)
...but maybe we can add an alternate API that returns the
*exact* fraction (as a numerator/denominator tuple)?
>>> unicodedata.numeric2(u"\N{VULGAR FRACTION ONE THIRD}")
(1, 3)
(hopefully, someone will come up with a better name)
</F>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4