[gst-devel] fractions and aspect ratios

[Thomas Vander Stichele]

Hi,

> > In my mind there is no point in having string ranges.  What would your
> > example represent ? What does the range from "hello" to "world"
> > represent even without the increment ?
> >
> Uh, it wasn't my idea to invent a general range type. ;)
> I just wanted to make you people aware of what that would mean.
> The general list type was only used, because we had a clear definition of
> what it would mean.

Agreed :) But I would make it impossible for string ranges to exist at
this point, since I don't yet see a real use case where they would be
useful.  All I'm promoting is that if we would want to have more than
two types of ranges, it would make a lot more sense to have a general
range type, which then gets restricted on what types the members could
have.

> FWIW, I thought a general range type would behave like this:
> given two GValues min and max, the set of values represented by the range
> would be all GValues x for which gst_value_compare (x, min) returns
> GST_VALUE_EQUAL or GST_VALUE_GREATER_THAN and gst_value_compare (x, max)
> returns GST_VALUE_EQUAL or GST_VALUE_LESS_THAN.

Agreed, with the exception that if there is an increment, it would be
"the set of values, limited to the ones that satisfy the increment".

> This could be made to work with intersections like this:
> The intersection between two ranges [min1, max1] and [min2, max2] would be
> defined as [min3 = MAX(min1, min2), max3 = MIN (max1, max2)], special
> casing the cases max3 < min3 (empty intersection) and min3 == max3 (just
> a simple return value, no range).

Agreed when no increment; when there is an increment, basically it's
intersection of a finite set.

> Subtractions are a little harder, because we don't have open ranges, but
> as I said we're cheating there anyway, so it might be made to work.
> 
> All of this is a lot harder for increments, because we have no concept of
> a distance between two values in our current GValue code.

I don't think we need to - a range with increment implicitly defines a
list.  So the same mathematical concepts apply.  The only problem is
having two ranges with different increments resulting possibly in a set
with no one increment, because it takes values from both.  In that case,
we could chose to either refuse the intersection/subtraction, or convert
to a list.  Not sure (since I don't understand all of gstvalue.c yet) if
that would be a viable approach.

> If I went with this definition and current GstValue string comparisons,
> the range ["hello", "world"] would be defined as all strings that are >=
> "hello" and <= "world" according to strcmp.

That's one possible solution.  But like I said, I can't reason about it
without a real use case.

> > There are 63 possible values for the fps index.  What I'm saying is that
> > something like [ 15/16, 90/16, 15/16 ] is a hell of a lot more
> > understandable than having ( 0.9375, 1.875, ... (numbers snipped because
> > I can't be bothered to calculate them right now, which goes to prove my
> > point) )
> >
> I know that it looks nicer to be able to write it like this, but it also
> means we need to support more code. Intersections and subtractions are
> mandatory.

Yes, and I'm proposing to maintain that code because I think it is
useful.

> FWIW, I don't care wether we use fractions or floats, general ranges or
> special ranges, ranges with or without increments, I'll leave that up
> to the rest of you to decide. But if you invent something new, I'll make
> sure to write a lot of tests for it and have whoever invented them fix all
> of those.

Agreed 100%.  I've added a few already and feel free to suggest more
places to do this.  I was also thinking of making a general gstvalue set
of testsuite cases too, outside of the caps.  That testsuite dir is
currently cluttered and ambiguous.

>  And I'll ask a lot of questions about semantics, too (like the
> string question above).

Scares me slightly more, but I'll try and tackle, because it should be
discussed :)

>  The caps system only rocks so much because there
> are no ambiguities and I'd like it to stay that way.

Great, agreed.

Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
- There it is. Ten thousand dollars. You're not gonna count it?
- Nah.
- You trust me?
- No. But I do kill people.
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/