[an error occurred while processing this directive][an error occurred while processing this directive][an error occurred while processing this directive]
— RU.COMPRESS
From : Eugene D. Shelwien 2:5020/400 18 Aug 01 00:40:58
To : All
Subj : cel500.png
From: "Eugene D. Shelwien" <shelwien@thermosyn.com>
e
|
V
bugin 644 cel500.png
MB5!.1PT*&@H````-24A$4@```H````'@!`,```#'_\'7````,%!,5$4`````
M`*@`J```J*BH``"H`*BH5`"HJ*A45%145/Q4_%14_/S\5%3\5/S\_%3\_/S]
M?%BS```IGTE$051XVNW=.X_K1MHG\+\3E4@VH9[$"N>K*7+;ZQFX3N+GO)X%
M6IO8\N6@&1F'@0%&8^,`"RCRV&_U`AWM>M$,%'D-#(C^"MK$IY,%-R@6[Y?B
M11*IEHR#EG5M_;HH5CW/4U4(+I<^EQF^W2*ZK%?Q-74%\X[79HV/2[U)[MJL
MY%K-,V;R8?(V+W/O:@Y@%;WQ"L`,J]5<W=3F(\WD"\6O]Y%ZDQG6UO9\`$V<
M`!"6N`#V`-QL-ANQV6PVF\W'F\$N7P[RW"_U'IX\[*?L71^G/]7'F\WFR\W'
M'W?ZH%\FS_IXL]EL/HKOD)+B3%J@=Y)#6`E.']#$R0`A+H#]`+$]`T#OE(#6
M]@+8"Q"6F#J@B9,"8BVV%\!>@"LU*)DFH.F='!"1X"0!O_%P>L!(<)*`'L8`
M*`?&4P0TU^,`!,1VDH#>:`!A;2<(:&(\@(@CA!,"],8$F(I27P`[`291ZJD`
MFA@78'P47P`[`JHX_U0`O=$!`F(['4`3(P2$M;T`]@*$M9T*H#=.0%AB&H`F
M1@H8I>M&#^B-%W`N)@!HXI2`^3QT_B)^&7UB_9]5=QTOL5[=`N.1\7A;H#G#
MB`_A.+8P7D!O[(!2<+2`)D8/"$N,#3"5__CG!``!,2[`5`+)G$T"$.("V`\0
M8CLB0"\!]*8".%>%K"<'--^]6YMQ6\1D`.-QW<D!@1C0]*8$"#$Z0&\]*4`I
M.")`$Q,#A/CU`M@+$-:O8P+TI@<(Z]=3`WK`6I82F9@@8#POY_2`IC=)0*T@
MZU$`/4P4$&(4@"8F"]C<I3X"H.E-&!!"G!S0PY0!92,\):")B0-"G!30G#Y@
M;9#U\(#>]`$A?KL`]@*$>#@=(,8"V)18K[V(WXZ?6/^F9L;Z*!/K]5UJ<?06
MF"]EF_(A7!UDO0#JYS_$!;`?8&F7^@+8`A!B>P'L!5A2R7H!1+OW$!?`GLN>
MB`M@SV5/5.G'"P;L>4G-\=2Z=`7TSA6PK>`Y`1(1!^,`\<QGI.C_"8"\G^1U
M^1P09QQ$("*`P?H7$0B,DWQ`_(_.'9!Q)@%9%C"B@`)A7-TBGY/^#\1AB7]Q
M!9B^[P4`@D.ULM1/!<LX5$OBR4-BG/@:X]96,@,$</4O]W<Y1\#H\&4<C*@.
M$%E`=9OD8YS]XU\)8/Q/-F[Y3/7SO``C/#`.2AW'\8>-%"@^G@%&!$;R-A9]
M]S$B_.-?\L8T(&@XP,*\N-&TP+:`/`)D)%LBD6QYUGTI((C4V0=G"(@$D*@(
M&.-FOQ_E(9Q\`\I#U[I_B!Y+J3,X$47GHDBP(Z`W>L"2DPB2ALBS@/%W7PJ0
M_4/\+YXYB:@NT``ML#BQ<'R`+(6D3BCR9W)Z*'9C4H`<XE^9^Q&UT^0U.@-Z
MHP0D2CJ^C*C0D5:`T0/E+9QQV9'FG")`H@@0_]BF.])G#]CV$G^/]1G7=0(T
M\5(`FP4[`7KG`:@76[@?'M#$^``WF\WF4((/%?=T3JS_U+`4_&D3Z\-<4@%5
M2Y5^#!50-8'S/X0S$>DH3#T4H#=:0*(D"L,H'<^20085%RR+JN1"+=F0?O5R
M`1T`WV&L@)DA6SK\21PLCO`5K%"FFLN)5"X7T![PW7JT@`2D%%+A+.)1A%E%
M4DH:8#U@Y0I<K0'?8=2`($:RQ:7B@7)H1YRB9J9::CIBDV!3>5;.NA\$T,3(
M`1G)H58F@\%DN(I8#I!3`5"A%M.:UOUO9P_(B*NQ:@&0&"=2AS!E6EL6L/P0
M!F"55;*V!?3&W0*CME4&J((&Z>^[]/=>TR$,8!XON-`9T,2D`#/?@>F32'4+
M1.4A#,Q+UF1M">B-&E!%[:+OO`Q@MAN3^P[,!%OK`(LK<)T5((AS%1-DE#K#
M$N4ZTKFS<"K27'L(EW2IVP&:&#?@H89RZ=LL<0'L!9B;'-8.T+L`2L&.@.]P
M`92"W0!-G"E@^\F&HA.@=P%,NM0=`$V,'3!=C9!+'O&XX"CJOJ0?V66Z:SRL
M.R=`5EZ`%M6U)/4R%`_JN@-"^&T!O0D`@I=%F2D>_T:`-``@Q/T9`LHA'%,C
M$06HRMY4-0(19[*DEW<'C);NT08T,7Y`XF"D1KVIT@X56%"@3(Z:HQ*D[E/^
M11M`#Y-H@:I`*%L2'K5&55BEP@X1:/<U$\3Y`&XVFXUJ9$14"JB^]V)`TD^.
M5\UUUTZL?]-BC_53)=9CP/1ABZBP+U6U2D@*UOJUP/2BM@TMT,,4#F$%&!W"
M\5F84`:HLGB]ECU)]EZK!337$P!497PL5Q_(2,;[U%E7=J09[WD6CCYF7+]5
M"^A-`;"D^WRHH5QZ+*SJM^H`35P`JQ/KUGT3H.E-#Y"5CXL/`1@)U@!ZF&`+
MQ-%:8&$[XSR@B2D!]IMPW0TPMYWQ!;##C/7T=L9Y0.\"V`R8+D?/`9JX`&H`
MXMO["V"_=6/B@OX<X#\O@'J`V2YU#&C.+H":@&IY]`M@]W5CQ+8`Z%T`6P#"
MVA;2Z1?`-H"PMMEDIG<!;`>HNM1)+NX"V`XPZE(GN;@+8$M`&:5.4DD7P+:`
M:TLXTN,;7`"[+7\GG"25=`'L``CQ_;0`RV<0#G'IN@"C@,K%30.0J"4,:3VD
MQU+P0DU-U]QC_;2)=18O$J@!$\TAR:\WF)F@"$37NR\!NHV2F>-O@<8L7H&C
MJD:PT+34VB_Y238#`EK_B8D`.K/LLDXZ@%1<;Y`*7Z34"_!==DPR&4"YC!TG
M$*-4O6#VGP3DF?4&XTK6J'ZP)Z"IPENC!S20!93+-\FIKTF]8/I?!)A;;Y!%
MR^/)J8JJ3*D/(-9B`H"&4P;(L@N*4?H^I%I@9K$RRJT_V`O0`[#&=O2`AH-:
MP*2D5Y7U)H#(K3>8%&+*_Q\`T-J.'-!PD`/D!<#X3*%:8@E@ZBR</*</H,K%
M6=LQ`[JNDQV))(=L=M6_S#]&<6-+'[(4%V*")UV:KH!Q+L[Z>;R`1G$HIP[5
M:#'9=+U@\B^"RJTWR-2"V^HLW`<PE4JRMB,%=,H`D>L']QS*=09,I9)F<9YD
M7("&\;W3`_"PP00S4]YF;4<)B$_JHS&MXPL#`GK9"M5"Z=$8`)T1A[/,?(VT
M]>OH`(TQ!U2]PC2';W\=&:#AC!@PFXN3U^(V.`[`3QQ,##`N(!P%H.&,.B?B
ME0$JP3$`&LZHDTJY9&9\K6Z"[%$!#6?<63FO`K!N@NPQ`0UGW&G-?"XN'4P0
M8P!\BW$#>C6`$*<'=$>>6#?K%Z$5IP9T,6U`B-,"N@?88[W[C/6RRT]-2\'?
MGS*Q_O5!]E@?M`5Z32N9QZOSGZ`%&LYJ[,5%9O-N#FHYV^,#R@[@N`$]G1UM
MQ`D`70>N,_[R-A-:NWJ)HP.Z<\.=0GV@IP=8&),<&M#M4&!YBHNI_4AQ/$`7
MAHN)`'IH(7@D0`.N@TZ`3/WDV?U%D*PU&*\IR)%:=YHJ-AU!<G_\),0IU$I`
M1J4IA\RB/0<$="IR(LV`"B&_OPB0680G?DC\(:DAQY+:^`5(KY)N5CZ^[/72
MB_8<#M"`#J";NSA(EGS/?.BD610!FSYP#6#T/U[MX_.7]*(]AP-T.@/&91S1
M_B*J;I"E=S9$:J4C2M8?C&L&4X>^>F[\^`P@Q0U0/2];CZA>._6728?YAP=T
MY347O0#3^XNHND%*E0\QRBZ'%V_7'-<,)A]8/5>]5K$TV$N^$WFN'C']VBFB
M.,P_.*`+UX7ANN@!2-G]15355J86FB6[6Y<"IFJNU7-+`9,&F%[<#$V`D>#P
M@$8T^)BC9PN,3@Z$J#8P#YC:C+X`F%MK-0.H*OS3[^,E+54;$-;#00"=AK1F
M)\`40GHUR^H6F#V79%L@D-Y^E\!X#`A59J<#".%/`I!1IDXP"YC[#F3I0[C8
M75&OE934R<>:F1995H]8"@AQ/SR@@8$`T_N+I.L&LYO4D]QCA**/3M'UJ+XP
M<ZBF7BO9"%`>MF9J6R'Y.JEZQ-1M!2+KUX$!H[K3OH"#732KO#QJ^6(QD?7K
M@("NZPXT6_/(EW=Z?&6`^/;7P0#=YK3F.`'UXC"990W38?Z?!P)TT1;0WB$8
M`Z#7_BF9,/]V"$##16O`G1W@#`!GLIB_#Z"1?/6W`+1'<@B;Z`D8CTDZ`SI=
M)MH$NY'$`W^DXOT-\<!\0+5J.H0FH-%EHDT``%B4)]:/&0]\EQVSU,8#*V>L
M?_M+C\3ZUV\[S%A_L]EL-IN[YR_Q+G?QCAL/_`)-@,V'\`P5TR&T6J#K=)FI
MM%L#6.PQ*P4\8CS02R.5ST\NC0?F(])6-T#7=;6"^WG``&L@W*,&\$CQ0"_=
M`./WTH@'YB/2H@N@JYNIS0$&'V$=AO(D4@IXM'B@R3-;NL>`6M&8;#QPVQ+0
M<#(QYS:``3Y"J$8BE2WP*/%`,_LX]5Y=`$MVAZ@#-!S#13=`&_@H7+<"/%@\
M\,?,@A7Q>W4!+-D=HA)0]IP[3K2Q=T`(?<"#Q@.]["&=>Z^F>&`N(EV83U(%
M^(FCQU8*&.R`\*-FP*/$`TUD#FEUOW8\,!>1MAZT``T'W0&#%1"B`?!H\4"S
M3=RP&3#:-K$!,)HKTPTPP`J+T82S3*_-WT(#4`K6`ZJY,IT`;6"%_6@`V[3V
MJGA@+B(M&@'?]I@G8N^`U6(T`56S\S.K`3/%;V6`G_28)V+_`3G^.&=`;&L!
M/W$Z`_X]V,VQ"$<4TO<.`IA:)*`(:#B=YXG8.V"^V(^H/M!4W1M>^WB->&`N
M4W=?!6BX3O>)-KL5,-^/J3Y0=J)9[1.Z`";[D^0!G1[S1&RL@$5)5L[/71Z.
M%0\TT^5M+3N2]8#Q_B0#`MH[K,+P61/P*/%`K[CR98OZP%I`-:C+`1K=)]H$
M.R`LSPM7`1XZ'FBJ5DR4^7K0K0^L!8P$,X"?N$Y70#N8`8M5"\`CQ`,]9$I\
M<X!=HC&9>ZT\8+1871?`8(<9%OM5RQ9XX'A@*6"K^L!:0(@LH!P`=P(,YL`,
M>_0!'#X>:*;_!.E3QE"`$&E`XVW7F4I!@#DP"]$9\##Q0$]UE]);CK>M#ZP%
MA$@!.EVG>@4`Y@A#M`8\;#SPBZ3#GLK2M:X/K*]0O8\!C:YSY0(`F"_JJK/R
M@+]M-IO#QP/-=G'#Z$$MEX+_]EXEPM]VF['^)I`_GYOV6#_^6-CK\+=HW0+Q
MZ3VB]?XZM4![!P!8A..K#^P0A]&,!V8CTI8`5C"<#H#!//(+]R,LL.R;-]`%
MG$/(Y>I:`P:0U5>+<)05JL<#A)"E?RT!@^C:8H\Q`IHX'J`KY\:V`PRB:XL]
M,,;YPEYVOC`OQ`M[Q0,S@`96UK8MH`T`81B&>W0$/&P\\%VF?]BB/K`]H.%@
M!6O;$G`'(-2MT@]SE_W!XX%FR737&L!>A[`#K`!KVPK0!K!`'\##Q@-_K-P)
MIT=]8#F@$7U@ZUX?T`YV`/:]`0\6#S3STUTITUGN6A]8"ABO]V?=/V@!!G_(
MWE^(?H"'C`?F`0O560-%8X#4>G_1HE%-@($<?2Q"H'\+/%0\\$>J!^Q:'U@$
M=#,1:;%M!`QRG9?A``>,!WZ1.O,4XX%]Z@/S]QJYG(BU;0"TY;7%'H,"#AP/
M_#$W7S@3#^Q7'YB[U\DGE:QM/>`.P%QU_OJ?A0\4#_PQ-U\X&P_L5Q^8N=<M
MIC6MG^L``T!F?OL#'C`>:+:+&U8\2`/0+<D+P[JO`K0#.?7HN37@D<?"7O>_
M11M`.?VC6!MCW3^4`MI1Z"4<^WSA=YV?V2H>:)17)F"&3\5O)8"1WW[T$Z[-
M@5ZG"="I!%RMQ$,1\`\`\MMKY(#><0`-U`#.A;\J1)^A)LY<``&LG5I`"-_W
M?3\]_IC'9]^!`%O&`^.O)X;::(Q9OGX@KXT?M@UGN?@:]8`0T<5_``(Y_M@/
M"]@R'I@.!]8"ELP7'KH^,%IULA90'<)"B/\A`B<:_'8$%+G+MD,\,`-8>P27
MK1\X;'V@T6Z^L`TA1/B,X0!_V6PVNO%`0G7\+L,@GVN6KA_8HCY0)['^MMV,
M]3\VF[M0W/N_==YCO:P%ZL<#DYTX*15%R&\W'CWWB_+E[P:M#S30I@7:@>S]
M64*((0]A_7B@)J!\KE<*.&Q]H-,",(ABSQ)&&@X$J!T/[`!(-?'`_O6!+0#M
M>1P]B+`2@:$!*^.!;0#-TO4#AZP/-!P#^H"[BN"I)83P_[<[&&!M/%"%N]1]
M26PPNQ8"XV3^6+I^X)#U@8Z<R*H'&&".1;@O_^93&CT`]>*!4=%DG)&+]APN
M`60_EJ\?.&!]H%%6F5`.&`2!G'?4D"$60G0!/$0LT$3[[E[+>*"C#1@M.[1'
M$V#<&$\^%FXS-;AC/-"`+N#?I5]C]SGU'2A.#=@[C-`<#W1T`>V=C%ZUFNHE
M3@MH#OMR98!?0P_0#G8K&;UJ-]E0G#N@HPGX!^2R!ZWG"XM3`GH'!W37>H!_
MGP.KDMZ?1C!!;$\6#S13\;VZ>&#W^D!#;_&Q(-C-$5;U_IJ&<M8OIXH'>KFN
MR.#U@8:C!6ACM9HONB\Z86V+@$'NLCM$/+`&<)#Z0,/16\'R=ZQ6\WV/94^L
MK1;@T/'`+^KV$^E?'RB7D-4`M&=8K<)>.UQ;][J`0\8#OZC;3Z1W?:"KNPRR
MO9OAL[#G'NMR>\HFP('C@3_6[2?2MS[0T%V(V]YAMMCWW:0>GXH'O18X7#S0
MK-M/I'=]X/>:@'_?`8O]JC?@"F+;&K!?/-"KVT^D;WV@H;F6OKU#&/Z)(0!A
M;=L`]HX'FK7[B?2M#W2T`(-@MUKTWV-=O9[UL\99>+!XH%>[GTC/^L"OM;;#
ML#'':C\<(#Y]J`4<-!YHMGALZWB@X6@![C!'B`$!/XHV.C[&6-@;ZN]1!NAH
M[6@3`/-P-2A@M-9CQ1[K8XS#,.+%&>NNSA[K;X+-9A/VWF,]GU@7OQQGQKIW
MB!>-?FE79U>O8`=@T7N/]6)$VMKB&!LT>]#>I%YO@^;DF@L-P&`%+,+]`0!A
M/1P!T,3!`%UH``98`?O^F]27)I7$PY0!76@`!BK\?!!`B(>#`WJ'`C2@`1A`
MA9\/`PAQ:$`3AP)T-`"#.:)%8P\$Z-\?&M`[%*"!9L!@-0?"8EIS,$#?.O1W
MH(D#`:K5W.L`;:SF6.!P@+ZU/32@=QC`U`:6-8`[K.)5=P\`>.7+";03!'2U
M)AL&P&?A'H<!_'3[G2S=.BR@B4,`&EJ3#0,`^WZ;U-<`_FR)NF#"J`'S&;AR
MP`#`8G4H0,M/PED'!(RWUA@2T'"@`1@`BW!_*$#KOB&Q/@S@N]K'=03,U:!6
M`$;%]P<"?-SB&(#F_!"`#C0`;<CB^X,`^H];3!?0@`;@FUTT^?(`@):LX3T&
MH'<(0$<#,-BIN6_#`XIB:4?]6E>ZER*@B0,`NF@&#+!6Q<\#`UX]B@>T`-3(
M]%`UH'<`0`/-@`&PWN,0@)^*^]]0#<A2%0/R!IY4$5#\&.0?<T3`KYUF0!O`
M'0X`Z(MM>85J'6"<WZVHIJH!-#$X8!Q`J`&T=RI^-3"@)?Q5`R#C/']X,@Z>
MAJ+"\4Y5@-[P@,ZZ"="6YX_U\(!B6SG-(:FVDH=J7`=(`./1X:O6!`3D8XAX
MNE:P^+XF!@<TT`BXD_WGP0$MX4,/,/K>4S4P+,)+U@1$U"PI5UUZ!$!'"W"/
MP0$M<>_/6@"FJK`8SP+&1=_J_ZN69]_\<]/]\F7)-9E#;YBQ_F:SN>NPQWK#
M1=S[O]7-6"\%).)Q?7>J94*=1$A5ZU>T0',V=`MT*Y\1M\!@%\U^&[(%6HV3
M#<M;(%``3)V%DX.W`M`;&-!PT02H9N\/"BC$/5H#(JE$S0(FMQ.0JU8]+*#A
MH`G0WJWCV9>#`0K?ASY@5+<7UP&J^N_H]J1JGI*S<`6@B4$!#0=-@/8.Z[C_
M-Q#@U6-C6A.8@8AHZ*&<-RA@*@-7!6COXL6OA@'T'V382@.P=NFE;L$$$T,"
ME@_@,H#V#EBLAP.\\B%S;CJ`(,+`@-Z@@`Z:`.T=@/UP@.(!0@C=12>&#V>9
M&!+06#<!VK\#"#$8H/507$&FY>)C_0*JWJ"`3A.@O9MA$6(P0'^KD=8\).`[
M#`EHH`GP=\P6>PP">.7[OB]P6D`30P(:3A-@,,N//SH#7CW(D<=I`7\:$M!U
MT``88+;X$\,`"D#\@C,"K!O`*;\U%OO9,("/$&*@%2Q[`)KSP0`-9]8$&.`N
M_!,#`/J^+T\>YP3H-%7IVP$6>\P&`/1A)>MDG1;0&PS0:*K2#W;`?CT$X&.R
MXM6I`4T,!NC4`]I!U'WN#7CUN.U<9#YB0!>U@'+Y)O0']/W'+<8#Z`T$*$_`
MU8#*KS>@#Y7O'06@B6$`#6==#ZC\>@'ZN(K66!P-H#<0H--0I1\HOSZ`5_/R
M8=L)`9-DYF$!@W4</^T!^#`7&!F@-PB@X1CU5?H!UO'F`1T!?=]_%`(C`TQ-
M+.P#^'U<1EX.:",I8.L(Z$?;10X!6#9CO>/EITUI2KSMY?OZ5WGSQV9S]ZRS
MQWIE8OTQ6O*^UXSUNCW6.[9`;Y`6:#1,<]BEZZ\ZM,"K.%LT']DAG)Z9V0/0
MJ0<,\N'[EH!_^\W:KLX9T*VOT@^B\4='0-\7JLQY?(#>$(!N;8VT':CQ1S=`
M'V+8"==#`F:FMG8%=%$'&.?/.P+Z,VMUWH`N:@%WR?BC`^"5;XGMB`&]WH"&
MNZX!#!#$>Q]U`?S;0]/FI*<%S,[,[`)H.'45J@&"=/>Y->#50^/VN"<%C-?*
M[P[HU!58V@#N]N@,Z#]H;-!\2D`/AP7<I3=?:`UXY0O1F)4[*:")WH`&:@!M
M8+%?=P7T'\6!UHT9#V!J*>,20'L'[-$-\&^^$%N,'?"GGH!&,:F4NA;U_SH!
M7CU8C5FY<P=4_><.@#X>5ML)`)KSGH!.#:"MYO^V![S"8YPP'S6@UP_0=5$-
M^&97F+Z@#?B;6OM^Y(`F>@%^7<B)I*_MU-YE[0']>/>%D0-Z_0"=:L``P7I?
M'[^I!+SRQ2^8!*")7H#NNA+01I!,GVX'>.4_B(,MO#,PH-<+T*TIL*P>?S0`
M^OX#!%X$H%M3H5HS_J@'O)+E:A,!+)L;K`UHH!K0_AV+/;H`/EC;RJ32^`"]
M'H"%E;`RXX\PW*,+H"_])@+X#MT!BRMAI<<?B\82WS)`WX]G:1T%L&]B_9N&
M6>>UE[?5SWWSQ^;Y2[V<=^9AWVV^%8/.6#]T8MU#]Q9HE+:L&0`$.X3HT@(?
MK&UU5FZ,AW`?0*<2,%@C1!=`W]IB4H`5Z_1J`;JH`K2Q#M$!\$J(+5X,H($J
M0/LI#-$!,"J8G!2@UQFP<B+US-[MM79SR`%>J8+3*0%6+3/;#%BQ$A8`>[=`
M!\#O'@6F!^AU!30JYP';O\?+-[4!O(J7.)@2H(FN@)736.U=,ONW!>!CLL3!
ME`"]KH!N%4>PD[-7VP%>/6Z'F_)_1$`3'0$K%W(*@/VL)>"5[S]N\:(`J^8!
M!P$RXP\MP*N'F=ABFH`_=0,T*CALW(4AV@+^3R$JDTHC!S3GW0"=B@\L3Q\M
M`7V!V40!3:\;H%O!$431YU:`OIA-%M!#)\"*$;`=+/9H"WCE"TP6T$07P#B'
MGN\^[[!ONS&?)818OS!``Q4<.RS0$O!Q"V#"@%X7P+<5@$$8[ML!1D.W%P9H
M5!07!8NRK%P=H!KZ3A>P?J'C<D##*0<,L&\%Z#]<J:'O=`&]#H!.>6U,$*\^
MJ0?HXSM1G94[8T"CO#8F6(=H`^@#`I,'--$>T"D#M(/\ZJ?U@%<^++&>/J#7
M%M!P790`VKO"ZJ>U@/X#Q!9C`NR66/]&>SGWVASZ9O-'9O9YS5+PF\UFL_']
M5-J\^XSU$236/;1L@48Q*R?/'\7RH>H6Z,M]*8#)'\(FV@(ZI8!!=ON*!L#O
M($1-5FY*@%Y;0!=E@-)/&_!1U&7EI@1HHB6@@3+`H'SUTRK`QRW.!=!K"9CD
M@%.`0;`OG[Y0#GCUN%V?"Z")=H#NVY+'!>M]8?>%&D"_/.\V34"O':!;]CB[
MNOJ^!%!DBX9>%J!;^KA==?5]$5`\U"25I@=HH@V@4?JXH*;ZO@!H/>"L`']J
M`V@X)?<&0;C7WT]$+6Y_+H!FBTWJH_-O[EX;>VAO1A`7K;U(P*C_DKMWMX`V
M8'J5OS,!]%H`.B7WVE'\60>PNO,R74`3^H!&R;WVKF3UH7)`N2W/N0%Z^H#Q
M`"1UK[TK6WVH%-"78]^7"U@V@)OO2E<?*@/TQ79VAH`FM`%+!W!)_[D!\%%T
MFB<R>D!/&]`MN3>8[Z$%*-.69PCX#KJ`1MGX(Y4_J@7T14U6;LJ`IN[[S@RG
M>&^`4&LA[BM?X$P!/6U`)W^;'02+4&L=:?]1X$P!3>WW=0NW[1#NM5;Q]9.*
MYY<+:!222K;\^FL$%$*TK=*?$*"G^;YR.ZG,;;L0&H#?";]UD?F$$NO?:&:A
MOWY;R'4'H<X3OWML2*QKS%@?<V+=T_MS&4XA*Q>$95FY_+6HYN]L#V%3\]V<
M?%+)5O63]8"/8KL^:T!/[]W<?%+)3N4_J@&3Z5KG"FCJO9N13RK93^$SF@"O
M2CLO+Q'0>)L##)XT%F"\>A1U6;GS`/1TWDU50<>``?;-@*F*YQ<.&(^`%:`,
M'S0`?BMJLW)G`JB3#3:<7$ZD,/XH`\S/-3]/0%,G&^SD<B)V8?Q1!!1"O\!R
MRH`:N3@Y#2X%&$1^U8!R4]J7`*B1BW/S(?U@$:(!\/X!+P2P.95DY$/Z05GW
M.0-X]5B;E7MA@$X.,,`SZ@'C[<E>`*")MH"9\'W9M629Q)<`V)R+RU5!!PAK
MGW'E5]>\G"&@"?V5L&3]U2*L?8;_*/3+VUX"8*X*VG[ZL^X9#34O9PCHH6DA
MI\QMP=.^9M&)JZ::E_,#;,H&&]G;@L6^9M6.JX?HY/&"`#W=$;`,WR_V-:MV
M7#V(6HZ7".AD;K,7>]0`/C04[)XC8$,VV,C<9C_M40/XV%2P>XZ`7OU[..G;
M[*=G5`)&&WR\-,#ZJ:W12D2J?.AI7SWEWW\46K4QYY98KTVGN[GT^7-U2OQ1
M=UOS<TNL>]H#N"!$Y83K:.0[?WF'<&TZ/3.`"T)4`JK9,B\/,+=K:_::FQE_
MA*@$C&<;O3S`NER<D1E_A*@"])/96B\.L"X7EUX)*U\^E`!:]^G(U8L#K,G%
M9:J@8[\"X'VF\W(!+!L!VT'BEP>T'H`7#&AJC8!WQ?"]`K2V>-&`GLX(V"X)
MWT>`4>3JQ0)69X/=U`CX*:R8;"A$;5;N)0.FD^A!V?O.`$O4_E8O`M#32*('
M^W+`Q^W\Q0.:S3E@.R@O'[IZW.("Z#6&$.RG\O(A_W&+D0%2%I`146=`1KT`
M4SE@&7XNYMW$SQ@9X"(/R/NT0#W`BFRPD>2`@WUIWDV(UIO4'QSP]@2`7M,(
M."@M'[($T`OP%2?0>PZBSSL!LCUQ$('QY6L073-BC,^Q!..O^&IYR]DU<4:D
M#;C@]#GC=`VZY:!KT@1\US0"#O9E[R;[SCT`V>>,,[XFQO&J6PM\#P(8!ZUN
M&<<2Q(CF=,-!,[JYGA.6G!AG7+L%$EZ!^)+Q.3%^P_4`S:81<+`O>3=+=-BD
M_A"`1"E`(IICF0($`:!V@&@)6)J+2ZV$%92,/RRQQ3"`]+X?(.-1"R1:@@BT
M8%$+7-X2ED`'P%4KP/)<7#R`LX.2Z0MB"V"H%HAA`#E66<#K.;`$V$D`XQ1F
MU/_+=EY$=4C_Z(=P"G"9!R0L@?;?@2T!RW)Q\5K0]E/QWFS:J-=9F'BOLS#>
M$P=Q`L5G8>(+K`@4G867'&AQ%IX3?<Z(K^19>,G!Z,,FP+)<G.I`SY5?ZMZK
M7-JH5S^0\7[]P/?13U+]0(J&<M1Q*$?I?N`-AT9B_:>:#='?/!7N\A]%ISW6
MRRYW?]X]]TNLJ]GQH4JLA^IGQ\1ZF"36[YX_>]9)K)<D,UT5OW\JC#\>4S4O
M0QS"_48B[#V7/^E:MD!&''.LP.CS3BUP03QI@;34"2:43&U5.>#=HC#^$-N.
M>ZR?;S3&*[R*6@G+7N3''Y8`+H!9P&^*(V"5_WC*CS_$%A?`1D`U`K:?]ME7
M?A3E[UL&R"BYC1'6(.+#`LK78WM&U`28_F7T`5]K`GKY5W'4](7,*UOW\?X`
M6BTP_3L3UHR#A@5D$2!%UX8&9)J`YCKW*JX:?V1?.?'K!"AO&1XPN58#2(<$
M]'*`1OGXX['MIE1$?$[$9:0$[],?N#\@>T^0AR[MU5]&`A(CL%N^(D8SMES.
MB2VU`8D1:$'X@`@WQ!?$V9*#Z*,HZ,C+`,U<C72TF+:M^G_1>]2FC2I:("TX
MB'&0!*0!3R*T9IQQQ@&V5W\9"<@XXYC3BG'V.:UN7C.ZX8SK`3+..+ME_!48
M7X*_)O`5`>Q#.>`&E0%Z.4`Y@@MR^0^Q12_`Y&,>`)"0`V2W*4#>$O!U&I!6
M!"(%6'8(F[D27Q<`%D&8'G\(6730!Y#6ZF,.#ZC^,@D@J1:X7+YF?`5"&T`@
M#0C&90NL.(2]+*`<@?R_S"L+O^F[5Z<%#GL63@-FS\(9P-5JSO@*1,3[`Z+L
M$#8SOU\T`K9WZ5=^?$`W0)[Y#CP`(#4#WKQF?)7K$N@#`OPZ!BS_#O0ROY^A
M_-*SC;;H!,AX<A9FA/>,B(8]"Q,CV0^,NN@1(!'8+;MF%)V%:84HP-`,2`2Z
M1706IEOBN`:(_Z7R$#8SOY_,`=M/Z5=^_`7=`(\SE&.<[;-#.<9E/Y#Q]D.Y
MZ+E1/Y`TAG)>YO=SBN,/L9V_4,"E#J"9^?U<S&$'Z?&'$/I+P9\HF$"4"R80
M24"B]H#1<S$#<$.\&=!+_RXN,+?3JP]90C>(\6*C,2E`PP4P?TI-7Z@IV+T`
M2D`S^0WD`,Y.NL^6`"Z`^H#2[P]UYW]-%JF;$T=3>=.Q`-E[S#`#`:0/R):R
MEU/XM1C7K<ZJ2FMZ\6_@ROZ?>A5?O$Y>CW'(X.4(6J`"9&T`Y8FY!R"K`#3C
MW\``$`;Q^$,(E@-DHP+,G'LU#F'J>0@W`AH.8`=)YP5@MS+<QHCFC#,^AD.8
MB.,]?8X9JSZ$B2W!B..6+<'H%98WMU%N//MK$2.`.!9$I8!)?>`2(/J0O6=1
M/#"=6/\IE4-_\T=\N]AL-G?/=\_A1OZ[>[Y[+FZ-/E1B77O&^MWS)MR$F_^[
M^7(3)MGTW(QUF0@/-W?/GSV'F__V_-E?[YXW?PU+7DQ^IK#\@WVY"9__>O>\
M"3>;SY[OGN\^O`O#\.YY$V82Z_\EG0..N\_R[,M>,TY@G*)K(VB!3,:U7]6>
M1!B_X8P("W[#"1_PF^L%1\EWH#JJ;JL.X:@^$+3DC+,/V9X7@PDJEV2LX_+G
MN16=?3.`Q"<%2(@`Z16_N9ZC(^"*T2W):&P$2)0!_&:E<ICKN'P\[KQ,N07&
M@)BA%R"/6G32`C,G$6^E<L#KR.]*Q*_";M.`HSB)2$#>!O`#?G,]![NN`U3A
M[%+`J`72AVQ?B`>^D_%`PXF/7S\U59H6R5F8..,-::UCG879GCZ/^H'[<D!:
M@A'C"XK.PLLYL"QV8Q@10%1]%H[K`Z\)Q/_"]OEXH!D%5&._1]W(R\F'<J]`
ME4,Y&7X&%KQ^*%?:[EH-Y3P)Z,(.]NLX[GP!U`4T933&@/VTQSJ.VT\"\`/B
ME8!$4BL_4ZG0D:9!``W'?@*PCL^^DP`<133&`]8K2+_4]@H70$U`$\!ZY4J_
MU/8*%\!&P/<<`/-`?/T)G@!D5B@^,\`/:)D"O*4A`+_B`$P.QK]V@FAKLK,%
M?!6-1*+!%08#]`#V'TX@9[N=,>`L#4C#',)?$<$D#N.'8!6MDS-&0&*$KXA`
M8)S1>PU`8K1:$,>2$1A>TQ+@,[I>SADM9=W?+6\#R*Z)+SCQ%1''7_A[QHG+
M%LBXR;CQP^ZKZ\AOC(",,_X>:CS^%6\&9)Q=ST&XX8P3NZ4E,3;#ZN8UX88S
M8IQ>M_L.7(+FQ.F&@]B'<BBG`#WV'S_\'_Y5R?8*XP-DC)/6(<PXNUY0&I"S
M&;^.`#GC-%?#CQ:`*`/\`L8/3TR(:XP<D(@3TSV$&6?7MZH%\@4M&>@#NKYY
M3;3DC`/=`%$$-#W\\&0)_M7H`0$08QS:AW`,R%ZS)0.]8LOE:\(*0P+2C]Q]
M$EM&$P!DG(A:?`?>IK\#$\`;68C9Y3NP"/C>)#<0!&+O5R,'_(JBD*[>(4RT
M6A#C-T1@?$Y+3NP#OKJ19V$"T.XLC"7Q!7'(LS#MY3RA&=;>#X%0B?7Q`K;O
M!S(N^X$W7'::5P!F[+K[4&Z9[@>J2O89UO_]WP(7P':`T2$,8(8W_XX[+^<%
M2"0!EP2`;B5@9BS<#I`M>=("_T)K1AS`#/_6WV.]4W+\<(GU<2P%__\!-ZCL
1?F4_4%,`````245.1*Y"8((`
`
end
--- ifmail v.2.15dev5
* Origin: Shadow Research Center (2:5020/400)
— RU.COMPRESS
From : Eugene D. Shelwien 2:5020/400 18 Aug 01 00:40:59
To : All
Subj : su_vs_sh.png
From: "Eugene D. Shelwien" <shelwien@thermosyn.com>
e
|
V
bugin 644 su_vs_sh.png
MB5!.1PT*&@H````-24A$4@```H````'@!`,```#'_\'7````,%!,5$4`````
M`*@`J```J*BH``"H`*BH5`"HJ*A45%145/Q4_%14_/S\5%3\5/S\_%3\_/S]
M?%BS```@ATE$051XVNV=NX[C1K>%UR0JBB#`=F+]V;R:(G?;,#`UB?=DK9/,
MSVDT($7&$'#`R&@PF5=@Y#-!/8Q.XI8!`W6"NK!(45*1NK0N)6!L#EM]^V87
M:Z^U=U5!AM<^KQ%F`OHU-1>8V:O(\^JA]V<XWZ1Y-:KOC;:]SUR-W,]H7DTC
M^VM%F`(883J-[&\:^?_0(_6%[-?[R7R3$680`>!^`"&J`'`O@$A$`+@70$`$
M@/L!A`@`]P,($0#N!Q!"!(!#`&;V]2"^9T-?#]G!7I\[+[>]__/6G^K!^<OG
M[.%AT$_[N?ZLARS+LI_L!YQ_N"D2H3*:$(%#AK#Z2"("P+T``D*'80`X$""`
M9Q$`[@5P!J'GY`!P($`SE`/`X0`!.RL'@`,!`E%B$`:`PP#:,`P`=RN1C7GX
ML]@E4H(2V65G)<)JY1"!_89P?:49!H!#`>K<)@#<`Z#U_P/`P0`1V<=A`#@,
MH'4<`L#!`-50#@#W`6AGY0!P*$!$MI`2E,A@-2&$"$ID>`2:H?P]#.']"NN_
MB@!PS\*ZG^T5`&[6PEZV5P"XU4Q(>A0!`L!.*9>(`!#[%=:W^X8!H(\?Z%42
M#0"WN3$>TTE0(EMK(KNK*$&)[/(#.XW7,(3[U$1LFU(`B*%UX40$@'L!5/-)
M`+@'0+>B'``.`0@@LCU*`>`P@+;/*P#$X,Z$I/DT#`#1NZR9N,YU4"*#NK.>
M15`B>S87V>PZ#.'!G0DJNPX`]VCM$$($@-BO-Z9S;6,`V*>H9!5*`#BXM:.]
MMC$`[%O63-:?A@%@WZJ<L[8Q`!Q46'^V"Z*"$AGZ<A1*4"*](W"F4\,J#&'L
MU1NC/*\`<#!`8):(*@#<!Z!M\KI$@*=X^1BJ^1\B`-P'(.S&%Q<#D(@X&`>(
M=_[:Y%YWO(5X\SWMS^D-$)@EXH(`,LX40+8;8-=;V!$`VD:YRP`(WJ#C4M)L
M=P%LW^_^M^A95!+B,I0(XWKX,@Y&9'][<VU@$",PSC@CQHD1&'%UCTA!)*K_
M<!W9.L('=F>I92CGKD28A@?&04[LV&L]'ADQSCCC!`(C-7#5'<9!ZF_F#Z@)
M<%`$*M^PNH`AO`E@\Z+&9R*Q#;#^HR[T)YK_#ZL+)^("GH$U0*)U@*Q^1#+B
M&B!JD'H2:@!47TNQ)$-P8&%=I347`M`!1JT90EV2-\`#1:`6RA<#L)XUZFMR
M`.IG8!N@_IM]!NJ/J2^QSS-P@_%Z7HFT_H^>0>W(M==D`XGTLX](3RI$(`W0
MG84/#Q#/G66H2Y%R]7.LF29OR+WWDW*;M?!Z&>H2`=+;`51NS:6;"<P1Q$2G
M!0C=*'=62N04/LQ!UXFXRU#.IR9R:,/JN"N5='9]?7[@Z59KZC+460`D<FP5
M:OE4M4_8:1>V9I&3+G=-Q!GY@18&-9Q2DQIOG''I#0$"0OQU#HDTP!LYGK6S
M.&IEL<$+?%N`L_$?U5D`!#%2$>?X@4K:$2<=9B927<>FX1WB+?9,^$.<!4!&
MQA!H/@.)$2?6`LAI#:"!^A9+_NM"Z%L!9.0X*BV`Q#B1&<+4TL@MY^:-`"(1
M;QV!.K:Z`'+&R3C+)O!HO4CR=D-8%4*KMU0B:P`;ST!W$MD<@4"/NL<1UHET
MK4`Y74V$.P!9$V`SC6D]`QVS]2V?@>K*MJV_12+-N?$$&;&F4]!(I%NSL.,Z
MO_$0[JPD!RG7$R!:*U`"P/X`X:Y`"0`'`:Q7H`2``P$:Z__L`9[S+KZ)$"(`
MW`,@`(CO.&%_8'<AB=N&(YV^N.\\^WVD$R&J4RB1NF[;`JAEF\G[R(JZ=HWC
M?'?Q?3;5D^,J$?`NEYFL_M4`B1JH+V,G\T2=KG5<1]KI\R.GM<.TO=G.!-)=
M"<0O!Z"948X)D#@8&=5+SA"FIMYE2C7K%J3+VDM?+>(Y7@2JIJ$F0-N>:IJL
M4'=B71S`:2+$7T?LSE*^`'4"M"V^J)LI+P\@@$0<&:`[;`$8>G86=IK9+A+@
M2!63CPA0#V$["Q.Z`)HJWF6>)Y(((800A^X/5/U^[?Y`Y?>965<ETHQ?W"S<
ME4@KC-41I)Q_N]45G&B3B$T[1`[OSO(#>#TG&_KL.-RG.XMM6#!WG1&H7DG'
M067!C>GI!PIA)I>A`*<=/]_-'=`\S@W%`'`?1[H1C@'@<#_0@!15`+B?&Y.(
M`'!/.\ODBP'@4#/A5_5,#`#W<6.T,7M^>V==T"Z^0ISGWEF7$8$`IA!"A"&\
MIQ]H^SD#P(%VEE'/`>`>?J`00@2`^QFJ>0!X0$<Z``P`WP)@SS7[@^S6ZP;8
M;\V^7\V$>JQ0O_3S1)CI#?0!J=>0M/<;;"Q0!/3UC42@V8UC4X_@6FB9?6#:
MBVQN%:#3"^@'D-;W&Z2U!RG=)$"H78@(Q,CI%VSM2$1ZMS=GOT';R:K[!V\6
M($&U;=A-%M'^HP&V]AMD!!V6]:Y:MPN0F0ZL>IFA_1B<"&QL5D:M_0<#0&[Z
M!<W0M;V#U+7?8-V(J?Y^FP#Y&D`[4YA([`#HS,+UY]P@P'K(N@!;ST#F;$KK
M#%FRC9C@=4IS:U+.#%6X^P.V9V$-JK7?(-/7=A9F_':42)<6WIY2^TFYFS83
M#N,OW##`WOY"`!CLK&"H!H"7"+`,`/<!&)<A`O<!&!=A".\#,"X0NK/V4"+E
M2^C.VB<"2P"`#$-X(,!R!@`R/`.'`2Q+S`#(,(D,`QBK65B&1'H@P`(_04H9
ME,A`@"7PDPQ2;BC`7TH`'X(6'@HP+@#@[P!P(,"XF`)(PSJ1@4KDZ25[R++Y
M:L<ZD1._+B<"XP*80BYW^8$!8#?`^`7`![G;4"55HM2],KQ5+*FW1G%V2`:8
M1S6*4==[+@5@641`NO1PI&UOC-HEIG$?MH&H=2PN>0#$)0,L@0A8MBW]O/5:
MN`!UIY;SZS>V@EH#N/-%ESN$XRD006(H0+LAO.V'Z>H=U%O)VQ&[WF<(>R:Q
M17\1`.-B"D@)/X"FS8.Q=8"D'F7NN9KF/.'F,9#N7EM.?R'C]GS."P(8%Y@B
M[:K*=4<@X!Z_;`&J,X(`1CT!-C<VNSR`*G]9[@W0.;/:"Z!^!%PXP+*(_U3Y
MBP_`KUF6=0&LD=4P=D>@:9OK!G@92J3,GEX^9YE<=7=G[8Y`L_\G7X.ACL<U
M`)VC<)WN_<8SD%U@!)9J$I&;.A.Z`)K]!!N)-(,Z=\1.,@J(F675S$(-@/8,
M=K>_T+EW`0!CE?V-)/H`W/O5+R<\8X!QH:XD>O7&G.)U$4,X+@"D4LK1^0%T
MMBD\6X!E`4`N^W=G!3<&<5F6)8!4#FEO"P#C0EVE2P2``P#&A;I2WE5_@`?S
M`QE=HA]8EGKN5?P\=O%MUS4.YP?25C_P/)5(:2[FJYWK1/+/*%NOXJ!^(%V>
M'UCJ*RF7G75A-P)SC+P!#O4#-[WG3/W`6/-+I4>+;XY-``_F!Q+6UAN?M18N
M7W3X+3U:?'-L!'@P/Y!0KSD^?X!EB4@I#^QN\<US]`?8UP^$66=\`0#CL@00
MP3SZM@,<YV86]@4XS`\DK*UX/U>`A;J2VPKK]NO]O)CY`]S##V2M9^`9^X&Q
M?OC!!^#X=VP%>#@_T/4"S]L/+`!(*7WZ`\?YXJ?M`&_0#RR5;^#58+G8J41.
MY0>>C1)Y*ANZ8_LZD2^[=_&]-3\P?@&PW-&98"(P7P0WI@VPB(`47@#'><-,
M$&<!$&\,,$9D`G`7P/'"E7*)0``(H$!DTY?M`,>+QBZ^U2'\0&O','+,P=I,
MV/(07+>_W@1@N3%]7@/XU9%RV_:1[N,'-ORL%A#:VC!X)@#+S>ES&V#N;L1M
M)A'1>E4]_<!M0'8"?/LA')<`I%>#Y<]Y+>5^K;>"]P78]@/7_3VJ]Q-DM(;(
MJU?PU`#CL@!2Z=5@F2\<+?P7M@/T\@/KHW*MMK7[">H(I68T[NP5/#'`LM"%
M(P^`>:U$DBKY:3/`[QNZL];]0&`C0*5UN4MP5Z_@&RB1LE7XV/9-<J<F\OWY
MNZ-$NH>PCQ^X`:`^AYW5YXN;F7UWK^!)([",8`3(S@C,'2V<-)6(+\!U/W!3
M!*)QH#,:1;LS`E@BLO/O5H#C/,\=*2>JO@`W^8&M9R!SA[`#L$^OX.D`EB40
M*0-F&\!QGN<+5\HE:V<J=0'T\P,)Q%U_3U_KO0=M(MVG5_!$`%7;2[-PV7VU
M:$FYI((/P`/[5OYO.@W`4MW:G?UAW%(B2766O3$X[1`NU2V/[&^\:`),ON,\
M`5IO\!0`2V"JELSL`JCY68"B.M/NK%-*N5_*"&;#B&T`QTZWLP8HSK:][80`
MXV(:04YW3!UYGB_:2D2(J7]WUENP.XD2>7IY>,CDCNZL+WG'-WGV.&/]R'Z@
M3Z_@D2.P_!/3J=S1G94ONK1PTJO!\CA^(+VQ'QB7&.&#W'5$^-J]1%0851L!
MRM9K>30_T*-7\)@`?RF`4;K<W%PTSO,\_[H&55118L[%W0?@(?S`G;V"1P2H
MEGPL-_?&C!==49F(72V^G0"/X@=Z]`H>#V!93`'Y]Y;FHD575(H*@P`>Q0_T
MZ!4\%L"XC#!-Y;;>F'''/5WX."#`??Q`GU[!(P$L"T3XL-S6&S/NF'N3"@<$
MN+\?Z-$K>!R`)8`H76(+P/&B.74DKJ^R+\`#^8$^O8)'`5@JYVJZ!:#EIRQ3
M))7_3N9M@*LLRX[C!V[O%3R6$GDJLRR3.[JSOKI_><[$]Q[GB71%X/7X@:6:
M?;>W=N1Y(]JJS9T)YVHF'&T(QP"FD-M;.W(7ELJ9+PW@T?S`%P!3N;VU8US#
M$D)\W];:<7-VUB\13-UH(\#Q0E^IV`O'83A7<1$A74ZW`=2N:03SZ`L`ZZNX
MF$;I<FMO3.ZH#@2`S8_&!:;I<FMO3-ZI.@+`F>:'#RML`5A;?XA<U1$`S@"@
M`-+EMM:.?%'_,&+7#]USQ?H5[.+[E&79:F-WUI<\=PL?8I^3#:\S`N,"D)LZ
M$TS!TGK.X52OM8\60+JI,R%O*1$1CD5;NU>JQM-.@'E+B0@$@.U[,53C9`?`
MG_.F$E&F<P#8N/=4Z,;)=8#C12.13D2%`'`-H.&W#G"\<!-IL2O[NU&`Y<PL
MG&D#S']W$VD1SM;L!!ACEJ(+X#BWB70BO)*7VP188+;L`OCSPBH144&(0YWN
M>FU*I,RR>5=WUI>O5HF(HY^QWO]U-A%8VCW7W`@<Y_G")M+B5"=<^QY&?TX`
M2R!=SMH`QPN;!_XJQ)&."%>M&`Y,W66@"L3V/6B_YZP`QD"Z7"NLCQ<V#TRJ
MHYVQW@70[@'C+)8Y:X`%TF6[L*ZL`P4PJ8YW2#UCG+>')^/@+JCU];]T5@!C
M]?QK`,SK/%"(OW`\@&:H$C>]>P#C>OB:OC]`O8=(KRXZ+X"%6CKH`LSK/%`<
MYY#Z!D#]W#.;B3'38&7[_J##TK3YGA7`6"L0^]&?\[S.`W_%B0"R>C<VQIL`
M;6.X;?,])X!QD;8^NG`2Z:0Z)4`B;EN>G<B$F40(^N]G!/"I,'N_=`$4U?2D
M$0BL`71FX3KV3%?5&2B1EUJ!F`4?1HD((0Y_QOJ:$G&&I@NJZSX!O)G2O'T$
MQC,3@/:C"Y4')@)'.&-]/0)U4Z":+$R[;GV_[JRG>A8^*X"R]=%<Y8'*]#L>
M0*)-VPM=EI0KYJV/YBH/%)OJPH<"R(@.X":\.<#8#F"8/;*!:02!8P,$$:X`
M8)$V/YJK1%K@^`"OP\YJ`51M+U.!XP.\#D<ZQM*]I]N&?HT"0%^`J7M/KSI*
MJ@#0%V#AN(#XLM#\IJ<`>!4UD:?,V0'KBUKU\?S]"&>L7VMW5IS6]\9JE_:D
M.L(9ZU<[A`L'X$)=50@`>P!<.@(.,^B>TP#0$V"<N@(.,].S&P!Z`BR6KH##
MS/0\!X">`+\U!!QF`@%@'X!QJN^I!#H1"`![`?S3U.(6*G^9!8"]`,8C#5`%
M8(73`KQ\)?(R=Q6(./@9Z]>N1&)]DH52P`F`,(1[`?P3?VL%H@5<`-@+8#F2
M(P`8SPR_`+`/P">DL`#UFM4`T!]@7.!O];;%S.ZW$0!Z`XR+F50UD3%F9M%Y
M`.@-,"XPUT6E!69FT7D`Z`LP+I`N+<#G"@%@/X`%L-0UD;%]`)X<X.4JD5+M
MB?4Y^YQE7[/G@YVQ?BM*I`2D<:3'0#)#&,)]`"I^-<`J`.P%4//3`!=($`#V
M`6CX*8#CAHD5`.X&:/DI@(L`L!_`<F8.8\5,3R$(`/T!EIC9%9DSC/`[4`6`
M_@!CU$NJ,<-H/&K:J`'@=H!J4R('X&*$Z@T!7IH2>7K)YK*Q&B3[_+SO&>LW
MI$24@>#>^QVC"F$(>P*,6RN",<M'`:`_P+A0>SK5][Y@I(W4`'`W0#M_V'OC
M!4;X*P#T!%A`)]`SRV^&D1@%@'X`ZRU-]+U\@1D2!(!^`.,9S$[_ZIYJIOPK
M`/0#&!>M]9AC`)B)40#H![!`<SVF.@-$X*T!7HH2*;.L<1KZEZ]9ECV+?<Y8
MORDE$@.-Y83Y`D!2[7/&^DT-X;AP]\3"+(?B%P#Z`6PK8-5,7B$`]`/85L#Y
M3,T?`:`GP**Y)U:.F>W%#P`]`)9H[(DU!F;V^(H`<#?`&(T]L<8+-#JQ`L`=
M`)\*N'MBC1<`9A4"0%^`A=T4U=4?YP/PW)7(4S9?=>B/86>LWZ(2*>;++OT1
MAK`GP,:.1([^"`#]`,:%[-8?`:`7P+)P]H,9N_HC`/0!6+H*6.W&(1``>@,L
M1ZX"7F!FUU('@#X`F[M"Y^A:"1(`;@88%VH9YLP(X(;^"`!W`8P+R%%3P`F<
M(\#S5")/Y4LF:XGQY>OF\P>#$NF(P+*8I;+V`W7\S1"&L!_`,I5RZ1BJ>OP&
M@)X`2RP;AFH.;&KB#0`[`,9(&X9JCO9>"`'@-H!Q@:4+,(?93#L`]`$8_ZG7
MP&F`^<SF+P&@!\"R&*6NG=6YE#\`W(C#M@!J@.,%9J@"0$^`90FD?SMVUGCA
M;&9WI@#/2(F463:7J\^M"HC8*1*"$M'Q!\BE:V>-?P<@9D`8PAX`RQ*I;-A9
M^6*$[H74`>!Z\E+:,PD-CAP8M2MP`>`&@&4!VW\UJBMPHW8%+@#L!/A40CW^
M:H!C6\$,`'<"C`L@E0T[:[R8`8GX"P'@;H!QT5S_,8)*GY-JZ"'U-P6P+`O,
M9=/.L@UL`>!.@/;IYP!4_G.%"P'XIDJDS%K+SYOR8\@9ZS>E1$JTET\;^3'X
MC/6;&L+&>G%^]7&^&-7UCP!P*\`2JG3DKO]8`",(!("[K\K2;EYBOMTXGP$8
M"02`.Z_B$NN'B2X:ZS\"P"U796&TA_UV>0Y@EHAJ%`#NO"K17#IHM"^>J[T.
MJ;\5@+5U9;Y=OH`U#P+`'5>Q=IZ=7UB%7R*JV04"/+42*5_6Q$=N3B+<ZXSU
M&U$B)5*M?>TWT8M7*^QUPO6-#.&RM@Y,\I*WDI<`<,M5&;62E[':^T7UO@2`
M.]X7E\[.B>H<N`4`/(NF'Q@`=E[%90'9,!-T\F?"+P#<^KZX0"H;9H(*/R$.
M<L;ZU0.,"\BE>R]7=3<!!(`>`.-"/?XB:[RH0VPK!(`^`$O-S]P;+[!AX590
M(ET;[Y;MC7?5&83?#W;&^G4KD;B([,;CD8D_"+$ALL(0;F=_]:X10`2,\P4V
M+YL)`-L?C0O(E7-/)R\(`/T`QD4C^S.Y,P)`/X!QD;K9W_BK3?X"0!^`99$N
MW>QO$0&)EFX!X$Z`9:FGCSK[B]"YZCP`?.CT_HSYIY*7?`%$EE\`N`M@&4GI
MW%.S;U+AV@`>2XD\97*][K%!?`0ELAZ!<2'=]QGKY0A'A%_G$(X+-_N+<NC9
M-P#T`U@6TOEH;I=,!X!>`'7M([+B([*S1P#H`;!IGJKDQ=0]`L#=`.,B=<S3
MO)F\!(`[`2KU:[,_`!#?$0#Z`HQ?7/-4\3O:(?77"+!PS--<\[MN@(=5(J6S
MY:X6'T<[8_T*E4A<8EEG?Y&U_L(0]@,8%ZCU1X[(=FT$@%X`5?X26>L^LH6W
M`-`+H.,^M_9+#`!]`):U^ZSX10%@'X!Q:MUG7?@-`/L`C+\9_3'.]>P;`/;X
M'K\8?JB72P>`_M^C?+'\OMJ.\1L!>`@E4M;UCZ_U@H_CG+%^C4JD3.6#DSY7
M7I\;AC!L\WBZU%).I<\(`/L`5/[?@V?Z'`!BK7D\76HEXI,^!X"MJ[)0W1L/
M-OX"P!X`X])T;SQ@O/!)GP-`]RI^L2NW'L8+K_0Y`(3;/%ZO?'M8F.DC`/0%
M&!>IL^[(3K\W!W"H$GEZJ<L?7_*'[/G(9ZQ?FQ*)BW1I[N4+/"05$(:P/T"5
MOD1&?N#7"@&@/T"3OIC.TZ2S]R``W/3URF_2W#.=:P\!H#_`TNX;4>^U&P#Z
M`RQM]J>7S50(`'L`+&5CV8RNG0>`G@#+4C:6S9C:>0#H!5#-OI$M'B76_+MA
M@#V42/E--A:=.\6/XYVQ?D5*I'06;N4+(*E.<<;Z]0SALEZX-=;97P#H#3`N
MZ^PE4JT;%0)`;X"V\]YDSZ+5.!D`;@48%])VGN:+R,Z^`:`?P/*;35[R'(C$
MNG45`&X&&*O9-[+:MZOR&P!N!&BL%]/WUUWY#0`W`;362Z0G#W'LTUT_<@!L
M">('!4A-@(R(!@-DY*U$2FG+'E^S[%F<X(SU_UEE639?9?/5(97(7#:5B+.>
M98`2D9Y*)+;)7[[H6K)ZE`A\Q]45.V@$/K8CD.\SA,EO",??C'65P]FPY-@`
MB0!:@A$-`\B6Q$$$QB>?0'3'B#$>80+&/_+IY)&S.^*,R/M'33G]QCC=@1XY
MZ(Y\`<;?3-TMA[MAR=$CD'&P)1AGOPV+P%<0P#AH^L@X)B!&%-$]!XWH_BXB
M3#@QSKAW!!(^@OB$\8@8O^>>`,MO2[W;FMWQX((`$CD`B2C"Q`$(`D#]`*(G
M0)/]Z=RE.MD9ZP<!R+B.0*()B$`ITQ$X>21,@`$`I[T`ZNDCLEO%7BA`CFD3
MX%T$3`!V9(!F^E72H\(I`9(&2(<!.&D#)$R`_L_`7@`UOW$>>2Y:.&0BS0B@
M5Q`;.`OCE3B($\C.PL133`FD9^$)!WK,PA'1;XSX5,W"$PY&/VX'J-5;ONC<
M;^/LI=RK_C^9/)"TE*.!4H[<//">[ZR)?%LI[>&YV=79U42,>I)&B4CS_X$U
M$5DKD?GJPVI'323^MIS9JMLISU@_5`2R5Z[^3W<J`AEQ1)B"T6^#(C`E7D<@
M37:8"?&W)6::7X5+!/C&;LRWI3DE*JD0`/8&^&T)?4I4KY;Q`%!_1*U:S3V3
M%S^`Y"1<CQS*"3D*0.+*3&!$NP`R&@+PTRZ`FM]LJ_/2%Z";L:8<YO<\`D"F
M`9*^.C1`M@M@N52%CUGOCN<^`-F1`=976P#2,0#&4J<OSQ4."9`>P8C`B)!R
MQH\SA-FK^@X`+0%W"!,CL$<^)48C-IE$Q";>`(D1*"6\(\(]\90XFW`0_:1-
M1]X`^$WS<PXY.DP$IIS`.('QXP&D&>.,,PYE1#@`&6<<$4T99[_1]/X3HWO.
MN!]`QAEGCXQ_!.,3\$\$/B6`_:@$-ZBA1%99]N7KEL+'0"4R7\U7,E-_YBNY
MJQXQ4(FHKSY?9=E\9;2(4B+SU7PUE_)AOIK_+1\^K.:K#^KG\'BIKSE?_5\V
M7[W/5BN9R0>92?EC)C,Y7S65R`=@O$!2'?H\D48$$L?Q(U`'H!.!9")P,OG$
M^!2$'A'X":@CD*9@7$5@>P@O#;]C`N1T`H#-6;@!<#J-&)^"B/C^``%R`*93
MP^_0`.EDST#:#?#^$^-38&`$`OS.`E3/0`>@X7=@@,3J6?B1,PZ5YAYA%B9&
M*@\D<@$2@3VR.T9Z%J8IM,&P&R`1Z!%Z%J9'XK@#B/_0,827TX5)_PX+\+12
MCG&V;$HYQE4>R'A_*:<_5^>!M%7*+7_N.*DB`*P!3K8#3+&H<`4`0=0R$X@4
M0*+^`/7G8@3@7HGZC0#'O^(J`+Z5&[.L`S``[`/0Y-RK/TYSQOJUKA-)Q\FT
MXQ_XD=?_#,35M'Y.$<A>,<((!)!_!+*)RG+6?BS&?;NSULN:Z:+J`I@Z`!D'
M"-WUZ#<;P@8@ZP-03<Q[`&3K`)=_P`<@SA-@8^[U>`;2GL_`#H#_)-T`M8)@
M]`BE-,]H"!-QO-)O&+'-0YC8!(PX'MD$C#YB<O^H:^/-'XL8`<21ZFI`&V#=
M'S@!B'YDKZSA!Z;C:D,$,JUC4R75-T3Y6P!D'(17?-SZ#-2]+$CY/2>\X_>3
ME&.R'H'FEWLT7F([`G5_('#/&6<_LE=J:.'T#W@`I(T:_*P!*BM<`[Q+.3J>
M@37`#4-8]P>")@K@DC<`+GT`$M_86GS6`,E$('WD]W<1!@*<,GHDQN]K@$06
MX#^57P2>TRS<'R!&V`L@UQ%=1Z"91-+Q)H#4?`:>'T#>!^`[?G\7@=UM`[CI
M&5CW!S)./[)EHR8R_V-#?B[G,IM+]4>NYBLIY>ILE(B4J_E*_IU]SF0V[_JY
M'K)L+M]G<SE?J?__7_;^?99E[]<+(G,ILTS_HET_U%RN'C(I5YG\C\SDZH?Y
M*I.9E"NM1)85CG?&^M&U\$?01BVL[&<@Y=NU<&?<^9L)_P2`>P%,$UPRP'?$
M-P(D4K]6>Z726B)->P'\XZ(!OKT?^$\5`.X%\%\$@/L`5"/X%@"^HXD#\)$.
M!/!;=2L`/VHEHMR_3X>*P'^JVQG"#D`ZS!">RZ=_E=9X?\XU$2.)9#9?-=7"
MIIJ(G,N'N5QE[^<RFV<K^3[+5I_E?]YG<_D^DW.9;1!5FWZH^7_D:KZ2JP<I
M5]D/*SE?R566?<8K'BNE=N_Y&4<@XXR_P@CS__+=$<@XNXM`N.>,$WND"3$V
MPO3^$^&>,V*</O5[!DY`$7&ZYR#V(UNJ#J\17O$O+@D@8YR\AC#C["XE%R!G
M(WZG`7+&*3+RHP=`=`,DN@B`1)P8XXQ>/0$^F@CD*4T8Z!W=W7\BFJCBQ""`
M6`.8_J_J=+N$"`2(,0[O(6P!LD]LPD`?V63RB3#%(0'^2Q<UA(EZ/`,?W6=@
M#?!>-6(.>0:N`_SOJZF[37#F`/]+ND_3;P@335-B_)X(C$<TX<3>\>E]Q-0N
M`,VN`1^`Q%/BF!)Q_$!+$'%@A'EE_AVN+`]D7.6!]UPES5,`(W8W7,I-W#R0
M+=52BA$D`L#>`/40!C#"*_'K!$BD`$X(`#TJ@`TMW`\@F_`Z`G^@F5IP-<+J
=H&>LWUYWUO\#%"""3.S.DC$`````245.1*Y"8((&
`
end
--- ifmail v.2.15dev5
* Origin: Shadow Research Center (2:5020/400)
— RU.COMPRESS
From : Eugene D. Shelwien 2:5020/400 18 Aug 01 00:45:00
To : All
Subj : Re: И еще по поводу rangecoder-а
From: "Eugene D. Shelwien" <shelwien@thermosyn.com>
Reply-To: shelwien@thermosyn.com
Leonid Broukhis wrote:
>
> Смотрю я, и что-то мне не нравится в первоначальном
>
> void FinishEncode () { DO(4) OutByte(low>>24), low<<=8; }
>
> А не нравится мне то, что раз при входе в FinishEncode()
> low ^ low + range > TopValue (это у нас инвариант, без него никуда),
> то выдавать все 4 байта не нужно,
> а будет достаточно одного, потому что при выполнении вышеуказанного
> условия код 0xNNffffff находится внутри диапазона между low и low + range,
> а при достижении конца файла InByte() возвращает именно 0xff. Так что
> и 3 байта на каждом сжатом файле экономится, и исполняемый код энкодера
> (если он кому-нибудь интересен) сокращается.
3 байта - таки да, экономятся. А вот насчет сокращения кода... Тут, увы,
не все так просто. Что, если дальше в файле будут идти еще какие-то данные
(а они будут - в архиве, например)? Ведь понадобится поставить в InByte()
проверку, и выдавать дополнительные FF'ы специально, если она сработает.
А пока она не будет срабатывать - будет тормозить.
Опять же, чтобы сделать возможной эту проверку, надо знать длину сжатого
представления. Hу, в архиве-то она, скорей всего, будет. Hо если вдруг не
будет, то не займет ли код этой длины больше места, чем сэкономленные
три байта? ;)
Байты-то эти Decode() читает, и другой возможности определить, какие из
них последние, просто нет.
Так что остается только писать в конец три FF'а. Для красоты ;)
Аналогичная проблема, btw, возникает с лидирующими нулями в low после
StartEncode() - они не нужны (в некоторых кодерах, например, CL-R, у
меня их несколько), но избавляться от них - себе дороже. (Они возникают,
если "рабочую область" в low делать больше log2(InitialRange) )
Счастливо!
- Шелвин
--- ifmail v.2.15dev5
* Origin: Shadow Research Center (2:5020/400)
— RU.COMPRESS
From : Leonid Broukhis 2:5020/400 18 Aug 01 10:32:44
To : Eugene D. Shelwien
Subj : Re: И еще по поводу rangecoder-а
From: leob@mailcom.com (Leonid Broukhis)
Eugene D. Shelwien wrote:
>> void FinishEncode () { DO(4) OutByte(low>>24), low<<=8; }
>>
>> А не нравится мне то, что раз при входе в FinishEncode()
>> low ^ low + range > TopValue (это у нас инвариант, без него никуда),
>> то выдавать все 4 байта не нужно,
>> а будет достаточно одного, потому что при выполнении вышеуказанного
>> условия код 0xNNffffff находится внутри диапазона между low и low + range,
>> а при достижении конца файла InByte() возвращает именно 0xff. Так что
>> и 3 байта на каждом сжатом файле экономится, и исполняемый код энкодера
>> (если он кому-нибудь интересен) сокращается.
>
>3 байта - таки да, экономятся. А вот насчет сокращения кода... Тут, увы,
Тут-то ты не понимаешь. :-) Я-то все о моей challenge пекусь.
В ней ни скорость сжатия, ни скорость
разжатия не интересуют (до разумных пределов порядка часа), а степень
сжатия и размер декодера интересуют одинаково сильно. Это все кстати к тому,
что у Максима Смирнова еще куча резервов, раз наличие переноса мало того,
что улучшает сжатие, так еще и размер декодера уменьшает.
Leo
--- ifmail v.2.15dev5
* Origin: leob@at-mailcom.dot-com (2:5020/400)
— RU.COMPRESS
From : Leonid Broukhis 2:5020/400 18 Aug 01 21:36:35
To : Eugene D. Shelwien
Subj : Re: Return of the Carry
From: leob@mailcom.com (Leonid Broukhis)
Eugene D. Shelwien wrote:
>Похоже, в исходники AriDemo посмотреть и тебе лень, несмотря на
>то, что они у тебя хостятся %).
>Впрочем, может, там просто не последняя версия? ;)
В aridemo6, скачанном с www.pilabs.org.ua, некоторых упомянутых тобой
файлов нет.
>В общем, смотри:
>
>shindler.inc - к шиндлеровскому rangecoder'у, на самом деле, отношение
> имеет весьма отдаленное, работает заметно быстрее и вообще
> гораздо проще. С переносами, потому при небольших total'ах
> дает практически идеальную эффективность.
Я не понял, зачем там в StartDecode и в FinishEncode стоит DO(5).
Мой код, кстати, компактнее и по идее должен работать быстрее.
>shcoder.inc - as above, но эффективность хорошая уже и при средних
> total'ах. Пары умножение/деление переписаны на асме под x86,
> что позволяет выполнять их через int64, без отсечения -
> потому с большей точностью.
>
>shindlet.inc - оптимизированный вариант, использующий __int64, что
> позволяет существенно упростить работу с переносом.
> __int64 можно заменить на "long long int"...
> или просто "long int", где как.
Вышеупомянутых двух файлов нет.
>clr.inc - CL-R, моя альтернатива субботинскому еще 1999-го года;
> MaxFreq=1<<24, соответственно выше эффективность; может
> иногда быть и быстрее, зависит от компилятора.
Вместо этого там cld-...
>shcoder.inc 10,467,200 11.200 30.380
>shindler.inc 10,468,021 11.750 21.420
>shindlet.inc 10,468,021 11.810 21.470
>CL-R 10,468,024 11.640 22.350
>subb_lb.inc 10,472,796 11.310 21.750
>subbotin.inc 10,474,842 11.090 21.750
Слабо мой вариант (subbroukhis :-) ) тоже попробовать? Интересует
не столько скорость, сколько сравнение качества кодирования
с 32-разрядным Шиндлером.
Leo
--- ifmail v.2.15dev5
* Origin: leob@at-mailcom.dot-com (2:5020/400)
— RU.COMPRESS
From : Eugene D. Shelwien 2:5020/400 19 Aug 01 05:36:19
To : Leonid Broukhis
Subj : Re: Return of the Carry
From: "Eugene D. Shelwien" <shelwien@thermosyn.com>
Reply-To: shelwien@thermosyn.com
Hi!
Leonid Broukhis wrote:
> >Похоже, в исходники AriDemo посмотреть и тебе лень, несмотря на
> >то, что они у тебя хостятся %).
> >Впрочем, может, там просто не последняя версия? ;)
>
> В aridemo6, скачанном с www.pilabs.org.ua, некоторых упомянутых тобой
> файлов нет.
Hу нет :). Они размножаются слишком быстро - никак не соображу, как
их систематизировать.
> >В общем, смотри:
> >
> >shindler.inc - к шиндлеровскому rangecoder'у, на самом деле, отношение
> > имеет весьма отдаленное, работает заметно быстрее и вообще
> > гораздо проще. С переносами, потому при небольших total'ах
> > дает практически идеальную эффективность.
>
> Я не понял, зачем там в StartDecode и в FinishEncode стоит DO(5).
Зачем вообще этот цикл, или почему 5?
От цикла в StartDecode действительно можно избавиться, как это
Шиндлер сделал - у него просто нормализация в Decode() идет перед
всем остальным, в ней байты и вычитываются.
Hо имхо не стоит так делать, чтобы не заставлять основное содержимое
Decode() и Encode() ждать результатов нормализации (лишние
dependency chains по регистрам). Да и другие причины есть.
А 5 потому, что кэш плюс четыре байта low. У Шиндлера тоже пять, на
самом деле, просто неявно. А у тебя там четыре благодаря лишнему
if (extra), про который мы с Шиндлером // ;) // решили, что он
вреден ;)
> Мой код, кстати, компактнее и по идее должен работать быстрее.
Hу, что компактнее - я бы не сказал, но работать быстрее, наверно,
его можно заставить - все-таки там low[3] используется вместо
отдельной переменной для хранения переноса. Hо как от этого
страдает эффективность!..
Хотя как
void Decode (uint cum_freq, uint freq, uint tot_freq) {
low+= cum_freq*range;
range*= freq;
while ((low ^ low+range) < TopValue || range < BotValue)
code= code<<8 | InByte(), range<<=8, low<<=8;
}
может быть быстрее
void Decode (uint cumFreq, uint freq, uint totFreq)
{
code -= cumFreq*range;
range*= freq;
while( range<TOP ) code=(code<<8)|InpSrcByte(), range<<=8;
}
лично мне понять до крайности трудно %)
И потом. ShiftLow() в shindler.inc сохраняет особенности оригинальной
шиндлеровской реализации. А вообще-то его можно заменить на
#define ShiftLow() \
{ \
if ( low<(uint)0xFF000000 ) { \
OutTgtByte( Cache + Carry ); \
Carry+=0xFF; \
while( FFNum-- ) OutTgtByte(Carry); \
Cache = low>>24; \
Carry = 0; \
} else FFNum++; \
low = low<<8; \
}
Hа скорость, впрочем, это заметного влияния не оказывает ;)
> >shcoder.inc - as above, но эффективность хорошая уже и при средних
> > total'ах. Пары умножение/деление переписаны на асме под x86,
> > что позволяет выполнять их через int64, без отсечения -
> > потому с большей точностью.
> >
> >shindlet.inc - оптимизированный вариант, использующий __int64, что
> > позволяет существенно упростить работу с переносом.
> > __int64 можно заменить на "long long int"...
> > или просто "long int", где как.
>
> Вышеупомянутых двух файлов нет.
Ты мои .uue распаковал, или тебе их отдельно выслать?
> >clr.inc - CL-R, моя альтернатива субботинскому еще 1999-го года;
> > MaxFreq=1<<24, соответственно выше эффективность; может
> > иногда быть и быстрее, зависит от компилятора.
>
> Вместо этого там cld-...
Да, так и есть. CL-D - это дальнейшее развитие ;)
> >shcoder.inc 10,467,200 11.200 30.380
> >shindler.inc 10,468,021 11.750 21.420
> >shindlet.inc 10,468,021 11.810 21.470
> >CL-R 10,468,024 11.640 22.350
> >subb_lb.inc 10,472,796 11.310 21.750
> >subbotin.inc 10,474,842 11.090 21.750
>
> Слабо мой вариант (subbroukhis :-) ) тоже попробовать? Интересует
> не столько скорость, сколько сравнение качества кодирования
> с 32-разрядным Шиндлером.
Тю на тебя. subb_lb.inc - как ты думаешь, что такое? %)
> Leo
Счастливо!
- Шелвин
--- ifmail v.2.15dev5
* Origin: Shadow Research Center (2:5020/400)
— RU.COMPRESS
From : Leonid Broukhis 2:5020/400 19 Aug 01 10:31:15
To : Eugene D. Shelwien
Subj : Re: И еще по поводу rangecoder-а
From: leob@mailcom.com (Leonid Broukhis)
Eugene D. Shelwien wrote примерно год назад:
> Впрочем, эвристика9: (моя, вроде бы) при делении теряется информация;
> во избежание деление рекомендуется всегда выполнять _после_ всех умноже-
> ний в формуле. Все виденные мною арифметические кодеры же относятся к
> этому правилу наплевательски, т.к. результат предварительного умножения
> может не поместиться в разрядную сетку используемого типа данных. Таков
> практический вред от применения языков программирования высокого уровня
> - ассемблерная команда MUL _всегда_ вычисляет результат с удвоенной раз-
> рядностью операндов. А команда DIV ей в пару выполняет деление двойного
> слова, содержащегося в двух регистрах, на одинарное. Hо на ЯВУ, соблюдая
> портабельность, этим воспользоваться нельзя, увы :).
Hа самом деле на ЯВУ при выполнении некоторых условий этим пользоваться
и не нужно. Смотри: если totFr - не более чем 1<<16, а freq - и подавно
(потому что freq < totFr), то range * freq / totFr
вычисляется в 32-битной арифметике как
(range/totFr) * freq + (range%totFr) * freq / totFr
Если компилятор достаточно умён (GCC, например), то
два подвыражения в скобках превратятся всего в одно деление.
Hо использование этого в том же субботинском кодере - дело не такое уж
тривиальное.
Leo
--- ifmail v.2.15dev5
* Origin: leob@at-mailcom.dot-com (2:5020/400)
— RU.COMPRESS
From : Leonid Broukhis 2:5020/400 19 Aug 01 20:26:20
To : Eugene D. Shelwien
Subj : Re: Return of the Carry
From: leob@mailcom.com (Leonid Broukhis)
Eugene D. Shelwien wrote:
>> >В общем, смотри:
>> >
>> >shindler.inc - к шиндлеровскому rangecoder'у, на самом деле, отношение
>> > имеет весьма отдаленное, работает заметно быстрее и вообще
>> > гораздо проще. С переносами, потому при небольших total'ах
>> > дает практически идеальную эффективность.
>>
>> Я не понял, зачем там в StartDecode и в FinishEncode стоит DO(5).
>
>Зачем вообще этот цикл, или почему 5?
Почему 5.
>А 5 потому, что кэш плюс четыре байта low. У Шиндлера тоже пять, на
Теперь понятно. Я просто поразился наглому выбрасыванию первого
байта при декодировании.
>самом деле, просто неявно. А у тебя там четыре благодаря лишнему
>if (extra), про который мы с Шиндлером // ;) // решили, что он
>вреден ;)
Hу просто так часто FinishEncode выполняется, что аж жуть.
>> Мой код, кстати, компактнее и по идее должен работать быстрее.
>
>Hу, что компактнее - я бы не сказал, но работать быстрее, наверно,
Я про декодер по сравнению с оригинальным субботинским.
>его можно заставить - все-таки там low[3] используется вместо
>отдельной переменной для хранения переноса. Hо как от этого
>страдает эффективность!..
Это смотря с чем сравнивать.
>Хотя как
>
> void Decode (uint cum_freq, uint freq, uint tot_freq) {
> low+= cum_freq*range;
> range*= freq;
> while ((low ^ low+range) < TopValue || range < BotValue)
> code= code<<8 | InByte(), range<<=8, low<<=8;
> }
>
>может быть быстрее
>
> void Decode (uint cumFreq, uint freq, uint totFreq)
> {
> code -= cumFreq*range;
> range*= freq;
> while( range<TOP ) code=(code<<8)|InpSrcByte(), range<<=8;
> }
>
>лично мне понять до крайности трудно %)
Опять же, не с тем сравниваешь. Hо таки да, необходимость использовать
при декодировании и code, и low - печальна.
>И потом. ShiftLow() в shindler.inc сохраняет особенности оригинальной
>шиндлеровской реализации. А вообще-то его можно заменить на
>
> #define ShiftLow() \
> { \
> if ( low<(uint)0xFF000000 ) { \
> OutTgtByte( Cache + Carry ); \
> Carry+=0xFF; \
> while( FFNum-- ) OutTgtByte(Carry); \
> Cache = low>>24; \
> Carry = 0; \
> } else FFNum++; \
> low = low<<8; \
> }
>
>Hа скорость, впрочем, это заметного влияния не оказывает ;)
Зато мне флаг Carry не нужен. У меня сам факт использования кэша (held)
означает бывшую возможность переноса, поэтому следующий по старшинству
байт (low<<24) по ликвидации возможности переноса или 00, или FF,
чем я и пользуюсь.
>Ты мои .uue распаковал, или тебе их отдельно выслать?
Какие uue? Все, что ты мне присылал, я выкладывал, можешь проверить.
>> >clr.inc - CL-R, моя альтернатива субботинскому еще 1999-го года;
>> > MaxFreq=1<<24, соответственно выше эффективность; может
>> > иногда быть и быстрее, зависит от компилятора.
>>
>> Вместо этого там cld-...
>
>Да, так и есть. CL-D - это дальнейшее развитие ;)
>
>> >shcoder.inc 10,467,200 11.200 30.380
Длинных делений многовато будет?
>> >shindler.inc 10,468,021 11.750 21.420
>> >shindlet.inc 10,468,021 11.810 21.470
>> >CL-R 10,468,024 11.640 22.350
>> >subb_lb.inc 10,472,796 11.310 21.750
>> >subbotin.inc 10,474,842 11.090 21.750
>>
>> Слабо мой вариант (subbroukhis :-) ) тоже попробовать? Интересует
>> не столько скорость, сколько сравнение качества кодирования
>> с 32-разрядным Шиндлером.
>
>Тю на тебя. subb_lb.inc - как ты думаешь, что такое? %)
Виноват, недоглядел. :-) Странно, что декодирование - с той же скоростью,
что и субботинское. Без ошибок хоть, кстати?
Leo
--- ifmail v.2.15dev5
* Origin: leob@at-mailcom.dot-com (2:5020/400)
— RU.COMPRESS
From : Eugene D. Shelwien 2:5020/400 20 Aug 01 05:05:29
To : Leonid Broukhis
Subj : Re: Return of the Carry
From: "Eugene D. Shelwien" <shelwien@thermosyn.com>
Reply-To: shelwien@thermosyn.com
Hi!
> >самом деле, просто неявно. А у тебя там четыре благодаря лишнему
> >if (extra), про который мы с Шиндлером // ;) // решили, что он
> >вреден ;)
>
> Hу просто так часто FinishEncode выполняется, что аж жуть.
Причем тут?.. Я о вот этом:
// carry not possible (anymore)
if (extra) {
^^^^^^^^^^^^
// guess what? low>>24 is either 0xff or 0 now
OutByte(held + 1 + (low >> 24));
while (--extra) OutByte(low>>24);
}
Дело в том, что extra в этом месте у тебя всегда
(после первой ренормализации) будет не меньше единицы.
> >его можно заставить - все-таки там low[3] используется вместо
> >отдельной переменной для хранения переноса.
> Зато мне флаг Carry не нужен. У меня сам факт использования кэша (held)
> означает бывшую возможность переноса, поэтому следующий по старшинству
> байт (low<<24) по ликвидации возможности переноса или 00, или FF,
> чем я и пользуюсь.
" - Твой кодер может быть быстрее, т.к. перенос хранится в low[3]
- Зато мне флаг Carry не нужен!"
;-)
> >Ты мои .uue распаковал, или тебе их отдельно выслать?
> Какие uue? Все, что ты мне присылал, я выкладывал, можешь проверить.
Sorry. В моем первом ответе на сабж предполагался uue'шный кусок
со всеми перечисленными inc'ами. Hо его кто-то съел %)
> >> >clr.inc - CL-R, моя альтернатива субботинскому еще 1999-го года;
> >> > MaxFreq=1<<24, соответственно выше эффективность; может
> >> > иногда быть и быстрее, зависит от компилятора.
> >>
> >> Вместо этого там cld-...
> >
> >Да, так и есть. CL-D - это дальнейшее развитие ;)
> >
> >> >shcoder.inc 10,467,200 11.200 30.380
>
> Длинных делений многовато будет?
uint GetFreq (uint totFreq) {
return muldiv( code-low, totFreq, range );
}
void Decode (uint cumFreq, uint freq, uint totFreq)
{
uint tmp = muldiv( cumFreq, range, totFreq ) + 1;
low += tmp;
range = muldiv( cumFreq+freq, range, totFreq ) - tmp;
while ( range<TOP )
{
code = (code<<8) | InpSrcByte();
low <<= 8;
range <<= 8;
}
}
Ты б лучше придумал, как сделать, чтобы и точность
сохранялась, и range/total с total/range отдельно
не считать.
> >> >shindler.inc 10,468,021 11.750 21.420
> >> >shindlet.inc 10,468,021 11.810 21.470
> >> >CL-R 10,468,024 11.640 22.350
> >> >subb_lb.inc 10,472,796 11.310 21.750
> >> >subbotin.inc 10,474,842 11.090 21.750
> >>
> >> Слабо мой вариант (subbroukhis :-) ) тоже попробовать? Интересует
> >> не столько скорость, сколько сравнение качества кодирования
> >> с 32-разрядным Шиндлером.
> >
> >Тю на тебя. subb_lb.inc - как ты думаешь, что такое? %)
>
> Виноват, недоглядел. :-) Странно, что декодирование - с той же скоростью,
> что и субботинское.
//------------------------------- твой вариант
void Decode (uint cum_freq, uint freq, uint tot_freq) {
low+= cum_freq*range;
range*= freq;
while ((low ^ low+range) < TopValue || range < BotValue)
code= code<<8 | InByte(), range<<=8, low<<=8;
}
//------------------------------- Субботин
void Decode (uint cumFreq, uint freq, uint totFreq) {
low += cumFreq*range;
range*= freq;
while ((low ^ low+range)<TOP || range<BOT && ((range= -low & BOT-1),1))
code = (code<<8) | InpSrcByte(), range<<=8, low<<=8;
}
Hу и почему бы им не работать с одинаковой скоростью? low ты считаешь
совершенно зря. ...Да и отладочный if в GetFreq я проглядел - но не
видно, чтоб он заметно влиял на время.
> Без ошибок хоть, кстати?
Явных не видно.
Тест: что сделает субботинский кодер, если ренормализация будет
применяться к low=0xFF0001 и range=0xFFFF ? ;)
> Leo
Счастливо!
- Шелвин
e
|
v
bugin 644 coders.rar
M4F%R(1H'`#O0<P@`#0````````!$5W2`@"<`Y0$``*`$````E#EI;DX9TRH4
M-0<`(````&-L<BYI;F,,`5$,S,P``!57V-`OP^0/Q)91BZ5MUB%&`61Q04"V
MNAM^D$83**:("1*A1+Z!M?[U*.*(E6[F:3IZ,KHW'`Z!$'TT[N==YN9S%I^,
MYG.`9@S?#0,YF^>[5QJZVXT`<'"FXHEFPNNO`GG)\.5BLOF++F2%55/S_+:D
M2N3A_L4A.O9LV-PVA]%_KPM&U0@<Q-\\(KD,>4S!WMP/ETQ&W%^XLW[>+$'%
M;<YVO:["M[./9](^N%]WI,AP]%Z@\*%4!DR(2QA@YK[;/J'$'0ZW"WC?MO/^
MYP4#0&?*4-!P&U^P?X`L\8[/X?-,)BW%%JZXYF.@S.!K(?#LLLLP<;ZA1<#&
M@\?_9LFR.T/W<P\;S/LZWXF5%Y[UM1`-XKWN<G/:5YG:7#`_R<[Y+XP+Z_7N
M[T):@XHH&-]<*5I4-D]DQ`D#$AE9@P6GFOE4..=V7$^Z^.@>#9``S"K$BD&W
M$$0#56$)B\H.;;!,T<DLSIO-WVDSZ=DTG`PH6AW!NZ;CZ!E-,SA^)OU4D10=
MSY0H$:+&UQ%LHZ%-4[4S,I:NHHLC*C@0-*&Q,40XE$$E#&@1BW_[VO\!.>!I
MXS^J?@><+FNK(`DT`Y@V\#61L^<U@P@@<=LG2O.X,%!/DDYELMO_)P/K*$=@
MX1QF\U/K=)"`*P#Z`0``TP<```"-9CJL2P'K*A0U"P`@````<VAC;V1E<BYI
M;F/:\@*?1H>SAY,DU]XBN"&Z07\3[T#+_>*C)#RP<I3,VK7]08,U[;;-YK(7
MGNLBJ0A1?%SDH8(+]QOHXDS^-N/G#F!2.N:K5DYM>/O;EY;>+`DD9XYA+`[T
M)-6^JI;/XQ%I<Q83-)(HN%@1H[U0R3E6,<V6:=Z69.A#/$9CY>6?F_'!\<.L
M]V2D/4[QPXG!$.;!#DP0XCSYWCV]6>Q//4'1%B=W7=R)C[`]9*.CV<_%6*ZY
M4[C!&@10\HBJLU\<=Z$#_\9_TCEICZ9>:9A^6R%!T"@B*!1)4A=C33/%4*\I
M28E)2$_Q[7LFR*&V"&6D:RMV@VUI6;*5Z$XKXL\\82-@Q(0;\A/T\/IA*LX(
M4(LR2)&Q#QX;A^-VQYH[;/)36ZK5JL7Q""==HVARFW!!C498BY3J!Z-&M8^)
M9:=?U%O3%,[$8/;4L;DFAC!J_B:.4I(-!9/927$"8:M<T%1[<K'4-FA'_:LM
M4T'XT2)(X-(=?`W7T&=#-ZL1O")&IK0\1=H\FGD\3.5K9Q=@^R&%$7*:?U$]
M9C<^.]P9PK;JQORQ?^I_9YM^\8:&]"F@O`TY$Q<"#$W$!&.H&/JT?880,MYU
M=<`R.\[T0D])SUC4KX6C*6B!F$4*C8?4IZ0_FWU%NWISB%CXU_UB`<-$>4&\
M+&XM7A![W718.,KDP+O\=)"`+`!&````F@4```!B;.2X3;1G*A0U#``@````
M<VAI;F1L97(N:6YC^^7TJ?HT=Z^(0::>^7J>CK^/6H,FKR"TRQ'V,"BK8NDW
MK+2<OW+?QZS=D^].2S-G>K3R?^0V<#-])6FZZ='K7^8V*#G,@)'Y=)"`+`"H
M````@`4```#7PEY5=!<3*Q0U#``@````<VAI;F1L970N:6YCR>'5'`:8WH8.
MD]1F>MR<<%5JZVD:2#T:2@:KY\"+NRY/A+55+W`AF+4]#`T>"7+3J=+4\J12
M,/OTL*#0_2*9^LLP`MM5"8OJ(;1WYSTL3J3&5(QR667GJ<E+,[::^I`.@0)L
M0;C,;,<9IMU]8I^.[$'V-WGSV[K)C[2E2'YYW=SV6[#I"Q9_J<I8^F>G^\4=
8H1@7W@ZX51);P)U\_=,^1_MTGJ^5YYOX
`
end
--- ifmail v.2.15dev5
* Origin: Shadow Research Center (2:5020/400)
— RU.COMPRESS
From : Eugene D. Shelwien 2:5020/400 20 Aug 01 05:05:29
To : Leonid Broukhis
Subj : Re: И еще по поводу rangecoder-а
From: "Eugene D. Shelwien" <shelwien@thermosyn.com>
Reply-To: shelwien@thermosyn.com
Hi!
> > рядностью операндов. А команда DIV ей в пару выполняет деление двойного
> > слова, содержащегося в двух регистрах, на одинарное. Hо на ЯВУ, соблюдая
> > портабельность, этим воспользоваться нельзя, увы :).
>
> Hа самом деле на ЯВУ при выполнении некоторых условий этим пользоваться
> и не нужно. Смотри: если totFr - не более чем 1<<16, а freq - и подавно
> (потому что freq < totFr), то range * freq / totFr
> вычисляется в 32-битной арифметике как
> (range/totFr) * freq + (range%totFr) * freq / totFr
Имхо вышеотквоченное верно всегда, вне зависимости от множеств значений
freq и totFr ;)
Хотя интересно было бы посмотреть, как ты собираешься объяснить 32-битному
компилятору сей (портабельно), что totFr<1<<16 %) . Short int ведь вовсе
не обязан быть двухбайтовым...
> Если компилятор достаточно умён (GCC, например), то
> два подвыражения в скобках превратятся всего в одно деление.
Интересно. IntelC упорно генерит три деления и два умножения.
#include <stdio.h>
void main( void ) {
volatile int x, range,totFr,freq;
x = (range/totFr) * freq + (range%totFr) * freq / totFr;
printf("%i\n", x );
}
Откомпили, pls, вот это твоим GCC и пришли асмовский листинг.
Потому как если он все это правильно свернет - то это очень
даже повод наехать на интелей.
> Hо использование этого в том же субботинском кодере - дело не такое уж
> тривиальное.
Отчего же? Если эксперимент пройдет успешно - ничто не помешает
использованию этой конструкции в субботинском (или любом другом) кодере.
> Leo
Счастливо!
- Шелвин
--- ifmail v.2.15dev5
* Origin: Shadow Research Center (2:5020/400)
— RU.COMPRESS
From : Maxim Smirnov 2:5020/400 20 Aug 01 09:33:07
To : All
Subj : к вопросу о сжимаемости Calgary Corpus
From: "Maxim Smirnov" <model@iac.spb.ru>
Hi All,
Осмелюсь предположить, что каждый
может найти десяток причин, по которым
Calgary есть дрянь и гадость. Hо все
равно интересно :-)
Hа сегодняшний день имею следующие
результаты:
байт bpb
bib 23536 1,692
book1 195728 2,037
book2 133374 1,747
geo 46895 3,664
news 100732 2,137
obj1 9130 3,397
obj2 65055 2,109
paper1 14051 2,114
paper2 21194 2,063
pic 26503 0,413
progc 10769 2,175
progl 12759 1,425
progp 8924 1,446
trans 14397 1,229
ВСЕГО 683047 1,975
Архив HA из 14 файлов и декодера имеет
размер 691473 байта. Если сделать solid,
то 686856 (сами файлы 678340).
Из результатов видно, что имеется значительный
провал на obj2, progp и trans. Также следует
пошерстить pic. Rangecoder субботинский, опять
же ;-)
Принимаются предложения по организации
эффективного кодирования символов в pic.
Maxim
--- ifmail v.2.15dev5
* Origin: FidoNet Online - http://www.fido-online.com (2:5020/400)
— RU.COMPRESS
From : Leonid Broukhis 2:5020/400 20 Aug 01 15:05:42
To : Eugene D. Shelwien
Subj : Re: И еще по поводу rangecoder-а
From: leob@mailcom.com (Leonid Broukhis)
Eugene D. Shelwien wrote:
>> Hа самом деле на ЯВУ при выполнении некоторых условий этим пользоваться
>> и не нужно. Смотри: если totFr - не более чем 1<<16, а freq - и подавно
>> (потому что freq < totFr), то range * freq / totFr
>> вычисляется в 32-битной арифметике как
>> (range/totFr) * freq + (range%totFr) * freq / totFr
>
>Имхо вышеотквоченное верно всегда, вне зависимости от множеств значений
>freq и totFr ;)
В _32_-битной арифметике - нет. Потому что если результат умножения >= 1<<32,
то все пропало.
>Хотя интересно было бы посмотреть, как ты собираешься объяснить 32-битному
>компилятору сей (портабельно), что totFr<1<<16 %) . Short int ведь вовсе
>не обязан быть двухбайтовым...
Hе обязан, но у субботинского кодера ограничение на totFr такое стоит,
что он <= 1<<16. Поэтому как руками напишешь, так и будет.
>> Если компилятор достаточно умён (GCC, например), то
>> два подвыражения в скобках превратятся всего в одно деление.
>
>Интересно. IntelC упорно генерит три деления и два умножения.
>
>#include <stdio.h>
>void main( void ) {
> volatile int x, range,totFr,freq;
> x = (range/totFr) * freq + (range%totFr) * freq / totFr;
> printf("%i\n", x );
>}
>
>Откомпили, pls, вот это твоим GCC и пришли асмовский листинг.
>Потому как если он все это правильно свернет - то это очень
>даже повод наехать на интелей.
Ты бы volatile убрал, ни к чему оно там. И GCC его, естественно,
тоже вполне уважает, и генерит 3 деления. А без volatile - все как надо.
>> Hо использование этого в том же субботинском кодере - дело не такое уж
>> тривиальное.
>
>Отчего же? Если эксперимент пройдет успешно - ничто не помешает
>использованию этой конструкции в субботинском (или любом другом) кодере.
В энкодере-то все в порядке. Основная проблема в декодере, в конструкции
(code-low)/(range/tot_freq). Здесь без длинного деления для достижения
большей точности в выражении (code-low)*tot_freq/range не обойтись.
Leo
--- ifmail v.2.15dev5
* Origin: leob@at-mailcom.dot-com (2:5020/400)
— RU.COMPRESS
From : Leonid Broukhis 2:5020/400 20 Aug 01 18:32:47
To : Eugene D. Shelwien
Subj : Re: Return of the Carry
From: leob@mailcom.com (Leonid Broukhis)
Eugene D. Shelwien wrote:
>Причем тут?.. Я о вот этом:
>
> // carry not possible (anymore)
> if (extra) {
>^^^^^^^^^^^^
> // guess what? low>>24 is either 0xff or 0 now
> OutByte(held + 1 + (low >> 24));
> while (--extra) OutByte(low>>24);
> }
>
>Дело в том, что extra в этом месте у тебя всегда
>(после первой ренормализации) будет не меньше единицы.
Это не так. extra у меня не меньше единицы, только если low[3] или 0xff,
или 0 после переноса.
>> >его можно заставить - все-таки там low[3] используется вместо
>> >отдельной переменной для хранения переноса.
>
>> Зато мне флаг Carry не нужен. У меня сам факт использования кэша (held)
>> означает бывшую возможность переноса, поэтому следующий по старшинству
>> байт (low<<24) по ликвидации возможности переноса или 00, или FF,
>> чем я и пользуюсь.
>
>" - Твой кодер может быть быстрее, т.к. перенос хранится в low[3]
> - Зато мне флаг Carry не нужен!"
>
>;-)
"Зато" относилось к эффективности.
>> >> Вместо этого там cld-...
>> >
>> >Да, так и есть. CL-D - это дальнейшее развитие ;)
>> >
>> >> >shcoder.inc 10,467,200 11.200 30.380
>>
>> Длинных делений многовато будет?
>
>uint GetFreq (uint totFreq) {
> return muldiv( code-low, totFreq, range );
>}
>void Decode (uint cumFreq, uint freq, uint totFreq)
>{
> uint tmp = muldiv( cumFreq, range, totFreq ) + 1;
> low += tmp;
> range = muldiv( cumFreq+freq, range, totFreq ) - tmp;
Hе понял, почему не
uint tmp = muldiv( cumFreq, range, totFreq );
low += tmp;
range = muldiv( cumFreq+freq, range, totFreq ) - tmp - 1;
Ибо если cumFreq == 0, то low меняться не должен по определению.
>Ты б лучше придумал, как сделать, чтобы и точность
>сохранялась, и range/total с total/range отдельно
>не считать.
Hе знаешь, как делить на "константу" с полной точностью
(в нашем случае на "временную константу" range/total)? Вычислить
(total<<32)/range и умножать на нее.
>> Виноват, недоглядел. :-) Странно, что декодирование - с той же скоростью,
>> что и субботинское.
>
>//------------------------------- твой вариант
> void Decode (uint cum_freq, uint freq, uint tot_freq) {
> low+= cum_freq*range;
> range*= freq;
> while ((low ^ low+range) < TopValue || range < BotValue)
> code= code<<8 | InByte(), range<<=8, low<<=8;
> }
>
>//------------------------------- Субботин
> void Decode (uint cumFreq, uint freq, uint totFreq) {
> low += cumFreq*range;
> range*= freq;
> while ((low ^ low+range)<TOP || range<BOT && ((range= -low & BOT-1),1))
> code = (code<<8) | InpSrcByte(), range<<=8, low<<=8;
> }
>
>Hу и почему бы им не работать с одинаковой скоростью? low ты считаешь
У меня код меньше, range= -low & BOT-1 отсутствует, кэш команд и таблица
branch prediction меньше засоряется.
>совершенно зря. ...Да и отладочный if в GetFreq я проглядел - но не
Hет, не зря, иначе синхронизация потеряется.
>видно, чтоб он заметно влиял на время.
>
>> Без ошибок хоть, кстати?
>
>Явных не видно.
>
>Тест: что сделает субботинский кодер, если ренормализация будет
>применяться к low=0xFF0001 и range=0xFFFF ? ;)
Обрубит range так, чтобы он стал равным 0xFFFF. :-)
Leo
--- ifmail v.2.15dev5
* Origin: leob@at-mailcom.dot-com (2:5020/400)
— RU.COMPRESS
From : Bulat Ziganshin 2:5093/4.126 20 Aug 01 18:55:29
To : Maxim Smirnov
Subj : к вопросу о сжимаемости Calgary Corpus
* Originally in RU.COMPRESS
Hello Maxim!
Monday August 20 2001, Maxim Smirnov writes to All:
MS> Архив HA из 14 файлов и декодера имеет
MS> размер 691473 байта. Если сделать solid,
MS> то 686856 (сами файлы 678340).
я так понимаю, лео назначил очередную премию, теперь за шесть шестёрок? :)
Bulat, mailto:bulatzATfort.tatarstan.ru, ICQ 15872722
... Иногда для того, чтобы изменить свое восприятие мира,
... люди пытаются изменить сам мир
--- GoldED+/W32 1.1.2
* Origin: За бессмертие платят жизнью. Можно чужой (2:5093/4.126)
— RU.COMPRESS
From : Eugene D. Shelwien 2:5020/400 20 Aug 01 19:43:29
To : Leonid Broukhis
Subj : Re: Return of the Carry
From: "Eugene D. Shelwien" <shelwien@thermosyn.com>
Reply-To: shelwien@thermosyn.com
Hi!
> > // carry not possible (anymore)
> > if (extra) {
> >^^^^^^^^^^^^
> > // guess what? low>>24 is either 0xff or 0 now
> > OutByte(held + 1 + (low >> 24));
> > while (--extra) OutByte(low>>24);
> > }
> >
> >Дело в том, что extra в этом месте у тебя всегда
> >(после первой ренормализации) будет не меньше единицы.
>
> Это не так. extra у меня не меньше единицы, только если low[3] или 0xff,
> или 0 после переноса.
Hу да, это меня переклинило. Только вот if от этого менее лишним не
становится :). В смысле, можно и без него обойтись.
OutByte( Cache + (low>>32) );
int c = 0xFF+(low>>32);
while( FFNum ) OutByte(c), FFNum--;
Cache = uint(low)>>24;
Байт все равно придется какой-то записывать, а while со значением
счетчика прекрасно разберется и без дополнительного if'а.
В общем, это надо, конечно, замерить оба варианта - с if'ом и
без. Hо пока что мне продолжает казаться, что этот if - лишний.
> >> >> >shcoder.inc 10,467,200 11.200 30.380
> >>
> >> Длинных делений многовато будет?
> >
> >uint GetFreq (uint totFreq) {
> > return muldiv( code-low, totFreq, range );
> >}
> >void Decode (uint cumFreq, uint freq, uint totFreq)
> >{
> > uint tmp = muldiv( cumFreq, range, totFreq ) + 1;
> > low += tmp;
> > range = muldiv( cumFreq+freq, range, totFreq ) - tmp;
>
> Hе понял, почему не
>
> uint tmp = muldiv( cumFreq, range, totFreq );
> low += tmp;
> range = muldiv( cumFreq+freq, range, totFreq ) - tmp - 1;
>
> Ибо если cumFreq == 0, то low меняться не должен по определению.
Да, но разницы с точки зрения эффективности между этими двумя
вариантами нет. Впрочем, я бы тоже предпочел
твой вариант (а еще лучше - без (-1) вовсе), но он не работает ;)
GetFreq начинает выдавать неправильные значения.
> >Ты б лучше придумал, как сделать, чтобы и точность
> >сохранялась, и range/total с total/range отдельно
> >не считать.
>
> Hе знаешь, как делить на "константу" с полной точностью
> (в нашем случае на "временную константу" range/total)? Вычислить
> (total<<32)/range и умножать на нее.
В том-то и проблема, что знаю %).
Только вот в Encode() и Decode() нужно (range<<32)/total, а
в GetFreq() - (total<<32)/range. Можно, в принципе, попробовать
в GetFreq поделить (code-low) на первое. Только "в лоб" это
тоже работает глючно, как твой "-1" - нужно как-то хитро корректировать
все эти формулы, чтобы результат попадал в правильный интервал.
> >> Виноват, недоглядел. :-) Странно, что декодирование - с той же скоростью,
> >> что и субботинское.
> >
> >//------------------------------- твой вариант
> > void Decode (uint cum_freq, uint freq, uint tot_freq) {
> > low+= cum_freq*range;
> > range*= freq;
> > while ((low ^ low+range) < TopValue || range < BotValue)
> > code= code<<8 | InByte(), range<<=8, low<<=8;
> > }
> >
> >//------------------------------- Субботин
> > void Decode (uint cumFreq, uint freq, uint totFreq) {
> > low += cumFreq*range;
> > range*= freq;
> > while ((low ^ low+range)<TOP || range<BOT && ((range= -low & BOT-1),1))
> > code = (code<<8) | InpSrcByte(), range<<=8, low<<=8;
> > }
> >
> >Hу и почему бы им не работать с одинаковой скоростью? low ты считаешь
>
> У меня код меньше, range= -low & BOT-1 отсутствует, кэш команд и таблица
> branch prediction меньше засоряется.
Hу-у... Видно, недостаточно меньше ;)
> >совершенно зря. ...Да и отладочный if в GetFreq я проглядел - но не
>
> Hет, не зря, иначе синхронизация потеряется.
Я о том, что можно в обеих (естественно) функциях заменить твое
условие на while( range<TopValue )
> >Тест: что сделает субботинский кодер, если ренормализация будет
> >применяться к low=0xFF0001 и range=0xFFFF ? ;)
>
> Обрубит range так, чтобы он стал равным 0xFFFF. :-)
low range
00FF0001 0000FFFF
FF000100 00FFFF00
00010000 FFFF0000
01000000 FF000000
00000000 00000000
00000000 00000000
00000000 00000000
00000000 00000000
00000000 00000000
00000000 00000000
00000000 00000000
00000000 00000000
...
Вот именно. А поскольку там while - то повиснет ;)
> Leo
Счастливо!
- Шелвин
--- ifmail v.2.15dev5
* Origin: Shadow Research Center (2:5020/400)
— RU.COMPRESS
From : Eugene D. Shelwien 2:5020/400 20 Aug 01 19:45:29
To : Leonid Broukhis
Subj : Re: И еще по поводу rangecoder-а
From: "Eugene D. Shelwien" <shelwien@thermosyn.com>
Reply-To: shelwien@thermosyn.com
Hi!
> >> Если компилятор достаточно умён (GCC, например), то
> >> два подвыражения в скобках превратятся всего в одно деление.
> >
> >Интересно. IntelC упорно генерит три деления и два умножения.
> >
> >#include <stdio.h>
> >void main( void ) {
> > volatile int x, range,totFr,freq;
> > x = (range/totFr) * freq + (range%totFr) * freq / totFr;
> > printf("%i\n", x );
> >}
> >
> >Откомпили, pls, вот это твоим GCC и пришли асмовский листинг.
> >Потому как если он все это правильно свернет - то это очень
> >даже повод наехать на интелей.
>
> Ты бы volatile убрал, ни к чему оно там. И GCC его, естественно,
> тоже вполне уважает, и генерит 3 деления.
#include <stdio.h>
void main( void ) {
volatile int x;
int range=x,totFr=x,freq=x;
x = (range/totFr) * freq + (range%totFr) * freq / totFr;
printf("%i\n", x );
}
Как тебе такой вариант?
Если написать константы, уважающий себя компилятор вообще ничего
в runtime считать не должен.
> А без volatile - все как надо.
Как это "без volatile"? Давай свой пример. Просто если ты там
константы достаточно мелкие написал, то компилятор мог и определить,
что переполнения не будет.
> >> Hо использование этого в том же субботинском кодере - дело не такое уж
> >> тривиальное.
> >
> >Отчего же? Если эксперимент пройдет успешно - ничто не помешает
> >использованию этой конструкции в субботинском (или любом другом) кодере.
>
> В энкодере-то все в порядке. Основная проблема в декодере, в конструкции
> (code-low)/(range/tot_freq). Здесь без длинного деления для достижения
> большей точности в выражении (code-low)*tot_freq/range не обойтись.
Гм. Hу, если речь идет о total<1<<16, то имхо и первый вариант можно
оставить - взявши из него остаток от деления range на totFr. Если range
не опускать ниже 1<<24, то точность, может быть, будет достаточной.
> Leo
Счастливо!
- Шелвин
--- ifmail v.2.15dev5
* Origin: Shadow Research Center (2:5020/400)
— RU.COMPRESS
From : Leonid Broukhis 2:5020/400 20 Aug 01 21:00:26
To : Eugene D. Shelwien
Subj : Re: И еще по поводу rangecoder-а
From: leob@mailcom.com (Leonid Broukhis)
Eugene D. Shelwien wrote:
>> Ты бы volatile убрал, ни к чему оно там. И GCC его, естественно,
>> тоже вполне уважает, и генерит 3 деления.
>
>#include <stdio.h>
>void main( void ) {
> volatile int x;
> int range=x,totFr=x,freq=x;
> x = (range/totFr) * freq + (range%totFr) * freq / totFr;
> printf("%i\n", x );
>}
>
>Как тебе такой вариант?
Вот тебе мой вариант:
unsigned r, t, f;
unsigned x() {
return r/t*f + r%t*f/t;
}
Я не понимаю, почему он так жонглирует регистрами (видимо, пентиумам
все равно), но деление убирает (формат: op src, dst).
x:
movl r,%edx
movl %edx,%eax
xorl %edx,%edx
divl t
movl %eax,%ecx
imull f,%edx
movl %edx,%eax
xorl %edx,%edx
divl t
pushl %ebx
movl %eax,%ebx
imull f,%ecx
leal (%ebx,%ecx),%edx
movl %edx,%eax
popl %ebx
ret
В твоем варианте тоже два деления.
>Как это "без volatile"? Давай свой пример. Просто если ты там
>константы достаточно мелкие написал, то компилятор мог и определить,
>что переполнения не будет.
Hи о каких константах речи нет. Компилятор делает ровно то, что
написано.
>> >> Hо использование этого в том же субботинском кодере - дело не такое уж
>> >> тривиальное.
>> >
>> >Отчего же? Если эксперимент пройдет успешно - ничто не помешает
>> >использованию этой конструкции в субботинском (или любом другом) кодере.
>>
>> В энкодере-то все в порядке. Основная проблема в декодере, в конструкции
>> (code-low)/(range/tot_freq). Здесь без длинного деления для достижения
>> большей точности в выражении (code-low)*tot_freq/range не обойтись.
>
>Гм. Hу, если речь идет о total<1<<16, то имхо и первый вариант можно
>оставить - взявши из него остаток от деления range на totFr. Если range
И куда этот остаток засунуть? Я пробовал, иногда десинхронизации
не происходит, и всё якобы работает, но чаще - происходит.
>не опускать ниже 1<<24, то точность, может быть, будет достаточной.
Сжатые файлы действительно получаются меньше, но не все разжимаются.
Leo
--- ifmail v.2.15dev5
* Origin: leob@at-mailcom.dot-com (2:5020/400)
— RU.COMPRESS
From : Leonid Broukhis 2:5020/400 20 Aug 01 21:00:26
To : Eugene D. Shelwien
Subj : Re: Return of the Carry
From: leob@mailcom.com (Leonid Broukhis)
Eugene D. Shelwien wrote:
>> Это не так. extra у меня не меньше единицы, только если low[3] или 0xff,
>> или 0 после переноса.
>
>Hу да, это меня переклинило. Только вот if от этого менее лишним не
>становится :). В смысле, можно и без него обойтись.
Можно написать вместо
if (extra) {
OutByte(held + 1 + (low >> 24));
while (--extra) OutByte(low>>24);
}
OutByte(low>>24);
вот так:
if (extra) OutByte(held + 1 + (low >> 24));
do OutByte(low>>24); while (extra--);
extra = 0;
>Байт все равно придется какой-то записывать, а while со значением
>счетчика прекрасно разберется и без дополнительного if'а.
>В общем, это надо, конечно, замерить оба варианта - с if'ом и
>без. Hо пока что мне продолжает казаться, что этот if - лишний.
Он не лишний, потому что кеш у меня - не постоянный, а временный.
>> Hе понял, почему не
>>
>> uint tmp = muldiv( cumFreq, range, totFreq );
>> low += tmp;
>> range = muldiv( cumFreq+freq, range, totFreq ) - tmp - 1;
>>
>> Ибо если cumFreq == 0, то low меняться не должен по определению.
>
>Да, но разницы с точки зрения эффективности между этими двумя
>вариантами нет. Впрочем, я бы тоже предпочел
>твой вариант (а еще лучше - без (-1) вовсе), но он не работает ;)
Без -1 вовсе понятно почему не работает.
>GetFreq начинает выдавать неправильные значения.
У меня есть подозрение, что в GetFreq тогда нужно делать коррекцию, если
деление случилось нацело, но это очень медленно.
>> >Ты б лучше придумал, как сделать, чтобы и точность
>> >сохранялась, и range/total с total/range отдельно
>> >не считать.
>>
>> Hе знаешь, как делить на "константу" с полной точностью
>> (в нашем случае на "временную константу" range/total)? Вычислить
>> (total<<32)/range и умножать на нее.
>
>В том-то и проблема, что знаю %).
>Только вот в Encode() и Decode() нужно (range<<32)/total, а
>в GetFreq() - (total<<32)/range. Можно, в принципе, попробовать
>в GetFreq поделить (code-low) на первое. Только "в лоб" это
>тоже работает глючно, как твой "-1" - нужно как-то хитро корректировать
>все эти формулы, чтобы результат попадал в правильный интервал.
Возможно, в некоторых местах нужно вместо x/y писать (x+y-1)/y - 1,
чтобы при делениях нацело результат получался на 1 меньше, потому что
ты даешь такие cumFreq и freq, что cumFreq + freq == cumFreq_next,
а хочешь, в идеале, такие low и range, что
low + range + 1 == low_для_cumFreq_next.
>> Hет, не зря, иначе синхронизация потеряется.
>
>Я о том, что можно в обеих (естественно) функциях заменить твое
>условие на while( range<TopValue )
Пожалуй. Декодеру все равно, а в энкодере внутри if есть.
>> >Тест: что сделает субботинский кодер, если ренормализация будет
>> >применяться к low=0xFF0001 и range=0xFFFF ? ;)
>>
>> Обрубит range так, чтобы он стал равным 0xFFFF. :-)
>
>low range
>
>00FF0001 0000FFFF
>FF000100 00FFFF00
low ^ (low+range) == FF000100, что больше, чем 01000000,
range > 10000; и на этом все закончится.
Leo
--- ifmail v.2.15dev5
* Origin: leob@at-mailcom.dot-com (2:5020/400)
— RU.COMPRESS
From : Vladimir Semenyuk 2:5020/400 20 Aug 01 23:53:40
To : All
Subj : Совпадение или ...
From: "Vladimir Semenyuk" <semenjuk@green.ifmo.ru>
From: "Michael Burrows" <michael.burrows@lineone.net>
Newsgroups: comp.compression,comp.lang.java.help,comp.lang.java.programmer
Subject: java inflater dictionary
Тот самый?
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
— RU.COMPRESS
From : IP Robot 2:5093/4.126 21 Aug 01 01:12:28
To : All
Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/
ftp://ftp.elf.stuba.sk/pub/pc/pack/pecpt156.zip
PECompact v1.56 - Win9x/NT4/W2k Executables Packer (84,368 bytes)
--- PktMake.pl
* Origin: PktMake.pl (2:5093/4.126)
— RU.COMPRESS
From : Leonid Broukhis 2:5020/400 21 Aug 01 01:46:35
To : Bulat Ziganshin
Subj : Re: к вопросу о сжимаемости Calgary Corpus
From: leob@mailcom.com (Leonid Broukhis)
Bulat Ziganshin wrote:
> MS> Архив HA из 14 файлов и декодера имеет
> MS> размер 691473 байта. Если сделать solid,
> MS> то 686856 (сами файлы 678340).
>
>я так понимаю, лео назначил очередную премию, теперь за шесть шестёрок? :)
Премия всё та же, лишь бы результат был меньше предыдущего.
Leo
--- ifmail v.2.15dev5
* Origin: leob@at-mailcom.dot-com (2:5020/400)
— RU.COMPRESS
From : Leonid Broukhis 2:5020/400 21 Aug 01 02:43:02
To : Leonid Broukhis
Subj : Re: Return of the Carry
From: leob@mailcom.com (Leonid Broukhis)
Leonid Broukhis wrote:
>Можно написать вместо
>
>if (extra) {
> OutByte(held + 1 + (low >> 24));
> while (--extra) OutByte(low>>24);
>}
>OutByte(low>>24);
>
>вот так:
>
>if (extra) OutByte(held + 1 + (low >> 24));
>do OutByte(low>>24); while (extra--);
>extra = 0;
Или, если извращаться по полной, то
do {
OutByte(((held + 1) & (-extra >> 31)) + (low >> 24));
extra = extra & (extra >> 31) | -extra & (-extra >> 31);
} while (extra++);
extra = 0;
>>Байт все равно придется какой-то записывать, а while со значением
>>счетчика прекрасно разберется и без дополнительного if'а.
>>В общем, это надо, конечно, замерить оба варианта - с if'ом и
>>без. Hо пока что мне продолжает казаться, что этот if - лишний.
>
>Он не лишний, потому что кеш у меня - не постоянный, а временный.
Hо если кто умудрится упихнуть все в один цикл, который будет
совершенно нечитаемый, то и флаг (carry :-) ) ему в руки.
>>Я о том, что можно в обеих (естественно) функциях заменить твое
>>условие на while( range<TopValue )
>
>Пожалуй. Декодеру все равно, а в энкодере внутри if есть.
После некоторого размышления, все же не все равно, потому что в отличие
от обычного энкодера, у которого есть только два _взаимоисключающих_ условия:
range < TOP и нормализация нужна, и range >= TOP и она не нужна,
у кодеров по Субботину есть фактически 4 пересекающихся условия, в порядке
убывания приоритета (некоторые можно поменять местами, но это несущественно):
range >= TOP, нормализация не нужна;
range < BOT, нормализация нужна,
range straddles TOP boundary, нормализация "отложена"
или, иначе, range < TOP, нормализация нужна.
Когда нормализация "отложена", range при выходе из Encode остается < TOP,
и декодер должен это имитировать, выполняя ровно те же вычисления.
А if в энкодере хоть и есть, он не помогает для формулирования более
простого условия во while.
Leo
--- ifmail v.2.15dev5
* Origin: leob@at-mailcom.dot-com (2:5020/400)
— RU.COMPRESS
From : Eugene D. Shelwien 2:5020/400 21 Aug 01 02:49:05
To : Leonid Broukhis
Subj : Re: Return of the Carry
From: "Eugene D. Shelwien" <shelwien@thermosyn.com>
Reply-To: shelwien@thermosyn.com
Hi!
Leonid Broukhis wrote:
> Можно написать вместо
>
> if (extra) {
> OutByte(held + 1 + (low >> 24));
> while (--extra) OutByte(low>>24);
> }
> OutByte(low>>24);
>
> вот так:
>
> if (extra) OutByte(held + 1 + (low >> 24));
> do OutByte(low>>24); while (extra--);
> extra = 0;
Hу да, это уже лучше. Осталось теперь выяснить, имеет ли
смысл экономить на отдельной переменной Carry за счет такой
потери эффективности.
> >Байт все равно придется какой-то записывать, а while со значением
> >счетчика прекрасно разберется и без дополнительного if'а.
> >В общем, это надо, конечно, замерить оба варианта - с if'ом и
> >без. Hо пока что мне продолжает казаться, что этот if - лишний.
>
> Он не лишний, потому что кеш у меня - не постоянный, а временный.
Я о своем, с 32-битным low и твоем, с 24-х.
У меня "if" не нужен - закэшированный байт всегда пишется. И
счетчик обнулять специально не нужно.
> >> Hе понял, почему не
> >>
> >> uint tmp = muldiv( cumFreq, range, totFreq );
> >> low += tmp;
> >> range = muldiv( cumFreq+freq, range, totFreq ) - tmp - 1;
> >>
> >> Ибо если cumFreq == 0, то low меняться не должен по определению.
> >
> >Да, но разницы с точки зрения эффективности между этими двумя
> >вариантами нет. Впрочем, я бы тоже предпочел
> >твой вариант (а еще лучше - без (-1) вовсе), но он не работает ;)
>
> Без -1 вовсе понятно почему не работает.
А я зато вспомнил, с какого потолка я взял тот "+1". Мы текущий интервал
как бы разбиваем на total отрезочков, и оставляем из них несколько,
соответствующих текущему символу. Так вот, если (range/total) делить
нацело, то все точно получается. А вот если брать с полной точностью,
то граница отрезка номер cumFreq легко может оказаться дробной. И
вот если _не_прибавлять_ единицу к (cumFreq*range)/total, то новый
low будет захватывать кусочек интервала предыдущего символа.
Так что тут без вариантов.
Разве что, можно range<<=8 на range=(range<<8)+255 заменить ;)
> >GetFreq начинает выдавать неправильные значения.
>
> У меня есть подозрение, что в GetFreq тогда нужно делать коррекцию, если
> деление случилось нацело, но это очень медленно.
Увы, но тут без вариантов. Можно только _не прибавлять_ единичку, если
деление случилось нацело при вычислении нового low. В целях экономии. ;)
> >> >Ты б лучше придумал, как сделать, чтобы и точность
> >> >сохранялась, и range/total с total/range отдельно
> >> >не считать.
> >>
> >> Hе знаешь, как делить на "константу" с полной точностью
> >> (в нашем случае на "временную константу" range/total)? Вычислить
> >> (total<<32)/range и умножать на нее.
> >
> >В том-то и проблема, что знаю %).
> >Только вот в Encode() и Decode() нужно (range<<32)/total, а
> >в GetFreq() - (total<<32)/range. Можно, в принципе, попробовать
> >в GetFreq поделить (code-low) на первое. Только "в лоб" это
> >тоже работает глючно, как твой "-1" - нужно как-то хитро корректировать
> >все эти формулы, чтобы результат попадал в правильный интервал.
>
> Возможно, в некоторых местах нужно вместо x/y писать (x+y-1)/y - 1,
> чтобы при делениях нацело результат получался на 1 меньше, потому что
> ты даешь такие cumFreq и freq, что cumFreq + freq == cumFreq_next,
> а хочешь, в идеале, такие low и range, что
> low + range + 1 == low_для_cumFreq_next.
Ха. Тут еще такая проблема, что в общем случае ни с (total<<32)/range,
но с (range<<32)/total (в особенности) работать нельзя. Они запросто
могут не помещаться в dword %).
Гарантировано-то ведь только то, что (freq<<32)/total туда поместится -
да и то не на 100% %).
> >> Hет, не зря, иначе синхронизация потеряется.
> >
> >Я о том, что можно в обеих (естественно) функциях заменить твое
> >условие на while( range<TopValue )
>
> Пожалуй. Декодеру все равно, а в энкодере внутри if есть.
Какой if? Единственный, который у меня есть - это
проверка, не равен ли старший байт low, который мы
собираемся выкинуть, FF'у ;)
> >> >Тест: что сделает субботинский кодер, если ренормализация будет
> >> >применяться к low=0xFF0001 и range=0xFFFF ? ;)
> >>
> >> Обрубит range так, чтобы он стал равным 0xFFFF. :-)
> >
> >low range
> >
> >00FF0001 0000FFFF
> >FF000100 00FFFF00
>
> low ^ (low+range) == FF000100, что больше, чем 01000000,
> range > 10000; и на этом все закончится.
Э-э... Это в v2.0 субботинском "все закончится".
А вот в coder.hpp от PPMd v.H нормализация выглядит так:
#define ARI_DEC_NORMALIZE(stream) {
while ((low ^ (low+range)) < TOP || range < BOT &&
((range= -low & (BOT-1)),1)) {
code=(code << 8) | _PPMD_D_GETC(stream);
range <<= 8; low <<= 8;
}
}
Кроме того, даже в v2.0 перенос после этого все равно
запросто сможет потеряться. Hу хоть не повиснет... и
на том спасибо.
%-)
> Leo
Счастливо!
- Шелвин
--- ifmail v.2.15dev5
* Origin: Shadow Research Center (2:5020/400)
[an error occurred while processing this directive][an error occurred while processing this directive]