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" sprintfThan 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
