Why matlab is outputting test values even though everything is suppressed?

I'm writing a function to find the roots of an inputted function and I've suppressed everything and I'm trying to make it run without any outputs, but I keep getting outputs that say test equals a number and I can't figure out why. If everything is suppressed why is this still being outputted and how do I fix it?

[José-Luis]

Hard to say without looking at your code. The simplest way to find out would be for you to use the debugger and cycle through your code.

[Andrew]

I've fixed every single error it shows, and I'm still getting the test output.

[José-Luis]

The semi-colon will suppress output from any given line. Knowing what line generate such output is a relatively easy task for the debugger. Just go through your code and look at what lines generates the output. Make sure to step in a function when necessary.

Us knowing what line generates that output is impossible without what people have taking to call the mind-reading toobox.

You need to either post some code reproducing your error or use the debugger yourself.

[Stephen23]

Feature added in R2024b:

https://www.mathworks.com/matlabcentral/discussions/tips/876699-find-unsuppressed-outputs-in-r2024b-using-dbstop

Answer 1

[Image Analyst]

Search your code for "test equals" or for "fprintf". If it spits out "test equals a number" to the command window then you should find one of those things in your code. Check that the lines have semicolons at the end of them.

Answer 2

[dpb]

...keep getting outputs that say test equals a number and I can't figure out why.

Because while you think you've got all output suppressed, clearly you missed at least one line.

Since it is variable test that is being echo'ed, in the code editor do a search for test on the assignment (LH) side of any line in every function you're calling. It'll show up eventually if you're thorough and methodical in the effort. Don't forget continued lines or any long lines that might trail off the right hand side of the screen--a good argument for breaking them up into multiple shorter lines or at least continuing them on subsequent lines if there are any such...

Alternatively, as another suggests, altho it might be slower depending on how the case runs before you get to the suspect line, use the debugger and step thru until the offending output shows up.