[Top][All Lists]

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

[Octave-bug-tracker] [bug #56869] matlab incompatibility - input format

From: Nicholas Jankowski
Subject: [Octave-bug-tracker] [bug #56869] matlab incompatibility - input format specifiers %E and %G produce errors
Date: Sat, 7 Sep 2019 16:36:38 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Edge/16.16299


                 Summary: matlab incompatibility - input format specifiers %E
and %G produce errors 
                 Project: GNU Octave
            Submitted by: nrjank
            Submitted on: Sat 07 Sep 2019 08:36:36 PM UTC
                Category: Octave Function
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Matlab Compatibility
                  Status: None
             Assigned to: None
         Originator Name: Nicholas Jankowski
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 5.1.0
        Operating System: Any



Referring to bug #56557 - in discussing Formatted Input documentation, was
notd that specifiers %E and %G (in caps) aren't valid in Octave. 
Documentation patch removes reference to %E and %G.  

Was noted that in Matlab 2019a, %E and %G are treated the same as %e and %g,
wheras in Octave it produces an "error: sscanf: invalid format specified"

The Octave documentation dating back to 1996 indicated that %E and %G were
supposed to operate just like %e and %g. This was thought to maybe have been
unintentional copying from the Formatted Output sections, but given that it
was around so long and is the same behavior as in Matlab, perhaps it was the
original intention. 

Alternatively, it should be noted that the current Matlab help for sscanf,
fscanf, etc., make no mention of %E and %G, but do for formatted input
sections. And we generally don't do undocumented compatibility.

Recommending that this be added as a low priority compatibility bug since it
seems like it should be a minor alias to have %E/G perform the same as %e/g. 
Wolud also need to remember to add the specifier text back in on the 'Table of
Input Conversions' page.


Reply to this item at:


  Message sent via Savannah

reply via email to

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