rldvec relies on being given correctly-sized but padded vectors ndarray

[mohawk2]

I was just re-reading the code for rldvec, and its Pars are: indx a(N); b(M,N); [o]c(M,N).

@moocow-the-bovine The output 2nd dim of N looks to me like it relies on the inputs having the right size, including a number of zeroes on the end of a. Am I missing something? If I'm right, then I think the output N needs to be another dim (perhaps N2), and it might as well be calculated by a RedoDimsCode rather than with Perl code.

[moocow-the-bovine]

@mohawk2 I'm not sure I understand the question... I looked over the rldvec code in slices.pd myself again just now, but aside from a documentation typo (the $c() at line 1249 should be $b()), nothing is jumping out at me.

Maybe you're referring to the (hack-y) if (!defined($c)) { ... } block in the PMCode at lines 1223-1229 ? That looks like something I might have written trying to simulate RedoDimsCode, but I don't recall what exactly I was thinking at the time (and I don't believe I ever actually wound up using rldvec() for anything productive either), so...

Am I missing something?

Probably not.

I think the output N needs to be another dim

Comparing the type signature of rldvec to that for rld (viz. $a(n); $b(n); [o]$c(m)), I think you're probably right.

[mohawk2]

Thank you for the quick reply! I think the same logic applies wherever there is a zeroes being used to provide an input, the calculation should be done rather than just relying on the inputs for this. Being able to provide nulls is a really nice feature, let's use it!

[mohawk2]

The linked commit executes this, so closing. Thank you for the help!