4 ms·

> I'm not sure why this is the default behavior, Um. You said the answer earlier: > because the parser treats the literal as a double BigFloats aren't built

by wnoise 3y ago

> I'm not sure why this is the default behavior, Um. You said the answer earlier: > because the parser treats the literal as a double BigFloats aren't built in to the syntax of the language (and probably should't be, so you need to escape the parser somehow -- either pass a string to the constructor, or use the @big_str macro to get a non-standard string parsed into a BigFloat.

kloch 3y ago
This makes perfect sense from the perspective of a language designer/computer scientist who is trying to keep their design clean and consistent. It makes no sense to an end user that expects an argument you pass to BigFloat to be treated as a BigFloat. As an end-user I would rather have a warning or even error than to have my argument silently treated as a double.
- sundarurfriend 3y ago
  It's a tricky case because they do provide the `big""` macros for literals, and mention in BigFloat's docs that: BigFloat(x::AbstractString) is identical to parse. This is provided for convenience since decimal literals are converted to Float64 when parsed, so BigFloat(2.1) may not yield what you expect. ... Examples ≡≡≡≡≡≡≡≡≡≡ julia> BigFloat(2.1) # 2.1 here is a Float64 2.100000000000000088817841970012523233890533447265625 However, saying RTFM is not a solution, especially for not-too-frequent parts of the language like BigFloats. It's still a trap many people are going to fall for. The solution here is a good linter though, not adding more work to the already overstressed compiler. It comes back to the issue of Julia needing more mature, easy-to-work-with tooling, that could say "hey, this is technically allowed, but you probably didn't mean this".
- DNF2 3y ago
  The argument isn't silently treated as a double, it is explicitly and loudly treated as a double, because it is a literal double. And this is not an advantage to the designer exclusively, it is very much an advantage for the end user that the treatment is explicit, consistent and predictable, instead of 'magically' reinterpreting the meaning of literals based on guessing the intent of the user. Basically, you seem to be saying that when passing x to BigFloat, x should not be treated as the value x, but as some nearby value that might be the one the caller intended (based on some rounding logic perhaps?) Or are you perhaps saying that x = 1e-300 y = BigFloat(x) should be different from y = BigFloat(1e-300) ? In other words, completely discarding referential transparency?
  - gnramires 3y ago
    I think the argument here is that parsing of the string '1e-300' maybe should be context dependent. In this case, 1e-300 is being parsed as a double, and then forwarded to the function. Maybe it could be parsed as a bigfloat whenever it is an argument of a function expecting a bigfloat.
    - jakobnissen 3y ago
      Julia does this for exponentiation, i.e. a literal exponent is parsef differently that exponentiation by a variable. I think it was a mistake. Invariably, a new user discovers the discrepancy and is thoroughly confused. Let's not repeat the same mistake with big nums.
      - DNF2 3y ago
        I don't think this has anything to do with whether 1e-300 and 10.0^-300 is parsed differently (and perhaps that is a mistake). The poster seems to want to parse 1e-300 directly as a BigFloat in the call `BigFloat(1e-300)`, because of the function it is passed to.
        jakobnissen 3y ago
        Yeah what I mean is - we already have "magic parsing" with literal_pow, and it's confusing and unnecessary. It was a mistake. We should not make the same mistake when parsing float literals
    - DNF2 3y ago
      Yes, I got that argument, and that is exactly what I was arguing against. You cannot and should not parse the literal double `1e-300` differently dependent on which function it is later passed to. This is what `big"1e-300"` or `BigFloat("1e-300")` is for, where the BigFloat constructor parses the string.

by wnoise 3y ago

kloch 3y ago

This makes perfect sense from the perspective of a language designer/computer scientist who is trying to keep their design clean and consistent. It makes no sense to an end user that expects an argument you pass to BigFloat to be treated as a BigFloat. As an end-user I would rather have a warning or even error than to have my argument silently treated as a double.

sundarurfriend 3y ago
It's a tricky case because they do provide the `big""` macros for literals, and mention in BigFloat's docs that: BigFloat(x::AbstractString) is identical to parse. This is provided for convenience since decimal literals are converted to Float64 when parsed, so BigFloat(2.1) may not yield what you expect. ... Examples ≡≡≡≡≡≡≡≡≡≡ julia> BigFloat(2.1) # 2.1 here is a Float64 2.100000000000000088817841970012523233890533447265625 However, saying RTFM is not a solution, especially for not-too-frequent parts of the language like BigFloats. It's still a trap many people are going to fall for. The solution here is a good linter though, not adding more work to the already overstressed compiler. It comes back to the issue of Julia needing more mature, easy-to-work-with tooling, that could say "hey, this is technically allowed, but you probably didn't mean this".
DNF2 3y ago
The argument isn't silently treated as a double, it is explicitly and loudly treated as a double, because it is a literal double. And this is not an advantage to the designer exclusively, it is very much an advantage for the end user that the treatment is explicit, consistent and predictable, instead of 'magically' reinterpreting the meaning of literals based on guessing the intent of the user. Basically, you seem to be saying that when passing x to BigFloat, x should not be treated as the value x, but as some nearby value that might be the one the caller intended (based on some rounding logic perhaps?) Or are you perhaps saying that x = 1e-300 y = BigFloat(x) should be different from y = BigFloat(1e-300) ? In other words, completely discarding referential transparency?
- gnramires 3y ago
  I think the argument here is that parsing of the string '1e-300' maybe should be context dependent. In this case, 1e-300 is being parsed as a double, and then forwarded to the function. Maybe it could be parsed as a bigfloat whenever it is an argument of a function expecting a bigfloat.
  - jakobnissen 3y ago
    Julia does this for exponentiation, i.e. a literal exponent is parsef differently that exponentiation by a variable. I think it was a mistake. Invariably, a new user discovers the discrepancy and is thoroughly confused. Let's not repeat the same mistake with big nums.
    - DNF2 3y ago
      I don't think this has anything to do with whether 1e-300 and 10.0^-300 is parsed differently (and perhaps that is a mistake). The poster seems to want to parse 1e-300 directly as a BigFloat in the call `BigFloat(1e-300)`, because of the function it is passed to.
      - jakobnissen 3y ago
        Yeah what I mean is - we already have "magic parsing" with literal_pow, and it's confusing and unnecessary. It was a mistake. We should not make the same mistake when parsing float literals
  - DNF2 3y ago
    Yes, I got that argument, and that is exactly what I was arguing against. You cannot and should not parse the literal double `1e-300` differently dependent on which function it is later passed to. This is what `big"1e-300"` or `BigFloat("1e-300")` is for, where the BigFloat constructor parses the string.