So I'm looking at the source code of igraph library for c, because I need to create a new type of graph which is not included in that library but it's somehow related to a fitness model graph for free-scale networks. While reading the code relative to the build up of such a graph, I've found that these functions are called in many occasions:
(void) IGRAPH_VECTOR_INIT_FINALLY(igraph_vector*,long_int);
(void) igraph_vector_cumsum(igraph_vector*,igraph_vector*);
I can't seem to locate it through the folder and I've searched online but it seems that I can't just find what it does. For example, in a portion of the code i have:
/* Calculate the cumulative fitness scores */
IGRAPH_VECTOR_INIT_FINALLY(&cum_fitness_out, no_of_nodes);
IGRAPH_CHECK(igraph_vector_cumsum(&cum_fitness_out, fitness_out));
max_out = igraph_vector_tail(&cum_fitness_out);
p_cum_fitness_out = &cum_fitness_out;
where cum_fitness_out it's an empty vector, no_of nodes is the number of nodes, igraph check it's a function to check the return of the function igraph_cumsum, vector tail returns the last element of a vector...
IGRAPH_VECTOR_INIT_FINALLY(vector, size) is a shorthand for:
IGRAPH_CHECK(igraph_vector_init(vector, size));
IGRAPH_FINALLY(igraph_vector_destroy, vector);
Basically, it initializes a vector with the given number of undefined elements, checks whether the memory allocation was successful, and then puts the vector on top of the so-called finally stack that contains the list of pointers that should be destroyed in case of an error in the code that follows. More information about IGRAPH_FINALLY can be found here.
igraph_vector_cumsum() calculates the cumulative sum of a vector; its source can be found in src/vector.pmt. .pmt stands for "poor man's templates"; it is essentially a C source file with a bunch of macros that allow the library to quickly "generate" the same data type (e.g., vectors) for different base types (integers, doubles, Booleans etc) with some macro trickery.
Related
What is the API for writing a custom (Elementwise or Raw) kernel that works on cuSPARSE instances in CuPy? If I want to write a kernel that can take cupyx.scipy.sparse.csr_matrix instances as argument, what arguments does the underlying CUDA code need to take?
Found it (at least approximately). For a CSR sparse matrix s, the fields s.data, s.indices, and s.indptr contain a dense array of length s.nnz of nonzero entries, a dense array of length s.nnz of column indices, and a list of locations (relative addresses) of the beginnings of each row in indices respectively. These are all normal cupy.ndarrays and can be passed into a kernel and then to cuSPARSE functions as normal.
My qsort using random pivot is too slow, so it can't pass all tests. Qsort with middle element as pivot is also too slow (because of special test). How can I improve my qsort? I don't really know what's wrong with it.
Here are some suggestions:
only call srand(time(NULL)); once in the main() function, not in the randompartition function.
use the same type int32_t for the array and the input/output methods. This will let you use a single call to fread and fwrite to load and store the data. Note however that this approach is non portable: it will fail if the file was produced with a different endianness.
the random pivot is not fully random: the last element will never be chosen because right is the offset of the last element, not the offset of the element past the end of the array. This convention is error prone and leads to confusing +1/-1 adjustments and off by one errors such as this one.
The pathological case for this approach is a array with all identical elements. You might want to handle this case by computing the slice of identical elements around p and only recurse on smaller slices at the left and right of these elements.
I have a fine tuned algorithm in MATLAB that operates on matrices (ofcourse). I've used matlab coder to generate c code for this algorithm and it works as expected.
Here's a function call that I used in Matlab
x = B/A
wherein
B is of size 1*500 (rows * columns)
A is of size 10*500
x, the result is of size 1*10
When this is converted into C source using Matlab Coder. I noticed that the function definition accepts parameters that are same as above sizes.
void myfunction(const double B[500], const double A[5000], double x[10])
For prototype and testing purposes this seems okay. However, in production I prefer to have this function be used for different sizes too. For example 100 instead of 500 in above mentioned variables should also work. How can I remove dependence of matrix dimensions in my algorithm ?
Additionally, there are few lines of code that use hard coded integers. For example, there is code like
if (rankR <= 1.4903363393874656E-8)
// Some internal function calls
else
// Usage of standard sqrt
or
500.0 * fabs(A[0]) * 2.2204460492503131E-16
Could any one explain what are these hard coded integers ? Are these generated from the test data that I've used in MATLAB ?
If the function call you refer to is the entry-point function, you can define the size when setting up Coder. The simplest way to run the Coder is using the GUI from the 'Apps' menu inside MATLAB (or type 'coder' at the console). After specifying the entry-point function, step 2 is to define the type and size for each of the input variables.
For each dimension of your input variable (there can be more than 2 if necessary), you can specify the:
n - dimension is exactly n long
:n - dimension is up to n long
inf - dimension is unbounded
If the function call is not the entry-point function, and is buried inside your code (or if you are running the codegen function from the console), you can explicitly define variables as being of varying size:
coder.varsize('myVariableName');
Bear in mind that some functions can only be used (with Coder) with fixed-sized inputs.
Fuller description here:
http://uk.mathworks.com/help/fixedpoint/ug/defining-variable-size-data-for-code-generation.html#br9t627
Not sure about the random constants unfortunately.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
Hello I am trying to create a hash function in C to remove duplicates from a set of strings a.k.a char*. The idea is to make what the hash function returns, to be the index of an array, so that if two strings are same they point to the same position at the array. But I am stuck at how could I achieve that.
On my first approach I tried to create an array of integers with size equal to the number of strings given and then make the int, that the hash function returns, modulo the size of the array but it didn't worked since for small number of strings many collisions were created.
To sum up, all I want is to implement a structure, probably a hashMap that getting an string will point me to a number, which is the index of the array, in which I store the number of occurences.
Is there any better idea?
You probably want string interning. Some libraries call them "quarks" (e.g. Glib) or "atoms" (like in X11: XInternAtom). See also symbols (e.g. in Lisp or Scheme).
You could store all your interned strings in a global hash table, and have some function
const char* internized_string(const char*str);
which given some string str returns a canonical interned string which compare equals (with strcmp) to it. But two calls of interned_string on equal (but not identical) strings would return the same address. It would work by first searching a similar string in the hash table; if none is found, add a new copy (perhaps using strdup) into the hash table, and return it.
You could use an hash table, a balanced tree (i.e. red black tree or an AVL tree etc....) a trie, or a hash array mapped trie, or any efficient container to implement your global collection of interned strings.
BTW, if you coded in C++11, you'll have many standard containers provided by the standard C++ library.
If you want to code all by yourself, you could have an hash table implemented as array of buckets; usually you want the size of the array to be prime. Each bucket could be a linked list, or a contiguous array, of string pointers. You re-organize your entire hash table when it gets full (e.g. when the mean -or perhaps the max- size of buckets reaches some threshold like 3 or 8) by growing the bucket array to a bigger prime size -e.g. a prime greater than 3/2 of the old one- (and refill the new table from the old one). Avoid collisions (but accept to have a few of them).
There are many hash table free software libraries in C; e.g. uthash, klib, tommyds, ulib, libstrhash, glib etc etc... GIYF. Study (at least for inspiration) the source code of some of them, and perhaps use one.
So, i've been commissioned to translate some fortran subroutines into C. These subroutines are being called as part of the control flow of a large porgram based primarily in C.
I am translating the functions one at a time, starting with the functions that are found at the top of call stacks.
The problem I am facing is the hand-off of array data from C to fortran.
Suppose we have declared an array in c as
int* someCArray = (int*)malloc( 50 * 4 * sizeof(int) );
Now, this array needs to be passed down into a fortran subroutine to be filled with data
someFortranFunc( someCArray, someOtherParams );
when the array arrives in fortran land, it is declared as a variable sized matrix as such:
subroutine somefortranfunc(somecarray,someotherparams)
integer somefarray(50,*)
The problem is that fortran doesn't seem to size the array correctly, becuase the program seg-faults. When I debug the program, I find that indexing to
somefarray(1,2)
reports that this is an invalid index. Any references to any items in the first column work fine, but there is only one available column in the array when it arrives in fortran.
I can't really change the fact that this is a variable sized array in fortran. Can anyone explain what is happening here, and is there a way that I can mitigate the problem from the C side of things?
[edit]
By the way, the fortran subroutine is being called from the replaced fortran code as
integer somedatastorage(plentybignumber)
integer someindex
...
call somefarray(somedatastorage(someindex))
where the data storage is a large 1d array. There isn't a problem with overrunning the size of the data storage. Somehow, though, the difference between passing the C array and the fortran (sub)array is causing a difference in the fortran subroutine.
Thanks!
Have you considered the Fortran ISO C Binding? I've had very good results with it to interface Fortran and C in both directions. My preference is to avoid rewriting existing, tested code. There are a few types that can't be transferred with the current version of the ISO C Binding, so a translation might be necessary.
What it shouldn't be that others suggested:
1. Size of int vs. size of Integer. Since the first column has the right values.
2. Row vs. column ordering. Would just get values in wrong order not segmentation faulted.
3. Reference vs value passing. Since the first column has the right values. Unless the compiler is doing something evil behind your back.
Are you sure you don't do this in some secret way?:
someCArray++
print out the value of the someCArray pointer right after you make it and right before you pass it. You also should print it out using the debugger in the fortran code just to verify that the compiler is not generating some temporary copies to help you.