[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
- Preserving signbit for range operator, Rik, 2013/02/25
- Re: Preserving signbit for range operator, Michael D. Godfrey, 2013/02/25
- Re: Preserving signbit for range operator, Daniel J Sebald, 2013/02/25
- Re: Preserving signbit for range operator, Michael D. Godfrey, 2013/02/25
- Message not available
- Re: Preserving signbit for range operator, Daniel J Sebald, 2013/02/25
- Re: Preserving signbit for range operator, Michael D. Godfrey, 2013/02/25
- Re: Preserving signbit for range operator, Daniel J Sebald, 2013/02/25
- Re: Preserving signbit for range operator,
Daniel J Sebald <=
- Re: Preserving signbit for range operator, Rik, 2013/02/27
- Re: Preserving signbit for range operator, Daniel J Sebald, 2013/02/27
- Re: Preserving signbit for range operator, Rik, 2013/02/27
- Re: Preserving signbit for range operator, Daniel J Sebald, 2013/02/27
- Re: Preserving signbit for range operator, Michael D. Godfrey, 2013/02/27
- Re: Preserving signbit for range operator, Daniel J Sebald, 2013/02/28
- Re: Preserving signbit for range operator, Michael D. Godfrey, 2013/02/28
- Re: Preserving signbit for range operator, Michael D. Godfrey, 2013/02/28
- Re: Preserving signbit for range operator, Rik, 2013/02/28
- Re: Preserving signbit for range operator, Michael D. Godfrey, 2013/02/28