Bug 2488 - Error in UanPdp::SumTapsFromMaxNc for single tap
Error in UanPdp::SumTapsFromMaxNc for single tap
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: uan
ns-3.25
PC Linux
: P5 minor
Assigned To: Federico Guerra
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-08-31 19:09 UTC by Randall Plate
Modified: 2016-09-10 15:03 UTC (History)
2 users (show)

See Also:


Attachments
uan-prop-model.cc patch (1.04 KB, patch)
2016-09-06 15:12 UTC, Randall Plate
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Randall Plate 2016-08-31 19:09:24 UTC
If there is a single tap, this function will currently return the value of that tap, regardless of the values of "delay" and "duration" passed in.

This does not seem correct to me, as if I pass in a delay > 0, I would suspect that I should get a 0 back from this function (there is no value at any delay other than 0 defined for a pdp of length 1).  Returning the value of the tap produces incorrect results in the UanPhyCalcSinrFhFsk::CalcSinrDb function when it calculates isiUpa.  For the case of a single tap, isiUpa (inter-symbol interference) should be 0, but instead, it ends up being equal to the received power (i.e., all the received power is treated as interference).

I suggest replacing the following code in UanPdp::SumTapsFromMaxNc:

if (m_resolution <= Seconds (0))
{
      NS_ASSERT_MSG (GetNTaps () == 1, "Attempted to sum taps over time interval in "
                     "UanPdp with resolution 0 and multiple taps");

      return m_taps[0].GetAmp ();
}

with:

if (m_resolution <= Seconds (0))
{
      NS_ASSERT_MSG (GetNTaps () == 1, "Attempted to sum taps over time interval in "
                     "UanPdp with resolution 0 and multiple taps");

      if(delay == 0) return m_taps[0].GetAmp ();
      else return 0;
}
Comment 1 Federico Guerra 2016-09-01 06:25:48 UTC
Hi Randall,
thanks.
I agree with the fix, which should be ported to WOSS Integration Framework by they way.
Comment 2 Federico Guerra 2016-09-04 05:54:39 UTC
Hi Randall,
the proposed patch should be modified to (two functions to be modified, check abs  since Nc is non coherent, check NS3 syntax):

double
UanPdp::SumTapsFromMaxNc (Time delay, Time duration) const
{
  if (m_resolution <= Seconds (0))
    {
      NS_ASSERT_MSG (GetNTaps () == 1, "Attempted to sum taps over time interval in "
                     "UanPdp with resolution 0 and multiple taps");

      if (delay == 0)
        {
           return std::abs (m_taps[0].GetAmp ());
        }

      return 0;
    }

std::complex<double>
UanPdp::SumTapsFromMaxC (Time delay, Time duration) const
{
  if (m_resolution <= Seconds (0))
    {
      NS_ASSERT_MSG (GetNTaps () == 1, "Attempted to sum taps over time interval in "
                     "UanPdp with resolution 0 and multiple taps");

      if (delay == 0)
       {
         return m_taps[0].GetAmp ();
       }

      return 0;
    }

furthermore please check how are these functions being called around UAN code and check for possible side effects in case of the new behavior.

thanks 

Federico
Comment 3 Federico Guerra 2016-09-04 05:57:39 UTC
from max NC is actually

std::complex<double>
UanPdp::SumTapsFromMaxC (Time delay, Time duration) const
{
  if (m_resolution <= Seconds (0))
    {
      NS_ASSERT_MSG (GetNTaps () == 1, "Attempted to sum taps over time interval in "
                     "UanPdp with resolution 0 and multiple taps");

      if (delay == 0)
       {
         return m_taps[0].GetAmp ();
       }

      return ::std::complex<double> (0.0, 0.0);
    }
Comment 4 Randall Plate 2016-09-06 15:12:21 UTC
Created attachment 2566 [details]
uan-prop-model.cc patch
Comment 5 Randall Plate 2016-09-06 15:13:54 UTC
Comment on attachment 2566 [details]
uan-prop-model.cc patch

I searched the entire NS3 code base and it appears that the SumTapsFromMax functions are only used in this one function (UanPhyCalcSinrFhFsk::CalcSinrDb) and thus there should be no negative side effects of this mod.
Comment 6 Federico Guerra 2016-09-07 02:25:16 UTC
Hi Randall, 
thanks for the patch.
unfortunately the indentation is not ns3 compliant, please check my example at comment 2 which is compliant.
if you have any doubt please check 
https://www.nsnam.org/developers/contributing-code/coding-style/

thanks again
Comment 7 Federico Guerra 2016-09-07 02:26:48 UTC
aside for this small issue, the patch looks good :)
Comment 8 Randall Plate 2016-09-07 11:48:13 UTC
I'm not sure what is not compliant.  The NS3 coding style states that "single-statement blocks may be placed on the same line of an if () statement".  I have also used 2 spaces for the indentation.  Is there something else you are referring to?
Comment 9 Federico Guerra 2016-09-07 12:10:15 UTC
My fault then, sorry
Comment 10 Tom Henderson 2016-09-07 12:39:27 UTC
(In reply to Federico Guerra from comment #9)
> My fault then, sorry

Was this mistakenly marked RESOLVED FIXED?  Nothing was pushed to ns-3-dev.  Should I push? 

It is OK to put single statement blocks on one line, although most of the codebase still uses braces for that.

One small change I would make is to change 'delay == 0' to 'delay.IsZero ()'.  I think it will work the same, but just wonder about making it immune to future compiler warnings about type mismatch.
Comment 11 Federico Guerra 2016-09-07 13:03:26 UTC
Thanks Tom for your comment. 
Yep my fault on the state change, I'm not that familiar with Bugzilla states
Comment 12 Tom Henderson 2016-09-10 15:03:58 UTC
pushed in changeset 12313:69ac866f029f