--===============1432611552==
Content-Type: multipart/signed;
  boundary="nextPart1908059.p6FAyT8VAG";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1908059.p6FAyT8VAG
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Wednesday, January 10, 2007 05:14:06 PM Tomas Mecir wrote:
> Looks good, as far as I can tell. Didn't look through the PointStorage
> thing too much, so I hope you have that one tested well.

The basic functionality, insertion and lookup, is tested well enough. For t=
he=20
specialties, like column insertions, some more tests are necessary, but it'=
s=20
not used by the ValueArray either.

> Is your PointStorage efficient enough for all of the following cases?
> - sparse matrix with lots of empty rows/columns
> - sparse matrix, where most/all columns/rows contain at least one value
> - matrix which contains a lot of values, all concentrated to upper left e=
nd
> - almost completely filled matrix
>
> Because any of these can happen quite frequently (especially with
> selections that span entire rows/columns).

It's a compressed row sparse matrix. Hence matrices with lots of empty colu=
mns=20
are no problem at all. Empty rows are represented by repeated values in the=
=20
m_rows vector.
I've added two scenarios to the benchmark, that covers the lookups in=20
column/row selections. The needed time per operation is of the order of 100=
=20
ns. Good enough, I think. The Cluster benchmark, which can be seen as dense=
=20
matrix (ignoring the two levelled array), produces times of the order of 10=
=20
ns. So, we have to pay one order of time for the reduced memory storage. Th=
is=20
is for the case where we have iterate over each column and row explicitly.=
=20
Not many functions will do this anyway. Maybe it's even completely avoidabl=
e=20
as you have access to the row and column also for the index-based iteration=
=20
over the non-empty entries.

The more common case, where we just iterate over the non-empty entries shou=
ld=20
beat the dense matrix behavior easily - benchmark's still to be written=20
though.

Regards,
Stefan

--nextPart1908059.p6FAyT8VAG
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQBFpR8PpfDn2DABIpcRAoziAJ4ra1IRGwwjgzHKJAYIaIO45fY1AQCgniE5
aBvLUq76gmgX6TSXe0NUmVk=
=//3j
-----END PGP SIGNATURE-----

--nextPart1908059.p6FAyT8VAG--

--===============1432611552==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel

--===============1432611552==--