Hello everyone, Let me make sure I get this right. Two or more PDLs are being operated on to produce a result, but nowhere are the two consulted for a desired output type or initialization. This has been tracked down to a loss of context somewhere in the chain of function calls. There are two problems here, the loss of context and the failure to negotiate the output type from the inputs. Loss of context has cropped up often in my C work, too: if I call a function without a particular piece of context, no deeper function calls will be able to have that context either.
But, I think the real problem is that PDL does not negotiate the output type from the inputs, and it does not ask the inputs if they have any opinions about initialization or setup. Obviously during PDL body allocation, we don't care which PDLs were involved that gave rise to this allocation, we just assume you really want a PDL to be allocated and set up. You need a way to hook into PDL's operator overloading code (in this case) so that it asks the input PDLs what sort of output to produce, and how it should initialize that output. Unfortunately, this issue will arise with any function the uses PDL::PP, as that function (to the best of my knowledge) returns pure PDLs without consulting any of its arguments for alternative return classes. It's not clear to me from a design perspective (not to mention implementation perspective) how I would modify PDL::PP to generically accommodate this sort of behavior. David On Wed, Nov 2, 2016 at 5:22 PM, Ingo Schmid <ingo...@gmx.at> wrote: > currently, I ran into this issue as well. It would help a lot if > initialize would receive information on what it triggered, i.e. the call > stack. > > The call of sin($x) should give in initialize @_ =($class, &operation, > @arguments) . > Is this doable? I think it is mostly code in PP.pm but I don't > understand it. > Ingo > On 10/24/2016 06:51 PM, Diab Jerius wrote: > > On Mon, Oct 24, 2016 at 12:43 PM, Diab Jerius <djer...@cfa.harvard.edu> > wrote: > >> initialize() currently must assume that object construction can be > >> done without any arguments to the constructor. That's inappropriate > >> in some instances (as described above). > > And once more, to clarify... > > > > initialize() is not passed any context, so must assume that object > > attributes have defaults which are context independent. This is not > > always appropriate. > > > > ------------------------------------------------------------ > ------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > > _______________________________________________ > > pdl-devel mailing list > > pdl-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/pdl-devel > > > > ------------------------------------------------------------ > ------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _______________________________________________ > pdl-devel mailing list > pdl-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/pdl-devel > -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian Kernighan
------------------------------------------------------------------------------
_______________________________________________ pdl-devel mailing list pdl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-devel
