Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Re: Normalizing a range of numbers to a percentage

by BrowserUk (Patriarch)
on Mar 08, 2019 at 11:22 UTC ( [id://1231047]=note: print w/replies, xml ) Need Help??


in reply to Normalizing a range of numbers to a percentage

Save runtime. Do the calculation once and then use a lookup:

#! perl -slw use strict; my $lookup = join '', map{ chr( $_ / 255 * 100 ) } 0 .. 255; print "$_ :: ", ord( substr $lookup, $_, 1 ) for 0 .. 255; __END__ C:\test>junk99 0 :: 0 1 :: 0 2 :: 0 3 :: 1 4 :: 1 5 :: 1 6 :: 2 7 :: 2 8 :: 3 9 :: 3 10 :: 3 11 :: 4 12 :: 4 13 :: 5 14 :: 5 15 :: 5 16 :: 6 17 :: 6 18 :: 7 19 :: 7 20 :: 7 21 :: 8 22 :: 8 23 :: 9 24 :: 9 25 :: 9 26 :: 10 27 :: 10 28 :: 10 29 :: 11 30 :: 11 31 :: 12 32 :: 12 33 :: 12 34 :: 13 35 :: 13 36 :: 14 37 :: 14 38 :: 14 39 :: 15 40 :: 15 41 :: 16 42 :: 16 43 :: 16 44 :: 17 45 :: 17 46 :: 18 47 :: 18 48 :: 18 49 :: 19 50 :: 19 51 :: 20 52 :: 20 53 :: 20 54 :: 21 55 :: 21 56 :: 21 57 :: 22 58 :: 22 59 :: 23 60 :: 23 61 :: 23 62 :: 24 63 :: 24 64 :: 25 65 :: 25 66 :: 25 67 :: 26 68 :: 26 69 :: 27 70 :: 27 71 :: 27 72 :: 28 73 :: 28 74 :: 29 75 :: 29 76 :: 29 77 :: 30 78 :: 30 79 :: 30 80 :: 31 81 :: 31 82 :: 32 83 :: 32 84 :: 32 85 :: 33 86 :: 33 87 :: 34 88 :: 34 89 :: 34 90 :: 35 91 :: 35 92 :: 36 93 :: 36 94 :: 36 95 :: 37 96 :: 37 97 :: 38 98 :: 38 99 :: 38 100 :: 39 101 :: 39 102 :: 40 103 :: 40 104 :: 40 105 :: 41 106 :: 41 107 :: 41 108 :: 42 109 :: 42 110 :: 43 111 :: 43 112 :: 43 113 :: 44 114 :: 44 115 :: 45 116 :: 45 117 :: 45 118 :: 46 119 :: 46 120 :: 47 121 :: 47 122 :: 47 123 :: 48 124 :: 48 125 :: 49 126 :: 49 127 :: 49 128 :: 50 129 :: 50 130 :: 50 131 :: 51 132 :: 51 133 :: 52 134 :: 52 135 :: 52 136 :: 53 137 :: 53 138 :: 54 139 :: 54 140 :: 54 141 :: 55 142 :: 55 143 :: 56 144 :: 56 145 :: 56 146 :: 57 147 :: 57 148 :: 58 149 :: 58 150 :: 58 151 :: 59 152 :: 59 153 :: 60 154 :: 60 155 :: 60 156 :: 61 157 :: 61 158 :: 61 159 :: 62 160 :: 62 161 :: 63 162 :: 63 163 :: 63 164 :: 64 165 :: 64 166 :: 65 167 :: 65 168 :: 65 169 :: 66 170 :: 66 171 :: 67 172 :: 67 173 :: 67 174 :: 68 175 :: 68 176 :: 69 177 :: 69 178 :: 69 179 :: 70 180 :: 70 181 :: 70 182 :: 71 183 :: 71 184 :: 72 185 :: 72 186 :: 72 187 :: 73 188 :: 73 189 :: 74 190 :: 74 191 :: 74 192 :: 75 193 :: 75 194 :: 76 195 :: 76 196 :: 76 197 :: 77 198 :: 77 199 :: 78 200 :: 78 201 :: 78 202 :: 79 203 :: 79 204 :: 80 205 :: 80 206 :: 80 207 :: 81 208 :: 81 209 :: 81 210 :: 82 211 :: 82 212 :: 83 213 :: 83 214 :: 83 215 :: 84 216 :: 84 217 :: 85 218 :: 85 219 :: 85 220 :: 86 221 :: 86 222 :: 87 223 :: 87 224 :: 87 225 :: 88 226 :: 88 227 :: 89 228 :: 89 229 :: 89 230 :: 90 231 :: 90 232 :: 90 233 :: 91 234 :: 91 235 :: 92 236 :: 92 237 :: 92 238 :: 93 239 :: 93 240 :: 94 241 :: 94 242 :: 94 243 :: 95 244 :: 95 245 :: 96 246 :: 96 247 :: 96 248 :: 97 249 :: 97 250 :: 98 251 :: 98 252 :: 98 253 :: 99 254 :: 99 255 :: 100

And if you'd prefer less zeros, or more 100s, then fudge it. (Add 0.5).


With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit

Replies are listed 'Best First'.
Re^2: Normalizing a range of numbers to a percentage
by Lotus1 (Vicar) on Mar 09, 2019 at 04:10 UTC

    I'm currently reading the book Higher Order Perl and I'm on the section where it covers memoization. The book says a single multiplication won't be improved on by memoization because of the overhead involved and because multiplication is already fast. I'm surprised that your lookup with ord() and substr() is faster than a single multiplication. The only difference I see is that my function is using a float constant and the ord() and substr() don't need to do float calculations.

    #!/usr/bin/env perl use warnings; use strict; use Benchmark 'cmpthese'; my $lookup = join '', map{ chr( $_ / 255 * 100 ) } 0 .. 255; my $const = 100 / 255; cmpthese(-2, { lookup => sub { my @output = map { ord( substr $lookup, $_, 1 )} 0 .. 255; }, calc => sub { my @output = map {$_ / 255 * 100} 0 .. 255; }, calc2 => sub { my @output = map {$_ * $const} 0 .. 255; }, }); my @output1 = map { ord( substr $lookup, $_, 1 )} 0 .. 5; my @output2 = map {$_ * $const} 0 .. 5; print "@output1\n"; print "@output2\n"; __END__ # Results on my machine (v5.22.1 built for MSWin32-x64-multi-thread): Rate calc calc2 lookup calc 12009/s -- -24% -31% calc2 15753/s 31% -- -9% lookup 17376/s 45% 10% -- 0 0 0 1 1 1 0 0.392156862745098 0.784313725490196 1.17647058823529 1.5686274509803 +9 1.96078431372549
      the ord() and substr() don't need to do float calculations.

      In this$_ * $const first the integer in $_ is promoted to a double (to match the type of $const), then the multiplication is done, and then (to make it useful for the OP though you aren't doing it here) the result needs to be converted (trunc'd) back to an integer. (If you added back that necessity, the difference would be more marked.)

      Runtime memoization and look up using a hash (per the Memoize module) would be much slower because each input integer needs to be be converted to a string, then that string must be hashed, then taken modulo the hash size (which must be looked up, then that table entry inspected, and (potentially) a linear search of an array performed, before the value is found.

      The lookup essential consists of a direct index and done.

      For the OPs purpose, an array lookup would probably be even quicker:

      #! perl -slw use strict; my @lookup = map{ int( $_ / 255 * 100 ) } 0 .. 255; print "$_ :: ", $lookup[ $_ ] for 0 .. 255;

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
      In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit

        Thanks for the explanation about the float conversions and hash memoization.

        The array lookup is quite a bit faster than the string index. I didn't see in the OP that the result had to be integers. The OP showed floats as the output. Edit: The array lookup method will work equally well with either floats or ints since the int() function is not in the part that does the lookup.

        #!/usr/bin/env perl use warnings; use strict; use Benchmark 'cmpthese'; my $lookup = join '', map{ chr( $_ / 255 * 100 ) } 0 .. 255; my @lookup = map{ int( $_ / 255 * 100 ) } 0 .. 255; my $const = 100 / 255; cmpthese(-2, { lookup => sub { my @output = map { ord( substr $lookup, $_, 1 )} 0 .. 255; }, calc => sub { my @output = map {$_ / 255 * 100} 0 .. 255; }, calc2 => sub { my @output = map {$_ * $const} 0 .. 255; }, arraylookup => sub { my @output = map { $lookup[ $_ ] } 0 .. 255;; }, }); my @output1 = map { ord( substr $lookup, $_, 1 )} 0 .. 5; my @output2 = map {$_ * $const} 0 .. 5; print "@output1\n"; print "@output2\n"; __END__ # Results on my machine (v5.22.1 built for MSWin32-x64-multi-thread): Rate calc calc2 lookup arraylookup calc 11990/s -- -25% -31% -47% calc2 15929/s 33% -- -9% -30% lookup 17496/s 46% 10% -- -23% arraylookup 22838/s 90% 43% 31% -- 0 0 0 1 1 1 0 0.392156862745098 0.784313725490196 1.17647058823529 1.5686274509803 +9 1.96078431372549

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1231047]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chilling in the Monastery: (7)
As of 2024-03-28 12:59 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found