I am an avid csh/tcsh user.
But the current environment I have to work on has all ksh scripts. The team works on k-shell.
So, if I select a seed and run a test in k-shell and c-shell, would the outcome be the same?
Seed is just one example, I want to know whether using alternate shell would create any divergence of end result?
The whole point of a seeding mechanism for random number generators is to be able to reproduce results regardless of other factors. This means that as long as you're running the same compiled code for the simulator (same version, basically) you're going to get the same results when passing in a seed, regardless of what machine you're running on, what shell you use, etc.
Also, the shell you use has no end effect on the executable being started, other than setting environment variables that the program might use. You're going to have to make sure that you don't diverge in this point.
Related
I'd like some advice on what vocabulary to use to describe the following. Having the right vocabulary will allow me to search for tools and ideas related to the concept
I'd like to say a script is SomeWord if it is expected to produce the same output no matter where it is run.
For example, the following script is not SomeWord:
#!/bin/bash
ls ~
because of course it depends on where it is executed.
Whereas the following (if it runs without error) is expected to always produce the same output:
#!/bin/bash
echo "hello, world"
A more useful example would be something that loads and runs a docker or singularity container in a way that guarantees that a very particular container image is being used. For example by retrieving the singularity image by its content-hash.
The advantages of SomeWord scripts are: (a) they may be safely run on a remote system without worrying about the environment and (b) their outputs may be cached.
The best I can think of would be "deterministic" or some variation on "environment independent" or "reproducible".
Any container should be able to do this, as that is a big part of why the tech developed in the first place. Environment managers like conda can also do this to a certain extent, but because it's just modifying the host environment it's possible to be using non-conda binaries without realizing it.
I am trying to allow others to use my programs, but I don't want those users to be sharing the programs without my permission, so my goal is to prevent the users from doing this on the TI-84 calculator, but I have had no apparent luck.
For the TI-84 calculator, I have tried the getkey command and the stop. I have tried conditional statements with for and while loops, but I can't seem to prevent the user from sharing the code.
Prompt V
V+2 -> C
Disp C
The code works like it is intended but I can't prevent people from transferring this code to other calculators.
There is no way to prevent people from transferring programs over the calculator. What you could try to do is make it so that after you transfer the program yourself you store a password into a variable that they are unlikely to use (done manually, make sure to clear afterwards). When the program runs it checks if the variable stores the correct value. If someone else transfers the program and doesn't load the password into the correct variable, then the program won't work. However, they can figure this out by simply reading the code. If you want to be extra tricky, you can create a simple hashing algorithm and read from multiple variables. For instance, storing 123 in Z could be hashed by *28 + 54 mod 71 to get to 19. Apply those math functions to the chosen variables and then compare to their hashed value. This protects people from figuring out the password by checking the program (since 19 cannot be reversed to 123). Of course, they can just delete the check, so try to hide it somewhere among junk code. Now, they might overwrite those variables where your password is stored (often by running other programs that use those variables). Simply tell them that they have to come back to you so you can "fix" their program. Hope this helps.
I am running a local blastx server. One of the command line options is -num_threads. Looking at the executable, blastx, thinking it may be a shell script that sets OMP_NUM_THREADS, it turns out that it is in machine code. I am assuming (possibly incorrectly) that it is an OpenMP application and this got me thinking.
Question : is it possible to change the number of OpenMP threads as a command line option, as opposed to using the environmental variable OMP_NUM_THREADS?
Using OpenMP, you have basically 3 different ways of specifying the number of threads to use in a parallel region:
The most commonly used one is the environment variable OMP_NUM_THREADS which needs to be set in the code's environment prior to running it for being effective;
The function omp_set_num_threads(), to be called before reaching a parallel region; and
The optional num_threads() clause of the parallel directive.
The relative priorities of these are defined in great details by the standard but pretty much boil down to num_threads() taking precedence over omp_set_num_threads(), which itself takes precedence over OMP_NUM_THREADS.
So now, if you want to have your code defining the number of OpenMP threads to use as a command line option, what you need is:
To parse you command line, either by hand, or using a function like getopt, and to store the value you read in a variable; and
To use this value in either a call to omp_set_num_threads() or as a parameter to the num_threads() clause. Either of the two will take precedence to the possible value set for OMP_NUM_THREADS.
OMP_NUM_THREADS is parsed by the program at runtime, so it already does what you want.
Setting it at compile time has no effect (unless you specifically design your build system to use it).
Because you export this environment variable, it's there at runtime as well. That's why you think it is doing something when you compile.
I like the Lua-scripting for redis but i have a big problem with TIME.
I store events in a SortedSet.
The score is the time, so that in my application i can view all events in given time-window.
redis.call('zadd', myEventsSet, TIME, EventID);
Ok, but this is not working - i can not access the TIME (Servertime).
Is there any way to get a time from the Server without passing it as an argument to my lua-script? Or is passing the time as argument the best way to do it?
This is explicitly forbidden (as far as I remember). The reasoning behind this is that your lua functions must be deterministic and depend only on their arguments. What if this Lua call gets replicated to a slave with different system time?
Edit (by Linus G Thiel): This is correct. From the redis EVAL docs:
Scripts as pure functions
A very important part of scripting is writing scripts that are pure functions. Scripts executed in a Redis instance are replicated on slaves by sending the script -- not the resulting commands.
[...]
In order to enforce this behavior in scripts Redis does the following:
Lua does not export commands to access the system time or other external state.
Redis will block the script with an error if a script calls a Redis command able to alter the data set after a Redis random command like RANDOMKEY, SRANDMEMBER, TIME. This means that if a script is read-only and does not modify the data set it is free to call those commands. Note that a random command does not necessarily mean a command that uses random numbers: any non-deterministic command is considered a random command (the best example in this regard is the TIME command).
There is a wealth of information on why this is, how to deal with this in different scenarios, and what Lua libraries are available to scripts. I recommend you read the whole documentation!
I need to run a ruby script for one week and check whether it is running for every hour.
Could you please suggest me some way? I need to check this in windows machine.
For ex:- I have script called one_week_script.rb which will run for one week, in between i want to check whether the script is running or not? if it is not running, then running that script from another script
A typical solution is to use a "heartbeat" strategy. The "to be monitored" notifies a "watchdog" process on a regular interval. A simple way of doing this might be to update the contents of some file every so often, and the watchdog simply checks that same file to see if it's got recent data.
The alternative, simply checking if the process is still 'loaded' has some weaknesses, The program could be locked up, even though it's still apparently 'running'. Using the heartbeat/watchdog style means you know that the watched process is operating normally, because you're getting feedback from it.
In a typical scenario, you might just write the current time, and some arbitrary diagnostic data, say the number of bytes processed (whatever that might mean for you).