Matlab Function in Simulink not allowing fortran scientific notation?

--Edited for clarity--

In Simulink you can create a constant block with a value of 3.14D2 which will lead to an output of 314.

In Matlab you can create a constant with a value of 3.14D2 which will also give an output of 314.

However, when you place a matlab function block in a simulink model and within that function you define a variable equal to 3.14D2 the resulting output is 3.14

Is there something I am needing to change to allow this function within a model to work correctly without manually changing the 3.14D2 to 3.14E2? Is there a setting to reinstate this functionality of utilizing Fortran notation in Matlab 2017b?

Summary: Functions originally in Fortran, recreated in matlab function blocks (2015a), attempting to update to 2017b. Lots of functions, lots of variables, was not originally written by me.

I would expect Matlab + Simulink to handle this gracefully, but it does not.

[dpb]

Need more context where you see such a symptom...

>> x=3.14D2
x =
 314
>> ver
-----------------------------------------------------------------------------------------------------
MATLAB Version: 9.3.0.713579 (R2017b)
...

[Star Strider]

I cannot reproduce that in R2018a:

Q = 3.14D2

Q =
   314

[Walter Roberson]

However it is true that sscanf does not recognize D exponent at least in r2018a

[dpb]

I think that's also been true "since forever"; which is why need more context...R2014b is earliest I have currently installed but get same result from it as with R2017b for

sscanf      - d,D not recognized
str2double  - d,D not recognized

while

str2num     - d,D are recognized
textscan    - d,D are recognized

Input parser interprets d,D exponent.

ADDENDUM

Now why chose to limit str2double I don't know, sscanf is relatively easy to follow as it basically is a vectorized version of the C library function.

It's a real shame when did the translation from the original Matlab Fortran version to C that didn't take the Fortran FORMAT statement and i/o with it instead of the easy-way-out--just think how many of the threads on how to parse fixed-width files wouldn't have been needed! :) Plus being able to have repeat factors instead of ugly repmat in building formatting strings would be so much more pleasant.

[Wiley Mosley]

I am sorry, but there is more context to this.

In Simulink you can create a constant block with a value of 3.14D2 which will lead to an output of 314.

In Matlab you can create a constant with a value of 3.14D2 which will also give an output of 314.

However, when you place a matlab function block in a simulink model and within that function you define a variable equal to 3.14D2 the resulting output is 3.14

Is there something I am needing to change to allow this function within a model to work correctly without manually changing the 3.14D2 to 3.14E2?

[James Tursa]

"... However, when you place a matlab function block in a simulink model and within that function you define a variable equal to 3.14D2 the resulting output is 3.14 ..."

Ouch! That behavior is nasty ...

[dpb]

I "know nuthink!" about Simulink so can't answer the question directly; would think would need to see the function content to be able to comment at all even if one did have/know Simulink.

But, I'd ask why are you writing the constant that way in the first place? In Matlab, unlike Fortran, the default floating point variable is double and it doesn't require a cast to create one and to ensure a constant is, indeed, a double constant and not a single precision constant being promoted to double storage; the reason for the 'D' in Fortran.

But how does Fortran behavior play any part at all in your Simulink/Matlab model other than you may have come with a Fortran background and thus are aware of the need there?

[Wiley Mosley]

Yes, this is not the most effective way to go about this. However, in 2015 the model worked flawlessly and I thought I would ask the community before I go through this legacy code to update it all.

To sum it all up: Functions originally in Fortran, recreated in matlab function blocks (2015a), attempting to update to 2017b. Lots of functions, lots of variables, was not originally written by me.

I would expect Matlab + Simulink to handle this gracefully, but it does not.

[dpb]

"TLDR:" ??

If this is really a change in behavior between R2015a and R2017b I think you'll need to submit support request to official TMW support to be able to get to the bottom of what the change might have been.

Perhaps you've uncovered a bug inadvertently introduced...given the same behavior of all the conversion functions and base Matlab input parser, it would seem unlikely such a change would have been deliberate.

[dpb]

"However, when you place a matlab function block in a simulink model and within that function you define a variable equal to 3.14D2 the resulting output is 3.14"

Is that internal to the function itself or does the function return the value?

Would be interested in seeing a sample function that exhibits the behavior.

(Although I still think contacting TMW Support is the thing to do here)

[Wiley Mosley]

Yes, I will contact TMW Support and submit this as a bug.

A simple amount of code can recreate this. In Simulink create a constant block with output 3.14D2. Connect that output to matlab function block. Define that matlab function block as:

function y = fcn(u)
u=3.14D2
y=u

Return Y as the output of the function block and input to a scope. If you place test points you can see the value starts at 314 then in the function gets assigne 3.14 which is then passed back to simulink and displayed in the scope.

[dpb]

That doesn't look like valid code block for the purpose, but presume that's just typo in writing "air code"...

From the description it looks like the function internally is correct but the value somehow is being reinterpreted from the text string instead of as a stored variable by Simulink.

I don't have Simulink (seems like very few of the "regulars" do, afaict) so can't poke around...

What happens if the function is instead

function out=name()
  y=3.14D2;
  out=y;
end

? Does that function also exhibit the problem?

[Wiley Mosley]

Yes, utilizing the debug features inside the matlab function inside the simulink model y=3.14D2 results in value of 3.14.

[dpb]

Yeech! As James said, that's nasty!

Bug city, indeed. :(

This one will be most interesting to see what TMW's response is if it is, in fact, perceived as anything but a bug.

Answer 1

[Wiley Mosley]

This was successfully addresed in a bug fix and update to 2019a.