I have a program that can dynamically generate expressions in SMT-LIB format and I am trying to connect these expressions to CVC4 to test satisfiability and get the models. I am wondering if there is a convenient way to parse these strings through the CVC4 C++ API or if it would be best to just store the generated SMT-LIB code in a file and redirect input to the cvc4 executable.
A cursory look at their API doesn't reveal anything obvious, so I don't think they support this mode of operation. In general, loading such statements "on the fly" is tricky, since an expression by itself doesn't make much sense: You'd have to be in a context that has all the relevant sorts defined, along with all the definitions that your expressions rely on, including the selection of the proper logic. That is, for instance, why the corresponding function in z3 has extra arguments: https://z3prover.github.io/api/html/classz3_1_1context.html#af2b9bef14b4f338c7bdd79a1bb155a0f
Having said that, your best bet might be to ask directly at https://github.com/CVC4/CVC4/issues to see if they've something similar.
I am creating my own index method in PostgreSQL based on GiST as extension. I want one of my functions (check out Examples section) in my operator to behave differently based on a value defined by the user- I want to avoid the user having to drop and create operators again.
So, I was looking at introducing a GUC variable. However, I am not so sure how to implement this appropriately. Right now in my implementation, the operator is being created with the value of GUC and is not behaving differently once GUC value changes at runtime.
I am not sure if I have to somehow change the signature of the function to use GUC or if I must introduce some pointer to the GUC. I cannot find any helpful material and I do not fully understand the internals to achieve this goal.
What best practices must I use for introducing an operator which changes behaviour at runtime? Unfortunately, I cannot find much information on writing internal functions/ operators/GUC in this context and so it would be great to hear any kind of feedback at all.
A “GUC” (Grand Unified Configuration) is simply a global C variable in your program code, so changing its value will take effect as soon as your code reads the variable.
Your function will be in a shared object that is loaded into PostgreSQL, and you can use the _PG_init() function that is called at load time to register a new GUC with the DefineCustomXXXVariable() functions.
Your GUC can then be set like any other GUC.
I recommend that you look at contrib modules like auto_explain to see how they do it.
I'm trying to implement a ruleset-type table for a bunch of questions in a form. I've got down the table for that ruleset, but originally I was going to just have them all in "AND"s. But I need to include ORs as well, and that means including brackets in to the equation. I'm not too sure how to implement it. I'm trying to figure out what the table needs or if it needs another table.
So this is an example of what I'm thinking.
{FieldRule: FieldRuleId, RuleId, FieldId}
When I get the other information, it'll evaluate to to True/False. How can I do it so I can do combinations of (Rule1 ^ Rule2) V Rule3?
Thanks!
Bump!
Last bump!
I implemented a Reverse Polish Notation system whereby I added the truth values to a stack as well as the OR and AND symbols. This seems to work very well! If anybody would like any further help on something like this, feel free to comment.
To make a somewhat long story short, I'm trying to do this:
#define MY_MACRO(x) id myObjectx;
to create myObject1 and myObject2 and so on. I have a lot of these, and the real situation is a little more complicated than just declaring the object and that's it, I need it to repeat a few different things with that number, and copy-paste is getting ugly.
Note: I understand that with the information I've given you you'll be tempted to suggest I just use an array, so I'll explain - I need a bunch of separate KVO properties, and they can't all go in a to-many because the amount of change notifications would get out of hand.
As bmargulies said, you can use ## in the macro:
#define MY_MACRO(x) id myObject##x;
bmargulies, why don't you add your comment as an answer...?
If I only want to check if something is impossible or not (i.e., I will not be using something like if(possible)), should I name the boolean notPossible and use if(notPossible) or should I name it possible and use if(!possible) instead?
And just to be sure, if I also have to check for whether it is possible, I would name the boolean possible and use if(possible) along with else, right?
You should probably use isPossible.
Negative names for booleans like notPossible is a very bad idea. You might end up having to write things like if (!notPossible) which makes the code difficult to read. Don't do that.
I tend to err on the side of positivity here and use possible. It means someone can't write some code later that does this...
if (!notPossible)
Which is unreadable.
I like to name booleans with consistent short-verb prefixes such as is or has, and I'd find a not prefix peculiar and tricky to mentally "parse" (so, I suspect, would many readers of the code, whether aware of feeling that way or not;-) -- so, I'd either name the variable isPossible (and use !isPossible), or just name the variable isImpossible (many adjectives have handy antonyms like this, and for a prefix has you could use a prefix lacks to make an antonym of the whole thing;-).
I generally try to name my flags so that they will read as nicely as possible where they are being used. That means try to name them so that they won't have to be negated where they are used.
I know some folks insist all names be positive, so that people don't get confused between the negations in the name and those in their head. That's probably a good policy for a boolean in a class interface. But if its local to a single source file, and I know all the calls will negate it, I'd much rather see if (impossible && ...) than if (!isPossible && ...).
Whichever is easier to read in your specifc application. Just be sure you don't end up with "if (!notPossible)".
I think it's considered preferable to avoid using negatives in variable names so that you avoid the double negative of if(!notPossible).
I recommend using isPossible. It just seems to make a lot of sense to use 'is' (or perhaps 'has') whenever you can when naming boolean variables. This is logical because you want to find out if something is possible, right?
I agree that negatively named booleans are a bad idea, but sometimes it's possible to reframe the condition in a way that's positive. For example, you might use pathIsBlocked rather than cannotProceed, or rather than isNotAbleToDie you could use isImmortal.
You should name it for exactly what is being stored in it. If you're storing whether it's possible then name it isPossible. If you're storing whether it's impossible name it isImpossible.
In either case you can use an else if you need to check for both cases.
From your description it seems more important to you to check for impossibility so I'd go with isImpossible:
if(isImpossible)
{
// ...
}
else
{
//...
}