SWI-Prolog version 8.0.3 for x64-win64, using yall for lambdas. (use_module(library(yall)).)
Trying to access a value in a dict, within a labmda, causes an error.
I think this is less a problem with yall, and more a problem with dicts in...let's call them "goal-as-value"s, because I'm not sure of the correct term. (For example, X = (Y = 1).) An example representative of my actual problem would be ?- L = [S]>>(S=a{x:_},S.x = 10)., but I'll give a simpler example to start.
Consider:
?- L = (S=a{x:_},S.x = 10).
ERROR: Arguments are not sufficiently instantiated
ERROR: In:
ERROR: [11] throw(error(instantiation_error,_11412))
ERROR: [8] '<meta-call>'(user:(...,...)) <foreign>
ERROR: [7] <user>
ERROR:
ERROR: Note: some frames are missing due to last-call optimization.
ERROR: Re-run your program in debug mode (:- debug.) to get more detail.
when I would instead expect something like the following:
?- L = (S=a{x:_},S.x = 10).
L = (S=a{x:_14168}, S.x=10).
Going back to lambdas, note that my intent can be accomplished, with e.g.
?- L = [S]>>(S=a{x:_},(.(S,x,10))).
L = [S]>>(S=a{x:_8692}, '.'(S, x, 10)).
It's just kinda horrible.
(Calling this lambda yields S = a{x:10}, as expected.)
This seems like a bug in SWI-Prolog, or at least an undocumented limitation. Have I missed something, or should I file a bug report?
As your L = (S=a{x:_},S.x = 10) query shows, the error have nothing to do with library(yall) but with dicts semantics. When using functional notation, as in S.x = 10, SWI-Prolog performs eager evaluation of S.x during query compilation, i.e. before the S=a{x:_} goal is proved. Hence the instantiation error. As you found, not using functional notation by switching to the '.'(S, x, 10) goal solves the problem as it becomes the second goal being proved on the conjunction.
Related
Is it possible to have a the software ignore the fact that there are unused arguments defined when a module is run?
For example, I have a module multiply(a,b), which returns the product of a and b. I will receive an error if I call the module like so:
multiply(a=20,b=30,c=10)
Returning an error on this just seems a bit unnecessary, since the required inputs a and b have been specified. Is it possible to avoid this bad behaviour?
An easy solution would be just to stop specifying c, but that doesn't answer why R behaves like this. Is there another way to solve this?
Change the definition of multiply to take additional unknown arguments:
multiply <- function(a, b, ...) {
# Original code
}
The R.utils package has a function called doCall which is like do.call, but it does not return an error if unused arguments are passed.
multiply <- function(a, b) a * b
# these will fail
multiply(a = 20, b = 30, c = 10)
# Error in multiply(a = 20, b = 30, c = 10) : unused argument (c = 10)
do.call(multiply, list(a = 20, b = 30, c = 10))
# Error in (function (a, b) : unused argument (c = 10)
# R.utils::doCall will work
R.utils::doCall(multiply, args = list(a = 20, b = 30, c = 10))
# [1] 600
# it also does not require the arguments to be passed as a list
R.utils::doCall(multiply, a = 20, b = 30, c = 10)
# [1] 600
One approach (which I can't imagine is good programming practice) is to add the ... which is traditionally used to pass arguments specified in one function to another.
> multiply <- function(a,b) a*b
> multiply(a = 2,b = 4,c = 8)
Error in multiply(a = 2, b = 4, c = 8) : unused argument(s) (c = 8)
> multiply2 <- function(a,b,...) a*b
> multiply2(a = 2,b = 4,c = 8)
[1] 8
You can read more about ... is intended to be used here
You could use dots: ... in your function definition.
myfun <- function(a, b, ...){
cat(a,b)
}
myfun(a=4,b=7,hello=3)
# 4 7
I had the same problem as you. I had a long list of arguments, most of which were irrelevant. I didn't want to hard code them in. This is what I came up with
library(magrittr)
do_func_ignore_things <- function(data, what){
acceptable_args <- data[names(data) %in% (formals(what) %>% names)]
do.call(what, acceptable_args %>% as.list)
}
do_func_ignore_things(c(n = 3, hello = 12, mean = -10), "rnorm")
# -9.230675 -10.503509 -10.927077
Since there are already a number of answers directly addressing the question, and R is often used by technically skilled non-programmers, let me quickly outline why the error exists, and advise against suppression workarounds.
The number of parameters is an important aspect defining a function. If the number of parameters mismatches, that's a good indication that there is a mismatch between the callers intent and what the function is about to do. For this reason, this would be a compilation error in many programming languages, including Java, Python, Haskell, and many others. Indeed, stricter type checking in many of these languages will also cause errors if types mismatch.
As a program grows in size, and code ages, it becomes harder to spot whether mismatches of this kind are intended or are genuine bugs. This is why an idea of "clean code" - simple to read code with no errors or warnings - is often a standard professional programmers work towards.
Accordingly, I recommend reworking the code to remove the unnecessary parameter. It will be simpler to understand and debug for yourself and others in the future.
Of course I understand that R users are often working on small scripts with limited lifespans, and the usual tradeoffs of large software engineering projects don't always apply. Maybe for your quick script, that will only be used for a week, it made sense to just suppress the error. However, it is widely observed (and I have seen in my own experience) that what code endures is rarely obvious at the time of writing. If you are pursuing open science, and publishing your code and data, it is especially helpful for that code to be useful in the future, to others, so they can reproduce your results.
A similar error is also thrown when using the select() function from the dplyr package and having loaded the MASS package too.
Minimal sample to reproduce:
library("dplyr")
library("MASS")
iris %>% select(Species)
will throw:
Error in select(., Species) : unused argument (Species)
To circumvent use:
library("dplyr")
library("MASS")
iris %>% dplyr::select(Species)
EXPLANATION:
When loading dplyr, a select function is defined and when loading MASS afterwards, the select function is overwritten. When the select function is called, MASS::select() is executed which needs a different number of arguments.
R has a function prod() which does multiplication really well. The example the asker gave works fine with the prod() function without returning an error.`
prod(a=20,b=30,c=10)
# 6000
In any case, an error highlighted is an opportunity to rectify it, so not a bad behaviour.
How can I translate the following code of R to Julia? I am new in Julia.
I know Julia has different ways to replace for loop.
max_trial <- max(dataframe[,1])
max_c1 <- NA
for(c in 1:max_trial){
c1 <- which(dataframe[,1]==c)
max_measure <- max(dataframe[c1,2])
max_c1[c] <- max_measure
}
As suggested I applied the following code translate
max_c1= []
for c in 1:max_trial
c1 = findall(dataframe[:,1] .== c)
max_c1[c] = maximum(dataframe[c1,2])
end
But I received the following error
ERROR: BoundsError: attempt to access 0-element Array{Any,1} at index [1]
Also the values received from this translation “ maximum(dataframe[c1,2])” is still different than The R code. It seems for this part of error some adjustment of the syntax needs improvement.
I think the corresponding Julia code would look like
for c in 1:max_trial
c1 = findall(dataframe[:,1] .== c)
max_c1[c] = maximum(dataframe[c1,2])
end
although I think you did not give enough information to completely answer your question, so I'm not really sure. Maybe adding the data you used and the output you are looking for in your question would help?
Is it possible to have a the software ignore the fact that there are unused arguments defined when a module is run?
For example, I have a module multiply(a,b), which returns the product of a and b. I will receive an error if I call the module like so:
multiply(a=20,b=30,c=10)
Returning an error on this just seems a bit unnecessary, since the required inputs a and b have been specified. Is it possible to avoid this bad behaviour?
An easy solution would be just to stop specifying c, but that doesn't answer why R behaves like this. Is there another way to solve this?
Change the definition of multiply to take additional unknown arguments:
multiply <- function(a, b, ...) {
# Original code
}
The R.utils package has a function called doCall which is like do.call, but it does not return an error if unused arguments are passed.
multiply <- function(a, b) a * b
# these will fail
multiply(a = 20, b = 30, c = 10)
# Error in multiply(a = 20, b = 30, c = 10) : unused argument (c = 10)
do.call(multiply, list(a = 20, b = 30, c = 10))
# Error in (function (a, b) : unused argument (c = 10)
# R.utils::doCall will work
R.utils::doCall(multiply, args = list(a = 20, b = 30, c = 10))
# [1] 600
# it also does not require the arguments to be passed as a list
R.utils::doCall(multiply, a = 20, b = 30, c = 10)
# [1] 600
One approach (which I can't imagine is good programming practice) is to add the ... which is traditionally used to pass arguments specified in one function to another.
> multiply <- function(a,b) a*b
> multiply(a = 2,b = 4,c = 8)
Error in multiply(a = 2, b = 4, c = 8) : unused argument(s) (c = 8)
> multiply2 <- function(a,b,...) a*b
> multiply2(a = 2,b = 4,c = 8)
[1] 8
You can read more about ... is intended to be used here
You could use dots: ... in your function definition.
myfun <- function(a, b, ...){
cat(a,b)
}
myfun(a=4,b=7,hello=3)
# 4 7
I had the same problem as you. I had a long list of arguments, most of which were irrelevant. I didn't want to hard code them in. This is what I came up with
library(magrittr)
do_func_ignore_things <- function(data, what){
acceptable_args <- data[names(data) %in% (formals(what) %>% names)]
do.call(what, acceptable_args %>% as.list)
}
do_func_ignore_things(c(n = 3, hello = 12, mean = -10), "rnorm")
# -9.230675 -10.503509 -10.927077
Since there are already a number of answers directly addressing the question, and R is often used by technically skilled non-programmers, let me quickly outline why the error exists, and advise against suppression workarounds.
The number of parameters is an important aspect defining a function. If the number of parameters mismatches, that's a good indication that there is a mismatch between the callers intent and what the function is about to do. For this reason, this would be a compilation error in many programming languages, including Java, Python, Haskell, and many others. Indeed, stricter type checking in many of these languages will also cause errors if types mismatch.
As a program grows in size, and code ages, it becomes harder to spot whether mismatches of this kind are intended or are genuine bugs. This is why an idea of "clean code" - simple to read code with no errors or warnings - is often a standard professional programmers work towards.
Accordingly, I recommend reworking the code to remove the unnecessary parameter. It will be simpler to understand and debug for yourself and others in the future.
Of course I understand that R users are often working on small scripts with limited lifespans, and the usual tradeoffs of large software engineering projects don't always apply. Maybe for your quick script, that will only be used for a week, it made sense to just suppress the error. However, it is widely observed (and I have seen in my own experience) that what code endures is rarely obvious at the time of writing. If you are pursuing open science, and publishing your code and data, it is especially helpful for that code to be useful in the future, to others, so they can reproduce your results.
A similar error is also thrown when using the select() function from the dplyr package and having loaded the MASS package too.
Minimal sample to reproduce:
library("dplyr")
library("MASS")
iris %>% select(Species)
will throw:
Error in select(., Species) : unused argument (Species)
To circumvent use:
library("dplyr")
library("MASS")
iris %>% dplyr::select(Species)
EXPLANATION:
When loading dplyr, a select function is defined and when loading MASS afterwards, the select function is overwritten. When the select function is called, MASS::select() is executed which needs a different number of arguments.
R has a function prod() which does multiplication really well. The example the asker gave works fine with the prod() function without returning an error.`
prod(a=20,b=30,c=10)
# 6000
In any case, an error highlighted is an opportunity to rectify it, so not a bad behaviour.
I'm trying to make a recursive function with Ocaml, but I keep getting the same error code.
let rec get x =
if x > 7 then
get x-7;;
And I get the very useful error message of:
Error: This expression has type int but an expression was expected of
type unit
I'm a complete beginner at OCaml, and studying it for a module at university.
And this is one of my assignments, and I'm a bit stuck!
I originally wanted to do it by a while loop, (as I'm a predominantly imperative programmer), but I couldn't get that to work, so I thought I'd try recursive!
Thanks
There's two problems with this code. First, the spacing of x-7 indicates that you would like to pass x - 7 to get, but it will actually be parsed as (get x) - 7. That's easily fixed with parentheses:
let rec get x =
if x > 7 then get (x - 7)
The second problem is that you don't have a second arm for the if, so the function doesn't have much of a chance of returning anything. (One arm if is taken to be of type unit, only useful for effects.)
You probably want to return something if x is less than 7, maybe:
let rec get x =
if x > 7 then get (x - 7) else x
Writing this with a while loop is possible, but you should understand that variables in OCaml are not mutable locations, only names. You'll have to introduce and manipulate mutable places explicitly:
let get x =
let y = ref x in
while !y > 7 do
y := !y - 7;
done;
!y
Hope that helps.
Is it possible to have a the software ignore the fact that there are unused arguments defined when a module is run?
For example, I have a module multiply(a,b), which returns the product of a and b. I will receive an error if I call the module like so:
multiply(a=20,b=30,c=10)
Returning an error on this just seems a bit unnecessary, since the required inputs a and b have been specified. Is it possible to avoid this bad behaviour?
An easy solution would be just to stop specifying c, but that doesn't answer why R behaves like this. Is there another way to solve this?
Change the definition of multiply to take additional unknown arguments:
multiply <- function(a, b, ...) {
# Original code
}
The R.utils package has a function called doCall which is like do.call, but it does not return an error if unused arguments are passed.
multiply <- function(a, b) a * b
# these will fail
multiply(a = 20, b = 30, c = 10)
# Error in multiply(a = 20, b = 30, c = 10) : unused argument (c = 10)
do.call(multiply, list(a = 20, b = 30, c = 10))
# Error in (function (a, b) : unused argument (c = 10)
# R.utils::doCall will work
R.utils::doCall(multiply, args = list(a = 20, b = 30, c = 10))
# [1] 600
# it also does not require the arguments to be passed as a list
R.utils::doCall(multiply, a = 20, b = 30, c = 10)
# [1] 600
One approach (which I can't imagine is good programming practice) is to add the ... which is traditionally used to pass arguments specified in one function to another.
> multiply <- function(a,b) a*b
> multiply(a = 2,b = 4,c = 8)
Error in multiply(a = 2, b = 4, c = 8) : unused argument(s) (c = 8)
> multiply2 <- function(a,b,...) a*b
> multiply2(a = 2,b = 4,c = 8)
[1] 8
You can read more about ... is intended to be used here
You could use dots: ... in your function definition.
myfun <- function(a, b, ...){
cat(a,b)
}
myfun(a=4,b=7,hello=3)
# 4 7
I had the same problem as you. I had a long list of arguments, most of which were irrelevant. I didn't want to hard code them in. This is what I came up with
library(magrittr)
do_func_ignore_things <- function(data, what){
acceptable_args <- data[names(data) %in% (formals(what) %>% names)]
do.call(what, acceptable_args %>% as.list)
}
do_func_ignore_things(c(n = 3, hello = 12, mean = -10), "rnorm")
# -9.230675 -10.503509 -10.927077
Since there are already a number of answers directly addressing the question, and R is often used by technically skilled non-programmers, let me quickly outline why the error exists, and advise against suppression workarounds.
The number of parameters is an important aspect defining a function. If the number of parameters mismatches, that's a good indication that there is a mismatch between the callers intent and what the function is about to do. For this reason, this would be a compilation error in many programming languages, including Java, Python, Haskell, and many others. Indeed, stricter type checking in many of these languages will also cause errors if types mismatch.
As a program grows in size, and code ages, it becomes harder to spot whether mismatches of this kind are intended or are genuine bugs. This is why an idea of "clean code" - simple to read code with no errors or warnings - is often a standard professional programmers work towards.
Accordingly, I recommend reworking the code to remove the unnecessary parameter. It will be simpler to understand and debug for yourself and others in the future.
Of course I understand that R users are often working on small scripts with limited lifespans, and the usual tradeoffs of large software engineering projects don't always apply. Maybe for your quick script, that will only be used for a week, it made sense to just suppress the error. However, it is widely observed (and I have seen in my own experience) that what code endures is rarely obvious at the time of writing. If you are pursuing open science, and publishing your code and data, it is especially helpful for that code to be useful in the future, to others, so they can reproduce your results.
A similar error is also thrown when using the select() function from the dplyr package and having loaded the MASS package too.
Minimal sample to reproduce:
library("dplyr")
library("MASS")
iris %>% select(Species)
will throw:
Error in select(., Species) : unused argument (Species)
To circumvent use:
library("dplyr")
library("MASS")
iris %>% dplyr::select(Species)
EXPLANATION:
When loading dplyr, a select function is defined and when loading MASS afterwards, the select function is overwritten. When the select function is called, MASS::select() is executed which needs a different number of arguments.
R has a function prod() which does multiplication really well. The example the asker gave works fine with the prod() function without returning an error.`
prod(a=20,b=30,c=10)
# 6000
In any case, an error highlighted is an opportunity to rectify it, so not a bad behaviour.