I have two CONTROLs (buttons specifically) that when activated act as one bit each.
So it basically means the highest number I can produce is 2 by having both buttons activated at the same time. EDIT: Okay what I meant to say was that the highest output I'm going to be able to produce is two because I only have 2 buttons, each representing a 1. So 1+1=2.
However, this is only understood logically because the bits are yet to be converted to a numerical(decimal) format. I can use a 'Boolean to 0,1' converted directly to get the values but I'm instructed to use a case structure to complete this.
Right now I'm completely perplexed because a case structure needs exactly ONE case selector but I have TWO buttons. Secondly, this problem seems way too SIMPLE to require a case structure therefore making it genuinely harder to use a more complex method.
So it basically means the highest number I can produce is 2 by having both buttons activated at the same time.
A 2bit-number can have four values, 0...3, hmm?
In general, if the two booleans are bits of the number, or the number can somehow be calculated from the bools, do it.
But if the number can have predefined values which depend on the booleans, but can not be calculated from them, you need some other kind of case distinction. Maybe, whoever instructed you, had this in mind.
You can make a case structure for the first boolean, and in each case, insert a second case structure for the second boolean. This is good when there will be more complex code and logic depending on the boolenans, so you can easily concentrate on one combination of values. For simple cases, this lacks overview, and when adding a third boolean, it's lots of work.
Calculate an interim value, and connect it to a single case structure. Now, there is only one case structure, but you have no overview over all cases. Note I've changed the radix of the case struture to boolean, so you can see the bits in the selector.
Use a simple array to take a value from
Create a lookup table with predefined conditions and values
(Note that the first two solutions force you to implement each case, while the last two do not - what if your arrays are of size 3, only?)
Related
I am facing a problem regarding the ability to enforce different resolutions of expressing time for different rdfs:Classes. I have a graph where:
:event a rdfs:Class.
:subevent rdfs:subClassOf :event.
and also related SHACL-rules where the event class requires its temporal existence reported only at the resolution of date, whereas the subevent is a more precisely defined point in time:
:eventSH a sh:NodeShape;
sh:targetClass :event;
sh:property [
sh:path :happeningOn;
sh:datatype xsd:date;
sh:minCount 1;
sh:maxCount 1;
].
:subeventSH a sh:NodeShape;
sh:targetClass :subevent;
sh:property [
sh:path :happeningOn;
sh:datatype xsd:dateTime;
sh:minCount 1;
sh:maxCount 1;
].
So, in an ontological sense, I have the need to express events at a varying resolution (some events are only known to occur on a certain year, some e.g. on a certain date, and some events are known to happen on a precise point in time).
In essence, the question is: is SHACL capable of expressing a constraint where the subevent timepoint must fall inside the superclass date? Is the only possibility to use SHACL-SPARQL for this? I understand that by nature year, month, day, date are different beasts compared to dateTime, as they are not points but rather ranges between two points in time.
I can't seem to find a function to convert dateTime to date, perhaps just casting into xsd:date would do it but not sure whether this is something most engines support in an unified way. So my primary question is - is this requirement of different resolutions for the same inherited predicate achievable in pure SHACL itself? Or should I resort to using different predicates with the help of e.g. OWL Time ontology? This would seem like an unnecessary complication compared to just using pure SHACL.
edit: As a clarification, I do recognize that in its current shape there is no possibility to define a subevent, as the shapes that restrict it are contradictory.
For this scenario you cannot use sh:datatype. Subclasses can only narrow down the constraints from superclasses. So if the superclass allows xsd:date then the subclass cannot constraint it further to xsd:dateTime. While it may sound intuitive to expect dateTimes to be a "subset" of dates, this is not how SHACL works, because it will compare the exact datatypes only, i.e. the URI of the datatype must match.
I also believe it would be very unusual to have a property that is either xsd:date or xsd:dateTime, depending on context. This makes it harder for applications to process. For example imagine an algorithm that is working against event and doesn't know about sub-event. Such an algorithm would be best if it could always assume xsd:date literals. One design alternative would be to define two properties, where the xsd:date property is always present (even for instances of the subclass), while the subclass may have another property to represent more details.
BTW to convert from xsd:dateTime to xsd:date, you can use xsd:date as a SPARQL function: BIND (xsd:date(NOW()) AS ?date)
I've got a piece of code that takes into account a given amount of features, where each feature is Boolean. I'm looking for the most efficient way to store a set of such features. My initial thought was to try and store these as a BitSet. But then, I realized that this implementation is meant to be used to store numbers in bit format rather than manipulate each bit, which is something I'd like to do (see the effect of switching any feature on and off). I then thought of using a Boolean array, but apparently the JVM uses much more memory for each Boolean element than the one bit it actually needs.
I'm therefore left with the question: What is the most efficient way to store a set of bits that I'd like to treat as independent bits rather than the building blocks of some number?
Please refer to this question: boolean[] vs. BitSet: Which is more efficient?
According to the answer of Peter Lawrey, boolean[] (not Boolean[]) is your way to go since its values can be manipulated and it takes only one byte of memory per bit to store. Consider that there is no way for a JVM application to store one bit in only one bit of memory and let it be directly (array-like) manipulated because it needs a pointer to find the address of the bit and the smallest addressable unit is a byte.
The site you referenced already states that the mutable BitSet is the same as the java.util.BitSet. There is nothing you can do in Java that you can't do in Scala. But since you are using Scala, you probably want a safe implementation which is probably meant to be even multithreaded. Mutable datatypes are not suitable for that. Therefore, I would simply use an immutable BitSet and accept the memory cost.
However, BitSets have their limits (deriving from the maximum number of int). If you need larger data sizes, you may use LongBitSets, which are basically Map<Long, BitSet>. If you need even more space, you may nest them in another map Map<Long, LongBitSet>, but in that case you need to use two or more identifiers (longs).
This question is about handling arrays of information, there's are many ways I could do this, but I would like some input from programmers with more experience, I know what I want to do just not how to organize the information the best way, and objective-C is really making me ponder this, I don't want to get 100 hours into work a decide, oops this wasted the beast way to do this. So here goes:
I have a grid where I'm simulating a playing field, each piece of the grid I call a cell. The cells have around 20 different values each, all integers, nothing fancy. A change to a cell will be either by player input, or occur or by surrounding cells through different algorithms.
The changes to cells will occur once a turn is complete, so it's not real time. Now, I'm not even sure about doing this with a MutableArrays, a plain Array, or just a plain matrix. Arrays are good at keeping such info for one dimension, but I would imagine would become quite cumbersome if you have to address a batch of 10,000 of these cells. On the other hand a simple matrix might not be so elegant, but probably easier to work with.
Any insight would be greatly appreciated.
You have two options here that I see:
1) Use standard containers
Assuming that the playing field is of constant size, then you can create a mutable array of x*y size, and populate it with mutable dictionaries. By giving everything in the second mutable dictionary keys, you can query and set their properties (all objects of course, so wrap ints in NSNumbers etc). For indexing use a macro INDEX_FROM_ROW_COL(row, col) and apply the appropriate code to multiply/add.
2) Create a helper object subclassed from NSObject. It would manage mutable objects as above, but you could load it with functionality specific to your application. You could provide methods that have parameters of "row:" and "col:". Methods that change or set properties of each cell based on some criteria. Personally, I think this is a better idea as you can incapsulate logic here and make the interface to it more high level. It will make it easier to log whats going on too.
I am making a (2X2) Sudoku game and I need to complete a puzzle. That means that some digits are immutable (they cannot be moved out of place.
In a 2X2 game, there are 16 Digits. The problem facts are rows, columns and blocks (get it?). The row is the only planning variable.
I specified boolean fixed as attribute for Digit. But (as per the user guide), I found no place to implement it.
What are the ways to actually make some planning entities immutable?
I find these methods:
Implement a moveFactory that changes the row only if it is immutable. This method is not documented.
If the row is not equal to a fixed_row, break a hard constraint.
Use #ValueRangeFromPlanningProperty. Let the immutable entities have a value_range of a single element, and the mutable entities have have a list that excludes the fixed rows. This seems unsustainable for anything larger than a Sudoku project, right? And there are (my?) alleged pitfalls that derail the solver?
Extra question: is method #3 the recommended way for something like a timetabling problem (allocate subject-teacher to a possible period)?
Option 4:
The fixed digits are problem facts: instances of a class that does not have a #PlanningEntity annotation.
The non-fixed digits are planning entities: instances of a class that does have a #PlanningEntity.
If you'd like to reuse the same class for both for design purposes:
A custom MoveFactory would be the way. Writing a custom move factory is documented: it's just a matter adding an if statement to excluding moves that change a fixed digit.
In that case it's not a build-in hard constraint but a normal hard constraint, I wouldn't recommend that for this use case. See manual info about "build-in hard constraints"
Overkill, but it would work :)
Option 5: https://issues.jboss.org/browse/JBRULES-3359
Specifically, the concept of set referred to here: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-16.html#%_sec_2.3.3
I understand how the data structures work and how to traverse through them, but the use of it is tougher to conceptualize.
Would someone mind explaining it in different words, perhaps that might help it click. Thanks so much.
If you have a set (a b c), then trying to insert a into it will result in the same set (a b c). It is just a collection that has the constraint/guarantee that no value will be duplicate.
Example use: You want to find all words used in a text, but their frequencies are irrelevant. If you have a set, then the algorithm is just: go through all words and add each into the set. Since the set automatically throws away all duplicates, it is the correct result when you finish.