Why is "c" a matrix of seemingly equal size to "A"?

Nobody has claimed this yet.

"minimize c^T x
subject to Ax ≤ b
x_i ∈ C_i for all i ∈ {1, 2, ..., I}"

This is what it says on your front page and how I know LP's. "c" would be a vector of the same size as x and "A" a matrix with width being size of x and height size of b.
However, seemingly everywhere in the source-code "c" is a sparse matrix with the same dimension as "A". How can this be? How would you even minimize the resulting vector from c^T times x? Are all entries of "c" except for the first row just zeroes?
Examples: https://github.com/linkedin/DuaLip/blob/240066ec2d50069248f1bb69d2e3e61680571c81/examples/movielens_matching/movies_lens_matching.py#L112
Both C and A have the same size: (num_rows, num_cols)

https://github.com/linkedin/DuaLip/blob/240066ec2d50069248f1bb69d2e3e61680571c81/benchmark/generate_synthetic_data.py#L110
Here in the benchmarking data generation seemingly every entry in "c" is getting it's own value just like "A".

This makes converting your own models into a form readible by DuaLip very hard and confusing. Either explaining the structure and differences of "c" to the orthodox cost vector or adding a "load_from_mps"-function would make it a lot more usable.

Start with the model construction in examples/movielens_matching/movies_lens_matching.py around line 112 and the synthetic data generation in benchmark/generate_synthetic_data.py around line 110. Trace how c is consumed relative to A, then document the representation and its conversion implications; if documentation cannot address the usability issue, define the scope of a load_from_mps function.

Written by the indexing model from the issue text.