I think the reason there is no "normalize" is because duration can have
months and years and those mean different things depending on what
timestamp they are relative to.
Agreed on localization, someone we also need for number printing. It just
hasn't been built yet.
On Wed, Jul 20, 2016 at 7:53 AM, Alexander Ilin <ajs...@yandex.ru> wrote:
> Hello, John and Jon!
>
> You both are very helpful, thank you for your replies.
>
> Continuing this general discussion of the calendar* vocabs, I wanted to
> note that I didn't notice anything like a "normalize" word for durations or
> timestamps. That would be very useful for my case. I'd like to have
> something like this:
>
> 3600 seconds normalize
> T{ duration f 0 0 0 0 1 0 0 }
> instead of
> T{ duration f 0 0 0 0 0 0 3600 }
>
> I.e. it should make sure all the lower slots with known limits hold
> valid values (0..60 for seconds and minutes, 0..24 for hours, any number
> for days).
> The question is, however, whether we should allow an arbitrary number of
> days or hours. I guess days are better, and if someone needs to report 26
> hours instead of 1 day 2 hours, it's easy to multiply by 24 and add.
>
> It's a matter of formatting, you see. If I call duration>hms, I want to
> see 26:00:00 rather than 02:00:00 or "1 day 02:00:00".
>
> And lastly, I see that we format times with the colon character. Is
> there a way to make sure the formatting is driven by the current system
> locale settings?
> I agree that the lowest level functions should produce the same string
> on any system for portability (i.e. use ":" for time separation), but if we
> want to present data to users, it might be a good idea to replace ":" with
> something locale-specific, don't you agree? For example, this link seems to
> suggest that in Italy they use the dot (".") as the time separator:
> https://msdn.microsoft.com/en-us/library/8kb3ddd4(v=vs.110).aspx
>
> 20.07.2016, 17:03, "John Benediktsson" <mrj...@gmail.com>:
>
> I would be surprised if that word becomes a bottleneck, but I can
> understand trying to be performance-aware as you build out a system.
>
> Are you dealing with floating point numbers of seconds? Because if so, I
> would guess it easier/faster/more correct to round the number of seconds
> first and then operate on integers. If you aren't dealing with floats,
> then rounding is redundant. So, perhaps something like this:
>
> : seconds>hms ( n -- str )
> round >integer 60 /mod [ 60 /mod ] dip 3array [ pad-00 ] map ":"
> join ;
>
>
> For what it's worth, using formatting is only like 5-7% slower:
>
> "%02d:%02d:%02d" sprintf
>
> Than this equivalent set of sequence operations:
>
> 3array [ pad-00 ] map ":" join
>
>
>
> That's a good idea, I keep forgetting about that formatting option. If
> it's shorter than the original, I'll use that, because performance is not
> an issue per se in my use case (it's UI, not number crunching).
>
>
> On Wed, Jul 20, 2016 at 6:19 AM, Jon Harper <jon.harpe...@gmail.com>
> wrote:
>
> Regarding over engineering, I think that the composability of factor's
> libraries make the object allocations worth it. See
> https://docs.factorcode.org/content/article-cookbook-philosophy.html "Object
> allocation is very cheap. Don't be afraid to create tuples [...]".
>
> However, the restriction to timestamps with TYPED: was added exactly (see
> b059ade5eda) to prevent using those words on durations. That's because
> their internal state doesn't behave like timestamps and you must call the
> duration>XX words instead of accessing the slots directly:
>
> 3600 seconds (timestamp>hms)
> 00:00:3600
>
> 3600 seconds duration>hm
> "01:00"
>
> It looks like we could have more duration>XXX formatting words ?
>
>
> Yes, I need duration>hms. When I tested with (timestamp>hms), I did
> prepare the hours-minutes-seconds split myself before calling the word, so
> the type restriction was not needed in my specific case, but I get your
> point.
>
>
> Also, in calendar.format, write-gmt-offset and write-rfc3339-gmt-offset
> access the slots directly. So now we have:
> 2010 10 10 10 10 10 1 hours <timestamp> timestamp>rfc822
> "Sun, 10 Oct 2010 10:10:10 +0100"
> 2010 10 10 10 10 10 3600 seconds <timestamp> timestamp>rfc822 .
> "Sun, 10 Oct 2010 10:10:10 +0000"
>
> Bug of feature ? :)
>
>
>
> Ha! Nice question. : ) I guess a "normalize" I suggested above could
> help here if used within timestamp>rfc822.
>
> ---=====---
> Александр
>
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning
> reports.http://sdm.link/zohodev2dev
> _______________________________________________
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
>
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
