pre-srfi / make-float

Construct/deconstruct floats from/to string/integer parts
0 stars 0 forks source link

Permit whitespace in input #2

Open lassik opened 3 years ago

lassik commented 3 years ago

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.

johnwcowan commented 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 .

mnieper commented 3 years ago

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 .

lassik commented 3 years ago

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...

johnwcowan commented 3 years ago

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 .

lassik commented 3 years ago

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?