octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: specfun release ? [WAS: laguerre.m functions in specfun package]


From: Juan Pablo Carbajal
Subject: Re: specfun release ? [WAS: laguerre.m functions in specfun package]
Date: Wed, 29 Apr 2015 20:38:44 +0200

On Wed, Apr 29, 2015 at 7:35 PM, Philip Nienhuis <address@hidden> wrote:
> Juan Pablo Carbajal wrote:
>>
>> On Tue, Apr 28, 2015 at 6:30 PM, Carnë Draug <address@hidden>
>> wrote:
>>>
>>> On 25 April 2015 at 20:30, Philip Nienhuis <address@hidden> wrote:
>>>>
>>>> Carnë Draug wrote:
>>>>>
>>>>>
>>>>> On 25 April 2015 at 15:56, Philip Nienhuis <address@hidden>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> After Colin has tidied up a bit in the OF specfun package, I'm
>>>>>> planning
>>>>>> to
>>>>>> make a new release of it.
>>>>>>
>>>>>> The package in the mercurial repo contains two laguerre.m functions,
>>>>>> one
>>>>>> in
>>>>>> inst/, the other in devel/
>>>>>>
>>>>>> The latter looks to be a bit more elaborate (it contains a demo and
>>>>>> perhaps
>>>>>> more aptly named variables), to compensate for that it is lacking a
>>>>>> bit
>>>>>> in
>>>>>> coding style and lacks the one comment line that was present in the
>>>>>> original
>>>>>> (?) one in inst/.
>>>>>>
>>>>>> So, any advice about which laguerre.m to retain?
>>>>>
>>>>>
>>>>>
>>>>> "hg log" tells me this is work from Juan Carbajal who was trying to
>>>>> merge
>>>>> the
>>>>> existing laguerre with laguerrepoly from the miscellaneous package:
>>>>>
>>>>>       o  changeset:   144:88d235233c5e
>>>>>       |  user:        jpicarbajal
>>>>>       |  date:        Sun Apr 14 19:33:57 2013 +0000
>>>>>       |  files:       devel/laguerre.m
>>>>>       |  description:
>>>>>       |  specfun: unifying laguerre and laguerrepoly
>>>>>
>>>>> Also, the plan was to simply move the whole specfun package into the
>>>>> unmaintained section.
>>>>>
>>>>> https://savannah.gnu.org/bugs/?44533#comment3
>>>>
>>>>
>>>>
>>>> Hmmm, I missed that part of the discussion (although I commented there
>>>> initially).
>>>>
>>>> I wouldn't mind keeping specfun around a little longer, esp. now that
>>>> Colin
>>>> pimped the heaviside and dirac functions.
>>>> His suggestion to move them to core is probably too late for 4.0.0 so I
>>>> suggested to temporarily have them in a new specfun release, see
>>>> https://savannah.gnu.org/patch/index.php?8644#comment4
>>>>
>>>> As far as I'm concerned that could be the last specfun release then; it
>>>> could have a dependency added on Octave < 4.2.0
>>>>
>>>> So, what shall I do?
>>>
>>>
>>> I am arguing that dirac and heaviside should be moved to the symbolic
>>> package.  And then we drop the specfun package.
>>> See https://savannah.gnu.org/patch/?8644#comment13
>>>
>>> Carnë
>>>
>>
>> I completely disagree with this.
>> Symbolic does not offer replacement for these functions. Specially it
>> is not true that
>>
>> multinom, multinom_coeff, multinom_exp -- I think these are monomials,
>> and nthcoeff in the sym,bolic package
>>
>> (mind the "I think"). These functions are optimized for numeric not
>> for symbolic manipulation (which by the way is the main role of
>> octave). The symbolic version of these function will just ad an over
>> heard in time execution and memory!
>>
>> Please always think of this when you want to replace a numerical
>> version of a function with a symbolic one (please!). You should
>> provide performance (time and memory) justifying the change.
>>
>> In any case, if you want to get rid of specfun (I do not know why you
>> would want that!), I would say be mindful if your are not a user of
>> the package. Your interest might not coincide with the interest of the
>> true/intended users.
>
>
> In the bug report that Carnë mentioned I read Mike's comment as a suggestion
> to drop specfun from the mxe-octave Windows installer, rather than drop it
> completely from Octave-Forge.
>
> specfun contains a few functions that still may be useful and are neither in
> core nor other OF packages. AFAIAC they can also go to e.g., miscellaneous.
> AFAICS the package does not constitute an undue maintenance burden. A
> release would have taken less time than all the collected time invested in
> this thread :-)  and probably much less investment than porting the rest of
> its functions to symbolic as suggested in
> https://savannah.gnu.org/patch/index.php?8644#comment13
>
> As to functions in symbolic versus numerical functions:
> Colin (symbolic package author) can explain best why there's a need for the
> overhauled heaviside.m and dirac.m to not live in symbolic; his original aim
> was to get them in core. In fact he did in his OP in
> https://savannah.gnu.org/patch/index.php?8644  I'm not sure if .m functions
> in an OF package can be called with a handle (Colin's motive AFAIU); .oct
> functions in an OF package can.
>
> Juan, if you can solve the laguerre.m issue I mentioned in my OP here I'm
> still prepared to make a new release (if Carnë is willing to upload it).
> But my suggestion to make it a temporary one until Octave 4.2.0 still stands
> (i.e., a dependency on Octave < 4.2.0). I think that would save all of us
> the most time now that Octave-4.0.0. is close.
>
> Philip
>

Philip,

I updated the function. Is it ok now?
It passes all the tests and has a demo.

Now, the signature is changed in a way that is closer to matlabs
http://ch.mathworks.com/help/symbolic/laguerrel.html

Shall we rename it to laguerreL? Or will it be implemented in the
symbolic package?

I am interested in seeing a performance comparison between symbolic
functions and numerical ones like laguerre or multinom.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]