Got Questions? Get Answers.
Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

Thread Subject:
A matlab bug?

Subject: A matlab bug?

From: Yuri Geshelin

Date: 6 Mar, 2012 14:26:14

Message: 1 of 13

In MATLAB Version 7.11.1.866 (R2010b) Service Pack 1, this line

>> x = [ [0.8 0.9]; [1.0000000000000002 0.9] ]; fprintf('%6.4f%7.4f %s \n',[x [37;37]]');

produces the expected output:

0.8000 0.9000 %
1.0000 0.9000 %

However, once x(2,1) becomes exactly 1, the output is screwed:

>> x = [ [0.8 0.9]; [1 0.9] ]; fprintf('%6.4f%7.4f %s \n',[x [37;37]]');
0.8000 0.9000 %
0.900037.0000 >>

I know that previous versions didn’t like idea of outputting variables of type DOUBLE with '%s' format. But R2010b does not seem to complain / warn about this. In any case, it looks like a bug to me.

Can anyone comment on this?

Subject: A matlab bug?

From: someone

Date: 6 Mar, 2012 19:32:14

Message: 2 of 13

"Yuri Geshelin" wrote in message <jj56q6$mt2$1@newscl01ah.mathworks.com>...
> In MATLAB Version 7.11.1.866 (R2010b) Service Pack 1, this line
>
> >> x = [ [0.8 0.9]; [1.0000000000000002 0.9] ]; fprintf('%6.4f%7.4f %s \n',[x [37;37]]');
>
> produces the expected output:
>
> 0.8000 0.9000 %
> 1.0000 0.9000 %
>
> However, once x(2,1) becomes exactly 1, the output is screwed:
>
> >> x = [ [0.8 0.9]; [1 0.9] ]; fprintf('%6.4f%7.4f %s \n',[x [37;37]]');
> 0.8000 0.9000 %
> 0.900037.0000 >>
>
> I know that previous versions didn’t like idea of outputting variables of type DOUBLE with '%s' format. But R2010b does not seem to complain / warn about this. In any case, it looks like a bug to me.
>
> Can anyone comment on this?

I'm running MATLAB 7.5.0 (R2007b).
Here are my results:

>> x = [ [0.8 0.9]; [1.0000000000000002 0.9] ]; fprintf('%6.4f%7.4f %s \n',[x [37;37]]');

0.8000 0.9000 Warning: The argument for the %s format specifier must be of type char (a string).
%
1.0000 0.9000 Warning: The argument for the %s format specifier must be of type char (a string).
%
>> x = [ [0.8 0.9]; [1 0.9] ]; fprintf('%6.4f%7.4f %s \n',[x [37;37]]');
0.8000 0.9000 Warning: The argument for the %s format specifier must be of type char (a string).
%
0.900037.0000

I'm not sure what your %s format code is pointing to.
Without it, I get:

>> x = [ [0.8 0.9]; [1 0.9] ]; fprintf('%6.4f%7.4f \n',[x [37;37]]');
0.8000 0.9000
37.0000 1.0000
0.900037.0000
>> x = [ [0.8 0.9]; [1.0000000000000002 0.9] ]; fprintf('%6.4f%7.4f \n',[x [37;37]]');
0.8000 0.9000
37.0000 1.0000
0.900037.0000

Subject: A matlab bug?

From: dpb

Date: 6 Mar, 2012 19:52:31

Message: 3 of 13

On 3/6/2012 8:26 AM, Yuri Geshelin wrote:
...

> I know that previous versions didn’t like idea of outputting variables
> of type DOUBLE with '%s' format. But R2010b does not seem to complain /
> warn about this. In any case, it looks like a bug to me.
> Can anyone comment on this?

I also think it's a bug, but the bug is in the code, not Matlab.

I don't think it's required that lying to the interpreter by passing a
double to a format descriptor expecting a string "work" w/o unexpected
results on occasion.

Try casting the 37's to char() before complaining about Matlab (or use
the doubled-up form to specify the '%' character explicitly instead or a
string/character variable)

--

Subject: A matlab bug?

From: Yuri Geshelin

Date: 6 Mar, 2012 20:30:26

Message: 4 of 13

"someone" wrote in message <jj5onu$re7$1@newscl01ah.mathworks.com>...

> I'm running MATLAB 7.5.0 (R2007b).
Here are my results:
……

Yes, this is what you get with R2007b. Turn warning off, and everything is OK, unless x(2,1) is exactly 1. Therefore the problem remains.

> I'm not sure what your %s format code is pointing to.

The purpose of %s is to output the percent sign. You can’t do it as dpb suggests: cast the 37's to char() or specify the '%' character explicitly. The first method fails, because once you concatenate variable x (which is double) with char, the result of concatenation is char. The latter method fails, because when the percent sign is part of the format, it screws things up.

Subject: A matlab bug?

From: Yuri Geshelin

Date: 6 Mar, 2012 20:36:13

Message: 5 of 13

dpb <none@non.net> wrote in message <jj5ptv$4j7$1@speranza.aioe.org>...

> I also think it's a bug, but the bug is in the code, not Matlab.

I can't rule it out. If this is the case, then please

(a) identify that bug in the code (i.e. suggest the fix)
(b) explain why that bug in the code shows up when x(2,1) is 1.0, but does not show up
when x(2,1) = 1.0000000000000002.

> Try casting the 37's to char() before complaining about Matlab (or use
the doubled-up form to specify the '%' character explicitly instead or a
string/character variable)

Please suggest a working code, it’s only a few lines. We will discuss it then.

Subject: A matlab bug?

From: dpb

Date: 6 Mar, 2012 20:48:28

Message: 6 of 13

On 3/6/2012 2:36 PM, Yuri Geshelin wrote:
> dpb <none@non.net> wrote in message <jj5ptv$4j7$1@speranza.aioe.org>...
>
>> I also think it's a bug, but the bug is in the code, not Matlab.
>
> I can't rule it out. If this is the case, then please
> (a) identify that bug in the code (i.e. suggest the fix)
> (b) explain why that bug in the code shows up when x(2,1) is 1.0, but
> does not show up
> when x(2,1) = 1.0000000000000002.
>
>> Try casting the 37's to char() before complaining about Matlab (or use
> the doubled-up form to specify the '%' character explicitly instead or a
> string/character variable)
>
> Please suggest a working code, it’s only a few lines. We will discuss it
> then.

What specific output do you want?

What's wrong w/

 >> sprintf('%f %f %% \n',x')
ans =
0.800000 0.900000 %
1.000000 0.900000 %

 >>

--

Subject: A matlab bug?

From: dpb

Date: 6 Mar, 2012 21:18:39

Message: 7 of 13

On 3/6/2012 2:36 PM, Yuri Geshelin wrote:
> dpb <none@non.net> wrote in message <jj5ptv$4j7$1@speranza.aioe.org>...
>
>> I also think it's a bug, but the bug is in the code, not Matlab.
>
> I can't rule it out. If this is the case, then please
> (a) identify that bug in the code (i.e. suggest the fix)

 From TMW doc online (fprintf) --

> If you specify a conversion that does not fit the data, such as a
> string conversion for a numeric value, MATLAB overrides the
> specified conversion, and uses %e.
>
> If you apply a string conversion (%s) to integer values, MATLAB
> converts values that correspond to valid character codes to
> characters. For example, '%s' converts [65 66 67] to ABC.

The first of the above two rules was what I expected and what I think is
the bug.

The second seems to be contradictory to the above and "special-cases"
the specific case of an integer-valued double.

It doesn't specify what happens when the two are mixed as yours however,
and I suspect that means A) above applies internally since there is, by
your use of square brackets only one array passed and you've mixed
metaphors in the middle, so to speak.

That would be my interpretation of the bug in the user code. The fix
is, obviously, "don't do that".

> (b) explain why that bug in the code shows up when x(2,1) is 1.0, but
> does not show up
> when x(2,1) = 1.0000000000000002.

By rule A) above, the actual format used would appear to be %e and so
the additional precision in the value will definitely affect the
appearance of the output formatted string.

--

Subject: A matlab bug?

From: dpb

Date: 6 Mar, 2012 22:19:39

Message: 8 of 13

On 3/6/2012 3:18 PM, dpb wrote:
...

>> If you specify a conversion that does not fit the data, such as a
>> string conversion for a numeric value, MATLAB overrides the
>> specified conversion, and uses %e.
...

NB that the Matlab documentation references C99 Standard; it appears
(I'm not C guru, just the result of a quick DAGS but it's what I
presumed would be) that C says the result of a mismatch in type to
corresponding conversion specification is "undefined". This means the
attempt Matlab makes to handle it for you is an extension beyond the C
model the functions were patterned after and you can't blame TMW for not
"getting it right" vis a vis a fallback to expected C behavior.

All in all, I'm comfortable in the position it's the programmer's
responsibility to get it right in matching types to conversion
specifiers and if you don't all bets are off...

--

Subject: A matlab bug?

From: Yuri Geshelin

Date: 7 Mar, 2012 02:43:23

Message: 9 of 13

dpb <none@non.net> wrote in message <jj62hs$sr9$1@speranza.aioe.org>...
> dpb wrote:

>What's wrong w/
>
>>> sprintf('%f %f %% \n',x')

Nothing is wrong, thanks :)
My mind had gone blank. The code had worked for years and then all of a sudden this happened.

>> If you specify a conversion that does not fit the data, such as a
>> string conversion for a numeric value, MATLAB overrides the
>> specified conversion, and uses %e.
>>
>> If you apply a string conversion (%s) to integer values, MATLAB
>> converts values that correspond to valid character codes to
>> characters. For example, '%s' converts [65 66 67] to ABC.
>
>The first of the above two rules was what I expected and what I think is
> the bug.
>
>The second seems to be contradictory to the above and "special-cases"
>the specific case of an integer-valued double.

Yes, it was this contradictory rule that let me down. I don't understand this: if, as they say, '%s' converts [65 66 67] to ABC, then I did not do anything forbidden. In my case it was just 37.

>By rule A) above, the actual format used would appear to be %e and so
>the additional precision in the value will definitely affect the
>appearance of the output formatted string.

It does not seem like the actual format to be used is ‘%e’. And it does not seem like additional precision with ‘%e’ format affects the output. Let’s try it out. Let’s replace %s with %e in my example.

>> x = [ [0.8 0.9]; [1.0000000000000002 0.9] ]; fprintf('%6.4f%7.4f %e \n',[x [37;37]]');
0.8000 0.9000 3.700000e+001
1.0000 0.9000 3.700000e+001

Nope. This is not what happens with ‘%s’.

Now let’s try the “bad” case, when x(2,1) = 1:

>> x = [ [0.8 0.9]; [1 0.9] ]; fprintf('%6.4f%7.4f %e \n',[x [37;37]]');
0.8000 0.9000 3.700000e+001
1.0000 0.9000 3.700000e+001

Same thing. So, with ‘%e’, it makes no difference whether there is additional precision (but the output is weird, of course).

But if we use 37.1 instead of 37 – that's a different story. That’s when ‘%e’ kicks in and overrides ‘%s’:

>> x = [ [0.8 0.9]; [1.00001 0.9] ]; fprintf('%6.4f%7.4f %s \n',[x [37.1;37.1]]');
0.8000 0.9000 3.710000e+001
1.0000 0.9000 3.710000e+001

Again, it does not matter if you output 1 or 1.000001

> This means the attempt Matlab makes to handle it for you is an extension beyond > > the C model the functions were patterned after

They seem to be inconsistent in that effort. The rule that you quoted (conversion of [65 66 67] to ABC) in fact explicitly encourages the user to mix the types. The documentation sets it as a rule of the programming language. In ver. 7.5.0 they issued the warning, but not anymore. This change is a move to less rigorous checking.

> All in all, I'm comfortable in the position it's the programmer's
> responsibility to get it right in matching types to conversion
> specifiers and if you don't all bets are off...

I agree: it is better to stay away from mixing different types.

Subject: A matlab bug?

From: Doug Schwarz

Date: 7 Mar, 2012 03:10:38

Message: 10 of 13

In article <jj56q6$mt2$1@newscl01ah.mathworks.com>,
 "Yuri Geshelin" <geshelin@hotmail.com> wrote:

> In MATLAB Version 7.11.1.866 (R2010b) Service Pack 1, this line
>
> >> x = [ [0.8 0.9]; [1.0000000000000002 0.9] ]; fprintf('%6.4f%7.4f %s \n',[x
> >> [37;37]]');
>
> produces the expected output:
>
> 0.8000 0.9000 %
> 1.0000 0.9000 %
>
> However, once x(2,1) becomes exactly 1, the output is screwed:
>
> >> x = [ [0.8 0.9]; [1 0.9] ]; fprintf('%6.4f%7.4f %s \n',[x [37;37]]');
> 0.8000 0.9000 %
> 0.900037.0000 >>
>
> I know that previous versions didn’t like idea of outputting variables of
> type DOUBLE with '%s' format. But R2010b does not seem to complain / warn
> about this. In any case, it looks like a bug to me.
>
> Can anyone comment on this?

The '%s' format specifier reads from the matrix until it encounters
something it can't interpret. Remember that the matrix elements are
consumed one at a time in storage order. In this case, when the matrix
is

[0.8 0.9 37;1.0000000000000002 0.9 37]'

The order is

[0.8 0.9 37 1.0000000000000002 0.9 37]

fprintf reads two floats and then hits the %s for which it reads 37.
The next number is 1.0000000000000002 which cannot be a character so it
terminates the %s and continues by re-using the format specifiers
starting again with %6.4f.

So, to summarize, we get

%6.4f -> 0.8
%7.4f -> 0.9
%s -> 37 = '%'
%6.4f -> 1.0000000000000002
%7.4f -> 0.9
%s -> 37

and then it's done.

However, if the 1.0000000000000002 is exactly 1 then %s consumes both
the 37 and the 1 since the 1 is a valid ASCII character:

%6.4f -> 0.8
%7.4f -> 0.9
%s -> [37 1] = ['%',char(1)]
%6.4f -> 0.9
%7.4f -> 37

and then we're out of data.

You can solve your problem simply by using %c instead of %s so only one
number is consumed from the input no matter what. Better is to use

fprintf('%6.4f%7.4f %% \n',x')

as suggested by dpb.

--
Doug Schwarz
dmschwarz&ieee,org
Make obvious changes to get real email address.

Subject: A matlab bug?

From: dpb

Date: 7 Mar, 2012 03:23:23

Message: 11 of 13

On 3/6/2012 8:43 PM, Yuri Geshelin wrote:
> dpb <none@non.net> wrote in message <jj62hs$sr9$1@speranza.aioe.org>...
>> dpb wrote:
>
>> What's wrong w/
>>
>>>> sprintf('%f %f %% \n',x')
>
> Nothing is wrong, thanks :)
> My mind had gone blank. The code had worked for years and then all of a
> sudden this happened.
...

Unstable code will do that... :)

>> This means the attempt Matlab makes to handle it for you is an
>> extension beyond > > the C model the functions were patterned after
>
> They seem to be inconsistent in that effort. The rule that you quoted
> (conversion of [65 66 67] to ABC) in fact explicitly encourages the user
> to mix the types. The documentation sets it as a rule of the programming
> language....

I interpret it as an attempt at a fixup; not a recommendation.

I've bit^h^h^hcommented for years that one thing TMW needs in the
documentation is to get away from the narrative description and actually
publish a normative definition of the the language. AFAIK this does not
exist anywhere. I suspect there's two reasons for this--one, it would
be a major effort at this point to develop in a form suitable for
end-users and two, it would tie down their hands in making modifications
more so than are now. A third would be that it would seem to make the
path for competition easier. After the first I don't know which of the
others play into the decision to have never done so...

--


--

Subject: A matlab bug?

From: Yuri Geshelin

Date: 7 Mar, 2012 12:47:12

Message: 12 of 13

Thanks everyone for the discussion. I admit that the bug is mine.

Subject: A matlab bug?

From: dpb

Date: 7 Mar, 2012 14:35:37

Message: 13 of 13

On 3/6/2012 9:10 PM, Doug Schwarz wrote:
...

> The '%s' format specifier reads from the matrix until it encounters
> something it can't interpret. Remember that the matrix elements are
> consumed one at a time in storage order. In this case, when the matrix
> is
>
> [0.8 0.9 37;1.0000000000000002 0.9 37]'
>
> The order is
>
> [0.8 0.9 37 1.0000000000000002 0.9 37]
>
> fprintf reads two floats and then hits the %s for which it reads 37.
> The next number is 1.0000000000000002 which cannot be a character so it
> terminates the %s and continues by re-using the format specifiers
> starting again with %6.4f.
...

This is the behavior I think is simply broken by the vectorization
implementation...it seems (and always has and is why so many get so
confused as I did again in part above altho I basically have given up
trying to parse what actually happens; thanks for the explanation there,
Doug) to me it ought to cycle a field per array entry instead of the
'%s' trying to consume the following values.

I can follow the input case logic much more clearly than this on output
although even there the '%s' is/has always been imo broken because
afaict it doesn't/won't honor field widths such as '%7s' to allow a
fixed-width field to be handled easily.

 >> s='thisisastring';
 >> t=sscanf(s,'%7s')
t =
thisisastring
 >> length(t)
ans =
     13
 >>

Whassup w/ that???

--

Tags for this Thread

What are tags?

A tag is like a keyword or category label associated with each thread. Tags make it easier for you to find threads of interest.

Anyone can tag a thread. Tags are public and visible to everyone.

Contact us