Wed 16 Nov 2016 08:51:28 PM UTC, comment #11:
Closing as fixed, according to comment #10.
|
Fri 10 Apr 2015 03:16:43 PM UTC, comment #10:
I have installed specfun in the last dev version, and it compiled without warnings
|
Sun 15 Mar 2015 11:59:41 PM UTC, comment #9:
Ok. I read through you cset and it definitely looks like
a very nice piece of work and quite complete.
Your timing is not ideal for 4.0, but if others will support
including it I have no objection.
Michael
|
Sun 15 Mar 2015 02:46:33 PM UTC, comment #8:
Forgot the attachment on the last comment. Here it is.
(file #33352)
|
Sun 15 Mar 2015 02:45:51 PM UTC, comment #7:
On reply to Michael Godfrey, comment #6:
> In any case, completing your implementation with tests, documentation and all will still take you a bit of time, right?
Not really. You don't really any more documentation than the formula, and I've probably wrote my most detailed test suite ever last night :p
It's attached here since I have no other place to push it (note that it's two csets, the second adds support for complex input)
On reply to Mike Miller, comment #5:
> But moving specfun to "unmaintained" status shouldn't depend on psi entering core, right? It sounds like you agree with dropping the specfun package.
Yes, I will go through the list of packages, there may be others than deserve the same "treatment".
|
Sun 15 Mar 2015 02:37:03 PM UTC, comment #6:
Of course, it is very useful to have psi. But, the
release rules should be followed. Getting 4.0 out
is critical.
Keep in mind that it is very likely that, given the
huge amount of change in 4.0, another release will be
needed fairly soon.
In any case, completing your implementation with tests,
documentation and all will still take you a bit of time,
right?
|
Sun 15 Mar 2015 01:42:05 PM UTC, comment #5:
I can't say about the release. I would be hesitant to add a new function at this point.
But moving specfun to "unmaintained" status shouldn't depend on psi entering core, right? It sounds like you agree with dropping the specfun package. Let's keep that a separate issue from adding psi to core. Even if it's unmaintained, the package is still out there if users really want it.
|
Sun 15 Mar 2015 04:04:54 AM UTC, comment #4:
I started to port psi into core but then noticed that is was quite inaccurate (the value of h was hardcoded to 10-9). So, I implemented it from scratch on core (actually, one part is based on the implementation of XLiFE++ which is also under GPLv3+).
http://uma.ensta-paristech.fr/soft/XLiFE++/var/files/htmlusrdoc-release/webuser_documentationch1.html#x4-120001.3
I would like to push this to core so we can then drop the specfun package. But this would add a new function and we are already releasing RC. Can this still be done? Or where should I push this?
|
Sat 14 Mar 2015 01:22:05 PM UTC, comment #3:
No packages depend on specfun it according to the Debian package database.
Most of the functions it contains are just numerical versions of functions provided by the symbolic toolbox (some not yet provided by the symbolic package). It does contain one function that could be moved to core, the psi function.
I'd be ok with downgrading it to unmaintained status and remove it from mxe-octave.
|
Sat 14 Mar 2015 12:53:59 PM UTC, comment #2:
Is there any package that depends on specfun? If not, we could just move it to the unmaintained section of OF. Even the 2011 release was made by me, before I knew better than trying to maintain all the packages no one cares about.
|
Fri 13 Mar 2015 11:18:18 AM UTC, comment #1:
This is a problem with the specfun package.
I've seen these same warnings for years now; specfun hasn't been overhauled for a long time. The last release is from the end of 2011.
That said, I've once proposed (again years ago) that the "pkg" command should have an option to not install package functions that shadow core functions.
Added [OF] to title + changed some tags to reflect it is an octave-forge issue.
It's not an incorrect result but an undesirable result; I wouldn't know a best matching Item group
|
Fri 13 Mar 2015 10:29:08 AM UTC, original submission:
|