"Mark Rickerby" wrote... > On 1/16/06, Paul Bryson <[EMAIL PROTECTED]> wrote: >> So in practice, to represent a rating of 4.3 in a range of 1 to 5 >> inclusive >> would be: >> "4.3 [1,5]" > > Note that the Ruby language has native support for ranges, and it uses > a syntax like: > > x = 1..5 > y = 1...5 > z = 'a'..'e' > > x.to_a #=> [1,2,3,4,5] > y.to_a #=> [1,2,3,4] > z.to_a #=> ['a','b','c','d','e'] > > So the common case of integers wouldn't necessarily work directly for > your example: > > x.member? 4.3 #=> false > x === 4.3 #=> false
I'm not familiar with Ruby syntax, but I guess you are saying that the range system built into Ruby is integer only? I'm guessing you could roll your own range functions, but that may not be completely relevant or practical. While not directly relevant to microformats, my mathematician friend suggested storing everything as a percentage. As I've never seen a review with more than two significant digits, you could just multiply the value by whatever amount to make it in a range of 100. Using my example, I guess you could multiply all of the values by 20 and get 86 [1,100]. You are once again using integers, which would be safe for Ruby ranges, and you can always output the values from your database in whatever range you prefer. > That's probably less relevant for the purposes of expression in HTML > though. It's unlikely someone would review something 4.3 stars out of > 5 unless they were dragging a slider bar, or similar kind of UI input, > and not picking the rating directly. A good portion of the numerical ratings on the internet are aggregates of many people voting, usually without their own detailed reviews, so getting a float value for the rating would be pretty likely. I'm also pretty sure that some professional reviewers for papers, reviewing movies, will rate in 0.5 increments, but I have no idea how common that is. > The start..end syntax is quite a nice shorthand for defining a range, > more typographic than mathematical though. I like "..." for being more user friendly, but it may also be more difficult to deal with when parsing. Any input? Atamido _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
