Sorting complex numbers

Can the complex number be sorted with real part then imaginary, rather than with magnitude and angle? This could be useful with geometry situation.

# Find flipline inside a bounding box
# bb=bounding box defined by two complex coordinates (left-bot & right-top)
# c=line single point as complex number, da=line angle
# Prerequisite is that the point c is inside the bounding box bb
function [fl]=flipline(bb,c,da)
  n=[bbo(1); bbo(2)-d; bbo(2); bbo(1)+d; bbo(1)];
  s1=conj(v(1:end)); s2=conj(p1);
  if (sum(cs)<2),

This case it need sorted with returned index i and then assembled again with complex().
Testing the function:

octave:171> bb=[-2-2i; 2+2i]; p=complex(8*rand()-4,8*rand()-4), a=180*rand()-90, ln=flipline(bb,p,a), if (length(ln)>0), plot(ln); else clf; end; d=real(bb(2)-bb(1)); n=[bb(1); bb(2)-d; bb(2); bb(1)+d; bb(1)]; line(real(n),imag(n));
p =  3.5601 - 1.1169i
a = -24.918
ln =

  -2.0000 + 1.4660i
   2.0000 - 0.3922i

If we assume that p is a column vector with complex entries this should work:

p = [1+i;3;2-i];
[~,idx] = sortrows([real(p),imag(p)]);

Is this what you are searching for?

This might be it… I couldn’t make sense of the manual page about this, but it looks working.
Is it sorting according to real, then according to imaginary basis?

Also I couldn’t find how to print the complex numbers with printf()-command…

How would you rephrase this help page to make it understandable? :thinking:

In the example by @Jose_Matos , there are not longer complex numbers involved for the call of sortrows. He split it already in two “real” vectors, which represent the real- and imaginary-part of the original number.

Now sortrows sorts by default (see the manual above) by the first column, then the second column, etc.

In my thinking, printf is for users who are not satisfied what the default Octave output (disp / display) produces. Thus you have to specify how you want to see the real and imaginary part of a scalar, vector, or matrix.

For example for vectors:

vec = 2 * ones (4, 1) + i
printf ("%d + %di\n", [real(vec), imag(vec)]')
2 + 1i
2 + 1i
2 + 1i
2 + 1i

sure, and if you want add text there like “a=1+i is something” in front of back of the printed number.
But I guess the default is quite good though.

Can I ask how the accuracy of the number (or complex number) is defined?
I tried to calcuate the accuracy and how the accuracy changes with different operations:
FPACC.pdf (37.3 KB)
and how can I use this if I have longer equation whose output accuracy should be estimated?
I could not see the numbers is operated exactly or rounded and if the number is
a+/-|a|xeps or if its a+/-|a|/2xeps if its rounded with floor it would be |a| and then error up to |a|xeps until next number a+|a|xeps is reached.

A complex number is represented by a pair of double precision real numbers.

Most of the time you do not need to care about the accuracy issues that you refer.

There are some general guidelines (best practives) that you need to follow, like avoid catastrophic cancellation Catastrophic cancellation - Wikipedia

But other than that there is no need to evaluate the possible error unless you have a very good reason to.

One important question to ask is, doing the kind of arithmetic that you shown what is the error that you are interested? Is it the average error or the worst case error? Because they will be quite different (most of the time orders of magnitude apart).

In this regard there is also suggestion to use

I hope find easy method to find error for any equation (as the last one in the earlier attached pdf) caused by the input parameters inaccuracy (a, b and c that case).
Maybe if the octave somehow can estimate itself what is maximum error for example in the below equation:
(c-a)/(b-a) ~ (c-a)/(b-a) +/- max_error,
but it depends on the parameters a,b,c magnitude also and a,b,c could be also
complex numbers and the case is changed again.
FPACC.xls (144.5 KB)
The excel table shows that the equation for min/max cases is changed by the variables magnitudes.
How to do the error-handling for the function, if most of the case error is ~result x 3 x eps,
but some cases error is >result x 1,000 x eps?
Change the function if possible?
The actual question(s) is if I should use:

Case A:
c-a>b-a => c>b

Case B:

for higher accuracy. Considering that the division may increase the errors, the latter could be better. When a,b,c are complex numbers (on same line) it may add problem also to the question.

octave:1> v=[-1-1i; 0+0i; 1+1i]
v =
  -1 - 1i
   0 + 0i
   1 + 1i
octave:2> issorted(v)
ans = 0

I think they are sorted (from smaller to bigger), but complex number case it doesn’t work like this (a=-1-1i, b=0, c=1+1i).

There is mistake here as it should be:
dividing into 2 cases:
Case A: (b-a>0 or a>b)
Case B: (b-a<0 or a>b)
And it should work with
except when it complex numbers it could not work.
Real numbers case it works:

octave:1> issorted([-1 0 1],"either")
ans = 1
octave:2> issorted([1 0 -1],"either")
ans = 1

I’m trying to find out what is best way to extend this into complex numbers that are 3 numbers on same line (at any angle in the complex plane).

Calculations for accuracies:
FPACC.pdf (38.5 KB)
Trying to estimate inaccuracy of the (c-a)/(b-a) by octave program:
funcmaxerr.m (886 Bytes)

octave:58> funcmaxerr
epsmax =    1.9569e+11
errmax =  0.0043452
Elapsed time is 9.37262 seconds.
errcase = [](0x1)

But I couldn’t find any difference of results between these two methods, when coordinates are on some “grid”. However I found some cases where the 0<=r<=1 method fails:


It looks possible to get into result that if
2*c/(b-a)*eps>=4 the 0<=r<=1 method will fail.