Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
Why not simply 17.5531 ms ("%.4f ms") to get rid of the
non-ASCII µ prefix?
fwiw I like this solution for the output. It is very clear to
me.
+1
and without space 17.5531ms
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Friday, 17 May 2019 at 18:02:04 UTC, kdevel wrote: On Thursday, 16 May 2019 at 20:31:23 UTC, Vladimir Panteleev wrote: On Thursday, 16 May 2019 at 20:17:37 UTC, Steven Schveighoffer [...] hnsecs is more confusing than nanoseconds. People know what a nanosecond is, a hecto-nano-second is not as familiar a term. Agreed, which is why Duration.toString shouldn't be used to present durations to users. Developers, however, are expected to know what a hectonanosecond is, same as with all the other technical terms. "hectonanosecond" looks like an illegal combination of SI prefixes [1]. I recommend changing the meaning of hnsecs to "[one] hundred nanoseconds". [1] "Prefixes may not be used in combination." https://en.wikipedia.org/wiki/Metric_prefix Exactly it really does not exist. Just try to search it on net. No one know what is it. Only few people from D world use it. Every time I need to work with D and time it takes hours to find out what hnsecs is.
Re: [OT] Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Tuesday, 21 May 2019 at 02:12:10 UTC, Les De Ridder wrote:
On Sunday, 19 May 2019 at 12:24:28 UTC, Patrick Schluter wrote:
On Saturday, 18 May 2019 at 21:05:13 UTC, Les De Ridder wrote:
On Saturday, 18 May 2019 at 20:34:33 UTC, Patrick Schluter
wrote:
* hurrah for French keyboard which has a rarely used µ key,
but none for Ç a frequent character of the language.
That's the lowercase ç. The uppercase Ç is not directly
composable,
No, note that I said and not . Using Lock> it
outputs a 'Ç' for me (at least on X11 with the French layout).
Does not work on Windows. and it gives 9. I tested
also on my Linux Mint box and it output lowercase ç with lock>.
There are 2 other characters that are not available on the
french keyboard: œ and Œ. Quite annoying if you sell beef
(bœuf) and eggs (œufs) in the towns of Œutrange or Œting.
It seems those are indeed not on the French layout at all.
Might I
suggest using the Belgian layout? It is AZERTY too and has both
'œ'
and 'Œ'.
No, it hasn't.
I indeed prefer the Belgian keyboard. It has more composable
deadkey characters accents, tildas. Brackets [{]} and other
programming characters < > | etc, are better placed than on the
French keyboard.
Btw æ and Æ are missing also, but there it's not very important
as there are really only very few words in French that use them
ex-æquo, curriculum vitæ, et cætera
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Thursday, 16 May 2019 at 15:52:05 UTC, Steven Schveighoffer wrote: On 5/16/19 4:27 PM, Vladimir Panteleev wrote: On Thursday, 16 May 2019 at 15:19:03 UTC, Alex wrote: What's an hnsec anyways? Hecto-nano-second, the smallest representable unit of time in SysTime and Duration. The output shouldn't involve the inner workings of the type. It should be changed to say 10 ns. -Steve It's 100ns. 10ns = 1dans = 1 deka-nano-second. deka = 10, hecto = 100 [1] [1] https://www.nist.gov/pml/weights-and-measures/metric-si-prefixes
Re: [OT] Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Sunday, 19 May 2019 at 12:24:28 UTC, Patrick Schluter wrote: On Saturday, 18 May 2019 at 21:05:13 UTC, Les De Ridder wrote: On Saturday, 18 May 2019 at 20:34:33 UTC, Patrick Schluter wrote: * hurrah for French keyboard which has a rarely used µ key, but none for Ç a frequent character of the language. That's the lowercase ç. The uppercase Ç is not directly composable, No, note that I said and not . Using Lock> it outputs a 'Ç' for me (at least on X11 with the French layout). There are 2 other characters that are not available on the french keyboard: œ and Œ. Quite annoying if you sell beef (bœuf) and eggs (œufs) in the towns of Œutrange or Œting. It seems those are indeed not on the French layout at all. Might I suggest using the Belgian layout? It is AZERTY too and has both 'œ' and 'Œ'.
[OT] Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Saturday, 18 May 2019 at 21:05:13 UTC, Les De Ridder wrote: On Saturday, 18 May 2019 at 20:34:33 UTC, Patrick Schluter wrote: * hurrah for French keyboard which has a rarely used µ key, but none for Ç a frequent character of the language. That's the lowercase ç. The uppercase Ç is not directly composable, annoying or to say it in French to illsutrate: "Ça fait chier". I use Alt+1+2+8 on Windows, but most people do not know these ancient OEM-437 based character codes going back to the orignal IBM-PC. The newer ANSI based Alt+0+1+9+9 is one keypress longer and I would have to learn actually the code. There are 2 other characters that are not available on the french keyboard: œ and Œ. Quite annoying if you sell beef (bœuf) and eggs (œufs) in the towns of Œutrange or Œting.
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Saturday, 18 May 2019 at 20:34:33 UTC, Patrick Schluter wrote: * hurrah for French keyboard which has a rarely used µ key, but none for Ç a frequent character of the language.
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Thursday, 16 May 2019 at 15:19:03 UTC, Alex wrote: 1 - 17 ms, 553 ╬╝s, and 1 hnsec That's µs* for micro-seconds. * hurrah for French keyboard which has a rarely used µ key, but none for Ç a frequent character of the language. WTH!! is there any way to just get a normal u rather than some fancy useless asci hieroglyphic? Why don't we have a fancy M? and an h? What's an hnsec anyways?
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Saturday, 18 May 2019 at 00:17:20 UTC, kdevel wrote:
Why not simply 17.5531 ms ("%.4f ms") to get rid of the
non-ASCII µ prefix?
fwiw I like this solution for the output. It is very clear to me.
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Thursday, 16 May 2019 at 15:19:03 UTC, Alex wrote: 1 - 17 ms, 553 ╬╝s, and 1 hnsec fancy useless asci hieroglyphic Holy shirt! All that time I was thinking this is just some sort of encoding artifacts in terminal(common problem on windows), especially because IIRC on Linux it is displaying this greek 'micro' correctly. This is completely out of context, and so should be replaced with something more conventional... Now when I realize it, for me it immediately start look like some sort of cave art or graffiti in art gallery, very unprofessional I say.
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Friday, 17 May 2019 at 18:02:04 UTC, kdevel wrote: On Thursday, 16 May 2019 at 20:31:23 UTC, Vladimir Panteleev wrote: On Thursday, 16 May 2019 at 20:17:37 UTC, Steven Schveighoffer [...] hnsecs is more confusing than nanoseconds. People know what a nanosecond is, a hecto-nano-second is not as familiar a term. Agreed, which is why Duration.toString shouldn't be used to present durations to users. Developers, however, are expected to know what a hectonanosecond is, same as with all the other technical terms. "hectonanosecond" looks like an illegal combination of SI prefixes [1]. I recommend changing the meaning of hnsecs to "[one] hundred nanoseconds". [1] "Prefixes may not be used in combination." https://en.wikipedia.org/wiki/Metric_prefix It through me off, it really makes no sense. The purpose of a prefix is to define something better. hectonano seems contradictory... and is it any different than nanohecto? There really is no point in it, the whole reason for the metric system is to provide a hierarchical resolution. Just use nano or pico
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Friday, 17 May 2019 at 20:30:56 UTC, Bastiaan Veelo wrote:
On Friday, 17 May 2019 at 18:36:00 UTC, ag0aep6g wrote:
I'd suggest "17 ms, and 553.1µs" for a better default (1 hns
is 0.1 µs, right?). No weird "hnsecs", no false precision,
still all the data that is there.
I was going to propose the same. Hns is weird.
Why not simply 17.5531 ms ("%.4f ms") to get rid of the non-ASCII
µ prefix?
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Friday, 17 May 2019 at 18:36:00 UTC, ag0aep6g wrote: I'd suggest "17 ms, and 553.1µs" for a better default (1 hns is 0.1 µs, right?). No weird "hnsecs", no false precision, still all the data that is there. I was going to propose the same. Hns is weird. Bastiaan.
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On 16.05.19 17:55, Vladimir Panteleev wrote: On Thursday, 16 May 2019 at 15:52:05 UTC, Steven Schveighoffer wrote: [...] The output shouldn't involve the inner workings of the type. It should be changed to say 10 ns. If the output is meant for the developer, then I disagree subjectively, as that creates the impression that the lowest resolution or representable unit of time is the nanosecond. If the output is meant for the user, then hectonanoseconds or nanoseconds are going to be almost always irrelevant. The duration should be formatted appropriately to the use case. I'd suggest "17 ms, and 553.1µs" for a better default (1 hns is 0.1 µs, right?). No weird "hnsecs", no false precision, still all the data that is there.
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Thursday, 16 May 2019 at 20:31:23 UTC, Vladimir Panteleev wrote: On Thursday, 16 May 2019 at 20:17:37 UTC, Steven Schveighoffer [...] hnsecs is more confusing than nanoseconds. People know what a nanosecond is, a hecto-nano-second is not as familiar a term. Agreed, which is why Duration.toString shouldn't be used to present durations to users. Developers, however, are expected to know what a hectonanosecond is, same as with all the other technical terms. "hectonanosecond" looks like an illegal combination of SI prefixes [1]. I recommend changing the meaning of hnsecs to "[one] hundred nanoseconds". [1] "Prefixes may not be used in combination." https://en.wikipedia.org/wiki/Metric_prefix
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Thursday, 16 May 2019 at 20:17:37 UTC, Steven Schveighoffer
wrote:
We do have a nanosecond resolution, and it's just rounded down
to the nearest 10.
For example:
auto d = 15.nsecs;
assert(d == 10.nsecs);
I'm not sure how to feel about this. Maybe there was a better way
to handle nanoseconds here.
You shouldn't be relying on what a string says to know what the
tick resolution is.
I don't like that with your proposal, it seems to add data that's
not there. The 0 is entirely fictional. It might as well be part
of the format string.
For example, if I do writefln("%f", 1.0), I get 1.00.
%f is a C-ism, %s does not do that.
hnsecs is more confusing than nanoseconds. People know what a
nanosecond is, a hecto-nano-second is not as familiar a term.
Agreed, which is why Duration.toString shouldn't be used to
present durations to users.
Developers, however, are expected to know what a hectonanosecond
is, same as with all the other technical terms.
If the output is meant for the user, then hectonanoseconds or
nanoseconds are going to be almost always irrelevant. The
duration should be formatted appropriately to the use case.
Depends on the user and the application.
If the durations are so small or so precise that it makes sense
to display them with such precision, then yes, applications would
do better to use nanoseconds instead of hectonanoseconds.
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On 5/16/19 9:17 PM, Steven Schveighoffer wrote: On 5/16/19 4:55 PM, Vladimir Panteleev wrote: If the output is meant for the developer, then I disagree subjectively, as that creates the impression that the lowest resolution or representable unit of time is the nanosecond. It is what it is. The reason hnsecs is used instead of nsecs is because it gives a time range of 20,000 years instead of 2,000 years. We do have a nanosecond resolution, and it's just rounded down to the nearest 10. And to prove my point about it being an obscure term, I forgot it's not 10 nanoseconds, but 100 nanoseconds. oops! For example: auto d = 15.nsecs; assert(d == 10.nsecs); This is not what I was trying to say, even though it's true (both are Duration.zero). I meant: auto d = 150.nsecs; assert(d == 100.nsecs); -Steve
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On 5/16/19 4:55 PM, Vladimir Panteleev wrote:
On Thursday, 16 May 2019 at 15:52:05 UTC, Steven Schveighoffer wrote:
Hecto-nano-second, the smallest representable unit of time in SysTime
and Duration.
The output shouldn't involve the inner workings of the type. It should
be changed to say 10 ns.
If the output is meant for the developer, then I disagree subjectively,
as that creates the impression that the lowest resolution or
representable unit of time is the nanosecond.
It is what it is. The reason hnsecs is used instead of nsecs is because
it gives a time range of 20,000 years instead of 2,000 years.
We do have a nanosecond resolution, and it's just rounded down to the
nearest 10.
For example:
auto d = 15.nsecs;
assert(d == 10.nsecs);
You shouldn't be relying on what a string says to know what the tick
resolution is.
For example, if I do writefln("%f", 1.0), I get 1.00. That doesn't
mean I should assume floating point precision only goes down to 1/1_000_000.
hnsecs is more confusing than nanoseconds. People know what a nanosecond
is, a hecto-nano-second is not as familiar a term.
If the output is meant for the user, then hectonanoseconds or
nanoseconds are going to be almost always irrelevant. The duration
should be formatted appropriately to the use case.
Depends on the user and the application.
-Steve
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Thursday, 16 May 2019 at 16:52:22 UTC, Vladimir Panteleev wrote: On Thursday, 16 May 2019 at 16:49:35 UTC, Alex wrote: Why not just use u? It generally works fine on all the other filesystems * operating systems
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Thursday, 16 May 2019 at 16:49:35 UTC, Alex wrote: Why not just use u? It generally works fine on all the other filesystems, which today have mostly standardized on UTF-8. If that is too much trouble then detect the code page and use u rather than the extended ascii which looks very out of place? Well, a more correct solution would be to check if we're printing to the Windows console, and use Unicode APIs, which would allow this to work regardless of the current 8-bit codepage. However, this (and your suggestion) are complicated to implement due to reasons related to how tightly Phobos is tied to C's FILE* for file input and output.
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Thursday, 16 May 2019 at 15:27:33 UTC, Vladimir Panteleev wrote: On Thursday, 16 May 2019 at 15:19:03 UTC, Alex wrote: 1 - 17 ms, 553 ╬╝s, and 1 hnsec WTH!! is there any way to just get a normal u rather than some fancy useless asci hieroglyphic? Why don't we have a fancy M? and an h? It's outputting UTF-8, but, your console is not configured to display UTF-8. On Windows, you can do so (before running your program), by running: chcp 65001 Or, within your program, by calling: SetConsoleOutputCP(CP_UTF8); Note that this has some negative side effects, which is why D doesn't do it automatically. (Blame Windows.) What's an hnsec anyways? Hecto-nano-second, the smallest representable unit of time in SysTime and Duration. Thanks... Why not just use u? If that is too much trouble then detect the code page and use u rather than the extended ascii which looks very out of place?
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Thursday, 16 May 2019 at 15:52:05 UTC, Steven Schveighoffer wrote: Hecto-nano-second, the smallest representable unit of time in SysTime and Duration. The output shouldn't involve the inner workings of the type. It should be changed to say 10 ns. If the output is meant for the developer, then I disagree subjectively, as that creates the impression that the lowest resolution or representable unit of time is the nanosecond. If the output is meant for the user, then hectonanoseconds or nanoseconds are going to be almost always irrelevant. The duration should be formatted appropriately to the use case.
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On 5/16/19 4:27 PM, Vladimir Panteleev wrote: On Thursday, 16 May 2019 at 15:19:03 UTC, Alex wrote: What's an hnsec anyways? Hecto-nano-second, the smallest representable unit of time in SysTime and Duration. The output shouldn't involve the inner workings of the type. It should be changed to say 10 ns. -Steve
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Thursday, 16 May 2019 at 15:19:03 UTC, Alex wrote: 1 - 17 ms, 553 ╬╝s, and 1 hnsec WTH!! is there any way to just get a normal u rather than some fancy useless asci hieroglyphic? Why don't we have a fancy M? and an h? It's outputting UTF-8, but, your console is not configured to display UTF-8. On Windows, you can do so (before running your program), by running: chcp 65001 Or, within your program, by calling: SetConsoleOutputCP(CP_UTF8); Note that this has some negative side effects, which is why D doesn't do it automatically. (Blame Windows.) What's an hnsec anyways? Hecto-nano-second, the smallest representable unit of time in SysTime and Duration.
1 - 17 ms, 553 ╬╝s, and 1 hnsec
1 - 17 ms, 553 ╬╝s, and 1 hnsec WTH!! is there any way to just get a normal u rather than some fancy useless asci hieroglyphic? Why don't we have a fancy M? and an h? What's an hnsec anyways?
