patchGNU Octave - Patches: patch #8644, Add dirac and heaviside functions

 
 

patch #8644: Add dirac and heaviside functions

Submitted by:  Colin Macdonald <cbm>
Submitted on:  Tue 07 Apr 2015 04:17:09 PM UTC  
 
Category:  None Priority:  5 - Normal
Status:  Done Privacy:  Public
Assigned to:  None Open/Closed:  Closed

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Sat 04 Jun 2016 11:11:16 PM UTC, comment #19: 
Carnë Draug <carandraug>
Project Member
Sat 30 Apr 2016 07:43:17 AM UTC, comment #18: 

@Carne, we may need to review the various special functions that have been moved from this pkg into core...  I'm no expert on special functions but Octave can be much better than this!

Here's a summary of where I'm at:

lambertw: good, based on the definitive paper.  I did some minor fixes for inf/nan inputs.

laguerre: was numerically unstable, essentially new implementation in Symbolic.

zeta: embarrassingly bad.  I found errors of at least 0.03 along the critical line.  I can't possibly merge this!

sinint: also bad, see https://github.com/cbm755/octsympy/issues/416

cosint: shares implementation (and inaccuracies #47738) with expint

Why are we rolling our own for these things?  SciPy uses the "cephes" and "specfun" Fortran libraries, maybe others...

- - - - - -

laplacian: I disagree: this does not belong in Symbolic: its a finite difference discretization of the Laplacian: like 'del2' in core.  Looks useful.  Also part of "BLOPEX".  (Its true that Symbolic does have a '@sym/laplacian')

- - - - - -

multinom, multinom_coeff, multinom_exp: haven't looked into these yet.

Colin Macdonald <cbm>
Tue 19 Apr 2016 07:24:18 PM UTC, comment #17: 

Thanks for removing those.  I will try to remember to make those commits to specfun when move other functions over.

Colin Macdonald <cbm>
Tue 19 Apr 2016 07:22:40 PM UTC, comment #16: 

I don't think I noticed that other laguerre, oops.

It still looks wrong to me.  I haven't read it all, but it uses polyval: my rule of thumb is doing anything numerical with monomial form of polynomials is suspicious and often numerically unstable.

Colin Macdonald <cbm>
Tue 19 Apr 2016 07:04:59 PM UTC, comment #15: 

I have made note of this move of functions http://hg.code.sf.net/p/octave/specfun/rev/f24d9a66c197

We should make a new release of the specfun package before the next release of the symbolic package (or maybe just mark it as unmaintained).

By the way, did you notice another version of laguerre.m in the devel directory? http://hg.code.sf.net/p/octave/specfun/file/f24d9a66c197/devel/laguerre.m

Carnë Draug <carandraug>
Project Member
Sat 09 Apr 2016 06:50:25 AM UTC, comment #14: 

I've started moving some things over to Symbolic as per the list in Carnë's comment #13.

See: https://github.com/cbm755/octsympy/pull/398

Colin Macdonald <cbm>
Tue 28 Apr 2015 04:28:56 PM UTC, comment #13: 

> Yes, I could do that. Although I feel core is better because SymPy's codegen features target Octave, not Octave+Symbolic.


Yeah, but this is the symbolic package, which targets a Matlab compatible implementation of their symbolic package. So it makes sense to have dirac and heaviside on the symbolic. Not every single function in the package needs to call sympy.

> OTOH, putting it in Symbolic avoids having symbolic depend on specfun pkg (which is sort of does right now).
>
> But then Symbolic and Specfun will shadow each other :(


The specfun package is mostly unmaintained. Its last active maintainer was more than 4 years ago, and we are planning on just dropping it from Octave Forge altogether, see

https://savannah.gnu.org/bugs/?44533#comment3

Here's the value of the specfun:

  • Ci -- deprecated in favour of cosint
  • Si -- deprecated in favour of sinint
  • cosint -- should be in the symbolic package
  • dirac -- should be in the symbolic package
  • ellipke -- removed and is now part of core
  • erfcinv -- removed and is now part of core
  • expint -- removed and is now part of core
  • expint_E1
  • expint_Ei
  • heaviside -- should be in the symbolic package
  • laguerre -- should be laguerreL in symbolic package
  • lambertw -- should be in the symbolic package
  • laplacian  -- should be in the symbolic package
  • multinom,  multinom_coeff,  multinom_exp -- I think these are monomials, and nthcoeff in the sym,bolic package
  • psi -- already ported for core (but will probably only make it to 4.2 (see https://savannah.gnu.org/bugs/?44533#comment8 )
  • sinint -- should be in the symbolic package
  • zeta -- should be in the symbolic package
  • ellipj -- removed and is now part of core
Carnë Draug <carandraug>
Project Member
Mon 27 Apr 2015 06:11:36 PM UTC, comment #12: 

Yes, I could do that.  Although I feel core is better because SymPy's codegen features target Octave, not Octave+Symbolic.

OTOH, putting it in Symbolic avoids having symbolic depend on specfun pkg (which is sort of does right now).

But then Symbolic and Specfun will shadow each other :(

What would you want to do?

Colin Macdonald <cbm>
Mon 27 Apr 2015 05:53:32 PM UTC, comment #11: 

I am a bit late to the discussion but I don't understand one thing. What's the difference between adding this functions to the specfun package and simply adding them to the symbolic package like a normal function?

Carnë Draug <carandraug>
Project Member
Sat 25 Apr 2015 02:42:46 PM UTC, comment #10: 

Thanks for this work.
I'll make a new specfun release then.

Philip Nienhuis <philipnienhuis>
Project Member
Wed 22 Apr 2015 12:46:41 PM UTC, comment #9: 

I don't see any option to close this bug...  please do so if you can.

Colin Macdonald <cbm>
Wed 22 Apr 2015 12:42:52 PM UTC, comment #8: 

Ok, I pushed my changes to specfun tip and updated NEWS.

I don't get any warnings about shadowing when using Octave 4rc3 with specfun tip so I agree about a release.  Have not tested on 3.8.2.

Colin Macdonald <cbm>
Tue 21 Apr 2015 07:35:24 PM UTC, comment #7: 

+1, Thanks!

If the then dev specfun pkg version doesn't shadow core functions anymore, would you think it's time for a new specfun pkg release?

I think we shouldn't push any more changes to core, just bug fixes, until 4.0.0 is out.

Philip Nienhuis <philipnienhuis>
Project Member
Fri 17 Apr 2015 02:59:33 PM UTC, comment #6: 

Or if you "+1" this, I think I may have permission to just push to specfun myself.

Colin Macdonald <cbm>
Fri 17 Apr 2015 02:58:35 PM UTC, comment #5: 

Ok, I've attached a patch against specfun, which extends the existing functions.

Should I also submit against the 4.2.0 branch?  I'm not sure of the procedure for moving files over to core and keeping their history (an "hg transplant"?)

(file #33704)

Colin Macdonald <cbm>
Wed 08 Apr 2015 05:45:03 PM UTC, comment #4: 

Thanks for that.
Could you come up with a nice combination of both? (without too much work)?

N.B. the core devs should decide on whether those functions go into core. I think it'll only happen for an Octave-4.2.0 release as 4.0.0 has a feature stop and the 4.0.x releases are supposed to be mere bugfix releases.

Would you agree with parking the improved functions in the specfun package until Octave-4.2.x is released?
I have plans to make a new specfun package release a little before Octave-4.0.0 is officially released (so that it can be incorporated in a binary Windows intaller).

Philip Nienhuis <philipnienhuis>
Project Member
Tue 07 Apr 2015 09:46:21 PM UTC, comment #3: 

Oh, I never knew about those (its specfun pkg not general for anyone following along).

I'm happy to patch the existing ones.  Should/can I still propose for core?

Comparison
----------

Mine treat nan correctly (e.g., heaviside(nan) is nan rather than 0).

Mine have tests and doctest-compatible documentation.

Their heaviside has a nice optional second argument.

Colin Macdonald <cbm>
Tue 07 Apr 2015 07:05:35 PM UTC, comment #2: 

I may miss the target completely, but OK: there are dirac and heaviside functions in the OF general package.

Can you compare your versions with those and advise which are the best?

Philip Nienhuis <philipnienhuis>
Project Member
Tue 07 Apr 2015 04:20:40 PM UTC, comment #1: 

Maybe its not clear from my comment: Matlab does something different than what I propose here.  My justification hopefully explains why I think we should do it differently.

Colin Macdonald <cbm>
Tue 07 Apr 2015 04:17:09 PM UTC, original submission:  

[tl;dr] I could put these into the Symbolic pkg but it seems to me these make more sense in core.

AFAICT, the Symbol Maths Toolbox for Matlab includes @double/dirac and @double/heaviside rather than in core Matlab. 

Longer explanation/justification:

1.  One reason we should have these at all is that SymPy can generate Octave code for a given symbolic expression, which will currently fail if the expression includes Heaviside or DiracDelta.  This effects us in Octave because it means the Symbolic pkg cannot (currently) generate a function handle (e.g, for fast plotting) from symbolic expressions that contain heaviside or dirac.
2.  I can easily patch SymPy to output code calling dirac.m and heaviside.m.  But If I add dirac and heaviside to @double/ in the Symbolic pkg than that patch for SymPy does not really generate Octave code but rather "Octave+Symbolic pkg" code.  Wearing my SymPy dev hat, I'm not sure I'd want to merge such a patch.
3.  In SymPy, I could generate inline Octave code for heaviside but it would not treat nan correctly (or at least I don't know of a function handle implementation that would: 1/2*(x==0) + double(x>0) does the wrong thing for nan.  And I don't know a one-liner for dirac.

So IMHO, simplest thing is to put heaviside.m and dirac.m into core Octave.

Colin Macdonald <cbm>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #33704:  specfun-dirac_heaviside_nan_doc_single.patch added by cbm (5KiB - text/x-patch - obseletes my octave patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by cbm (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-04-25 philipnienhuis StatusNeed Info => Done
        Open/ClosedOpen => Closed
    2015-04-17 cbm Attached File- => Added specfun-dirac_heaviside_nan_doc_single.patch, #33704
    2015-04-07 philipnienhuis StatusNone => Need Info
    2015-04-07 cbm Attached File- => Added octave_add_dirac_heaviside.patch, #33580

    Back to the top


    Powered by Savane 3.5