Mon 19 Dec 2016 12:23:36 AM UTC, comment #10:
I've confirmed that the scenario I described is what is happening. That is, I'll write notes in the code below of what happens with the "x = A(rand(3,4)); whos" command:
I see the the line ALWAYS GOES THIS ROUTE accessed maybe 50 or 60 times with the command. (I suppose there are many things in the symbol table beyond the user's variables.)
Beyond that, I've not looked further, mainly because of the slowness of doing development when touching any sort of header file. Takes maybe 20 to 30 minutes to recompile in that case. These routines longer than a few lines should not be inline and inside the header file. Inline routines are for the case when the cost of jumping (i.e., setting up stack, making the jump, etc.) is large relative to the length of the routine.
|
Sun 18 Dec 2016 10:52:21 PM UTC, comment #9:
I lost track of this bug...
I no longer see a "elements += val.capacity ();" in variables.cc. Perhaps a change was made there to fix bug #43096 but didn't get to checking this one. Anyway, the line of code that computes number of elements and displays is now
It appears here that after extracting the A class files to a subdirectory and generating x, y, z according to comment #5, numel(x) produces a proper result. The code that does this is (from data.cc):
It seems to me that now both routes use the octave_value::numel() route. So why does one produce a correct result and not the other? The answer might be in the symbol_record::varval() routine, which is:
That is, whereas the numel() function definition uses the octave_value "arg(0)" directly, this symbold_record::varval() routine might be returning something other than the symbol's octave_value depending on active_context(). Just a theory. I'll experiment after compiling finishes.
|
Sun 18 Dec 2016 08:38:51 PM UTC, comment #8:
I think this behavior is still present in Octave 4.2.0.
The result from the code in comment #5 is still the same. (Even though the mentioned bug #43096 is now marked as fixed.)
|
Fri 06 Feb 2015 09:37:43 PM UTC, comment #7:
I would expect this is related to the kluge mentioned in https://savannah.gnu.org/bugs/?43096, so a proper fix there would likely resolve this.
|
Fri 06 Feb 2015 08:28:25 PM UTC, comment #6:
OK, I understand it now.
Yeah, I tried searching too and I see the "elements += val.capacity ();" line in variables.cc. And searching through octave_value indicates that capacity() is basically numel() in the base class and sometimes is nelem().
But I'm having trouble grepping for "class" definition because, well, "class" is used a thousand times in the code. I think "class" is something new. Is it this routine:
in libinterp/octave-value/ov-class.cc?
|
Fri 06 Feb 2015 10:34:54 AM UTC, comment #5:
Let's start again so its all in this bug instead of cross-linked to the other one where @mtmiller pointed this out. See attached class.
Note each x and y counts as only one "element" even though x reports numel(x) -> 12 and size(x) -> [3 4].
I.e., the element calculation does not respect numel/size/etc for a user-defined class. From reading the code, the element count is done by adding up the ".capacity". That is as far as I've tracked it down.
|
Fri 06 Feb 2015 10:27:07 AM UTC, comment #4:
I take it back, I think the current sparse behaviour looks correct to me. The count matches nnz() of the sparse matrix. That's what I expect.
|
Fri 06 Feb 2015 10:24:33 AM UTC, comment #3:
yeah, sorry "symbolic". Any simple class will demonstrate it, see @A class in the linked bug report.
As you note, apparently sparse shows it too.
|
Fri 06 Feb 2015 09:33:17 AM UTC, comment #2:
What is 'sym'? Is it related to symmetric elimination tree? "symbolic"? Here's another example:
Could it be that the sparse variables only count the defined, non-zero values? Filling in the zero value results in two elements:
|
Thu 05 Feb 2015 10:57:05 PM UTC, comment #1:
This is a minor bug (I don't seem to be able to set that?)
|
Thu 05 Feb 2015 10:56:13 PM UTC, original submission:
In this example, the count should be 9 (from the doubles) + 7 (from the user-defined class sym). But instead each sym counts only as 1 and we see 11 displayed.
@mtmiller found this looking at a related bug:
https://savannah.gnu.org/bugs/?43096
There is a minimal class that demonstrates this problem in that bug.
In that other bug, I said:
> The number of elements thing is counted by adding up
> the ".capacity" of each varval. So I guess "capacity"
> is wrong for simple classes.
|