David Bateman wrote:
Christian Neumair wrote:
Thank you for the link. Comparing qaskenco() from MATLAB R2008 /
7.7.0.471 and the code written by you (octave 3.0.1), it looks like
a) MATLAB's version *always* returns column vectors while octave's
automatically returns row vectors if nargin==1 and otherwise adapts to
the orientation of the input vector
b) for only one return argument, MATLAB returns only the in-phase
component while octave's returns both as complex number
In both cases, I prefer octave's implementation but these differences
should be documented somewhere.
Yeah, I think the Octave behavior is better here
c) none of them can handle multidimensional input arguments which
wonders me because that's the way I always want to use them for large
simulation setups. IMO this kind of operation should just work
entry-wise.
Yes it would make sense to make the code work with multi-dimensional
arrays and is easy. For some reason I'm getting errors when committing a
patch so I attach it here. Soren could you commit it for me with the
changelog
"Make qaskenco and qaskdeco handle NDArrays. Add tests"
d) the Gray coding is very different.
Is the gray coding different between Octave and Matlab for qaskenco or
between qaskenco and qammod on Matlab? (The goal being to make
qammod/qamdemod call the same code as qaskenco/qaskdeco).. I really
don't have to time to make the qam and qask code the same however and
would welcome someone else doing it.
Frankly I don't if using a different is really an issue. If you want a
particular mapping you're better off defining the constellation to make
sure there are no issues. However even if you don't and there are
significant errors in the BER then that means either
1) The gray mappings in qaskenco/qaskdeco are wrong, which I don't think
that they are given that I've used them quite a bit
2) That the message to be modulated isn't ergodic, and in this case can
you really be said to be doing real BER calculations.
So perhaps it isn't a real issue.. I suppose it would make sense to make
it the same as matlab if the code remains as fast and the change is easy
In general, how should we handle such tiny incompatibilities between
MATLAB and octave? Where should they be documented? Shouldn't there be a
website and doc page listing the differences package-wise?
In the docstring of the function itself is the best place.
D.
with the patch
D.
--
David Bateman dbate...@dbateman.org
35 rue Gambetta +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE +33 6 72 01 06 33 (Mob)
Index: qaskdeco.m
===================================================================
--- qaskdeco.m (revision 5896)
+++ qaskdeco.m (working copy)
@@ -166,10 +166,10 @@
a = a';
endif
- if (any(isnan(a)))
+ if (any(isnan(a(:))))
## We have a non-square constellation, with some invalid points.
## Map to nearest valid constellation points...
- indx = find(isnan(a));
+ indx = find(isnan(a(:)));
ix = ix(indx);
qx = qx(indx);
ang = atan2(quadr(indx),inphase(indx));
@@ -191,3 +191,25 @@
end_unwind_protect
endfunction
+
+%!function dec = __fntestqask1__ (msg, m)
+%! [inp, qudr] = qaskenco (msg, m);
+%! dec = qaskdeco (inp, qudr, m);
+
+%!function __fntestqask2__ (m, dims)
+%! msg = floor( rand(dims) * m);
+%! assert (__fntestqask1__ (msg, m), msg);
+
+%!test __fntestqask2__ (2, [100,100])
+%!test __fntestqask2__ (4, [100,100])
+%!test __fntestqask2__ (8, [100,100])
+%!test __fntestqask2__ (16, [100,100])
+%!test __fntestqask2__ (32, [100,100])
+%!test __fntestqask2__ (64, [100,100])
+
+%!test __fntestqask2__ (2, [100,100,3])
+%!test __fntestqask2__ (4, [100,100,3])
+%!test __fntestqask2__ (8, [100,100,3])
+%!test __fntestqask2__ (16, [100,100,3])
+%!test __fntestqask2__ (32, [100,100,3])
+%!test __fntestqask2__ (64, [100,100,3])
Index: qaskenco.m
===================================================================
--- qaskenco.m (revision 5896)
+++ qaskenco.m (working copy)
@@ -64,7 +64,7 @@
if (nargin == 1)
M = msg;
elseif (nargin == 2)
- if ((min(msg) < 0) || (max(msg) > M-1))
+ if ((min(msg(:)) < 0) || (max(msg(:)) > M-1))
error ("qaskenco: message invalid");
endif
else
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Octave-dev mailing list
Octave-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/octave-dev
