octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #60784] Inconsistent behavior for boolean matr


From: Kai Torben Ohlhus
Subject: [Octave-bug-tracker] [bug #60784] Inconsistent behavior for boolean matrix types with matrix functions
Date: Wed, 16 Jun 2021 00:26:13 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.106 Safari/537.36

Follow-up Comment #6, bug #60784 (project octave):

Adding a timing might have obfuscated the point I tried to make, sorry for the
confusion 😓

On a machine with 1 TB of main memory:


A = rand (2e4);
B = logical (A);
C = single (B);
D = int16(B);

>> whos
Variables visible from the current scope:

variables in scope: top scope

   Attr Name        Size                     Bytes  Class
   ==== ====        ====                     =====  ===== 
        A       20000x20000             3200000000  double
        B       20000x20000              400000000  logical
        C       20000x20000             1600000000  single
        D       20000x20000              800000000  int16
        ans         1x1                          8  double

Total is 1600000001 elements using 6000000008 bytes


tic; det (A); toc           # Elapsed time is 24.2933 seconds.
tic; det (B); toc           # Elapsed time is 14.8445 seconds.
tic; det (double (B)); toc  # Elapsed time is 15.7939 seconds.
tic; det (C); toc           # Elapsed time is 8.57522 seconds.
tic; det (D); toc           # Elapsed time is 14.6047 seconds.


Thus roughly confirmed your timing observations.  The difference with det(A)
to det(B) I explain with the "nicer" structure of B (only ones) the algorithm
can exploit (DGETRF, LAPACK LU-factorization, summing up the diagonal)
https://hg.savannah.gnu.org/hgweb/octave/file/84d7e1ace446/liboctave/array/dMatrix.cc#l862

My point is memory consumption during the algorithm execution.  The timings
themselves are of minor interest and I introduced them only to "ensure" that
the same "branches" of the algorithm are taken (not a smart decision
apparently).

Now when monitoring only the memory


##                 Basic mem.   def. A   det (A)                  det (double
(A))
A = rand (2e4);  #   2.1 GB     5.1 GB   8.0 GB (10.0 GB peak)
A = logical (A); #   2.1 GB     2.5 GB   8.4 GB (11.4 GB peak)    8.4 GB (11.4
GB peak)
A = single (A);  #   2.1 GB     3.6 GB   5.1 GB ( 6.1 GB peak)
A = int16 (A);   #   2.1 GB     2.8 GB   8.8 GB (11.8 GB peak)


Can you make similar observations @dasergatskov?

Regarding comment #5: I think you prefer user convenience then?


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?60784>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]