To determine if a variable is a function, I use the following method
function isFunction(variable)
return type(variable) == "function"
end
To my knowledge, this is a string comparison. As I've understood it, string comparisons are relatively slow and I fear this function might be a bottleneck in my code. Is there a less costly way to determine if a variable is a function?
I'm hoping there's a function which returns an integer that indicates the type of the variable instead. Or I can ask my question another way: How does type(var) determine the type of a variable? Surely, each variable can't hold a string representing its type so I'm guessing there is some backend-stuff in lua that looks up the string "function" when invoking type(var).
String comparisons in Lua are really fast because most strings are interned.
Internally, every Lua value contains a tag identifying its type. It is this tag that type uses.
Related
They are described as scalar, but I think that refers to the return type rather than the arguments.
I'm trying to define one in rust that will provide a TEXT value derived from other columns in the row, for convenience/readability at point of use, I'd like to call it as select myfunc(mytable) from mytable rather than explicitly the columns that it derives.
The rusqlite example simply gets an argument as f64, so it's not that clear to me how it might be possible to interpret it as a row and retrieve columnar values from within it. Nor have I been able to find examples in other languages.
Is this possible?
This doesn't seem possible.
func(tablename) syntax that I'm familiar with seems to be PostgreSQL-specific; SQLite supports func(*) but when func is user-defined it receives zero arguments, not one (structured) or N (all columns separately) as I expected.
I'm trying to declare an array in R, something logically equivalent to the following Java code:
Object[][] array = new Object[6][32]
After I declare this array, I plan to loop over the indices and assign values to them.
I am not familiar with what you are planning on doing in R, but loops are generally not recommended. I would say this is especially true when you don't know the length of the output.
You might want to find a "vectorized" solution first and if not, then using something in the apply family might also be helpful
Disclaimer: I am certain there is more nuance to this discussion based on what I have read, so I don't want to claim to be an expert on this subject.
Given the name of an R object (as a string), how can I return the object with that name?
(The context in which this comes up is that I am running the function findGlobals, which returns a vector objects as a strings. I would like to then iterate through the list and test to make sure each name refers to a function using is.function. If you know of a solution to this specific problem without the more general question above, that would also be appreciated.)
get() is what you're looking for. And by "iterate" I assume you mean using an apply variant, e.g.
sapply(ls(), FUN = function(x) is.function(get(x)))
i'm confused about IS OF and TREAT(). what the difference between IS OF and TREAT() (when come to sub-type and super-type) in oracle?
IS OF is an operator that tests an object and returns either true or false.
TREAT is a function that converts an object and returns an object.
So use IS OF it you just want to test whether an object is of some more specific subtype. Use TREAT if you not only want to test but use the object.
Given the following query
let $a := xs:dateTime("2012-01-01T00:00:00.000+00:00")
let $b := xs:dateTime($a)
let $c := xs:dateTime($a cast as xs:string)
(: cannot - don't know how to - execute the function without assignment :)
let $d := adjust-dateTime-to-timezone($a, xs:dayTimeDuration("PT1H"))
return (<a>{$a}</a>,<b>{$b}</b>,<c>{$c}</c>)
the output is as follows
<a>2012-01-01T01:00:00+01:00</a>
<b>2012-01-01T01:00:00+01:00</b>
<c>2012-01-01T00:00:00Z</c>
Based on XQuery's documentation on constructor functions (the constructor function for a given type is used to convert instances of other atomic types into the given type) this is the expected behaviour. Calling xs:dateTime($a) simply returns $a as there is no need to cast, but xs:dateTime($a cast as xs:string) creates a new xs:string from $a first. However this requires an extra conversion.
Is there any other way to tackle this problem? Or conversions are cheap and I shouldn't care?
(If it makes any difference my XQuery processor is BaseX 7.2.)
It seems it does a make a difference that I'm using BaseX. I've really thought that this is the way the xs:dateTime constructor function and the adjust-dateTime-to-timezone function should be working, this is why I misinterpreted the XQuery documentation.
Given the input I've been given by Dimitre and Ranon it seems the problem described is gone.
By the why my use case is, or more like it was, that I wanted to make a date-time interval based query against my XML data set's date-time element. Because the input parameters and the source date-time values used different time-zones I had to make time-zone corrections with the above function, which modified its input parameter (the original source date-time in my case), however I wanted to preserve the original value. Given the function's name adjust-dateTime I thought that it's okay that it modifies its argument, so I automatically thought that I had to copy my original value using a constructor function to be able to keep the original date-time value.
Looks like you ran into some really weird bug.
Your line 5 shouldn't change $a-c at all as XQuery is a functional programming language with immutable variables (adjust-dateTime-to-timezone should not change your variables) and without side effects. Thats why you were forced to assign $d, otherwise your calculated results directly would have been thrown away.
I just submitted some bug request. Zorba is doing your query right, you can use it for understanding the problem.
BaseX as you preferred XQuery processor will do within few days, too. I or some other BaseX team member will trigger you here as soon as it's fixed.
I guess your problem arised from missunderstanding and wrong behaviour of BaseX and should be solved. Feel free to ask again if anything stayed unclear with your query.
The output that is reported is incorrect.
The correct output (produced running Saxon under oXygen) is:
<a>2012-01-01T00:00:00Z</a>
<b>2012-01-01T00:00:00Z</b>
<c>2012-01-01T00:00:00Z</c>
The adjust-dateTime-to-timezone() function, as any other function cannot modify its arguments -- its effect is only contained in the variable $d -- which you don't use in the return clause.