Post by: TempodiBasic on October 16, 2020, 07:42:34 pm
what do you think about the QB45 instuction PMAPhttp://www.qb64.org/wiki/PMAP (http://www.qb64.org/wiki/PMAP)? It is a useful function set to translate between physical screen cohordinates and WINDOW logical cohordinates...
but what do you think if it was possible to translate a value (cohordinate or scalar value) from a range to another with a simple function?
Here I post a simple approach to this issue comparing two methods...
Proportion vs Normalization
Code: QB64: [Select]
- iMin = 1
- iMax = 10
- iNewMin = 10
- iNewMax = 100
- PRINT " StartValue Proportion Translation"
- iValue = i
- dNewValue = Proportion#
- dNewValue2 = Normalize#
- NEXT i
- END ' local end of the program
- FUNCTION Proportion#
- ' Delta1:Delta2 = iValue : iValue2
- ' iValue2 = (Delta2 * ivalue) /Delta1
- Delta1 = iMax - iMin
- Delta2 = iNewMax - iNewMin
- Proportion# = (iValue * Delta2) / Delta1
- FUNCTION Normalize#
- 'valore normalizzato = minimoscala+
- '((osservazione-MIN(intervallo))/
- '(MAX(intervallo)-MIN(intervallo))*
- '(massimoscala-minimoscala)
- Normalize# = iNewMin + ((iValue - iMin) / (iMax - iMin) * (iNewMax - iNewMin))
Thanks to read
Post by: Richard Frost on October 16, 2020, 11:04:05 pm
Variables prefixed with an "i" are reserved for Apple products.
My translation method uses a hammer. Yours is far better, since
it works to expand too. Your 2nd SUB (Normalize#) is best, because
it's only one line. Both your methods should test for zero, as
dividing by it makes a CPU very grumpy.
Post by: bplus on October 17, 2020, 11:27:21 am
I thought Fellippe's map function covered things quite well.
reminder:
Code: QB64: [Select]
- map! = ((value! - minRange!) / (maxRange! - minRange!)) * (newMaxRange! - newMinRange!) + newMinRange!
Using WINDOW automatically does most of this.
Post by: TempodiBasic on October 17, 2020, 01:32:08 pm
I'm glad you know the map! function of pj library.
you're right about all except that
1. the map! function has been translated into QB64 by Fellippe & Ashish
2. it releases a single value
3. my normalize# function has the same radix but it releases a double value
in this post my goal was to evaluate 2 mathematical methods... the Proportion vs the Normalization formulas...
I have used the double type of data to see if there was a significant difference between the two formulas because from my hobbyst point of view I don't know if the difference in calculations is significant or not...
Code: QB64: [Select]
- iMin = 1
- iMax = 10
- iNewMin = 10
- iNewMax = 100
- PRINT " StartValue Proportion Translation"
- iValue = i
- dNewValue = Proportion#
- dNewValue2 = Normalize#
- NEXT i
- END ' local end of the program
- FUNCTION Proportion#
- DIM Delta1, Delta2
- SHARED iNewMin, iNewMax
- ' Delta1:Delta2 = iValue : iValue2
- ' iValue2 = (Delta2 * ivalue) /Delta1
- Delta1 = iMax - iMin
- Delta2 = iNewMax - iNewMin
- Proportion# = (iValue * Delta2) / Delta1
Thanks for feedback I love to know your opinion on this last issue (proportion vs normalization)
Post by: bplus on October 17, 2020, 01:49:45 pm
Looks like Fellippe's is the only one that is working correctly, yours don't seem capable of negative scales and are knocked out when divided by 0 as mentioned by Mr Frost:
Code: QB64: [Select]
- iMin = 0
- iMax = 10
- iNewMin = -100
- iNewMax = 0
- PRINT " StartValue Proportion Translation"
- iValue = i
- dNewValue = Proportion#
- dNewValue2 = Normalize#
- NEXT i
- END ' local end of the program
- FUNCTION Proportion#
- DIM Delta1, Delta2
- SHARED iNewMin, iNewMax
- ' Delta1:Delta2 = iValue : iValue2
- ' iValue2 = (Delta2 * ivalue) /Delta1
- Delta1 = iMax - iMin
- Delta2 = iNewMax - iNewMin
- Proportion# = (iValue * Delta2) / Delta1
- FUNCTION Normalize#
- 'valore normalizzato = minimoscala+
- '((osservazione-MIN(intervallo))/
- '(MAX(intervallo)-MIN(intervallo))*
- '(massimoscala-minimoscala)
- Normalize# = iNewMin + ((iValue - iMin) / (iMax - iMin) * (iNewMax - iNewMin))
- map! = ((value! - minRange!) / (maxRange! - minRange!)) * (newMaxRange! - newMinRange!) + newMinRange!
Post by: TempodiBasic on October 17, 2020, 01:54:40 pm
I'm sorry to make this mistake about "i" prefix!
I'll correct the typemismatch as soon as I can!
I agree totally about the issue of division by zero, but in this case the range is not a range because imin == imax && inewmin == inewmax
if only one of the extreme points of the range is 0 it's not matter
Here the Proportion# function in one line
Code: QB64: [Select]
- iMin = 1
- iMax = 10
- iNewMin = 10
- iNewMax = 100
- PRINT " StartValue Proportion Translation"
- iValue = i
- dNewValue = Proportion#
- dNewValue2 = Normalize#
- NEXT i
- END ' local end of the program
- FUNCTION Proportion#
- ' DIM Delta1, Delta2
- SHARED iNewMin, iNewMax
- ' Delta1:Delta2 = iValue : iValue2
- ' iValue2 = (Delta2 * ivalue) /Delta1
- ' Delta1 = iMax - iMin
- ' Delta2 = iNewMax - iNewMin
- Proportion# = (iValue * (iNewMax - iNewMin)) / (iMax - iMin)
- FUNCTION Normalize#
- SHARED iNewMin, iNewMax
- 'valore normalizzato = minimoscala+
- '((osservazione-MIN(intervallo))/
- '(MAX(intervallo)-MIN(intervallo))*
- '(massimoscala-minimoscala)
- Normalize# = iNewMin + ((iValue - iMin) / (iMax - iMin) * (iNewMax - iNewMin))
About your opinion how is significative the difference of results of the two function?
Post by: TempodiBasic on October 17, 2020, 02:08:17 pm
glad to get your feedback
the code posted by you for comparison among proportion#, Normalization# and the superlative PMAP! gives to me this result
[ This attachment cannot be displayed inline in 'Print Page' view ]
I cannot see the difference for now. However my goal is not to post a duplicate (better or worse than) PMAP! of Fellippe, but to evaluate if the difference got with the 2 methods is significant or not for ordinary calculation, because I think that it is important for calculation of NASA. As you can remember the proportion method has been used by Talete from Mileto to calculate the radium of the earth using the pyramid of Aegipt and a pole. On the other hand Normalization is a statistical method.
Thaks to talk about this.
Post by: bplus on October 17, 2020, 02:13:00 pm
Running in Windows 10-64 laptop QB64 v 1.4 stable
Quote
(better or worse than) PMAP! of Fellippe,PS not using PMAP, using Fellippe's map! function.
Quote
because I think that it is important for calculation of NASA.:-)) I am thinking if NASA used your code they might be firing rockets into the center of the earth!
Post by: TempodiBasic on October 17, 2020, 06:38:55 pm
yes you're right PMAP is a QB45 keyword, that of Fellippe & Ashish is map!, but I have it in so much consideration that I have made a Freudian's lapsus.
so you're thinking that the earth is hollow... mmmh but in this case it is simpler to reach the center of the earth by pole's hole,is it? :)) Nevertheless I can pass my code to the NASA if you think that this is useful.
about my C++ compiling error, in the following attemps I got your results.... QB64 1.5 dev in Windows 8 Pro 64bits.
My curiosity is about the result of Normalization#... nan? Is it an alien number that comes out?
However thanks Bplus you let see nearer my code so I see now that I have translate bad this template formula
Code: QB64: [Select]
- 'valore normalizzato = minimoscala+
- '((osservazione-MIN(intervallo))/
- '(MAX(intervallo)-MIN(intervallo))*
- '(massimoscala-minimoscala)
Code: QB64: [Select]
- Normalize# = iNewMin + ((iValue - iMin) / (iMax - iMin) * (iNewMax - iNewMin))
a typo error!
about proportion# it has been build only for positive numbers...
but if we want adapt it to all combinations (like your example where it manages negative numbers) we must use the ABSolute value of the variable passed to it and adding at the end the iNewMin because the counting of numbers starts from there.
So here the code!
Code: QB64: [Select]
- iMin = 0
- iMax = 10
- iNewMin = -100
- iNewMax = 0
- PRINT " StartValue Proportion Translation"
- iValue = i
- dNewValue = Proportion#
- dNewValue2 = Normalize#
- NEXT i
- END ' local end of the program
- FUNCTION Proportion#
- SHARED iNewMin, iNewMax
- ' Delta1:Delta2 = iValue : iValue2
- ' iValue2 = (Delta2 * ivalue) /Delta1
- ' Delta1 = Absolute( iMax - iMin)
- 'Delta2 = Absolute(iNewMax - iNewMin)
- FUNCTION Normalize#
- SHARED iNewMin, iNewMax
- 'valore normalizzato = minimoscala+
- '((osservazione-MIN(intervallo))/
- '(MAX(intervallo)-MIN(intervallo))*
- '(massimoscala-minimoscala)
- Normalize# = iNewMin + ((iValue - iMin) / (iMax - iMin)) * (iNewMax - iNewMin)
- map! = ((value! - minRange!) / (maxRange! - minRange!)) * (newMaxRange! - newMinRange!) + newMinRange!
in this you can see that the differences between Normalize# and map! are apparents and not real, the only that stands still on is that normalize gives a double type back while map gives a single type back.
Now that you have helped me to correct my first code... do you want say me your opinion about Proportion method vs Normalize method?
Post by: bplus on October 17, 2020, 08:07:44 pm
Quote
Now that you have helped me to correct my first code... do you want say me your opinion about Proportion method vs Normalize method?
Hi TempodiBasic,
I rewrote each equation using like terms and applied Algebra
(ABS was not needed I am pretty sure in proportion.)
They worked out to this
Code: QB64: [Select]
- Proportion# = (NewMax - NewMin) * (Value - 0) / (Max - Min) + NewMin
- Normalize# = (NewMax - NewMin) * (Value - Min) / (Max - Min) + NewMin
- map! = (NewMax - NewMin) * (Value - Min) / (Max - Min) + NewMin
- I would start like this:
- (newMax - newMin) * (Value - Min) / (Max - Min) = X - newMin
- X = (newMax - newMin) * (Value - Min) / (Max - Min) + newMin
- QED
Normalize is identical to map and proportion only works if Min = 0
So between Proportion and Normalize, NASA engineers prefer Normalize 99.99 % ;-))
But hey! What if all Mins are 0 which is very likely case with lengths of things then our formula simplifies to
X = newMax * Value / Max
or
X is to NewMax AS Value is to Max
which is what Proportional means to me.