bugGNU Octave - Bugs: bug #46816, Assignment error: complex single...

 
 

bug #46816: Assignment error: complex single precision

Submitter:  Ceral Paquet <octavebugs>
Submitted:  Tue 05 Jan 2016 09:32:32 AM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 4.0.1-rc1 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 04 Feb 2016 08:56:13 AM UTC, comment #10: 

Hi Rik, yes it seems fixed in the development version - although unfortunately not in the 4.0.1 release candidate.

Ceral Paquet <octavebugs>
Tue 12 Jan 2016 06:20:13 PM UTC, comment #9: 

Can this be closed now?

Rik <rik5>
Group administrator
Tue 12 Jan 2016 12:26:58 AM UTC, comment #8: 

This bug is a duplicate of bug #37946, which was locked and closed without being solved.

Could someone please mark that bug as a duplicate of this bug?

Also, can this bug be closed since jwe applied the patch, or is there something else I can do?

Lachlan Andrew <lachlan>
Fri 08 Jan 2016 02:55:14 PM UTC, comment #7: 

OK, thanks.

John W. Eaton <jwe>
Group administrator
Fri 08 Jan 2016 03:30:58 AM UTC, comment #6: 

jwe, you are probably right.  I just looked at the execution flow for assignment of real floats to an array slice of doubles, and mirrored that for complex numbers.

One possible reason to handle assignment conversions differently is that assigning to an array slice will affect the type of the rest of the array.  Normally (single, double) results in single, but for (indexed) assignment it results in double, which means that other elements of the array are unaffected as expected.

Lachlan Andrew <lachlan>
Thu 07 Jan 2016 12:06:14 PM UTC, comment #5: 

I checked in the change here (on default):

  http://hg.savannah.gnu.org/hgweb/octave/rev/10071454a4ba

Then it occurred to me that this could also be handled by an assignment conversion.  Since we don't have other float-complex by complex mixed-type operations, maybe that would be more consistent?

I don't remember now why there type conversions for assignment are handled separately from other type conversions.

John W. Eaton <jwe>
Group administrator
Wed 06 Jan 2016 09:47:53 AM UTC, comment #4: 

Yep, that fixed it - thanks!

Ceral Paquet <octavebugs>
Wed 06 Jan 2016 04:52:04 AM UTC, comment #3: 

The attached patch proves the required conversion, and passes make-check.  Ceral, can you give it a go?

For the record, it also changes the naming of two existing functions in libinterp/operators/op-fcm-fcm.cc to match the convention in other operators files that "sgl_assign" assigns to a single precision variable and "dbl_assign" assigns to a double.

(file #35929)

Lachlan Andrew <lachlan>
Tue 05 Jan 2016 10:39:14 AM UTC, comment #2: 

Thanks for the report, Ceral.  I'll take a look, and report back if I get stuck...

Lachlan Andrew <lachlan>
Tue 05 Jan 2016 09:33:27 AM UTC, comment #1: 

Re-post - formatting removed.

>> clear
>> A=zeros(38,1);
>> B=zeros(38,38,'single')+i;
>> A(:,1)=B(:,1);

error: operator =: no conversion for assignment of 'float complex matrix' to indexed 'complex matrix'
error: assignment failed, or no method for 'matrix = float complex matrix'

>> whos

Variables in the current scope:

   Attr Name        Size                     Bytes  Class
   ==== ====        ====                     =====  =====
        A          38x1                        304  double
   c    B          38x38                     11552  single

Total is 1482 elements using 11856 bytes

Ceral Paquet <octavebugs>
Tue 05 Jan 2016 09:32:32 AM UTC, original submission:  


clear
A=zeros(38,1);
B=zeros(38,38,'single')+i;
A(:,1)=B(:,1);

error: operator =: no conversion for assignment of 'float complex matrix' to indexed 'complex matrix'
error: assignment failed, or no method for 'matrix = float complex matrix'

>> whos
Variables in the current scope:

   Attr Name        Size                     Bytes  Class
   ==== ====        ====                     =====  =====
        A          38x1                        304  double
   c    B          38x38                     11552  single

Total is 1482 elements using 11856 bytes
+verbatim+

Ceral Paquet <octavebugs>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #35929:  bug_46816.cset added by lachlan (2KiB - application/octet-stream)

 

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 jwe (Posted a comment)
  • -email is unavailable- added by siko1056 (Updated the item)
  • -email is unavailable- added by lachlan (Posted a comment)
  • -email is unavailable- added by octavebugs (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 17 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-02-04 rik5 StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2016-01-12 rik5 CategoryInterpreter None
        Severity4 - Important 3 - Normal
        Item GroupRegression None
        StatusFixed In Progress
        Assigned tojwe None
        Open/ClosedClosed Open
    2016-01-12 siko1056 Open/ClosedOpen Closed
    2016-01-12 siko1056 CategoryNone Interpreter
        Severity3 - Normal 4 - Important
        Item GroupNone Regression
        StatusIn Progress Fixed
        Assigned toNone jwe
        Dependencies- Depends on bugs #37946
    2016-01-06 lachlan Attached File- Added bug_46816.cset, #35929
    2016-01-05 siko1056 StatusNone In Progress

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code