formatting bug

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

formatting bug

John Beck
So when you do:
(@(vargin)vargin{:})(1,2,3)
it displays as
ans=1
ans=2
ans=3

However that value should be the exact same as the value:
[1,2,3]

Which displays as
ans=
1 2 3

And I think that since these values are equivalent they should display the same way. The type system should be able to tell that these two values are the same and display them the same way. It is not a system breaking bug but it is a bug in the display of the values.

--
Sincerely,
Rev. John M. Beck
Ordained Dudeist Priest


Reply | Threaded
Open this post in threaded view
|

Re: formatting bug

apjanke-floss


On 5/1/19 1:47 PM, John Beck wrote:
So when you do:
(@(vargin)vargin{:})(1,2,3)
it displays as
ans=1
ans=2
ans=3

However that value should be the exact same as the value:
[1,2,3]

That's not actually the case. [1, 2, 3] is a single array that contains 3 elements. When you do (@(varargin)varargin{:})(1, 2, 3), what results is not a single array, but a "comma-separated list" containing 3 separate arrays, each of which contains a single element.

You can make it a little clearer by assigning the output to variables:

>> [a,b,c] = (@(varargin)varargin{:})(1, 2, 3)
a =  1
b =  2
c =  3

The original output is less clear because it's just calling all 3 of the output variables "ans", even though they're effectively different variables.

What is weird is that it's the third argout that actually gets retained in "ans".

>> (@(varargin)varargin{:})(1, 2, 3)
ans =  1
ans =  2
ans =  3
>> ans
ans =  3
>>

I think the normal thing to do is that when there are multiple argouts, but none of them are explicitly captured in variables, only the first argout is displayed and captured in "ans", and the second and later argouts are silently ignored. So I would expect that code to actually do this:

>> (@(varargin)varargin{:})(1, 2, 3)
ans =  1
>> ans
ans = 1
>>


Cheers,
Andrew
Which displays as
ans=
1 2 3

And I think that since these values are equivalent they should display the same way. The type system should be able to tell that these two values are the same and display them the same way. It is not a system breaking bug but it is a bug in the display of the values.

--
Sincerely,
Rev. John M. Beck
Ordained Dudeist Priest