Abstract data type (ADT) : Organized data and operations on this data
Examples : Stack, Queue
what's meaning of Concrete data type (CDT)?
please explain by Examples.
One way to understand it is that an ADT is a specification of an object with certain methods.
For example if we talk about a List we are referring to an object that performs list operations such as:
add to the beginning
add to the end
insert at position
size
etc..
A "concrete data type" in this context would refer to the actual Data Structure you use to implement the list.
For example, one implementation of a List is to create nodes with a value and next pointer to point to the next node in the list.
Another is to have a value array, and a next array to tell you where the next node is (this is a more popular implementation for parallelism).
And yet another is to have a dynamic array (known as an ArrayList in Java) where you use an array till it fills up and then you duplicate it's size and copy the values to the new array.
So the concrete data type refers to the data structure actually being used, whereas the ADT is the abstract concept like List, Dictionary, Stack, Queue, Graph, etc..
There are many ways to implement an ADT.
Related
I'm struggling to understand how to use UICollectionViewDiffableDataSource and NSDiffableDataSourceSnapshot to model change of items.
Let's say I have a simple item which looks like this:
struct Item {
var id: Int
var name: String
}
Based on the names of the generic parameters, UICollectionViewDiffableDataSource and NSDiffableDataSourceSnapshot should operate not with Item itself, but only with identifier, which Int in this example.
On the other hand, again based on names of generic parameters, UICollectionView.CellRegistration should operate on complete Item's. So my guess is that UICollectionViewDiffableDataSource.CellProvider is responsible for finding complete Item's by id. Which is unfortunate, because then aside from snapshots, I need to maintain a separate storage of items. And there is a risk that this storage may go out of sync with snapshots.
But it is still not clear to me how do I inform UICollectionViewDiffableDataSource that some item changed its name without changing its id. I want UICollectionView to update the relevant cell and animate change in content size, but I don't want insertion or removal animation.
There are two approaches that would work solve your problem in this scenario.
The first is to conform your Item model to the hashable protocol. This would allow you to use the entire model as an identifier, and the cell provider closure would pass you an object of type Item. UICollectionViewDiffableDataSource would use the hash value for each instance of your model (which would consider both the id and name properties, thereby solving your name changing issue) to identify the data for a cell. This is better than trying to trick the collection view data source into considering only the id as the identifier because, as you stated, other aspects of the model might change. The whole point of structs is to act as a value-type, where the composition of all the model's properties determine its 'value'...no need to trick the collection view data source into looking only at Item.id.
Do as you said, and create a separate dictionary in which you can retrieve the Items based on their id's. While it is slightly more work to maintain a dictionary, it is a fairly trivial difference in terms of lines of code. All you should do is dump and recalculate the dictionary every time you apply a new snapshot. In this case, to update a cell when the model changes, make sure to swap out the model in your dictionary and call reloadItem on your snapshot.
While the second option is generally my preferred choice because the point of diffable data source is to allow for the handling of massive data sets by only concerning the data source with a simple identifier for each item, in this case your model is so simple that there's really no concern about wasted compute time calculating hash values, etc. If you think your model is likely to grow over time, I would probably go with the dictionary approach.
Stack is an example of an abstract data type, stack is an example of a data structure but yet abstract data types are different from data structures how come?
You can think of an ADT (Abstract Data Type) as collection of operations (i.e. add, remove, insert that define how the ADT behaves on a collection of data elements. At the ADT level, the exact way that the data is stored is hidden; hence the Abstract in Abstract Data Type. The big idea here is to hide the way data is presented to make it more accessible to others. Examples include Map and Que.
A data structure, on the other hand, actually implements those operations that define the ADT's behaviour. Examples include Array and List.
In more practical terms, you'll typically see an ADT defined in two files: 1) an interface file, which specifies the required operations; 2) an implementation file, which implements those operations using a specific data structure.
This is why you'll see something like public interface SomeList<T> at the head of interface files and public class SimpleLink<T> implements SomeList<T> at the head of implementation files — the implements is a "promise" to implement all of SomeList<T>'s methods.
I have a reflexive entity, a classic parent - children.
This hierarchy is edited by the user in the front-end and then passed back to the backend.
The only way I've found to record that kind of array with doctrine/symfony2 is this way (ps no code, logic here):
getting the modified array array_result
getting all the objects from the bdd (via the repository, I get an array of all the objects) array_bdd
loop over array_result, each element of the modified array
if element.id can be found in array_bdd then
comparing all the properties
if there is a difference in the properties, I modify the object in array_bdd and persist it
end of loop
flush
It's seems a bit heavy to me but from what I've read I couldn't find another way.
Is it correct to perform like this with doctrine ?
I am working on using a real time application in java, I have a data structure that looks like this.
HashMap<Integer, Object> myMap;
now this works really well for storing the data that I need but it kills me on getting data out. The underlying problems that I run into is that if i call
Collection<Object> myObjects = myMap.values();
Iterator<object> it = myObjects.iterator();
while(it.hasNext(){ object o = it.next(); }
I declare the iterator and collection as variable in my class, and assign them each iteration, but iterating over the collection is very slow. This is a real time application so need to iterate at least 25x per second.
Looking at the profiler I see that there is a new instance of the iterator being created every update.
I was thinking of two ways of possibly changing the hashmap to possibly fix my problems.
1. cache the iterator somehow although i'm not sure if that's possible.
2. possibly changing the return type of hashmap.values() to return a list instead of a collection
3. use a different data structure but I don't know what I could use.
If this is still open use Google Guava collections. They have things like multiMap for the structures you are defining. Ok, these might not be an exact replacement, but close:
From the website here: https://code.google.com/p/guava-libraries/wiki/NewCollectionTypesExplained
Every experienced Java programmer has, at one point or another, implemented a Map> or Map>, and dealt with the awkwardness of that structure. For example, Map> is a typical way to represent an unlabeled directed graph. Guava's Multimap framework makes it easy to handle a mapping from keys to multiple values. A Multimap is a general way to associate keys with arbitrarily many values.
I'm creating a client side cache object and one of the consumers of the cache needs a means of looking up data by type. Obviously I can't just have a map from class to data since that wouldn't retrieve subtypes of the class. Is there a 'standard' or well suited data structure for this kind of thing?
Instead of using a HashTable, it'd be easier to use a tree, since a tree would easily represent the type heirarchy.
If you key you HashMap by Class objects it will behave exactly as you expect it to. There will be no lookup on "subtype".