[chuck-users] easy random numbers

[Kassen]

On 21/11/2007, Scott Wheeler <wheeler at kde.org> wrote:
>
>
> But let's say that you want your ChucKoo clock to let you sleep in on
> Saturday.  Well, then you need your date / time class to be able to
> report the day of the week.  Or if you want to say, "How much time is
> there between now and tomorrow at noon?"  You need to have API support
> for adding and subtracting time.



I'm sure this is very naive again, but we do have lots of support for adding
and subtracting time. We have both "time" and "duration" as datatypes and
day, hour, minute,etc, etc, etc as constants ready made.

If we'd have even -say- a function that would report the amount of samples
that have passed since newyear 2000 in our timezone it would be quite
straightforward to discover the amount of time until "tomorow at noon".

The hard bits -as I see it- would be that daylight saving time is variable
per country and that within countries this changes as well from year to year
(for reasons I don't quite understand like much of how government works...).
Just now I read that people are debating whether we should even observe
leap-seconds at all. To me it seems quite clear that we will never be able
to make a function that can predict the whims of politicians in every
country ChucK may be used in with regard to how we will look at the clock
and calendar in the future. I'm not even sure if computers in Israel (which
I assume observes the Jewish calender) or China (which I would guess
observes the Chinese year) use the same calender as my European computers
do.

As I see it right now these are cultural questions which don't need to
matter all that much from a ChucKian point of view. If we'd like to
establish the time from a ChucKian point of view I think it would do to know
the amount of time that has passed since some known point in time (the birth
of the universe, ChucK, Unix or one's favourite religious person, etc) and
to know how the calender we'd like to observe works. We already have enough
ways to deal with time to take it from there on.

Admittedly that would be a bit abstract at the expense of ease of use for
most people most of the time but I don't think that a API to reason about
time as such is the bottle-neck here.


Ok, now that I think about it there are some quite amusing questions. For
example, if we would have such a built in calender/clock, would we be able
to use this?;

if (day % 24::hour) //check to see if we need to adjust for daylight savings
time today

That would be quite funny.
:¬)

Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20071121/f97b7376/attachment.htm