Github user zasdfgbnm commented on a diff in the pull request:
https://github.com/apache/spark/pull/18444#discussion_r125173449
--- Diff: python/pyspark/sql/types.py ---
@@ -935,6 +936,86 @@ def _parse_datatype_json_value(json_value):
long: LongType,
})
+# Mapping Python array types to Spark SQL DataType
+# We should be careful here. The size of these types in python depends on C
+# implementation. We need to make sure that this conversion does not lose
any
+# precision.
+#
+# Reference for C integer size, see:
+# ISO/IEC 9899:201x specification, § 5.2.4.2.1 Sizes of integer types
<limits.h>.
+# Reference for python array typecode, see:
+# https://docs.python.org/2/library/array.html
+# https://docs.python.org/3.6/library/array.html
+
+_array_int_typecode_ctype_mappings = {
+ 'b': ctypes.c_byte,
+ 'B': ctypes.c_ubyte,
+ 'h': ctypes.c_short,
+ 'H': ctypes.c_ushort,
+ 'i': ctypes.c_int,
+ 'I': ctypes.c_uint,
+ 'l': ctypes.c_long,
+ 'L': ctypes.c_ulong
+}
+
+# TODO: Uncomment this when 'q' and 'Q' are supported by
net.razorvine.pickle
+# Type code 'q' and 'Q' are not available at python 2
+# if sys.version > "2":
+# _array_int_typecode_ctype_mappings.update({
+# 'q': ctypes.c_longlong,
+# 'Q': ctypes.c_ulonglong
+# })
+
+
+def _int_size_to_type(size):
+ """
+ Return the Scala type from the size of integers.
+ """
+ if size <= 8:
+ return ByteType
+ if size <= 16:
+ return ShortType
+ if size <= 32:
+ return IntegerType
+ if size <= 64:
+ return LongType
+ raise TypeError("not supported type: integer size too large.")
+
+_array_type_mappings = {
+ # Warning: Actual properties for float and double in C is not
unspecified.
--- End diff --
Yes, you are correct. Thanks for figuring this out.
I just checked, `sys.float_info` is the info for C type double, not for C
type float:
```python
>>> import sys
>>> sys.float_info.max
1.7976931348623157e+308
>>> sys.float_info.dig
15
```
So we can not use this to check range for C float. But this is not the main
reason I'm not using it.
The main reason is:
Although C does not specify that we have to use IEEE-754 floating point
types, all the C platform I have ever seen uses IEEE-754. (Also there is a
StackOverflow question about this:
https://stackoverflow.com/questions/31967040/is-it-safe-to-assume-floating-point-is-represented-using-ieee754-floats-in-c
) I don't even know if there exists a platform in the world that: python is
supported, JVM is supported, and floating point types in C does not use
IEEE-754. So, I think it would be OK to assume that these types are IEEE-754
for now to make the code cleaner. It does not worth any effort to support
something that might not even exist. But I'm not an expert on this either, so
if you know someone that might know more on this, please ping them to double
check. On the other hand, If there do exist users that use these platform find
that this is a wrong assumption, they can report a new bug to fix this. But
yes, my comment seems to be confusing and I will try if I can make it clearer.
Also, thank you for pointing out the `sys.float_info`, although I don't
think I need to use it here, it would be very useful in test cases. I will
change part of my test cases to use it to make code more readable.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org
