bugGNU Octave - Bugs: bug #65070, rose() and histc() made some...

 
 

bug #65070: rose() and histc() made some undesired results

Submitter:  Idar Barstad <idar>
Submitted:  Thu 21 Dec 2023 07:17:11 PM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Duplicate Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 6.3.0 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 22 Dec 2023 07:36:45 PM UTC, comment #4: 

I'm going to mark this as a duplicate of bug #48889 and continue development there.

As for the second question, try 'help histc'.  In particular, this paragraph,


When X is a vector, the function counts the number of elements of X
that fall in the histogram bins defined by EDGES.  This must be a
vector of monotonically increasing values that define the edges of
the histogram bins.  'N(k)' contains the number of elements in X
for which 'EDGES(k) <= X < EDGES(k+1)'.  The final element of N
contains the number of elements of X exactly equal to the last
element of EDGES.


Hence, the number of ordinary bins is EDGES-1 and the last bin uses a different inclusion criteria, but brings the total number to EDGES.  This is Matlab-compatible.

Rik <rik5>
Group administrator
Fri 22 Dec 2023 05:53:02 AM UTC, comment #3: 

... I see that the documentation says that the last element is number of counts equal at the outer edge: "...The final element of N contains the number of elements of X exactly equal to the last element of EDGES." This is a odd thing, but I guess has something to do with matlab-compability.

Idar Barstad <idar>
Fri 22 Dec 2023 05:24:08 AM UTC, comment #2: 

Yes, should be even. Using histc to make a patch, it turned out that histc gave a bad result too:
Using edge_vector = [0:10:350 365]/180*pi as input to histc gives an equally long output from histc. I believe the output should be one less since the output is bin counts.

Idar Barstad <idar>
Fri 22 Dec 2023 01:54:28 AM UTC, comment #1: 

attached is what I get for rose in Octave 8.4.0. is this also what you see in v6.3.0?  is the issue the long and short sectors on either side of 0?


Nicholas Jankowski <nrjank>
Group Member
Thu 21 Dec 2023 07:17:11 PM UTC, original submission:  

 I used Octave ver6.3 and did the following:


 >>[t1,r1] = rose( [1:1:360]/180*pi , [0:10:350]/180*pi )
 >>polar(ti,r1)


and got an uneven rose at about 0. Similar code in matlab produces an even rose.  Shouldn't we get an even rose in Octave also since the background distribution is even?

In my attempt to make a fix I also found that

[bin_counts]=histc(x,edge_vector)

gave the same length for the bin_counts as for edge_vector. I would expect length(bin_counts) to be one less than length(edge_vector).

Idar Barstad <idar>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #55476:  rose.png added by nrjank (82KiB - image/png - comment #0 rose plot in octave 8.4.0)

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by nrjank (Updated the item)
  • -email is unavailable- added by idar (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-12-22 rik5 StatusNone Duplicate
        Open/ClosedOpen Closed
        Dependencies- Depends on bugs #48889
    2023-12-22 nrjank Attached File- Added rose.png, #55476

    Back to the top

    Powered by Savane 3.13-04b1.
    Corresponding source code