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.
Related
I have the following function: problema_firma_emprestimo(r,w,r_emprestimo,posicao,posicao_banco), where all input are scalars.
This function return three different matrix, using
return demanda_k_emprestimo,demanda_l_emprestimo,lucro_emprestimo
I need to run this function for a series of values of posicao_banco that are stored in a vector.
I'm doing this using a for loop, because I need three separate matrix with each of them storing one of the three outputs of the function, and the first dimension of each matrix corresponds to the index of posicao_banco. My code for this part is:
demanda_k_emprestimo = zeros(num_bancos,na,ny);
demanda_l_emprestimo = similar(demanda_k_emprestimo);
lucro_emprestimo = similar(demanda_k_emprestimo);
for i in eachindex(posicao_bancos)
demanda_k_emprestimo[i,:,:] , demanda_l_emprestimo[i,:,:] , lucro_emprestimo[i,:,:] = problema_firma_emprestimo(r,w,r_emprestimo[i],posicao,posicao_bancos[i]);
end
Is there a fast and clean way of doing this using vectorized functions? Something like problema_firma_emprestimo.(r,w,r_emprestimo[i],posicao,posicao_bancos) ? When I do this, I got a tuple with the result, but I can't find a good way of unpacking the answer.
Thanks!
Unfortunately, it's not easy to use broadcasting here, since then you will end up with output that is an array of tuples, instead of a tuple of arrays. I think a loop is a very good approach, and has no performance penalty compared to broadcasting.
I would suggest, however, that you organize your output array dimensions differently, so that i indexes into the last dimension instead of the first:
for i in eachindex(posicao_bancos)
demanda_k_emprestimo[:, :, i] , ...
end
This is because Julia arrays are column major, and this way the output values are filled into the output arrays in the most efficient way. You could also consider making the output arrays into vectors of matrices, instead of 3D arrays.
On a side note: since you are (or should be) creating an MWE for the sake of the people answering, it would be better if you used shorter and less confusing variable names. In particular for people who don't understand Portuguese (I'm guessing), your variable names are super long, confusing and make the code visually dense. Telling the difference between demanda_k_emprestimo and demanda_l_emprestimo at a glance is hard. The meaning of the variables are not important either, so it's better to just call them A and B or X and Y, and the functions foo or something.
I am very new to Julia and mostly code in Python these days. I am using Julia to work with and manipulate HDF5 files.
So when I get to writing out (h5write), I get an error because the data argument is of mixed type and I need to find out why.
The error message says Array{Dict{String,Any},4} is what I am trying to pass in, but when I look at the values (and it is a huge structure), I see a lot of 0xff and values like this. How do I quickly find why the Any and not a single type?
Just to make this an answer:
If my_dicts is an Array{Dict{String, Any}, 4}, then one way of working out what types are hiding in the Any part of the dict is:
unique(typeof.(values(my_dicts[1])))
To explain:
my_dicts[1] picks out the first element of your Array, i.e. one of your Dict{String, Any}
values then extracts the values, which is the Any part of the dictionary,
typeof. (notice the dot) broadcasts the typeof function over all elements returned by values, returning the types of all of these elements; and
unique takes the list of all these types and reduces it to its unique elements, so you'll end up with a list of each separate type contained in the Any partof your dictionary.
Help files call attributes() a function. Its syntax looks like a function call. Even class(attributes) calls it a function.
But I see I can assign something to attributes(myobject), which seems unusual. For example, I cannot assign anything to log(myobject).
So what is the proper name for "functions" like attributes()? Are there any other examples of it? How do you tell them apart from regular functions? (Other than trying supposedfunction(x)<-0, that is.)
Finally, I guess attributes() implementation overrides the assignment operator, in order to become a destination for assignments. Am I right? Is there any usable guide on how to do it?
Very good observation Indeed. It's an example of replacement function, if you see closely and type apropos('attributes') in your R console, It will return
"attributes"
"attributes<-"
along with other outputs.
So, basically the place where you are able to assign on the left sign of assignment operator, you are not calling attributes, you are actually calling attributes<- , There are many functions in R like that for example: names(), colnames(), length() etc. In your example log doesn't have any replacement counterpart hence it doesn't work the way you anticipated.
Definiton(from advanced R book link given below):
Replacement functions act like they modify their arguments in place,
and have the special name xxx<-. They typically have two arguments (x
and value), although they can have more, and they must return the
modified object
If you want to see the list of these functions you can do :
apropos('<-$') and you can check out similar functions, which has similar kind of properties.
You can read about it here and here
I am hopeful that this solves your problem.
What is the difference between this lines of code?
mean(some_argument)
mean(x = some_argument)
The output is the same, but has the explicit mention of x any advantages?
People typically don't add argument names for commonly used arguments, such as the x in mean, but almost always refer to the na.rm arguments when removing missing values.
While neglecting the argument name makes for compact code, here are four (related) reasons for including the names of arguments rather than relying on their position.
Re-order arguments as needed. When you refer to the arguments by name, you can arbitrarily re-order the arguments and still produce the desired result. Sometimes it is useful to re-order your arguments. For example, when running a loop over one of the arguments, you might prefer to put the looped argument in the front of the function.
It is typically safer / more future-proof. As an example, if some user-written function or package re-orders the arguments in an update, and you relied on the positions of the arguments, this would break your code. In the best scenario, you would get an error. In the worst scenario the function would run, but would an incorrect result. Including the argument names greatly reduces the chances of running into either case.
For greater code clarity. If an argument is rarely used or you want to be explicit for future readers of your code (including you 2 months from now), adding the names can make for easier reading.
Ability to skip arguments. If you want to only change the third argument, then referring to it by name is probably preferable.
See also the R Language Definition: 4.3.2 Argument matching
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.