Modelica assert(condition, message, level=AssertionLevel.warning); - assert

Part 8.3.7 of the Modelica Spec describes the function assert and gives two examples, but whenever I try to use one of the following commands, it does not work as expected:
assert(T > 250 and T < 400,
"Medium model outside full accuracy range",
AssertionLevel.warning);
or
assert(T > 250 and T < 400,
"Medium model outside full accuracy range",
level=AssertionLevel.warning);
What is wrong here? Did I miss something obvious?

So I checked with Dymola (2012FD01) and it looks like Dymola has not implemented the level argument:
> document("assert")
function assert "assert that a condition is true"
input Boolean _condition;
input String _error;
The given condition should be true.
If it is false an error message will be given
end assert;
Or maybe it's simply not documented. You probably should ask the DS support on that. In OpenModelica it seems they have implemented as described in the specs (see also http://build.openmodelica.org/Documentation/assert.html).

You do not state what tool you are using, but I would point out that this is a relatively new syntax for assert. You might try without the "level" indicator (i.e. just two arguments: a Boolean and a String).

Related

Predict only one class (person) in YOLACT/YOLACT++

I want to predict only one class i.e. person from all the 84 classes that are being checked for and predicted.
For YOLACT reference https://github.com/dbolya/yolact
The results are pretty fine but I guess I just need to modify one of the codes and in a very short way but I cant manage to find out
There is one issue related to this in which I did what he mentioned like adding the 4 lines in Yolact/layers/output_utils.py and changing nothing else. Those lines are as following:
boxes = torch.cat((boxes[classes==0], boxes[classes==2]),dim=0)
scores = torch.cat((scores[classes==0], scores[classes==2]),dim=0)
masks = torch.cat((masks[classes==0], masks[classes==2]),dim=0)
classes = torch.cat((classes[classes==0], classes[classes==2]),dim=0)
But it gives the following error:
RuntimeError: strides[cur - 1] == sizes[cur] * strides[cur] INTERNAL ASSERT FAILED at
/opt/conda/conda-bld/pytorch_1573049310284/work/torch/csrc/jit/fuser/executor.cpp:175,
please report a bug to PyTorch.
The above operation failed in interpreter, with the following stack trace:
terminate called without an active exception
Aborted (core dumped)
I tried adding the if condition as mentioned but still it gives error. I am using pytorch 1.3
In order to show a single class (person, id:0) output at the time of inference, you simply need to add
cur_scores[1:] *= 0
after cur_scores = conf_preds[batch_idx, 1:, :] in line 83 of yolact/layers/functions/detection.py.
Then running
!python eval.py --trained_model=weights/yolact_resnet50_54_800000.pth --score_threshold=0.15 --top_k=15 --image=input_image.png:output_image.png
will give you single class inference.
As mentioned by the author in issue#218:
you can make the change to save on NMS computation,
simply add cur_scores[<everything but your desired class>] *= 0
For the index, if you wanted only person (class 0), you can put 1:, but if you wanted another class than that you'd need to do 2 statements: one with :<class_idx> and the other with <class_idx>+1:. Then when you run eval, run it with --cross_class_nms=True and that'll remove all the other classes from NMS.
Other method is to modify the output in output_utils.py.

What are the differences between to.equal(true) and to.be.true?

I'm learning Mocha and Chai.
I try understand when I have to use to.equal(true) or to.be.true to know which is better in different kind of situations.
Thanks!
My understanding from the docs is that .to and .be and various other pieces of the Expect/Should syntax are just syntactical sugar, with no real functionality.
So .to.be.true === .true and .to.equal(true) === .equal(true). So the difference, if any, is between .true and .equal(true) -- and there isn't any difference; .true is just a syntactical shorthand for .equal(true).
They test the same thing. In other words, wherever .to.equal(true) fails, .to.be.true will also fail, and where .to.equal(true) succeeds, so does .to.be.true.
However, they do differ in that .to.equal takes an optional custom error message whereas .to.be.true does not take a custom error message.
var settings = {
verbose: "foo"
};
settings.verbose.should.equal(true, "verbose setting");
will show an error message like:
AssertionError: verbose setting: expected 'foo' to equal true
Same thing with expect(settings.verbose).to.equal(true, "verbose setting"). Without the custom error message, the error will be:
AssertionError: expected 'foo' to equal true
If you use expect(settings.verbose).to.be.true("verbose setting") the test will fail but the custom error message will be ignored.
it doens't look there are any differences
https://github.com/chaijs/chai/blob/master/lib/chai/core/assertions.js#L298
https://github.com/chaijs/chai/blob/master/lib/chai/core/assertions.js#L502

WTL CListViewCtrl getSelectedItem is causing an Assertion fail for me

