Mirror of forum.nim-lang.org

5836 :: Nim will silently auto convert a float64 to a float32 and loose precision... is that good? Thoughts?

• treeform (orginal) [2020-01-20T04:13:41+01:00] view original

  I get why float32 can auto convert to float64... there is no loss in precision.

  But its strange to me that reverse is also true. Nim will auto convert a float64 to a float32 and loose precision!!! Silently! This is not true for ints.

  Here it states so in the manual: https://nim-lang.org/docs/manual.html#type-relations-convertible-relation

  var
    a: float64 = 20e-70
    b: float32 = a
    c: float64 = b
  
  echo a
  echo b
  echo c
  Run

  Output:

  
  2e-69
  0.0
  0.0
  Run

  You can see here we had float64 of 20e-70 go through an intermediate float32 that rounded it, so that the next float64 was 0.

  My fear that its easy to have a random float32 in your code that is basically a rounding function. And you will never know!

  Thoughts? Why was it done like this? Do you guys think this is good? Does it matter? Can't change now because too much code depends on it?

---

• kidandcat (orginal) [2020-01-20T09:34:48+01:00] view original

  I don't see where the silently is, you are forcing a type conversion. In JS nearly the whole language can be converted back and forth.

  I would see that dangerous if you don't declare the type of "b" and the compiler implies float32, but if you declare its type, that's not silently for me.

---

• Stefan_Salewski (orginal) [2020-01-20T09:53:54+01:00] view original

  For me it is silently.

  Mixing float64 and float32 unintentionally can be dangerous for precision and have disadvantage for performance.

  May we allow that mixing only when lenientOps is imported or can compiler give us warnings at least?

---

• Araq (orginal) [2020-01-20T10:53:56+01:00] view original

  I agree it's bad and we need to do something about it. Maybe only allow implicit conversions from float literals to float32? We can make the compiler produce a warning for the other cases.

---

• mfiano (orginal) [2020-01-20T22:21:09+01:00] view original

  I'm not sure if this is related behavior, but @treeform made this post after trying to figure out the following code:

  type Elem = float32 or float64
  type Vec2[T : Elem] = object
    x : T
    y : T
  
  proc vec2[T:Elem](x, y: T) : Vec2[T] = Vec2[T](x: x, y: y)
  
  let a = vec2(1f32,2f64)
  let b = vec2(1f64,2f32)
  
  echo typeof(a) # Vec2[system.float32]
  echo typeof(b) # Vec2[system.float64]
  Run

  The OP's code wasn't very surprising to me, as it was explicitly casting, but this one here is very surprising to me.

---

• Stefan_Salewski (orginal) [2020-01-21T08:30:54+01:00] view original

  The result of your code is not really surprising: As you specify the type Elem as an or type, you get finally two instances of vec2() proc. One produces an object containing float32 fields, and one producing an object containing float64 fields. The decision to use which of then is here taken from first proc argument, as the second argument is a compile time constant that one is silently converted.

---

• jibal (orginal) [2020-01-23T00:00:33+01:00] view original

  I don't see where the silently is

  It's silent because there's no warning of the loss of precision.

  you are forcing a type conversion

  By this reasoning, there are no silent type conversions, just type conversions, all of which are "forced" by the semantics of the language.

  In JS nearly the whole language can be converted back and forth.

  And your point is ...? JS is not a good model.

  if you don't declare the type of "b" and the compiler implies float32

  type
    a: float64 = 20e-70
    b = a # b is float32
  Run

  wouldn't be a silent type conversion, it would just be absurd.

---