MATLAB: Normalize between -1 > x > 1 (not equal to -1 or 1)

normalize

How to normalize values so that they fall within -1 and 1 (but no values should be equal either -1 or 1). Thank you.

Best Answer

You can't do this. Not effectively. Ok, let me say that you cannot do this well. Strict inequalities are not easily used when working with floating point numbers. You should essentially never test for something exactly equal to a number anyway in floating point arithmetic.

So I don't know what you are trying to do. But it is a bad idea in general. Have I convinced you?

Sigh, since I know someone will give you an answer anyway, I might as well offer a decent one, something that should work. Are you asking for a linear normalization? Thus a linear shift and scale of the vector elements?

x= randn(1,100);
format long g
min(x)
ans =
          -2.0648600364807
max(x)
ans =
          3.56986777687433

Now, how to normalize x as you apparently wish. This would normalize a vector to +/- 1. But floating point arithmetic being involved, there is no assurance that a strict inequality will exist. In fact, it might even result in something less than -1 or greater than +1 by some amount on the order of eps.

xnorm = (x - min(x))/(max(x) - min(x))*2 - 1;
min(xnorm) == -1
ans =
  logical
   1
max(xnorm) == 1
ans =
  logical
   1

In fact, in this case, it hit +/-1 on the nose. To try to yield a strict inequality, I'll do one extra step.

xnorm = ((x - min(x))/(max(x) - min(x))*2 - 1)*(1-eps);

This time, I multiplied by 1-eps. That contracts the result by just enough that the min and max elements will be closer to zero by the smallest amount possible.

min(xnorm) == -1
ans =
  logical
   0
max(xnorm) == 1
ans =
  logical
   0
min(xnorm) +1
ans =
      2.22044604925031e-16
max(xnorm) - 1
ans =
     -2.22044604925031e-16

So the min is just above -1 by eps. The max is just below 1 by eps. All is good in the world, at least for today. To safer, I might perhaps have chosen to contract things by a factor of (1-2*eps) instead of (1-eps).

Regardless, trying to work with strict inequalities like this will lead you into trouble one day. One day, not far into the future we may see an anguished question from you, asking why your code does not work properly.

Related Solutions

MATLAB: MATLAB showing two equal numbers as not equal to each other

They LOOK equal, when written out as numbers with limited signifcant digits. Are they? Consider this example:

format short
x = 1 + eps
x =
    1.0000
>> x == 1
ans =
  logical
   0
sprintf('%0.55f',x)
ans =
    '1.0000000000000002220446049250313080847263336181640625000'

So, while MATLAB displays 1.0000, the number was not truly 1, at least not exactly so. It was reasonably close. But exactly equal?

I'd suggest you look far more carefully at those values. Decide if they truly are -1 and are both identically so, or if there is a tiny difference.

For example, you might try things like this:

principal_stress - (-1)
principal_stress(2) - principal_stress(1)

Do they show the two values are not equal? What is that difference? Are they truly both exactly -1?

One big clue is in just how MATLAB displayed them.

format short
x = [-1;-1;2]
x =
    -1
    -1
     2
    
y = x;
y(2) = y(2) + eps
y =
   -1.0000
   -1.0000
    2.0000

As you can see, when I created x here, the numbers were true integers. They are exactly representable in floating point arithmetic as such. (As long as an integer does not exceed 2^53-1, that will be true. That is not true of a number like 1/3 however, which is not exactly representable as a floating point number with a finite number of digits unless you are using a ternary numeric storage, or something similar. MATLAB, like most computer languages, uses a binary system. So MATLAB can represent reasonably small integers exactly, or purely binary fractions like 1/4. Fractions like 1/3 or even 1/10 are not representable in a finite number of binary bits.)

sprintf('%0.55f',1/4)
ans =
    '0.2500000000000000000000000000000000000000000000000000000'

Note that x above was displayed without any trailing zeros. However, when I adulterated x by adding a tiny perturbation to even one of the numbers, MATLAB now displayed them as having trailing zeros. This could have been your first clue the elements of principal_stress were not truly what they seemed - those trailing zeros as displayed.

As for the question of what should be done to make them equal, the problem lies not in the numbers themselves, but in your understanding of floating point numbers. I would first do as I suggested. How different are they? Is the difference down in the limits of floating point trash? Thus, in the depths of the least significant bits of a floating point number? NEVER trust those least significant bits, at least not until you know comprehensively when you can trust them.

So you need to learn about tolerances, and how to apply them. You need to learn about floating point arithemetic in general, about how numbers are stored in a computer, how they are manipulated. Once you get to that point, then you have a better chance of knowing when to trust those least significant bits. Until then, ponder if the

0.9999999999999999999... (truncated at some point) is really identically equal to 1. Is a truncated 0.3333 really the same number as 1/3? Of course not.

MATLAB: Subscript indices must either be real positive integers or logicals

There is a problem with the lines of code containing:

      max(x) = Navios
      min(x) = Navios

max and min are built-in functions, you can't use them as variables

Best Answer

Related Solutions

MATLAB: MATLAB showing two equal numbers as not equal to each other

MATLAB: Subscript indices must either be real positive integers or logicals

Related Question