Matching decimal/fraction ranges

Feb. 25, 2012, 12:30 AM
Post: #1




Matching decimal/fraction ranges
I've been trying to change the main text on most sites to 13px and have found that some of them specifiy font sizes in "em" units. For example, "fontsize:0.8125em"
The values that need to be changed are in a range of something like 0.75 to 1.25, but I haven't been able to match the decimal values. It seems like the example below would work but it doesn't. Match = "fontsize:[#0.75:1.25]em" Replace = "fontsize:13px" 

Feb. 25, 2012, 01:37 AM
(This post was last modified: Feb. 25, 2012 01:38 AM by ProxRocks.)
Post: #2




RE: Matching decimal/fraction ranges
i haven't tried it, but try swapping your "[#0.75:1.25]" for "[#0:1].[#25:75]"


Feb. 25, 2012, 09:49 AM
Post: #3




RE: Matching decimal/fraction ranges
proxo's weaknesses:
1. cannot match ranges of decimals. help and some testing implies proxo numerical range expressions must be integers. 2. numerical test "eats" leading zeroes. example: proxo sees 0005 as 5 the test value that begins 0. is easier because the remaining integers never lead with 0 this expression seems to work 0.([#7:9][#75:99][#750:999][#7500:9999]) add diagnostic LOG() Code: 0.([#7:9]$LOG(W7:9)[#75:99]$LOG(W75:99)[#750:999]$LOG(W750:999)[#7500:9999]$LOG(W7500:9999)) 0.0005 no match 0.7005 no match 0.7000 no match 0.7499 no match 0.75 75:99 0.7500 7500:9999 0.9999 7500:9999 we might prefer this match, but it needs extending the match expression to another digit 0.99990 no match I'm going to try to make the other messier values match expression... 1. then 4 more digits, values 0 through 25 

Feb. 25, 2012, 04:49 PM
Post: #4




RE: Matching decimal/fraction ranges
the rabbit hole got deeper and deeper... after hours, my brain lost concentration. (also causing clumsy sentence structure in this post)
An idea: if you usually leave browser Javascript enabled, javascript should do math very conveniently (but I don't know js). otherwise this is as far as i followed the rabbit holes. And maybe the test examples are useful. My previous reply is the 0.nnnn case. i actually tested the expression in the Bounds with only * in Match. Code: (0).([#7:9]$LOG(W7:9)[#75:99]$LOG(W75:99)[#750:999]$LOG(W750:999)[#7500:9999]$LOG(W7500:9999)) above includes small edit, for when real world css might omit leading 0 example .8888 match by .nnnn 0.nnnn case seems ok. same testing of the 1.nnnn case. Code: 1(.(([#0:1001]$LOG(C#0:1 )2$LOG(C2 )([#0:401]$LOG(C#0:4 )5$LOG(C5 )([#0:*]$LOG(C#0:* )$LOG(Cnothing ))))[#0:*])[#0:*]) This filter tests only the 1.nnnn case Code: Name = "FontReSizeCss[sbk20120225T2a 1.nnn was1c" examples of possible css numerical variations. 1.2501 2 5 #0:* 1.24 #0:1 1.2400001 2 1.249 #0:1 1.2499 2 1.24999 2 1 yes 1. yes 1.0 #0:1 1.000 #0:1 1.0000 #0:1 1.00000 #0:1 1.00009 #0:1 1.0009 #0:1 2 [No Match] 2. [No Match] 2.0 [No Match] 3 [No Match] I tested bounds expression alone, in Bounds. (use only an * in Match) Then assembled bounds, 1.nnnn, and 0.nnnn Code: Name = "FontReSizeCss[sbk20120225T1c" Then i found a problem. i hadn't earlier tried this numerical example, which the assembled filter fails to reject: 1.999 used this to test the assembled filter: fontsize:1.999 em I then tested example with only Bounds and with only 1.nnnn They also fail to reject. My suspicion: [#0:*] sub expressions were intended to eat excess trailing digits. But i think these subexpression(s) have too much freedom. For the fail example fontsize:1.999 em the [#0:*] allow the overall Match to act like 1*++em or act like 1.*++em i think those trailing digit subexpressions [#0:*] need to be moved to inside some OR cases, so the [#0:*] cannot eat trailing digits of some examples, which would cause filter to reject. i think the Bounds has similar problem. It eats trailing digits for too many examples. This would be the part: )))*++ em and for the same example 1.999 Sometimes I thought treating digits as characters [04] would be better than treating digits as numerical ranges [#0:4] But I think variations of few or many digits would cause same difficulty to match . Some examples: 1 1. 1.2 1.29999 i think all of this demonstrates how easy to get into a mess. 

Feb. 25, 2012, 05:34 PM
Post: #5




RE: Matching decimal/fraction ranges
preliminary completely different approach.
(except a similar Bounds to filter only when beginning characters are only 0. . 1 1. ) the main part of filter might be able to find number of the digits and location of dot. 0.nnnn 0.nnn 0.nn 0.n .nnnn .nnn .nn n 1.nnnn 1.nnn 1.nn 1.n 1. 1 remove dot. 0nnnn nnnn nnn nn n 1nnnn 1nnn 1nn 1n 1 1 test with different numerical range, depending on original number of digits: 0nnnn, nnnn, 1nnnn [#7500:12500] 0nnn, nnn, 1nnn [#750:1250] 0nn, nn, 1nn [#75:125] 0n, n, 1n [#8:12] 1 [#1] 

Feb. 25, 2012, 10:16 PM
Post: #6




RE: Matching decimal/fraction ranges
Problem with [#m:m] is that it requires integers.
Problem with decimals is that .3 is larger than .200 Try something like Code: [Patterns] HTH 

Feb. 26, 2012, 03:40 AM
Post: #7




RE: Matching decimal/fraction ranges
JJoe, thank you, that one works perfectly with all my test examples so far, even ones without the leading "0".
I may have to adjust the range a bit, depending on results, but it seems pretty simple to tweak. sbk, I appreciate all the testing, although parts of the rabbit hole did get a bit too deep for me to follow. 

« Next Oldest  Next Newest »
