I am stuck on the operation on BDD of CUDD (C interface), I don't know if we can remove some variables when doing compute image (from a state to another state of BDDs) and how to travel the result BDD (final BDD) to get all the variable, could anybody please tell me if we can do that by CUDD?. Cheers
I've never used CUDD but the list of variables used in a BDD is usually called its support.
Removing variables from a BDD is usually done via existential quantification.
Grepping the source code, I've found
/**Function********************************************************************
Synopsis [Finds the variables on which a DD depends.]
Description [Finds the variables on which a DD depends.
Returns a BDD consisting of the product of the variables if
successful; NULL otherwise.]
SideEffects [None]
SeeAlso [Cudd_VectorSupport Cudd_ClassifySupport]
******************************************************************************/
DdNode *
Cudd_Support(
DdManager * dd /* manager */,
DdNode * f /* DD whose support is sought */)
and
/**Function********************************************************************
Synopsis [Existentially abstracts all the variables in cube from f.]
Description [Existentially abstracts all the variables in cube from f.
Returns the abstracted BDD if successful; NULL otherwise.]
SideEffects [None]
SeeAlso [Cudd_bddUnivAbstract Cudd_addExistAbstract]
******************************************************************************/
DdNode *
Cudd_bddExistAbstract(
DdManager * manager,
DdNode * f,
DdNode * cube)
Related
I have an existing TTree after doing a simulation. I would like to add a Branch to this TTree and I want to call it Muon.Mass to the tree. I would also want to give the Muon.Mass branch a value of 0.1.
How can I write that?
I have seen how to create TTrees from scratch and to have branches of different variables. But I am not sure exactly what to do when I already have a TTree.
You can call the TTree::Branch method on an existing TTree the same way as for a new TTree. Just for filling you need to ensure you only fill the branch. (this is a strongly cut down example from https://github.com/pseyfert/tmva-branch-adder)
void AddABranch(TTree* tree) {
Float_t my_local_variable;
TBranch* my_new_branch = tree->AddBranch( ... /* use address of my_local_variable */ );
for (Long64_t entry = 0 ; entry < tree->GetEntries() ; ++e ) {
tree->GetEntry();
/* something to compute my_local_variable */
my_new_branch->Fill();
}
}
As alternative you might want to look at the root tutorials for tree friends.
As a side note, depending what you want to do with the tree / whom you give the tree to, I advise against using . in branch names as they cause headache when running MakeClass (branch names can contain periods, but c++ variables can't, so the automatically generated class members for each branch will undergo character replacement).
I want to write a C++ libgit2 wrapper to perform some basic git operations because libgit2 is too much atomic to be used as is (in my opinion).
As libgit2 is written in C, it does not matter if I get a C or C++ oriented solution, I will adapt it by myself.
I encounter difficulties with the gitPull() function that is supposed to be the "git pull" equivalent.
I planned to implement it as follows:
git_remote_fetch()
git_annotated_commit_from_fetchhead()
git_merge() (with the previously got git_annotated_commit)
git_commit_create()
Considering that it is the proper way to do it (tell me if it is not), I struggle with two issues:
How to check if the fetched HEAD is equal or different to the local HEAD ? (in order to know if the merge + commit are needed or not, in other words, if there is something to merge or if we already are up-to-date).
How or where to get the git_oid * id required by git_annotated_commit_from_fetchhead() ? (the last parameter).
I know these questions may look quite basic but I could not find any exploitable information or example neither on the libgit2 API reference documentation nor in the libgit2 samples.
I already have checked the already existing stackoverflow threads about this topic but none of them provide any exploitable code sample.
I will be very grateful if someone could give me some helpful information about how to achieve it or explain what I have misunderstood.
How to check if the fetched HEAD is equal or different to the local HEAD ?
You can call git_merge_analysis, which will tell you if you would need to do a merge. In this case, GIT_MERGE_ANALYSIS_UP_TO_DATE indicates that there is no need to merge (git merge on the command line would respond with "Already up to date").
How or where to get the git_oid * id required by git_annotated_commit_from_fetchhead()?
You can iterate the FETCH_HEAD file with git_repository_fetchhead_foreach. It will provide you all the information necessary to generate an annotated commit from whichever remote branch you want to merge.
For example:
int fetchhead_cb(const char *ref_name, const char *remote_url, const git_oid *oid, unsigned int is_merge, void *payload)
{
if (is_merge)
{
printf("reference: '%s' is the reference we should merge\n");
git_oid_cpy((git_oid *)payload, oid);
}
}
void pull(void)
{
/* here's the id we want to merge */
git_oid id_to_merge;
/* Do the fetch */
/* Populate id with the for_merge branch from FETCH_HEAD */
git_repository_fetchhead_foreach(repo, fetchhead_cb, &id_to_merge);
}
(Note that you'd probably want to actually capture all the details of the FETCH_HEAD information - not just the id - so that you could create an annotated commit from the data, but this is an example of how the git_repository_fetchhead_foreach function works with callbacks.)
In order to avoid the Slowly Changing Dimension problem (in short: I want to keep my order data even if a user gets deleted from the system), I thought about hijacking the delete event and instead setting an invalid flag on the record.
I know of the softdeletable filter from StofDoctrineExtensionsBundle but I'm unsure if this will cascade to child objects.
Is this a common/good practice/idea and do this with the following lifecycle callback?:
/
/**
* #ORM\PreRemove
*/
public function makeInvalid() {
$this->enddate = new \DateTime(); // set the end of validity property to now
cascadeToRelatedObjects(); // i.e. make sure all 'child' objects also change validity
somehowContinueTheOperation(); // i.e. do not cause an Error of sorts
}
or should I, rather, change the functionality of the delete button on the form and assign an update function to it which does the above?
In fact, using the softdeleteable from DoctrineExtensions is the way to go. It even cascades fine if you set the cascade={"remove"} option correctly on the property of your owning object (generally speaking, the one with OneToMany).
Correct me if I'm wrong, but I don't think you need to set onDelete="CASCADE", as this is a function executed by the database, which is unaware of the requirement to soft-delete, so it won't soft-delete any children.
The easiest way for me to get this extension, was to installing StofDoctrineExtensionsBundle with the command composer require StofDoctrineExtensionsBundle and configuring it in config.yml, you can use it as described below. Soft-deleting an instance of Device will then also soft-delete its dependent Parts.
For restoring them you'd probably have to write a function or something.
use Gedmo\Mapping\Annotation as Gedmo;
/**
* ...
* #Gedmo\SoftDeleteable(fieldName="deletedAt", timeAware=false)
*/
class Device {
/**
* #ORM\Column(name="deletedAt", type="datetime", nullable=true)
*/
private $deletedAt;
/**
* #ORM\OneToMany(targetEntity="Part", mappedBy="device", cascade={"persist","remove"})
*/
private $parts;
}
In an Isabelle theory file, I can write simple one-line tactics such as the following:
apply (clarsimp simp: split_def split: prod.splits)
I find, however, when I start writing ML code to automate proofs, to produce an ML tactic object, these one-liners become rather verbose:
clarsimp_tac (Context.proof_map (
Simplifier.map_ss (fold Splitter.add_split #{thms prod.splits})
#> Simplifier.map_ss (fn ss => ss addsimps [#{thm split_def}]))
#{context}) 1
Is there an easier way to write the simple one-line tactics at the Isabelle/ML level?
For example, something like an anti-quotation: #{tactic "clarsimp simp: split_def split: prod.splits"} producing a function of type context -> tactic, would be an ideal solution.
I see a variety of possibilities, it depends a bit on the context of your the application what is best. Note that in general, individual ML code for proof automated used to be common-place in the very old times, but it is relatively rare today. For example, compare the amount of custom tactics in rather small HOL-Bali (started in 1997) with the large JinjaThreads in AFP (started in 2007 and continued until recently).
Nesting ML antiquotations like #{tactic} would in principle work, but you would quickly run into further questions, like what happens if your theorem arguments should be again Isar or ML source.
Instead of antiquoting tactic building blocks in ML, a more basic approach is to quote your proof precedure in Isar by giving it regular method syntax like this:
ML {*
(*foo_tac -- the payload of what you want to do,
note the dependency on ctxt: Proof.context*)
fun foo_tac ctxt =
let
val my_ctxt =
ctxt |> Simplifier.map_simpset
(fold Splitter.add_split #{thms prod.splits} #>
Simplifier.add_simp #{thm split_def})
in ALLGOALS (clarsimp_tac my_ctxt) end
*}
method_setup foo = {*
(*concrete syntax like "clarsimp", "auto" etc.*)
Method.sections Clasimp.clasimp_modifiers >>
(*Isar method boilerplate*)
(fn _ => fn ctxt => SIMPLE_METHOD (CHANGED (foo_tac ctxt)))
*}
Here I've first made a conventional foo_tac definition in Isabelle/ML, and then wrapped it up the usual Isar way as proof method. The latter means you have wrappers like SIMPLE_METHOD taking care of pushing "chained facts" into your goal state, and CHANGED to ensure that the Isar method makes progress (like simp or auto).
The foo_tac example assumes that your modification of the context (or its simpset) is constant, by the hard-wired split rules. If you want to have further parameters there, you can include that in the concrete method syntax. Note that Method.sections is already quite sophisticated in this respect. More basic argument parsers are given in the section "Defining proof methods" of the isar-ref manual. You should also look at existing examples by searching the sources for method_setup (in Isabelle/Isar) or Method.setup (in Isabelle/ML).
If you still want to do ML antiquotations instead of concrete method syntax, one could try a variant of #{context} that allows modifiers like this:
#{context simp add: ...}
That is a bit speculative, invented on the spot, and might turn out as bad practice. As I've said, fine-grained tactic programming in Isabelle became a bit out of use in recent years, although ML is an integral part of the Isabelle framework. If you pose a more concrete question with more of the application context, we can reconsider the antiquotation approach.
Additional to the other answers, I think it's worth mentioning that there is a new high-level tactic/proof method construction language (similar to Ltac in Coq) called Eisbach in Isabelle2015, which aims to be easier to understand and maintain.
The Method class appear to provide enough of an interface to extract out a tactic, via a cases_tactic as follows:
(*
* Generate an ML tactic object of the given Isar string.
*
* For example,
*
* mk_tac "auto simp: field_simps intro!: ext" #{context}
*
* will generate the corresponding "tactic" object.
*)
fun mk_tac str ctxt =
let
val parsed_str = Outer_Syntax.scan Position.start str
|> filter Token.is_proper
|> Args.name
val meth = Method.method (Proof_Context.theory_of ctxt)
(Args.src (parsed_str, Position.start)) ctxt
in
Method.apply (K meth) ctxt [] #> Seq.map snd
end
or alternatively as an anti-quotation:
(*
* Setup an antiquotation of the form:
*
* #{tactic "auto simp: foo intro!: bar"}
*
* which returns an object of type "context -> tactic".
*
* While this doesn't provide any benefits over a direct call to "mk_tac" just
* yet, in the future it may generate code to avoid parsing the tactic at
* run-time.
*)
val tactic_antiquotation_setup =
let
val parse_string =
((Args.context -- Scan.lift Args.name) >> snd)
#>> ML_Syntax.print_string
#>> (fn s => "mk_tac " ^ s)
#>> ML_Syntax.atomic
in
ML_Antiquote.inline #{binding "tactic"} parse_string
end
and setup in a theory file as follows:
setup {*
tactic_antiquotation_setup
*}
which can then be used as follows:
lemma "(a :: nat) * (b + 1) = (a * b) + a"
by (tactic {* #{tactic "metis Suc_eq_plus1 mult_Suc_right nat_add_commute"} #{context} *})
as desired.
Does NetBeans have C auto comment?
I installed NetBeans IDE 7.2.1 and C/C++ Plugins.
When I type in "/**" and press Enter, it automatically generate some code like bellow.
/**
* #param param1
* #param param2
* #param param3
*/
I'm just wondering if I can modify what it generate.
I want to add more info like author, date, remark.
Simply saying, I want some comment to be generated when I type in "/**" and press Enter like bellow.
(The function is already defined.)
/**
* #author
* #date
* #param param1
* #param param2
* #param param3
* #remark
*/
void do_something( struct sturct_one *param1, int param2, char *param3 )
{
...
}
Please help me.
Jan,
the NetBeans IDE documentation section on adding source code documentation does not mention the possibility to customize the Doxygen template. So a short answer to your question
I'm just wondering if I can modify what it generate
is: no, you can't.
Typically, one does not need any extras, e.g. the tags #author and #date from your example are unnecessary if you use a version control system. Did you considered using a CVS?
As an alternative solution (though not as elegant as typing '/**') you could use code templates. As described in the NetBeans documentation, you can define abbreviations for code templates. In your case you could define templates for Doxygen comments with #author, #date, #remark tags and 1, 2, 3, ... parameters, and use abbreviations 1, 2, ... to quickly insert the comments.