www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - 1 - 17 ms, 553 =?UTF-8?B?4pWs4pWdcyw=?= and 1 hnsec

reply Alex <AJ gmail.com> writes:
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?
May 16 2019
next sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
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.
May 16 2019
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
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
May 16 2019
next sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
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.
May 16 2019
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
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.000000. 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
May 16 2019
next sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
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
May 16 2019
prev sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
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.000000.
%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.
May 16 2019
parent reply kdevel <kdevel vogtner.de> writes:
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
May 17 2019
next sibling parent Alex <AJ gmail.com> writes:
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....
May 17 2019
prev sibling parent Daniel =?UTF-8?B?S296w6Fr?= <kozzi11 gmail.com> writes:
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.
May 27 2019
prev sibling parent reply ag0aep6g <anonymous example.com> writes:
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.
May 17 2019
parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
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.
May 17 2019
parent reply kdevel <kdevel vogtner.de> writes:
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?
May 17 2019
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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.
May 18 2019
parent KnightMare <black80 bk.ru> writes:
 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
May 28 2019
prev sibling parent wjoe <invalid example.com> writes:
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
May 27 2019
prev sibling parent reply Alex <AJ gmail.com> writes:
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?
May 16 2019
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
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.
May 16 2019
parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
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
May 16 2019
prev sibling next sibling parent evilrat <evilrat666 gmail.com> writes:
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.
May 17 2019
prev sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
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?
May 18 2019
parent reply Les De Ridder <les lesderid.net> writes:
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.
<Caps Lock><key marked with '9' on the number row><Caps Lock>
May 18 2019
parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
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.
<Caps Lock><key marked with '9' on the number row><Caps Lock>
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.
May 19 2019
parent reply Les De Ridder <les lesderid.net> writes:
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.
<Caps Lock><key marked with '9' on the number row><Caps Lock>
That's the lowercase ç. The uppercase Ç is not directly composable,
No, note that I said <Caps Lock> and not <Shift>. Using <Caps 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 'Œ'.
May 20 2019
parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
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.
<Caps Lock><key marked with '9' on the number row><Caps Lock>
That's the lowercase ç. The uppercase Ç is not directly composable,
No, note that I said <Caps Lock> and not <Shift>. Using <Caps Lock> it outputs a 'Ç' for me (at least on X11 with the French layout).
Does not work on Windows. <Caps lock> and it gives 9. I tested also on my Linux Mint box and it output lowercase ç with <Caps 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
May 27 2019