I am going to create a list of string, for example, ["a", "10", "p20", ...]. Which way is more efficient, using string, vector, QVector, QLinkedList or others?
The efficiency depends on how you're going to use them. For instance, if you're inserting into the middle, QStringList (which is QList ) handles insertions very well. If you know the exact size up front and it isn't going to change, then QVector might be a better choice. Read up on the various possibilities and then use the one that's appropriate for your needs.
The QVector documentation provides a nice guideline for comparing the different Qt-based possibilities.
Related
I am looking for an Array-like type with the following properties:
stores elements on disk
elements can have composite type
elements are read into memory, not the whole array
it is possible to write individual elements without writing the whole array
supports setindex!, getindex, push!, pop!, shift!, unshift! and maybe vcat
is reasonably efficient
So far I have found the following leads:
https://docs.julialang.org/en/latest/stdlib/SharedArrays/
http://juliadb.org
https://github.com/JuliaIO/JLD.jl
The first one seems promising, but it seems the type of the elements has to be isbits (meaning a simple number, some structs but not, e.g., an Array{Float64,1}). And it's not clear if the whole array contents are loaded into memory.
If it does not exist yet, I will of course try to construct it myself.
NCDatasets.jl addresses part of the requirements:
stores elements on disk: yes
elements can have composite type: no (although some support for composite type is in NetCDF4, but not yet in NCDatasets.jl). Currently you can have only Arrays of basic types and Arrays of Vectors (of basic types).
elements are read into memory, not the whole array: yes
it is possible to write individual elements without writing the whole array supports setindex!, getindex, push!, pop!, shift!, unshift! and maybe vcat: just setindex!, getindex
is reasonably efficient: the efficency is reasonable for me :-)
The project making it yourself sounds very interesting. I think it would server certainly a gap in the current ecosystem.
Some storage technologies that might be good to have a look at are:
HDF5 (for storage, cross-platform and cross-language)
JLD2 (successor of JLD) https://github.com/simonster/JLD2.jl
rasdaman (a "database" for arrays) http://www.rasdaman.org/
possibly also BSON http://bsonspec.org/
Maybe you can also reach out to the JuliaIO group.
In some dynamic programming problems, I notice that my cache table is very sparse. In other words, if I define a table as DP[i][j], i<=10^6, j<=10^2, only a fraction of the table is used and the rest is -1.
So my question is, is it common practice to use a hashmap instead to store (i, j) pairs with their DP value and access them in average O(1) time rather than storing them in the sparse table to save memory?
First of all, Yes you can use hashmap instead of the array for dynamic programming problems. But there are some limitations as well as well as benefits for using a hashmap.
When you use a hashmap for this particular case(dynamic programming), it reduces memory complexity but simultaneously it will increase the constant factor of your code. That means if you can perform 10^{8} operations/second with the help of array, then you will be able to perform around 10^{7} operations/second when used hashmap due to its constant factor although with the same complexity of the algorithm.
So if possible to declare that much size of the array, use array otherwise use the hashmap.
Yes, is the definitely a common practice to use hashmaps. Particularly in the case of sparsity.
It is even possible to go beyond that... For even larger problems, approximate dynamic programming draws from tools such as function approximation.
I am on several lines codes from a Qt project to appending into a Qvector every 1s. I noticed that in STL deque could have a better performance in adding a new element into the end that vector. What's the equivalent or similar Qt way? Cause I don't find any in Qt libraries.
Julio
There is no direct equivalent to the std::deque class in QT.
However, your best bet is to use QList.
Here is what the documentation says about QT container classes:
For most purposes, QList is the right class to use. Its index-based API is more convenient than QLinkedList's iterator-based API, and it is usually faster than QVector because of the way it stores its items in memory. It also expands to less code in your executable.
Anyways, if you are only appending items once every second, there will not be much impact to choose one over the other.
There is no need to have a Qt equivalent for every std container, you can use std::deque if that is what you are after.
Anyway, note that for the case when you do a lot of insertions at the end of the vector both std::vector and QVector have a member function named reserve (see the links) that can be used to pre-allocates a bigger buffer and make insertions at the end faster.
I've been using Object as a way to have a generic associative array (map/dictionary) since AS3/Flex seems to be very limited in this regard. But I really don't like it coming from a C++/Java/C# background. Is there a better way, some standard class I've not come across... is this even considered good/bad in AS3?
Yes, Actionscript uses Object as a generic associative container and is considered the standard way of doing this.
There is also a Dictionary class available, flash.utils.Dictionary.
The difference is that Dictionary can use any value as a key, including objects, while Object uses string keys. For most uses, Object is preferred as it is faster and covers the majority of use cases.
You can see the details on Object here: http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/Object.html
and Dictionary here: http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/utils/Dictionary.html
and the differences between them here: http://livedocs.adobe.com/flex/3/html/help.html?content=10_Lists_of_data_4.html
I'm afraid there's no native alternative to Object or Dictionary for maps and other structures. As for standard, well, it depends on how one defines standard, but there are a couple of known libraries that you might like to check out if you look for Java style collections.
Like this one:
http://sibirjak.com/blog/collections/as3commons-collections/
Also, you could take a look at this question, that has links to a couple of ds libraries (including the above one).
Collections in Adobe Flex
I wouldn't say using Objects is either good or bad practice. In the general case they are faster than any Actionscript alternative (since they are native), but less featured. Sometimes the provided functionality is good enough. Sometimes, it's a bit bare-bones, so something more structured could help you getting rid of lower level details in your code and focusing in your "domain logic", so to speak.
In the end, all of these libraries implement their data structures through Objects, Dictionaries and Arrays (or Vectors). So, if the native objects are fine for your needs, I'd say go with them. On the other hand, if you find yourself basically re-writting, say, an ad-hoc Set, perhaps, using one of these libs would be a wise choice.
Qt's QList class provides several methods for getting the number of items in the list - count, length, and size. As we all know, consistency is important, so which should be the canonical/preferred method to use of those 3?
I agree with everything #Cogwheel said, but in all honesty I would just pick one and stick with it. I think good style would dictate that if "size" sounds the best to you, then use "size" everywhere...don't alternate between "count", "length" and "size" haphazardly. That will lead to potential confusion or a lot of unnecessary trips to documentation pages.
You could try to come up with some other kind of rationale, but the language itself isn't even consistent. All the STL containers (e.g. list, vector) only provide "size", the string class provides "size" and "length", etc.
Pick your favorite (or if you have multiple developers, you should all agree on a favorite) and just stick with it.
The consistency you should work towards is within your project. You're not really going to gain anything by trying to be consistent with everyone else, unless there's some way they'd be incompatible.
That being said, there are subtle semantic differences (in English, not C++) between the names of the functions. If you can make your code clearer by taking advantage of the differences, then consistency may actually work against you.
IMHO, Any one of those. Since even different developers follow different functions within your project, the function names are quite self documented, in the sense that other developers can easily understand what the function is meant to.
I usually go with "size." Ultimately, it is a bit arbitrary, but Qt containers and STL containers both generally have a size, so it is easy to stay consistent between the two types. It's also the shortest. Whenever several solutions are basically equivalent, I always go with whichever results in the least amount of typing. It's a simple rule of thumb, so everybody on the project can usually remember it.