Open lassik opened 3 years ago
What should we do about commas? Forbid, treat as decimal point, ignore?
On Mon, May 3, 2021 at 2:09 PM Lassi Kortela @.***> wrote:
If we ignore any whitespace and underscores in the string arguments given to inexact-real-from-strings, that should make it easier to pass more kinds of number syntaxes directly into this SRFI without filtering out the digit group separators. I don't see an obvious downside to this.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pre-srfi/make-float/issues/2, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANPPBWUDBW47BBUZMN3AG3TL3RF5ANCNFSM44BIEOSQ .
There's also a comment about whitespace in GMP: https://gmplib.org/manual/Assigning-Floats.
Am Mo., 3. Mai 2021 um 20:24 Uhr schrieb John Cowan < @.***>:
What should we do about commas? Forbid, treat as decimal point, ignore?
On Mon, May 3, 2021 at 2:09 PM Lassi Kortela @.***> wrote:
If we ignore any whitespace and underscores in the string arguments given to inexact-real-from-strings, that should make it easier to pass more kinds of number syntaxes directly into this SRFI without filtering out the digit group separators. I don't see an obvious downside to this.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pre-srfi/make-float/issues/2, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AANPPBWUDBW47BBUZMN3AG3TL3RF5ANCNFSM44BIEOSQ
.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pre-srfi/make-float/issues/2#issuecomment-831443758, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHDTQ4GK4NFNADYJUVJA7DTL3S6PANCNFSM44BIEOSQ .
We should not interpret any character as a decimal point. There are several traps, perhaps the main one being that countries disagree on where and how to use commas and periods in numbers.
I'm generally opposed to lenient number parsers because they are difficult to use as subroutines in reliable parsers (as the GMP authors note in that document). However, since the procedures in this SRFI take parts of numbers rather than entire numbers, the parts must have been vetted by a stricter parser before they ended up here. That's why some leniency might be in order. It means the stricter, higher-level parser can validate the string containing the entire number, and after that validation, use one call to substring
to get parts even if they contain digit separators.
However, as John notes, commas can also be used as digit separators. Would it be confusing and bug-prone if the procedures in this SRFI ignore commas? Probably...
On Mon, May 3, 2021 at 2:37 PM Lassi Kortela @.***> wrote:
We should not interpret any character as a decimal point. There are several traps, perhaps the main one being that countries disagree on where and how to use commas and periods in numbers.
We've got to interpret something as a decimal point when parsing numeric strings. We have three choices: decimal point only (as in all programming languages and data files without exception), both decimal point and comma, or a flag argument to say which to use as the decimal point and which to ignore.
I'm generally opposed to lenient number parsers because they are difficult
to use as subroutines in reliable parsers (as the GMP authors note in that document). However, since the procedures in this SRFI take parts of numbers rather than entire numbers, the parts must have been vetted by a stricter parser before they ended up here. That's why some leniency might be in order. It means the stricter, higher-level parser can validate the string containing the entire number, and after that validation, use one call to substring to get parts even if they contain digit separators.
However, as John notes, commas can also be used as digit separators. Would it be confusing and bug-prone if the procedures in this SRFI ignore commas? Probably...
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/pre-srfi/make-float/issues/2#issuecomment-831451332, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANPPBTH7KZKC3UJE75PXUTTL3UQPANCNFSM44BIEOSQ .
The current draft assumes that splitting the integer part from the fractional part happens before those parts reach this SRFI. I think that's a good thing since there isn't universal agreement on all that syntax. Do you think the SRFI should do the splitting?
If we ignore any whitespace and underscores in the string arguments given to
inexact-real-from-strings
, that should make it easier to pass more kinds of number syntaxes directly into this SRFI without filtering out the digit group separators. I don't see an obvious downside to this.