Numerical accuracy when converting from Single to float #1896

Activity

1. lostmsu commented on Aug 3, 2022

   

   lostmsu

   on Aug 3, 2022

   Last edited by lostmsu

   Member

   More actions

   Always check your types )

   The three expressions perhaps surprisingly give values of two different types: the 1st and 3rd are Python float (which in CPython is a float64, so same as System.Double), and the 2nd is System.Single (float32). And the values are actually equal. The reason you see different strings has to do with how precision of the number type affects rounding.

   Sadly, it looks like the current behavior deserves its place in the famous JavaScript WAT video.

   The cause for type to be different is that in most cases any System.Single value returned to Python from a call to .NET is automatically widened without loss of precision to Python float (again, which is == float64 == System.Double) similarly to how System.Int32 is widened to Python int - for convenience. The direct invocation of System.Single "constructor" is AFAIK the only exception because it is used to explicitly convert type to System.Single in order to choose a .NET overload when necessary.

   So I guess that WAT-like behavior is by design, and we won't change it in 3.0.0

   Though while playing with your code I noticed that in 3.0 (at least) float(System.Single(42)) fails, and so does any attempt to use int() or float() on instances of primitive .NET types, which looks like a bug, but it also might be intentional.

   @filmor thoughts on the float(System.Single(42)) issue?

   My experiments:

   >>> parsed = System.Single.Parse('1e-2')
   >>> from_py = System.Single(0.01)
   >>> cloned = from_py.MemberwiseClone()
   >>> parsed
   0.009999999776482582
   >>> from_py
   <System.Single object at 0x000001E25534B580>
   >>> cloned
   0.009999999776482582
   >>> from_py.ToString()
   '0.01'
   >>> float(from_py)
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
   TypeError: float() argument must be a string or a real number, not 'Single'
   >>> parsed == from_py
   True
   >>> float(from_py)
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
   TypeError: float() argument must be a string or a real number, not 'Single'
   >>> from_py2 = System.Single(0.02)
   >>> parsed == from_py2
   False
   >>> System.Double(from_py)
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
   TypeError: System.Single value cannot be converted to System.Double
   >>> System.Array[int](10).Length
   10
   >>> type(System.Array[int](10).Length)
   <class 'int'>
   >>> float(System.Int32(42))
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
   TypeError: float() argument must be a string or a real number, not 'Int32'
   >>> int(System.Int32(42))
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
   TypeError: int() argument must be a string, a bytes-like object or a real number, not 'Int32'

   😄React with 😄1Reacted by Marco Rossi
2. m-rossi commented on Aug 3, 2022

   

   m-rossi

   on Aug 3, 2022

   ContributorAuthor

   More actions

   Thank you for that detailed explanation!

   The reason you see different strings has to do with how precision of the number type affects rounding.

   I guessed it's something related to this. That's why I chose that title with accuracy. Floats can be evil sometimes.

   Sadly, it looks like the current behavior deserves its place in the famous JavaScript WAT video.

   Thank you, I did not know the video. I laughed out loud and can't wait to send it to colleagues tomorrow. 😂

   Though while playing with your code I noticed that in 3.0 (at least) float(System.Single(42)) fails, and so does any attempt to use int() or float() on instances of primitive .NET types, which looks like a bug, but it also might be intentional.

   That's reassuring, I thought I was just too stupid to make it a Python datatype again and therefore came up with

   System.Single(0.01).MemberwiseClone()
3. filmor commented on Aug 10, 2022

   

   filmor

   on Aug 10, 2022

   Member

   More actions

   I guess float(Single(42)) used to work because we implicitly converted Single to Python's float. We currently don't implement __float__ or __int__ on any .NET types, that is what's missing here.
4. m-rossi commented on Aug 10, 2022

   

   m-rossi

   on Aug 10, 2022

   ContributorAuthor

   More actions

   As a workaround I can use numpy for the rescue and its float32-datatype

   import clr
   import numpy as np
   import System
   
   s = System.Single(0.01).MemberwiseClone()
   print(s)
   n = np.float32(s)
   print(n)

   0.009999999776482582
   0.01
5. filmor

   closed this as completedon Aug 12, 2022