Difference between revisions of "Statistical Algorithms Importer: FAQ"

From Gcube Wiki
Jump to: navigation, search
Line 36: Line 36:
 
zip_namefile <- zip_namefile_random
 
zip_namefile <- zip_namefile_random
 
</pre>
 
</pre>
 +
 +
== An algorithm does not receive input from the interface ==
 +
StatMan searches in the code for the declared default value and then it substitutes this with the user provides through the interface.
 +
 +
This means that the default value in the code should correspond to the one declared in the annotations (and thus displayed in the Input/Output window) and vice versa. For example, if starting_point_latitude has -7.931 as declared default value, then StatMan searches in the code for one of the following lines:
 +
 +
starting_point_latitude <- "-7.931"
 +
starting_point_latitude = "-7.931"
 +
 +
whereas, in the case of numeric variables, it searches for
 +
 +
starting_point_latitude <- -7.931
 +
starting_point_latitude = -7.931
 +
 +
Thus, if the initialization in the code is
 +
starting_point_latitude <- "-13.548"
 +
 +
then StatMan cannot find the default value to change. In other words, the default values in the code should correspond to the ones declared.
 +
 +
We use this approach since SAI could be theoretically applied also to other programming languages than R, thus we do not rely on the R interpreter behind the scenes but on strings substitution using regular expressions.
  
 
[[Category:Statistical Algorithms Importer]]
 
[[Category:Statistical Algorithms Importer]]

Revision as of 10:26, 12 July 2016

F.A.Q. of Statistical Algorithms Importer (SAI), here are common mistakes we have found.

In some cases, an algorithm worked in R Studio but did not work via SAI.

This kind of issue is usually related to the production of the output files:

  • The file was produced in a subfolder, but is was declared to be in the root folder. E.g. the file output.zip was produced in the ./data folder by the process, but in SAI the variable referring to the output was declared as
output<-"output.zip"
Thus with no ./data indicated in the file name
  • A forced switch of the working folder was done inside the code, which mislead the service about the produced file. E.g.:
output<-"output.zip"
setwd("./data")
save(output)
switch of the working folder inside the script should be generally avoided.
  • A process tried to overwrite another file that had already been produced on the processing machine, but which was corrupted due to an update of the machine. This conflicted with the newly generated files.
Generally, files with new names should be generated by a script that is being transformed into a web service. Generating output files with new names prevents errors due to several concurrent requests creating the same files, when the requests are managed by the same machine.
For example, instead of declaring
zip_namefile <- "data_frame_result_query.zip"
The timestamp should be added to the generated file:
zip_namefile_random <- paste("data_frame_result_query_",Sys.time(),".zip",sep="")
zip_namefile <- zip_namefile_random

An algorithm does not receive input from the interface

StatMan searches in the code for the declared default value and then it substitutes this with the user provides through the interface.

This means that the default value in the code should correspond to the one declared in the annotations (and thus displayed in the Input/Output window) and vice versa. For example, if starting_point_latitude has -7.931 as declared default value, then StatMan searches in the code for one of the following lines:

starting_point_latitude <- "-7.931" starting_point_latitude = "-7.931"

whereas, in the case of numeric variables, it searches for

starting_point_latitude <- -7.931 starting_point_latitude = -7.931

Thus, if the initialization in the code is starting_point_latitude <- "-13.548"

then StatMan cannot find the default value to change. In other words, the default values in the code should correspond to the ones declared.

We use this approach since SAI could be theoretically applied also to other programming languages than R, thus we do not rely on the R interpreter behind the scenes but on strings substitution using regular expressions.