first time poster.
I am a student working in netlogo.
I am running the Game if Thrones model and have an error.
The code works, but is appears when the humans defeat the nightlong, before the text comes up, I get an error message.
Code is:
If season = “winter” and count whitewalkers = 0 [
set season “spring”
ask patches with [ snow? ][
set snow? false
if else resources = 0 [
set pcolor brown
][
set pcolor green
]
]
user-message “The Night King has been defeated! Summer is back.”
stop
]
The error message is:
WITH expected a true/false value from (patch 70 253), but got 0 instead. Error while observer running WITH Called bu procedure GO Called by button “go”
Many thanks
I have tried removing the brackets, but I believe they are needed.
I have put more space in between the brackets, but that makes no difference.
NetLogo does not perform type inference and the ? at the end of such primitives is a convention to indicate to the reader of the code that it is a boolean type, but not a language feature. NetLogo’s compiler does not immediately assign a boolean value to a variable that has a ? in its name, but simply assumes that it is an integer and assigns 0.
You probably need to set the snow? variable to a default value before using it elsewhere in your code, probably on top of your model’s setup procedure.
Here is a simple piece of code to illustrate how to initialize boolean variables in NetLogo:
patches-own [snow?]
to show-snow
show "before assigning bool value"
show [snow?] of patches
ask patches [ set snow? false ]
show "after assigning bool value"
show [snow?] of patches
end
enter image description here
Related
When I run a Xcos model containing a scifunc_block_m block like shown below
I get an error message relating to data dimensions inconsistency:
"Data dimensions are inconsistent:"
" Variable size=[1,1]"
"Block output size=[100,1]."
But when I double click in the block in order to see what can I change to make the dimensions correct I get a message in the console saying
Undefined variable: scifunc_block_m
What bugs me is that scifunc_block_m is not the name of any variable, but rather the name of the block itself like can be seen in the official docs.
Of course I double checked that nowhere in my function phase_shifter neither anywhere else I have any variable named like that.
I tried with Scilab 6.1.1 and 6.1.0 believing that it might be a bug from apparently not.
In your phase_shifter.sce file generating the input variable,
the signalIn variable does not comply with the From Workspace block requirements, whose documentation says that the input variable
must be a structure with time and values fields
.time must be a column vector, and in your case
.values must also be a column
So,
t = (0:1/fs:Npp/fs - 1/fs); // time vector
signalIn = A*%e^(%i*w*t);
should be replaced with
t = (0:1/fs:Npp/fs - 1/fs)'; // time column vector
signalIn = struct("time",t, "values",A*%e^(%i*w*t));
This fixes the inconsistent dimensions message.
In addition, i am not able to reproduce your issue about Undefined variable: scifunc_block_m. The parameters interface opens as expected.
You may get this kind of messages if you try to run some xcos parts out of xcos, without beforehand loading xcos-related libraries.
Then, we get an unclear "Output should be of complex type." message on the From workspace block.
By the way, you try to plot some complex values. Please have a look to the MATMAGPHI block before entering MUX: https://help.scilab.org/docs/6.1.1/en_US/MATMAGPHI.html
My model has links with defined duration, and I am trying to register the new links and the old ones in two different vectors.
The Problem: When I run the simulation the new links are stored correctly, but the old ones appear duplicated in the csv file. I am making a mistake at some point and I really need some help. If there is a more elegant way of doing it, I appreciate the tips! Thanks all for the collaboration!
ifelse not link-neighbor? myself
[
create-new-links-with partner in-radius 0.1
ask new-links
[
set registernew []
set link-duration max (list duration maxduration)
set link-creation time:copy dt
set link-end time:plus link-creation link-duration "year"
set link-installment invtransf
set meets 1
set registernew ([(list link-creation link-duration link-end link-installment meets end1 end2) ] of new-links)
add-records
set breed old-links
]
]
[
ask old-links
[
set registerold [ ]
set meets time:copy dt
set registerold ([(list link-creation link-duration link-end link-installment meets end1 end2) ] of old-links)
]
I haven't checked this, but I suspect that the problem is that you have bidirectional links WITH, not unidirectional links TO or FROM, so the old-links get reported by each end separately which duplicates their presence in the list.
Again I haven't tried this but you might set a flag-variable in each link at the start of each large pass, like, reported? to false, and then deep in the loop when you are about to report it see if it's already been reported and if not, go ahead ( report and set the flag ) and if it has, don't report it again but interrupt the run with a user-message and examine what just happened.
Wade
I have a fill-in with the following code, made using the AppBuilder
DEFINE VARIABLE fichNoBuktiTransfer AS CHARACTER FORMAT "N(18)":U
LABEL "No.Bukti Transfer"
VIEW-AS FILL-IN NATIVE
SIZE 37.2 BY 1 NO-UNDO.
Since the format is N, it blocks the user from entering non-alphanumeric entries. However, it does not prevent the user from copypasting such entries into the fill-in. I have an error checking like thusly to prevent such entries using the on leave trigger:
IF LENGTH(SELF:Screen-value) > 18 THEN DO:
SELF:SCREEN-VALUE = ''.
RETURN NO-APPLY.
END.
vch-list = "!,*, ,#,#,$,%,^,&,*,(,),-,+,_,=".
REPEAT vinl-entry = 1 TO NUM-ENTRIES(vch-list):
IF INDEX(SELF:SCREEN-VALUE,ENTRY(vinl-entry,vch-list) ) > 0 THEN DO:
SELF:SCREEN-VALUE = ''.
RETURN NO-APPLY.
END.
END.
However, after the error handling kicked in, when the user inputs any string and triggers on leave, error 632 occurs:
error 632 occurs
Is there any way to disable the error message? Or should I approach the error handling in a different way?
EDIT: Forgot to mention, I am running on Openedge version 10.2B
You didn't mention the version, but I'll assume you have a version in which the CLIPBOARD system handle already exists.
I've simulated your program and I believe it shouldn't behave that way. It seems to me the error flag is raised anyway. My guess is even though those symbols can't be displayed, they are assigned to the screen value somehow.
Conjectures put aside, I've managed to suppress it by adding the following code:
ON CTRL-V OF FILL-IN-1 IN FRAME DEFAULT-FRAME
DO:
if index(clipboard:value, vch-list) > 0 then
return no-apply.
END.
Of course this means vch-list can't be scoped to your trigger anymore, in case it is, because you'll need the value before the leave. So I assigned the special characters list as an INIT value to the variable.
After doing this, I didn't get the error anymore. Hope it helps.
To track changes in a fill-in I always use at first this code:
ON VALUE-CHANGED OF FILL-IN-1 IN FRAME DEFAULT-FRAME
DO:
/* proofing part */
if ( index( clipboard:value, vch-list ) > 0 ) then do:
return no-apply.
end.
END.
You could add some mouse or developer events via AppBuilder to track changes in a fill-in.
I am facing an incoherent behavior with the -rte option in Magnesium version (installed directly from ubuntu). I am wondering if someone is aware of that problem or if I am doing something wrong.
I have a program with an incorrect acces outside an array. When lauching frama-c-gui with no options and value analysis, the out-of-bounds access is detected and the corresponding annotation is displayed with an orange circle. When using the -rte option, two annotations are displayed (for the lower and upper bound of the array), and a green circle is displayed for both (which is incorrect).
/*# assert rte: index_bound: 0 ≤ cpt; */
/*# assert rte: index_bound: cpt < 5; */
The console says :
tableau_erreur.c:11:[value] Assertion 'rte,index_bound' got status valid.
I suspect there is a mismatch between the two annotations because they both have the same "name" : index_bound.
Also, the part of code after the loop containing the faulty access is colored in red, suggesting that the analysis correctly inferred that it is not reachable because of an error before.
Here is my program :
int main(){
int t[5] = {1,2,3,4,5};
int cpt =0 ;
int tmp ;
while (cpt<10){
tmp = getchar() ;
if ( t[cpt] > tmp )
{ return 1 ; }
cpt++ ;
}
return 10 ;
}
Here is a capture of my display (using frama-c-gui -rte tableau_erreur.c).
When I do not use the -rte option the result is correct (orange circle) :
I had a look at the bug tracker but did not find trace of that. I did not manage to compile a more recent version of Frama-C to test it.
Update: this behavior has been fixed in the Silicon release of Frama-C (the status associated to assertion rte: index_bound: cpt < 5 remains unknown).
I couldn't reproduce exactly what you said, but after launching the GUI as in your command, then clicking on the "Run" button in the Value analysis panel, I got the green bullets.
This is equivalent to running frama-c-gui -rte -then -val, which also displays the green (incorrect) bullets.
Indeed this seems to be an issue even in the current Frama-C version, so a bug report is in order. Note that manually inserting an equivalent annotation (//# assert cpt < 5;) does result in an yellow bullet, as expected. Also, unrolling the loop (with -slevel 5, for instance) also results in an yellow bullet. The issue seems to be related specifically to the usage of the RTE plug-in, but in any case it will be investigated.
On a side note, the index_bound label next to the property is not an identifier, just a label, hence not unique, and unrelated to the issue here.
Technical details: Frama-C has notions of properties and statuses, which are summarized by the bullets next to the source code, but described in more detail either through the Properties panel (you may need to modify some filters and click on the Refresh button to see them) or the Report plug-in (e.g. frama-c -val -then -report). In your example, the first iteration of the loop has a value of cpt that is 0, therefore the property acquires a valid status (green bullet), and in the last iteration (when cpt is 5) it gets a unknown status (yellow bullet). For some reason it was (incorrectly) consolidated as valid, hence the green bullet. The Value log does however display file.c:8:[value] warning: assertion 'rte,index_bound' got status unknown, which shows up in the Messages panel in the GUI. This does not explain the error, but the combination of both Messages and Properties panels is a powerful tool to diagnose issues with properties.
I have a table such as the following:
mafiadb:{"Etzli":{"alive":50,"mafia":60,"vigilante":3,"doctor":4,"citizen":78,"police":40},"Charneus":{"alive":29,"mafia":42,"vigilante":6,"doctor":14,"citizen":53,"police":33}}
There are more nested tables, but I'm just trying to keep it simple for now.
I run the following code to extract certain values (I'm making an ordered list based on those values):
sortmaf={}
for k,v in pairs(mafiadb) do
sortmaf[k]=v["mafia"]
end
That's one of the codes I run. The problem I'm running into is that it doesn't appear you can do arithmetic in a table loop. I tried:
sortpct={}
for k,v in pairs(mafiadb) do
sortpct[k]=(v["alive"]*100)/(v["mafia"]+v["vigilante"]+v["doctor"]+v["citizen"]+v["police"])
end
It returns that I'm attempting to do arithmetic on field "alive." What am I missing here? As usual, I appreciate any consideration in answering this question!
Editing:
Instead of commenting on the comment, I'm going to add additional information here.
The mafiadb database I've posted IS the real database. It's just stripped down to two players instead of the current 150+ players I have listed in it. It's simply structured as such:
mafiadb = {
Playername = {
alive = 0
mafia = 0
vigilante = 0
doctor = 0
police = 0
citizen = 0
}
}
Add a few hundred more playernames, and there you have it.
As for the error message, the exact message is:
attempt to perform arithmetic on field 'alive' (nil value)
So... I'm not sure what the problem is. In my first code, the one with sortmaf, it works perfectly, but suddenly, it can't find v["alive"] as a value when I'm trying to do arithmetic? If I just put v["alive"] by itself, it's suddenly found and isn't nil any longer. I hope this clarifies a bit more.
This looks like a simple typo to me.
Some of your 150 characters is not well written - probably they don't have an "alive" property, or it's written incorrectly, or it's not a number. Try this:
for k,v in pairs(mafiadb) do
if type(v.alive) ~= 'number' then
print(k, "doesn't have a correct alive property")
end
end
This should print the names of the "bad" characters.