Hi "Llelan D.",
In your text below, see the line marked in red. Would 'listfunctions()'
before and after the 'exec' do what you need? (Apologies if that is too
naive).
Adrian.
Adrian Weeks
Development Engineer
HID Global,
3 Cae Gwyrdd,
Green Meadow Springs
Business Park,
Cardiff CF15 7AB,
United Kingdom.
+44 (0)29 20528523
(Office)
awe...@hidglobal.com
www.hidglobal.com
From: "Llelan D." <llel...@thesnakepitdev.com>
To: users@lists.scilab.org
Date: 09/07/2014 19:17
Subject: Re: [Scilab-users] Multiple files of functions with the same name
Sent by: "users" <users-boun...@lists.scilab.org>
Thank you all for your kind replies. Samuel has come up with what seems
to be the only workable solution using the namespaces provided by
library variables (I'll explain after a couple of points and an example).
----------
The rest of the replies have to do with either loading and running each
implementation sequentially, or manually renaming the loaded function
variables.
As I explained in the OP:
* Both functions MUST be resident without clashing so they both can be
run. Constantly reloading, re-interpreting, and recompiling each
function for what may be millions of times per match is pathetically
inefficient.
* The .sci files might not only implement the specified function
prototype, they might also implement many support functions. Since the
implementation files might be written by 3rd parties (such as in a
tournament), the support function names can not be known beforehand. So,
it is impossible to know what to rename after an exec() is done, and
I've never found a way to list what functions are loaded by an exec().
As to the confusion of what is being done: This is a description of a
generic process that can be applied to a great variety of algorithm
profiling and tournament situations. The overall products that might use
this are not important. The ability to have functions with the same name
and prototype implemented in different .sci files resident in the same
session is.
However, I'll give you a concrete example:
Some years ago, a tournament was held for response algorithms to the
Iterated Prisoner's Dilemma (see http://www.prisoners-dilemma.com for
details). Competitors would each implement a set of "personalities" each
of which implements a "responseString = response(iGame, lastScore)"
prototype. The tournament software expects to see in the tournament
directory a set of directories each named for a competitor. In each
competitor directory is a set of personality directories each of which
holds the implementation of the response prototype function and possibly
many other support functions. While the competitor names are registered
unique, the personality and support function names might not be. Each
competitor is paired against each other competitor where each
personality of one competitor is played against each personality of the
other 20 times. The average score for each personality and competitor is
accumulated and the competitor(s) with the highest average score wins.
With hundreds of competitors, some using dozens of personalities and
many with the same names but different implementations, the number of
games can easily run into the hundreds of thousands.
In this scenario, the personalities should not be constantly reloaded,
re-interpreted, and re-compiled for each and every call. The whole
tournament would be uselessly bogged down.
----------
The library solution proposed by Samuel can deal with this since the
loaded library functions can be qualified with the library variable
name. For example: Two libraries are created in directories testLib1 and
testLib2, each of which implements the "y = test(x)" prototype. After
using the lib() function to load both to two variables called testLib1
and testLib2, you can call either testLib1.test(2) or testLib2.test(2)
without having to reload anything. There is a little annoying magic
where the variable "test" will be assigned to whatever library was last
loaded but, if you do not use that variable, there is no problem, unless
you run into variable space overruns (I do wish there was a way to not
do that).
For tournament software, it is important to be able to require
competitors to submit implementation sources so that you can verify
nothing goes on that breaks the rules. Scilab allows you to create the
libraries without external utilities all in the same language. Setting
funcprot(2) makes sure that competitor implementations do not try to
futz with the environment used by the other competitor but still allows
the qualified libraries with functions of the same name to be loaded.
I've tested this and it works.
Thank you Samuel for your solution to this. I am greatly appreciative.
However – namespaces or qualified names are definitely needed in Scilab.
_______________________________________________
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users
_______________________________________________
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users
