Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#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

  • 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.