This is my code in order to get the name of the item which has been selected in my CListViewCtrl:
LVITEM item = { LVIF_PARAM };
CString itemText;
clistViewCtrl.GetSelectedItem(&item);
clistViewCtrl.GetItemText(item.iItem, item.iSubItem, itemText);
Note that this code is working. I recently did another project, where I grabbed the name in exactly this way, however, I had no problems there with any assertion fails.
When I execute this with my current project, I always get a debug assertion:
"File: ... atlctrls.h"
Line: 3242
Expression: (GetStyle() & 0x0004) != 0
Even though the expression already states it pretty much, here is the line causing the failure:
ATLASSERT((GetStyle() & LVS_SINGLESEL) != 0);
I have barely any idea what the problem is. As I said, the exact same code worked on my other project, and I just went through both, trying to find any differences which could cause this behaviour, but nothing caught my eye.
Honestly, I don't even know if this is related to my code at all, considering the two compared elements seem to be predefined.
My first guess would have been that this part is being called before the items are created, but all items in the listview are created at the point I try to call this code passage.
Can anyone point me to a solution?
Your control is not created with style flag LVS_SINGLESEL. So calling GetSelectedItem is causing an assert. In case of multi selection use GetFirstSelectedItem and GetNextSelectedItem instead of GetSelectedItem. For single selection you can continue useing GetSelectedItem, but you have to add LVS_SINGLESEL style flag to your control.

Assert statement in Verilog

I'm completely new to Verilog, so bear with me.
I'm wondering if there is an assert statement in Verilog. In my testbench, I want to be able to assert that the outputs of modules are equal to certain values.
For example,
mymodule m(in, out);
assert(out == 1'b1);
Googling gave me a few links, but they were either too complex or didn't seem to be what I wanted.
There is an open source library for assertions called OVL. However, it's pretty heavy. One trick I nicked from there is creating a module to do assertions.
module assert(input clk, input test);
always #(posedge clk)
begin
if (test !== 1)
begin
$display("ASSERTION FAILED in %m");
$finish;
end
end
endmodule
Now, any time you want to check a signal, all you have to do is instantiate an assertion in your module, like this:
module my_cool_module(input clk, ...);
...
assert a0(.clk(clk), .test(some_signal && some_other_signal));
...
endmodule
When the assertion fails, you'll get a message like this:
ASSERTION FAILED in my_cool_module.a0
The %m in the display statement will show the entire hierarchy to the offending assertion, which is handy when you have a lot of these in a larger project.
You may wonder why I check on the edge of the clock. This is subtle, but important. If some_signal and some_other_signal in the expression above were assigned in different always blocks, it's possible the expression could be false for a brief period of time depending on the order that your Verilog simulator schedules the blocks (even though the logic was entirely valid). This would give you a false negative.
The other thing to note above is that I use !==, which will cause the assertion to fail if the test value is X or Z. If it used the normal !=, it could silently give a false positive in some cases.
Putting the above together with a macro works for me:
`define assert(signal, value) \
if (signal !== value) begin \
$display("ASSERTION FAILED in %m: signal != value"); \
$finish; \
end
Then later in my test module:
initial begin // assertions
#32 `assert(q, 16'hF0CB)
end
As an example test fail case:
ASSERTION FAILED in test_shift_register: q != 16'hF0CB
you can write like this
if(!(out==1'b1)) $finish;
If your simulator supports SystemVerilog syntax, there is an assert keyword which does what you want.
Verilog doesn't support assertions. Some tools support PSL, which places the assertions in comments but this is non-standard. You should consider using hierarchical references from a testbench instead otherwise you have to place each assertion in a process which will get messy.
The easiest way to mimic C-like assertions is probably a `define since this will make them global.
`define assert(condition) if(condition) begin $finish(1); end
In order to check signals in a non-procedural context, such as your example, you will need a different macro that builds a condition signal and then triggers a test event for that signal.
`define assert_always(condition) generate if(1) begin wire test = condition; always #(test) `assert(condition) end endgenerate
The generate above will create a new scope for the variable test so multiple instances should work.
A better way in a procedural might be to create a task in a separate file and then include that in any module declaration.
task assert(input condition);
if(!condition)
$finish(2);
endtask
For non-procedural contexts you'll need to create a module containing a process and instance that module. This will require a unique name for each instance unless you put it in a generate block.

Error while calling member function

Hi I have just started using C++ today, and I am working on checkboxes. I have tried using CheckBox1->Checked in an if statement or whatever, but it isn't working.
The error is:
Error 2 error C2227: left of '->Checked' must point to class/struct/union/generic type
EDIT: The Code is:
void function ()
{
if (1001->Checked)
{
Sleep(2000);
}
}
Without seeing some of your code, it's very difficult to offer targeted assistance.
However, that error message usually comes about because the item you're de-referencing is not a pointer.
Check to ensure it's of the correct type. It should be something along the lines of:
tCheckBox *CheckBox1;
One possibility is that you've declared it not as a pointer to the checkbox but as a checkbox itself:
tCheckBox CheckBox1;
Note the lack of the asterisk there that would otherwise mark it as a pointer. In that case, you would use CheckBox1.Checked rather than CheckBox1->Checked, if it's allowed by the framework (this isn't standard C++ since that beast has no concept of GUI libraries).
If that doesn't help, please post the code so we can offer better suggestions.
Update:
if (1001->Checked) ?????
1001 is not a pointer - it's not a variable of any description, it's an integer constant.
You need to declare and use a variable of some description. First step is, I think, to read up on the documentation for your framework and/or get some sample code that does compile and work, basing your initial work of that.
Use CButton::GetCheck() to determine the state of the checkbox - like so...
CButton* pButton = (CButton*) GetDlgItem(IDC_CHECKBOX_RESOURCE_ID);
if ( BST_CHECKED == pButton->GetCheck() )
{
// button is checked
}