octave-maintainers
[Top][All Lists]
Advanced

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

Re: Preserving signbit for range operator


From: Daniel J Sebald
Subject: Re: Preserving signbit for range operator
Date: Wed, 27 Feb 2013 19:16:45 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

On 02/25/2013 04:17 PM, Daniel J Sebald wrote:
On 02/25/2013 03:57 PM, Michael D. Godfrey wrote:
On 02/25/2013 04:11 PM, Daniel J Sebald wrote:
octave:28> [-0:3:5]
ans =

0 3

which is not abiding by the definition.
But, this is what Matlab gets.

Does -0 by itself produce -0 or 0? If the former, then Matlab isn't
abiding by its definition. If the latter, then somehow -0 has to be
input for some variable to test.

Any progress or insight on this?

At this point, I think the issue here is the manner in which value is treated and displayed. That is, Matlab may preserve the sign bit in computations, but when it displays an integer (as opposed to float) there is no -0. -0 is mapped to 0 before being used in print or display operations.

To illustrate, here are some results from Octave using the sprintf command:

octave:25> sprintf("%d ",[-0])
ans = 0
octave:26> sprintf("%f ",[-0])
ans = -0.000000

From this I conclude the negative sign is preserved but lost when the output format is an integer. I say it is lost because of the following result:

octave:28> sprintf("%+d ",[-0])
ans = +0
octave:29> sprintf("%+f ",[-0])
ans = -0.000000

OK, so now let's first address what Octave is doing INTERNALLY. I'm going to try and take the display element out of this and just answer what the result should be for ranges, and I think there might be a mistake.

octave:42> sprintf("%+f ",[0:3:6])
ans = +0.000000 +3.000000 +6.000000
octave:43> sprintf("%+f ",[0:-3:-6])
ans = +0.000000 -3.000000 -6.000000
octave:44> sprintf("%+f ",[-0:3:6])
ans = +0.000000 +3.000000 +6.000000    ## INCORRECT
octave:45> sprintf("%+f ",[-0:-3:-6])
ans = -0.000000 -3.000000 -6.000000
octave:46> sprintf("%+f ",[6:-3:0])
ans = +6.000000 +3.000000 +0.000000
octave:47> sprintf("%+f ",[6:-3:-0])
ans = +6.000000 +3.000000 +0.000000
octave:48> sprintf("%+f ",[-6:3:0])
ans = -6.000000 -3.000000 +0.000000
octave:49> sprintf("%+f ",[-6:3:-0])
ans = -6.000000 -3.000000 +0.000000

There is one case which I think is internally incorrect. Going by the algorithm definition, [a:z:b] should have as its first element 'a' unless the range is nonsensical in which case the empty set results. Therefore, the ## above should have -0.000000 as the first element. The last element of [a:z:b] is not necessarily 'b', it is whatever the computation turns out to be, e.g., 6 + 2 * -3 which is 0, not -0.

Now, let's address the DISPLAY aspect of this by removing the sprintf(), which presumably will treat the values as integers. Again, there looks to be an answer that is incorrect (in a display perspective):

octave:53> [0:3:6]
ans =

   0   3   6

octave:54> [0:-3:-6]
ans =

   0  -3  -6

octave:55> [-0:3:6]
ans =

   0   3   6

octave:56> [-0:-3:-6]
ans =

  -0  -3  -6              *** INCORRECT

octave:57> [6:-3:0]
ans =

   6   3   0

octave:58> [6:-3:-0]
ans =

   6   3   0

octave:59> [-6:3:0]
ans =

  -6  -3   0

octave:60> [-6:3:-0]
ans =

  -6  -3   0

I'm now thinking, as Michael points out, that all the results above should have 0 and no -0, even though internally the -0 should be retained in the proper case.

Notice that the *** above is the same scenario as the incorrect result ## internally. Rik, could you please think this over and check the pertinent case in the code for that scenario? Perhaps there is a bug. Or if you agree there is a bug, then go ahead and file a bug report.

Dan


reply via email to

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