Re: DateTime::Set - Number of elements in set
> Flavio, is there already a method to determine
> the number of elements in a DateTime::Set?
>
> If not, I can currently make it as_list, and then
> get the length of the list, but it would be
> cleaner to have a method to do this.
What would be a name for this method?
There is no accessor yet. The number of
elements is stored as:
$set->{set}{too_complex} -- if set is infinite
1 + $#{$set->{set}{list}} -- number of elements
- Flavio S. Glock
PS: sorry if this mail is being re-sent,
I had a problem with my webmail
Re: DateTime::Set - Number of elements in set
--- Rick Measham <[EMAIL PROTECTED]> wrote: > Flavio, is there already a method to determine the > number of elements in > a DateTime::Set? > > If not, I can currently make it as_list, and then > get the length of the > list, but it would be cleaner to have a method to do > this. There is an internal method. Would you suggest a name for it? $set->cardinality $set->n $set->??? - Flavio S. Glock __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: DateTime::Set - Number of elements in set
On Mon, 2003-08-18 at 02:37, [EMAIL PROTECTED] wrote:
> > Flavio, is there already a method to determine
> > the number of elements in a DateTime::Set?
> >
> > If not, I can currently make it as_list, and then
> > get the length of the list, but it would be
> > cleaner to have a method to do this.
>
> What would be a name for this method?
$set->length (sound like it could be a DT::Duration between the first
and last)
$set->elements (sounds like a clone of as_list)
$set->count (possible, though could it be a count of something else?)
$set->number_of_elements (long, but self explainitory)
So what does it return? I figure it returns
1 + $#{$set->{set}{list}}
when it can, and it returns
$DateTime::INF
when it can't.
It would also be good if it could accept a span like as_list does.
Then if there is an infinite set (Say a set of Friday 13ths), we can get
the number of them in a particular span. Without the span parameter it
returns the count of the whole set or it returns INF.
Cheers!
Rick
Re: DateTime::Set - Number of elements in set
On Mon, 18 Aug 2003, Flavio S. Glock wrote: > DT::Set v.0.09: > > DateTime::Set count() > > - returns scalar 'Inf' for recurrences; This should probably be undef. We don't know whether or not recurrences are infinite. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Set - Number of elements in set
Dave Rolsky wrote: > > On Mon, 18 Aug 2003, Flavio S. Glock wrote: > > > DateTime::Set count() > > - returns scalar 'Inf' for recurrences; > > This should probably be undef. We don't know whether or not recurrences > are infinite. There are some cases when we don't know if a recurrence has any event at all. This may happen when you do an intersection of recurrences. Otherwise, if they don't have a start and end, they are infinite, right? But 'undef' is ok - I'll change that. - Flavio S. Glock
Re: DateTime::Set - Number of elements in set
On Tue, 19 Aug 2003, Flavio S. Glock wrote: > There are some cases when we don't know if a recurrence has any event at > all. > This may happen when you do an intersection of recurrences. > Otherwise, if they don't have a start and end, they are infinite, right? > But 'undef' is ok - I'll change that. Well, the set may not have a start or end, but it's quite possible that the callback may simply not return anything before or after certain datetimes. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Set - Number of elements in set
Dave Rolsky wrote: > > On Tue, 19 Aug 2003, Flavio S. Glock wrote: > > > There are some cases when we don't know if a recurrence has any event at > > all. > > This may happen when you do an intersection of recurrences. > > Otherwise, if they don't have a start and end, they are infinite, right? > > But 'undef' is ok - I'll change that. > > Well, the set may not have a start or end, but it's quite possible that > the callback may simply not return anything before or after certain > datetimes. I think this would give an error, in current implementation. If a recurrence ends, it must have an explicit 'end' date. - Flavio S. Glock
Re: DateTime::Set - Number of elements in set
On Tue, 19 Aug 2003, Flavio S. Glock wrote: > > > There are some cases when we don't know if a recurrence has any event at > > > all. > > > This may happen when you do an intersection of recurrences. > > > Otherwise, if they don't have a start and end, they are infinite, right? > > > But 'undef' is ok - I'll change that. > > > > Well, the set may not have a start or end, but it's quite possible that > > the callback may simply not return anything before or after certain > > datetimes. > > I think this would give an error, in current implementation. > If a recurrence ends, it must have an explicit 'end' date. If we want to document and specify that this is an error, then the size should be infinite. Otherwise, if we might want to allow this in the future, undef is correct. I don't feel too terribly strongly either way. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Set - Number of elements in set
Dave Rolsky wrote: > > On Tue, 19 Aug 2003, Flavio S. Glock wrote: > > > > > There are some cases when we don't know if a recurrence has any event at > > > > all. > > > > This may happen when you do an intersection of recurrences. > > > > Otherwise, if they don't have a start and end, they are infinite, right? > > > > But 'undef' is ok - I'll change that. > > > > > > Well, the set may not have a start or end, but it's quite possible that > > > the callback may simply not return anything before or after certain > > > datetimes. > > > > I think this would give an error, in current implementation. > > If a recurrence ends, it must have an explicit 'end' date. > > If we want to document and specify that this is an error, then the size > should be infinite. Otherwise, if we might want to allow this in the > future, undef is correct. I don't feel too terribly strongly either way. Ok. So let's document that it is an error. Note that DateTime::Set 0.10 changes the way sets are 'counted'. DateTime::Set has quite a variety of internal types of sets: 1 - simple list of dates. 2 - plain recurrence. 3 - recurrence with start date _or_ end date. 4 - recurrence with start _and_ end dates. 5 - function of recurrences. In sets of type 1, the count is a plain number; Sets of type 2 and 3 have an 'infinite' count; Sets of type 4 are 'huge sets'. These have an 'unknown' count. The count can be thousands or even millions of dates, but it is not infinite. Before version 0.10, you would run out of memory if you specified something like "all seconds in the century". Now, the program will just go on normally - it creates a 'huge set'. And it doesn't attempt to count the set elements. Sets of type 5 can have either an infinite or an unknown count: intersections always have 'unknown' count; unions are infinite if both sets are infinite. How about: return 'infinity' when we _know_ the set is infinite, and return 'undef' when we don't know how big the set is. - Flavio S. Glock
Re: DateTime::Set - Number of elements in set
On Tue, 2 Sep 2003, Flavio S. Glock wrote: > > If we want to document and specify that this is an error, then the size > > should be infinite. Otherwise, if we might want to allow this in the > > future, undef is correct. I don't feel too terribly strongly either way. > > Ok. So let's document that it is an error. Sounds good. We can always change it later if we decide we need that flexibility. > How about: return 'infinity' when we _know_ the set is infinite, and > return 'undef' when we don't know how big the set is. That works. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Set - Number of elements in set
Flavio S. Glock wrote: > Sets of type 4 are 'huge sets'. These have an 'unknown' count. The count > can be thousands or even millions of dates, but it is not infinite. - or two or three - > Before version 0.10, you would run out of memory if you specified > something like "all seconds in the century". > Now, the program will just go on normally - it creates a 'huge set'. And > it doesn't attempt to count the set elements. Would there be some way we could 'guess' if it's loo large to count? Or maybe if a count is requested, we count 10,000 and then return undef if there's more? I'm thinking there would be a lot of recurrences such as 'every tuesday' with restraints such as 'in 2003'. This is easily countable and probably useful. The 'guess' part would be to look at the recurrence and check it's 'density'. With the occurrence above, the density is 1/week. Given a start and end date, we could calculate this for a large number of years. Lets say this module doesn't return counts over 10,000. We build in yearly guestimates for our density denominators. The week guestimate is 52. So we can count the elements for (range as years in float)/52 recurrences. If we have a recurrence of 'every second' then the yearly guestimate is 60*60*24*356.25. Now we can take our (range as years in float) and divide it by our yearly guestimate. If the result is over 10,000 we return undef. While all this is a heap of code, we can quickly see if it's worth counting the actual occurrences. ALSO If we go this path or not, I'd prefer not to get plain undef back. I'd like an indication that it was 'too hard to count', or that it was 'over 10,000'. Cheers! Rick
Re: DateTime::Set - Number of elements in set
Rick Measham wrote: > > Flavio S. Glock wrote: > > Sets of type 4 are 'huge sets'. These have an 'unknown' count. The > count > > can be thousands or even millions of dates, but it is not infinite. > > - or two or three - Two or three are ok :) > > Before version 0.10, you would run out of memory if you specified > > something like "all seconds in the century". > > Now, the program will just go on normally - it creates a 'huge set'. > And > > it doesn't attempt to count the set elements. > > Would there be some way we could 'guess' if it's loo large to count? Or > maybe if a count is requested, we count 10,000 and then return undef if > there's more? That's the way it works, kind of. I set the count limit to 200 elements. This seems to fit most practical uses. > I'm thinking there would be a lot of recurrences such as 'every tuesday' > with restraints such as 'in 2003'. This is easily countable and probably > useful. No problem with this, it's below the limit. > The 'guess' part would be to look at the recurrence and check it's > 'density'. With the occurrence above, the density is 1/week. Given a > start and end date, we could calculate this for a large number of years. > Lets say this module doesn't return counts over 10,000. We build in > yearly guestimates for our density denominators. The week guestimate is > 52. So we can count the elements for (range as years in float)/52 > recurrences. > > If we have a recurrence of 'every second' then the yearly guestimate is > 60*60*24*356.25. Now we can take our (range as years in float) and > divide it by our yearly guestimate. If the result is over 10,000 we > return undef. > > While all this is a heap of code, we can quickly see if it's worth > counting the actual occurrences. That's a good idea, but some sets have a variable density, such as friday-13. > ALSO If we go this path or not, I'd prefer not to get plain undef back. > I'd like an indication that it was 'too hard to count', or that it was > 'over 10,000'. That would be ok, can you suggest an API? Is it ok to die with a message? - Flavio S. Glock
Re: DateTime::Set - Number of elements in set
On Tue, 3 Sep 2003, Rick Measham wrote:
> ALSO If we go this path or not, I'd prefer not to get plain undef back.
> I'd like an indication that it was 'too hard to count', or that it was
> 'over 10,000'.
But undef means unknown, and if we can't count, we don't know how many
elements are in the set. We certainly can't return a number, and we can't
return a string or object because then people will do:
if ( my $count = $set->count ) { ... }
and that would succeed. So that leaves undef or an exception. It seems
silly to throw an exception here, and in fact I really don't like the idea
of accessor methods throwing exceptions.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
