Yes, and that can be a pain. But it is not so bad to roll one's own for a
corner case like that.
(Mobile)
> On Oct 3, 2015, at 3:14 PM, Chris Marshall wrote:
>
> Don't you lose the PP threading for the OtherPar PDL *?
>
>> On 10/3/2015 17:11, Craig DeForest wrote:
>> Sorry I missed the fir
Don't you lose the PP threading for the OtherPar PDL *?
On 10/3/2015 17:11, Craig DeForest wrote:
Sorry I missed the first iteration. You want something like the $T
macro, which will substitute source code snippets depending on the
$GENERIC type. But by the time you see the PDLs they will hav
Sorry I missed the first iteration. You want something like the $T macro,
which will substitute source code snippets depending on the $GENERIC type. But
by the time you see the PDLs they will have been coerced to a common type, in a
vanilla PP routine. I suggest passing the second argument in
I don't think it can be done in one PP routine but I can
implement the overload sub so that it uses power for the
non-integer exponent cases and ipow for integer exponents.
--Chris
On 10/2/2015 11:00, Chris Marshall wrote:
> I would like to implement integer exponentiation support for ** that
>
I would like to implement integer exponentiation support for ** that is
used when the exponent is an integer data type. Unfortunately, I can't
figure out how to conditionalize the code so that pow is called for float
type exponent but ipow is called for integer type exponents. The generic
type in