What does this syntax mean?
torch.*Torch?
It's specific to jupyter/ipython. It's invalid in Python.
Related
I am coding in R and due to stability purposes when I have to deploy something, I call every function with the syntax package::function(arguments) just to avoid conflicts that as you know may happen when using a lot of packages. It helped me a lot over the years.
I know that if is a reserved word so technically speaking it is impossible (or at least it should be in my knowledge) for someone to define an object and name it if.
I am also aware that it belongs to control flow statement (which I think are a different "thing") and due to the previous consideration I am also aware that the following questions might be useless. My pure technical doubts are:
Why if I embrace it in back-ticks the function class returns "function" as a result?
Why without back-ticks I get an error? and last but most important
Why I am unable to access it via the usual base::if() syntax?
As I said, most likely useless questions but at this point I am curious about the details underneath it.
> class(if)
Error: unexpected ')' in "class(if)"
> class(`if`)
[1] "function"
> base::if(T) T
Error: unexpected 'if' in "base::if"
> if(T) T
[1] TRUE
> base::if(`T`) T
Error: unexpected 'if' in "base::if"
if-with-backticks actually returns .Primitive("if")
The R language definition section on "Internal vs Primitive" specifies that .Primitive objects include
“Special functions” which really are language elements, but implemented as primitive functions:
{ ( if for while repeat break next
return function quote switch
The reason that a naked "if" without backticks or base::if don't work is that the "language elements" above are treated as special cases by R's parser. Once you have typed base::, R's parser expects the next symbol to be a regular symbol that can be looked up in the base namespace. base::if, base::for, and base::( all return errors because R does not expect these special elements to occur at this position in the input stream; they are syntactically incorrect.
I am updating my code from Julia v0.6 to v0.7. I get the following error at runtime:
Warning: Deprecated syntax `parametric method syntax Base.show{S (io::IO, m::Base.MIME("text/plain"), scvec::Vector{StatesContainer{S}}) around /Users/logankilpatrick/.julia/packages/SHERPA/A8APz/src/utils/states_containers.jl:74.
Use Base.show(io::IO, m::Base.MIME("text/plain"), scvec::Vector{StatesContainer{S}}) where S instead.
So I do the following:
Original code: Base.show{S}(io::IO, m::Base.MIME("text/plain"), scvec::Vector{StatesContainer{S}})
Updated Code: function Base.show(io::IO, m::Base.MIME("text/plain"), scvec::Vector{StatesContainer{S}}) where S
I still get the following error: ERROR: LoadError: LoadError: ArgumentError: invalid type for argument m in method definition for show at /Users/logankilpatrick/.julia/packages/SHERPA/A8APz/src/utils/states_containers.jl:74
All line 74 shows is: println(io, typeof(scvec))
Any suggestions as to how to resolve this issue?
Thanks!
Note: I tried commenting out what was on line 74, and re-running it. It then said there was an issue with line 76!
I also tried getting rid of the "where S" part at the end of the function but that doesn't resolve the issue.
A correct signature is:
Base.show(io::IO, m::MIME{Symbol("text/plain")}, scvec::Vector{StatesContainer{S}}) where S
Does Julia have an equivalent of Python's with? Maybe as a macro? This is very useful, for example, to automatically close opened files.
Use a do block. Docs on do blocks are here.
And here is an example of how to do the usual with open(filename) as my_file of Python in Julia:
open("sherlock-holmes.txt") do filehandle
for line in eachline(filehandle)
println(line)
end
end
The above example is from the Julia wikibooks too.
Although the do block syntax does have certain similarities to Python's with statement, there is no exact equivalent. This is discussed in further detail in the GitHub issue "with for deterministic destruction". The issue concludes that this structure should be added to Julia, although no syntax or plan for such is established.
I would like to use functions from the xquery-operators namespace (http://www.w3.org/2002/08/xquery-operators) in Zorba, specifically, op:add-dayTimeDuration-to-dateTime.
However I get a static error: "op:add-dayTimeDuration-to-dateTime": function with arity 2 not declared". I had to declare the op namespace to get that far, so maybe Zorba uses a different prefix. Or, maybe these functions aren't implemented. I've had difficulty trying to search for answers to these questions.
Thanks!
From the spec: Functions defined with the op prefix are described here to underpin the definitions of the operators in [XML Path Language (XPath) 2.0], [XQuery 1.0: An XML Query Language] and [XSL Transformations (XSLT) Version 2.0]. These functions are not available directly to users, and there is no requirement that implementations should actually provide these functions. For this reason, no namespace is associated with the op prefix. For example, multiplication is generally associated with the * operator, but it is described as a function in this document.....
Can't you just use the + operator?
My Marklogic XQuery fn:data(<type>hello world</type>) gives me Invalid lexical value error
This is the stack trace:
query evaluated in Documents at file::Docs/ as 1.0-ml (cq v4.1-1-EA)
[1.0-ml] XDMP-LEXVAL: xs:integer("hello world") -- Invalid lexical value "hello world"
Stack trace:
line 2:
1:
2: fn:data(<type>hello world</type>)
xdmp:eval("
fn:data(<type>hello world</type>)", (), <options xmlns="xdmp:eval"><isolation>different-transaction</isolation></options>)
in /cq/eval.xqy line 111:
And when I use fn:data(<p>hello world</p>) it is giving me expected answer (hello world).
Any help on this error would be appreciated.
Thanks.
Finally figured what was wrong.
Had an xsd which was defining element type as xs:integer thats why this error was coming. Removed that xsd and now everything is working fine :)
Glad you figured it out. It looks like the extra schema was targeting the empty namespace?
Here's a tip: avoid using a schema unless it also specifies a namespace. That makes it much easier to keep your schemas organized.