#84 bad object type of xchg output

critical
closed-invalid
core (120)
5
2004-09-15
2004-05-19
Anonymous
No

When I use object of type PDL::Complex, $obj->xchg
(1,2) return object of type PDL::Complex but $obj->xchg
(0,1) no (PDL).

Cheers, greg

Discussion

  • Nobody/Anonymous

    Logged In: NO

    Sorry, it's a mistake

    You can remove it...

    Cheers, Greg

     
  • Craig DeForest

    Craig DeForest - 2004-09-15

    Logged In: YES
    user_id=20200

    This is a wart, not a bug. The PDL::Complex object is a
    loose ("convenience") subclass of PDL, so you still have
    acess to the 0th dim just as you would with a raw PDL. But
    exchanging the 0th dim with some other invalidates the
    subclass, because (in your example) now the 1st dim runs
    over the components of the compex, and the 0th runs over
    something else entirely. But the PDL::Complex subclass
    needs the 0th dimension to run over the components.

    If you really mean to do that, you can force it back to
    PDL::Complex with bless(): $b =
    bless($a->xchg(0,1),'PDL::Complex')

     
  • Craig DeForest

    Craig DeForest - 2004-09-15
    • assigned_to: nobody --> zowie
    • status: open --> closed-invalid
     
  • Craig DeForest

    Craig DeForest - 2004-09-15

    Logged In: YES
    user_id=20200

    Hmmm... in my other response, I argued that the
    complained-about behavior would be reasonable, but I can't
    seem to reproduce it. xchg() always returns a PDL::Complex,
    as I would expect [even though it breaks the class as
    described].

    I'm closing this bug out, but if anyone wants to make
    PDL::Complex more airtight, please feel free. Right now,
    it's an expert-friendly convenience class. But there are no
    handrails or trigger-guards -- it's sort of dangerous to the
    unwary.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks