I'm currently working on a project involving confluent hypergeometric functions and I trie dto implement my existing code in Python with the help of scipys special functions. When I try to run the code, I get the following error:
TypeError: ufunc 'hyp1f1' not supported for the input types, and the inputs could not be safely coerced to any supported types according to the casting rule ''safe''
Googling turned up a post where the user tried to call symbolic values, but this is not the case. I do however have complex arguments. Is this an issue for the implementation of these functions?
The problematic code reads
special.hyp1f1(g(k,zeta)+1-1j*y(En,m,zeta),2*g(k,zeta)+1,-2*1j*p(En,m)*r), where g,y, and p are real functions.
Any help is much appreciated!
Apparently, scipy's confluent hypergeometric function hyp1f1(a,b,x) only allows real parameters. Documentation
Parameters: a, b:array_like
Real parameters
x:array_like
Real or complex argument
Related
The following code is stored in a file called sample.py.
import re
from typing import Optional, Tuple
def func(path: str) -> Optional[Tuple[str, str]]:
regex = re.compile(r"/'([^/']+?)'/'([^/']+?)'")
try:
return regex.match(path).groups()
except AttributeError:
return None
The Mypy Python linter throws the following error when analyzing the code:
sample.py:8: error: Incompatible return value type (got "Union[Sequence[str], Any]", expected "Optional[Tuple[str, str]]")
sample.py:8: error: Item "None" of "Optional[Match[str]]" has no attribute "groups"
While regex.match(path).groups() may return a None type, which does not have a groups attribute, the resulting exception is handled and the handling is specified in the return type. However, Mypy does not seem to understand that the exception is being handled. As far as I understand Optional[Tuple[str, str]] is the correct return type and Mypy instead insists that the less specific type Union[Sequence[str], Any] is correct . What is the proper way to use exception handling with Python typing? (Please, note that I am not asking for alternate ways to write the code without using exception handling. I am just trying to provide a minimal and complete example, where Python type checkers do not behave as I would expect with exception handling.)
Mypy does not really understand exceptions on a deep level -- in this case, does not understand that since you're catching the AttributeError, it can ignore the "what if regex.match(path) is None?" case.
More generally, the fundamental assumption mypy makes is that when you have some object foo with type Union[A, B] and you do foo.bar(), both types A and B have a bar() method.
If only one of those types have a bar() method, you'll need to do one of several things:
Give mypy sufficient information to narrow down the union to just one of the relevant types before performing the attribute access. For example, isinstance checks, x is not None checks...
Acknowledge that you are attempting to do something the type checker does not understand and settle for suppressing the generated error. For example, you could cast the type, add on a # type: ignore comment, find a way of making foo be the dynamic Any type...
Find a way of redesigning your code to side-step this issue altogether.
(In this particular case, I suppose another alternative might be to submit a pull request to mypy adding support for this pattern. But I'm not sure if this is really feasible: changing any kind of fundamental assumption is difficult work on multiple dimensions.)
Similarly, Mypy also does not understand regexes on a deep level -- e.g. doesn't try and analyze your regex to determine how many groups you'll get and so won't understand your particular regex happens to match strings with exactly two groups. The best it can do is assert that the group will return some unknown number of strings -- hence the type Sequence[str] instead of Tuple[str, str].
This sort of limitation is pretty common in type checkers in general, actually: most type systems in mainstream languages don't really support a way to predicate a return type based on the contents of any actual values passed in. Such type systems (dependent type systems, refinement type systems...) are pretty difficult to implement and often have a steep learning curve for end users.
However, it would be easier to make mypy support this on a best-effort basis by writing a mypy plugin, if you're up for it. Specifically, try taking a look at get_method_hook() and get_function_hook().
I've started learning the typing system in python and came across an issue in defining function arguments that are picklable. Not everything in python can be pickled, can I define a type annotation that says "only accept objects that can are picklable"?
At first it sounds like something that should be possible, similar to Java's Serializable but then there is no Picklable interface in python and thinking about the issue a little more it occurs to me that pickling is an inherently runtime task. What can be pickled lists a number of things that can be pickled, and it's not difficult to imagine a container of lambda functions which would not be picklable, but I can't think of a way of determining that before hand (without touching the container definition).
The only way I've come up with is to define something like a typing.Union[Callable, Iterable, ...] of all the things listed in What can be pickled but that does not seem like a good solution.
This issue on github partially answers the question, although the issue is specifically related to json not pickle but the first answer from Guido should still apply to pickle
I tried to do that but a recursive type alias doesn't work in mypy right now, and I'm not sure how to make it work. In the mean time I use JsonDict = Dict[str, Any] (which is not very useful but at least clarifies that the keys are strings), and Any for places where a more general JSON type is expected.
https://github.com/python/typing/issues/182
I'm developing an app in a language other than Objective-C and I came across newBoxWithDimensions. It uses the vector_float3 type which comes from the SIMD API.
I can not encode this function because of the vector_float3 type.
I've found Why can't gcc or clang properly #encode SIMD vector types?; the problem here is when #encode does not encode the SIMD types, then it can not create a proper form for those functions that use SIMD types and then the message sending verification fails. How can I bypass this encoding problem in message sending verification?
As an experiment, I requested the method signature for +newBoxWithDimensions:segments:geometryType:inwardNormals:allocator:, using:
NSMethodSignature* sig = [MDLMesh methodSignatureForSelector:#selector(newBoxWithDimensions:segments:geometryType:inwardNormals:allocator:)];
I then enumerated its arguments and their type encodings. It turns out that the signature just skips the two vector arguments. It shows a total of 5 arguments, which includes the implicit self and _cmd arguments, when there should be 7. The encodings are "#", ":", "q", "c", "#", the first two of which correspond to self and _cmd and the last three of which match the last three arguments of the method.
I think your safest approach is to write an Objective-C module that exports a function wrapping this method but where the vector components are passed separately (i.e. three float arguments for the dimensions and three unsigned int arguments for the segments). It would construct the vector arguments from those individual arguments and call through to the class method, returning its result.
Work-around solution for Rust
For those who are using Rust and have the same problem, I found the work around for bypassing the errors, but keep in mind the problem still exists and my solution will make the developer blind in their debugging process.
If you are using objc crate, try to remove the verify_message feature from your crate, else do not do message verifying.
Use simd representation for your vector data and put your data in your message without any encoding.
In this case you are insanely blind in your development, one way I can suggest is to take your debugging in to Xcode (this is not good too!).
I'd like to undertand how I can dynamically add number of days to a given timestamp: I tried something similar to the example shown below. The issue here is that the second argument is expected to be of type Int, however in my case it returns type Column. How do I unbox this / get the actual value? (The code examples below might not be 100% correct as I write this from top of my head ... I don't have the actual code with me currently)
myDataset.withColumn("finalDate",date_add(col("date"),col("no_of_days")))
I tried casting:
myDataset.withColumn("finalDate",date_add(col("date"),col("no_of_days").cast(IntegerType)))
But this did not help either. So how is it possible to solve this?
I did find a workaround by using selectExpr:
myDataset.selectExpr("date_add(date,no_of_days) as finalDate")
While this works, I still would like to understand how to get the same result with withColumn.
withColumn("finalDate", expr("date_add(date,no_of_days)"))
The above syntax should work.
I think it's not possible as you'd have to use two separate similar-looking type systems - Scala's and Spark SQL's.
What you call a workaround by using selectExpr is probably the only way to do it as you're confined in a single type system, in Spark SQL's and since the parameters are all defined in Spark SQL's "realm" that's the only possible way.
myDataset.selectExpr("date_add(date,no_of_days) as finalDate")
BTW, you've just showed me another reason where support for SQL is different from Dataset's Query DSL. It's about the source of the parameters to functions -- only from structured data sources, only from Scala or a mixture thereof (as in UDFs and UDAFs). Thanks!
I'm trying to learn Haskell in guidance of Learn You a Haskell, but the following puzzles me.
lucky :: (Integral a) => a -> String
lucky 7 = "LUCKY NUMBER SEVEN!"
lucky x = "Sorry, you're out of luck, pal!"
As you can see, there's one line up there stating the exact types of the function. But is this necessary? Can't the types of parameters and return values be deduced from the patterns below that line?
You are right, they are absolutely not necessary. However, it's a very common practice to state the type of the function nevertheless, for at least two reasons :
To tell the compiler what you actually mean. In case you make a mistake writing the function, the compiler will not infer a bad type, but warn you of your mistake
To tell the people who read your code. They'll have to find out the type of the function anyway while understanding the code, so you might as well make it easier for them. Having the type explicitly makes the code more readable.
This is why, although they are optional, the types of top level functions are almost always spelled out in Haskell code.
To complete with what Zeta said, it is not necessary in this case. However, in some situations, it is necessary to specify the type of the function when the code is too ambiguous to infer.
For documentation purpose, and because for some type extensions the automatic inference fails. Read here.