bugGNU Octave - Bugs: bug #41112, symbolic package: function names...

 
 

bug #41112: symbolic package: function names differ from Matlab

Submitted by:  None
Submitted on:  Sun 05 Jan 2014 07:12:07 PM UTC  
 
Category: Octave Forge PackageSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Matlab Compatibility
Status: ConfirmedAssigned to: None
Originator Name: Swizzla KalongieOriginator Email: -unavailable-
Open/Closed: ClosedRelease: other
Operating System: Any

Add a New Comment(Rich Markup)
   

You are not logged in

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

 

Sun 22 Feb 2015 06:23:29 AM UTC, comment #5:

The new symbolic package appears to implement correctly-named functions for symbolic variables:

Closing report as fixed. Please test the new symbolic package and comment follow up or report a new bug if this is not fixed.

Mike Miller <mtmiller>
Project Administrator
Mon 06 Jan 2014 06:11:03 PM UTC, comment #4:

Jordi,

Have you looked at Reduce at:
http://reduce-algebra.sourceforge.net/

Reduce goes way back and for a long time was
controlled by Rand and therefore not widely
used. I have used it and it worked well for what
I needed.

Anyhow, it is now Open Source.

Michael Godfrey <godfrey>
Project Member
Mon 06 Jan 2014 03:01:39 PM UTC, comment #3:

How have you used the symbolic package? It doesn't handle matrices, which seems to me like one of the biggest drawbacks and makes it almost useless for me.

simplify and integrate are very complicated functions. GiNaC can't even integrate anything other than polynomials right now. In fact, I don't know of any free package that has a simplify symbolic function that is reasonably good for anything slightly complicated.

Where did you see a git package for an alternative symbolic package?

Jordi GutiƩrrez Hermoso <jordigh>
Project Administrator
Mon 06 Jan 2014 02:33:34 PM UTC, comment #2:

Really?

It seems to work well enough. Well for me it's better than nothing. It was useful. Maybe it just needs some attention. Re-name those functions, add in the missing ones (the only ones i really miss are simplify() and integrate() --int() in matlab -- ) and it will be of some use to the community for some time still.

I've been looking around - without much success - to see if anyone at the school is willing to mess around in GiNaC to implement a missing function (or two). Is GSOC any hope? -- in which case implementing more matlab compatibility functions could be part of a bigger, more useful project?

I did come across a Git page where someone was working on a modified octave-symbolic package to make it more matlab-like. If only....

Anonymous
Mon 06 Jan 2014 01:29:57 AM UTC, comment #1:

Thanks for the cheering.

The symbolic package is in bad need of disrepair. I think it's far more of a disappointment than a help. I think perhaps we should just stop listing it as a viable Octave package.

I have heard of someone writing a replacement package, but I don't know how far they are with it.

Jordi GutiƩrrez Hermoso <jordigh>
Project Administrator
Sun 05 Jan 2014 07:12:07 PM UTC, original submission:

Dear Developers,

First off I would like to say:
Thank you for your hard work on octave. I love it. It has been a tremendous asset for me as a student. I refuse to crack a copy of matlab just to do my homework. I wish the school would just use octave instead! GNU FOREVER!

About the BUG that I'd like to report.
some symbolic functions need their names adjusted for case sensitivity.see the situation below:

I was trying to do an assignment that required me to use symbolic computations. Normally I just learn the MATLAB syntax in class and write my octave scripts as such. However there is a nasty difference that I only spotted by accident: in matlab, cos, cosh and the other functions are the same for both numerical and symbolic operations. however to do a symbolic y = cos(x); in octave, you must enter the function name with a capital letter, i.e y = Cos(x) to get the symbolic cosine function.

I think the symbolic function should be merged in with the standard cos function. Maybe cos() could use type checking of the function arguments to determine whether the input type is a symbolic and then call the symbolic Cos() from the octave-symbolic package. If not installed maybe cos() could throw an error about the missing symbolic Cos() from the symbolic package. I'm not an expert, but it actually doesn't sound like too much to do.

How about it? Does my suggestion make sense? I understand octave is NOT matlab, but compatibility certainly can help encourage adoption.

Thanks Guys! Keep up the good work!
I can't wait to use the GUI when it goes stable.

Cheers,
Swizzla

Anonymous

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by mtmiller (Updated the item)
  • -unavailable- added by godfrey (Posted a comment)
  • -unavailable- added by jordigh (Posted a comment)
  • -unavailable- added by None (Submitted the item)
  •  

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

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 22 Feb 2015 06:23:29 AM UTCmtmillerOpen/ClosedOpen=>Closed
    Mon 20 Jan 2014 04:42:13 AM UTCmtmillerRelease3.6.4=>other
      Operating SystemGNU/Linux=>Any
      SummaryOctave-Symbolic function naming=>symbolic package: function names differ from Matlab
    Mon 06 Jan 2014 01:29:57 AM UTCjordighStatusNone=>Confirmed

    Back to the top


    Powered by Savane 3.1-cleanup1