On Mon, Apr 30, 2012 at 12:26 PM, Robert T. Short <oct...@phaselockedsystems.com> wrote: > On 04/30/2012 08:45 AM, Carnë Draug wrote: >> On 30 April 2012 15:34, Robert T. Short<oct...@phaselockedsystems.com> >> wrote: >>> On 04/30/2012 04:34 AM, SourceForge.net wrote: >>>> Bugs item #3522120, was opened at 2012-04-27 16:06 >>>> Message generated for change (Comment added) made by carandraug >>>> You can respond by visiting: >>>> >>>> https://sourceforge.net/tracker/?func=detail&atid=102888&aid=3522120&group_id=2888 >>>> >>>> should this function be made a subfunction of the marcumq? >>> I don't really care but tablify is a general purpose function that I use in >>> other places including a confluent hypergeometric function I posted on the >>> octave-forge mailing list a few weeks ago. >> What happened to this function? Was it ever implemented on any >> package? I can't find your name on any of the octave-forge files. When >> these things are sent to the mailing list, sometimes they get lost. > I followed the instructions on the web site and just mailed it to the > list instead of putting it on the tracker. I gather there isn't much > interest but I can post it on the tracker. I have a more general > hypergeometric function as well. > > BTW, the hypergeometric functions also use tablify. So does the inverse > marcumq function I will post in a day or two. >>> All tablify does (and I hate the name but can't think of a better one) is >>> copy data around. Jordi has rightfully made the point that this is >>> fundamentally dumb, but I don't think there is currently a better octave >>> solution for problems of this type. If bsxfun allowed more than two >>> arguments 'tablify' wouldn't exist at all but I have not got around to >>> looking at bsxfun. >> Well it can either be made private for the whole package or added to >> another package and add its dependency to that. >> > Don't care. Whatever is right. The original marcumq used a function > called padarray to create tables, from image as I recall. The tablify > function is a simpler version of that, and an extension of common_size > from the octave core. Seems it should go in something like > miscellaneous or general or something. Or, if we really don't like it, > I can redo marcumQ so users have to handle the common size issues their > own selves (yech).
I started looking at your implementation, not in too much detail yet, but to the point where it does seem to work for me :) I'll look some more but don't let me slow down the process. The current marcumq implementation resizes the inputs using padarray from the image package. So we definitely don't want to lose the ability to accept any size input. If you want to keep tablify in there, I agree it should go in either general or miscellaneous. If you want to replace tablify with padarray, it may not be as efficient as yours, but it will give the same results and be backwards compatible. Does your function depend on any particular version of Octave? -- mike ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
