help-octave
[Top][All Lists]
Advanced

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

Re: formatting bug


From: Andrew Janke
Subject: Re: formatting bug
Date: Wed, 1 May 2019 16:57:57 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1



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


    


reply via email to

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