Re: Separate Printing Mantissa and Exponent of a Floating Point
On Monday, 11 August 2014 at 15:30:30 UTC, Justin Whear wrote: 1. http://dlang.org/phobos/std_bitmanip.html#.FloatRep Could someone briefly outline the algorithm that converts the fraction part of FloatRep into a string in base 10? My first guess is sum = 0; foreach (bit_index i, bit_value b; fraction) if (b == 1) sum += 2^^(-i); return to!string(sum); /Per
Re: Separate Printing Mantissa and Exponent of a Floating Point
On Wednesday, 13 August 2014 at 07:51:30 UTC, Nordlöw wrote:
1. http://dlang.org/phobos/std_bitmanip.html#.FloatRep
Can somebody shortly explain why
import std.stdio, std.algorithm, std.range, std.stdio,
std.bitmanip;
void main(string args[])
{
{
float x = 1.23e10;
auto y = *cast(FloatRep*)(x);
writeln(y.fraction, , ,
y.exponent, , ,
y.sign);
}
{
double x = 1.23e10;
auto y = *cast(DoubleRep*)(x);
writeln(y.fraction, , ,
y.exponent, , ,
y.sign);
}
}
prints
3623111, 160, false
1945142772629504, 1056, false
safe pure unittest
This is the first time I've seen attributes on unittests: https://github.com/D-Programming-Language/phobos/pull/2349/files#diff-ba05e420ac1da65db044e79304d641b6R179 Has this always been supported? I guess it's good practice to add these on unittests too, but does people even know about this feature? And are there any cons to doing this?
drop* and take* only for specific element values
Are there variants of drop* and take* that only drop element if its equal to a value kind of like strip does? If not I believe they should be added.
Re: safe pure unittest
On 08/13/2014 02:50 PM, Dicebot wrote: On Wednesday, 13 August 2014 at 12:26:02 UTC, simendsjo wrote: This is the first time I've seen attributes on unittests: https://github.com/D-Programming-Language/phobos/pull/2349/files#diff-ba05e420ac1da65db044e79304d641b6R179 Has this always been supported? I guess it's good practice to add these on unittests too, but does people even know about this feature? And are there any cons to doing this? unittest block is effectively just a special function declaration so all function attributes are applicable and act in a similar way. It is an extremely important idiom when you wan't to ensure specific properties of templated function that may be valid or not depending on template arguments. For example, function with output range may be @nogc or not depending if used output range type triggers GC. But you can mark with @nogc unittest that uses it with dummy output range to ensure that _nothing else_ allocated. Thanks. The unittest documentation notes that unittests are functions in one of the sentences, but nothing regarding attributes (except for private) is mentioned: http://dlang.org/unittest.html
Re: drop* and take* only for specific element values
On Wednesday, 13 August 2014 at 12:37:34 UTC, Nordlöw wrote: Are there variants of drop* and take* that only drop element if its equal to a value kind of like strip does? If not I believe they should be added. No, but it'd probably be useful. Maybe call them dropIf/takeIf, or just add an overload that takes a predicate... I'll look into making a pull request sometime this week. How do you envision these working?
Re: drop* and take* only for specific element values
On Wed, 13 Aug 2014 14:28:29 + Meta via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Wednesday, 13 August 2014 at 12:37:34 UTC, Nordlöw wrote: Are there variants of drop* and take* that only drop element if its equal to a value kind of like strip does? If not I believe they should be added. No, but it'd probably be useful. Maybe call them dropIf/takeIf, or just add an overload that takes a predicate... I'll look into making a pull request sometime this week. How do you envision these working? They're called find and until. You just have to give them the opposite predicate that you'd give a function called dropIf or takeIf. - Jonathan M Davis
Re: safe pure unittest
On Wed, Aug 13, 2014 at 03:03:14PM +0200, simendsjo via Digitalmars-d-learn wrote: On 08/13/2014 02:50 PM, Dicebot wrote: On Wednesday, 13 August 2014 at 12:26:02 UTC, simendsjo wrote: This is the first time I've seen attributes on unittests: https://github.com/D-Programming-Language/phobos/pull/2349/files#diff-ba05e420ac1da65db044e79304d641b6R179 Has this always been supported? I guess it's good practice to add these on unittests too, but does people even know about this feature? And are there any cons to doing this? unittest block is effectively just a special function declaration so all function attributes are applicable and act in a similar way. It is an extremely important idiom when you wan't to ensure specific properties of templated function that may be valid or not depending on template arguments. For example, function with output range may be @nogc or not depending if used output range type triggers GC. But you can mark with @nogc unittest that uses it with dummy output range to ensure that _nothing else_ allocated. Thanks. The unittest documentation notes that unittests are functions in one of the sentences, but nothing regarding attributes (except for private) is mentioned: http://dlang.org/unittest.html A PR to fix this would be greatly welcomed. ;-) T -- Why do conspiracy theories always come from the same people??
Re: drop* and take* only for specific element values
On Wed, 13 Aug 2014 07:45:17 -0700 Jonathan M Davis via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Wed, 13 Aug 2014 14:28:29 + Meta via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Wednesday, 13 August 2014 at 12:37:34 UTC, Nordlöw wrote: Are there variants of drop* and take* that only drop element if its equal to a value kind of like strip does? If not I believe they should be added. No, but it'd probably be useful. Maybe call them dropIf/takeIf, or just add an overload that takes a predicate... I'll look into making a pull request sometime this week. How do you envision these working? They're called find and until. You just have to give them the opposite predicate that you'd give a function called dropIf or takeIf. I should probably pointed out that we attempted to put dropWhile and takeWhile into Phobos quite some time ago (which would basically be dropIf and takeIf), but Andrei refused to let them in, because all they did was reverse the predicate, so arguments that they should be added based on the fact that find and until take the opposite predicate aren't going to fly. - Jonathan M Davis
Re: Emacs d-mode cannot handle backquoted backslashe
On Tue, 2014-08-12 at 23:53 +0100, Russel Winder wrote: […] Per Nordlöw has offered a putative fix via a pull request. I'll check out the claim and if it seems to be true (and I fully expect it to be so) I'll accept the pull request. People using MELPA should see the new package quite quickly. Fix committed to the mainline repository. Not sure how long it will take to get into MELPA. Should we release 2.0.7? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Linked list as a bidirectional range? I have some questions...
On Monday, 11 August 2014 at 20:02:38 UTC, H. S. Teoh via Digitalmars-d-learn wrote: Anyway, clearly we're not understanding each other, so let me present some concrete code so that we aren't just talking past each other: I've used your advice and implemented a range over the list as suggested, the problem being i cannot get it to pass the isForwardRange check. Code: http://dpaste.dzfl.pl/cad89406bbcc#line-220 You'll notice the assert on line 220 fails. Any idea what i'm doing wrong?
Re: Linked list as a bidirectional range? I have some questions...
On Wed, Aug 13, 2014 at 06:31:32PM +, Gary Willoughby via Digitalmars-d-learn wrote: On Monday, 11 August 2014 at 20:02:38 UTC, H. S. Teoh via Digitalmars-d-learn wrote: Anyway, clearly we're not understanding each other, so let me present some concrete code so that we aren't just talking past each other: I've used your advice and implemented a range over the list as suggested, the problem being i cannot get it to pass the isForwardRange check. Code: http://dpaste.dzfl.pl/cad89406bbcc#line-220 You'll notice the assert on line 220 fails. Any idea what i'm doing wrong? You need to put @property on .save. T -- Valentine's Day: an occasion for florists to reach into the wallets of nominal lovers in dire need of being reminded to profess their hypothetical love for their long-forgotten.
Re: Linked list as a bidirectional range? I have some questions...
On Wednesday, 13 August 2014 at 18:58:59 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
On Wed, Aug 13, 2014 at 06:31:32PM +, Gary Willoughby via
Digitalmars-d-learn wrote:
On Monday, 11 August 2014 at 20:02:38 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
Anyway, clearly we're not understanding each other, so let me
present
some concrete code so that we aren't just talking past each
other:
I've used your advice and implemented a range over the list as
suggested, the problem being i cannot get it to pass the
isForwardRange check.
Code: http://dpaste.dzfl.pl/cad89406bbcc#line-220
You'll notice the assert on line 220 fails. Any idea what i'm
doing
wrong?
You need to put @property on .save.
Hmm...
struct Result {
public @property auto save1() {
return this;
}
public auto save2() {
return this;
}
}
pragma(msg, typeof(Result.init.save1));
pragma(msg, typeof(Result.init.save2));
This outputs:
Result
Result()
`Result()` looks bogus.
Re: Linked list as a bidirectional range? I have some questions...
On Wed, Aug 13, 2014 at 07:23:30PM +, via Digitalmars-d-learn wrote:
On Wednesday, 13 August 2014 at 18:58:59 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
On Wed, Aug 13, 2014 at 06:31:32PM +, Gary Willoughby via
Digitalmars-d-learn wrote:
[...]
I've used your advice and implemented a range over the list as
suggested, the problem being i cannot get it to pass the
isForwardRange check.
Code: http://dpaste.dzfl.pl/cad89406bbcc#line-220
You'll notice the assert on line 220 fails. Any idea what i'm doing
wrong?
You need to put @property on .save.
Hmm...
struct Result {
public @property auto save1() {
return this;
}
public auto save2() {
return this;
}
}
pragma(msg, typeof(Result.init.save1));
pragma(msg, typeof(Result.init.save2));
This outputs:
Result
Result()
`Result()` looks bogus.
File a bug. :-)
https://issues.dlang.org/enter_bug.cgi
T
--
What is Matter, what is Mind? Never Mind, it doesn't Matter.
Re: Linked list as a bidirectional range? I have some questions...
On Wednesday, 13 August 2014 at 18:58:59 UTC, H. S. Teoh via Digitalmars-d-learn wrote: On Wed, Aug 13, 2014 at 06:31:32PM +, Gary Willoughby via Digitalmars-d-learn wrote: On Monday, 11 August 2014 at 20:02:38 UTC, H. S. Teoh via Digitalmars-d-learn wrote: Anyway, clearly we're not understanding each other, so let me present some concrete code so that we aren't just talking past each other: I've used your advice and implemented a range over the list as suggested, the problem being i cannot get it to pass the isForwardRange check. Code: http://dpaste.dzfl.pl/cad89406bbcc#line-220 You'll notice the assert on line 220 fails. Any idea what i'm doing wrong? You need to put @property on .save. T Gah! Thanks, i need sleep. :)
Re: Linked list as a bidirectional range? I have some questions...
On Wed, Aug 13, 2014 at 07:37:09PM +, Gary Willoughby via Digitalmars-d-learn wrote: On Wednesday, 13 August 2014 at 18:58:59 UTC, H. S. Teoh via Digitalmars-d-learn wrote: On Wed, Aug 13, 2014 at 06:31:32PM +, Gary Willoughby via Digitalmars-d-learn wrote: [...] I've used your advice and implemented a range over the list as suggested, the problem being i cannot get it to pass the isForwardRange check. Code: http://dpaste.dzfl.pl/cad89406bbcc#line-220 You'll notice the assert on line 220 fails. Any idea what i'm doing wrong? You need to put @property on .save. T Gah! Thanks, i need sleep. :) No worries, the only reason I could pinpoint this almost immediately was because I got bitten by exactly the same problem before, and it took me *hours* to figure out what was wrong. :-/ T -- Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte
Re: Linked list as a bidirectional range? I have some questions...
On Wednesday, 13 August 2014 at 19:43:20 UTC, H. S. Teoh via Digitalmars-d-learn wrote: On Wed, Aug 13, 2014 at 07:37:09PM +, Gary Willoughby via Digitalmars-d-learn wrote: On Wednesday, 13 August 2014 at 18:58:59 UTC, H. S. Teoh via Digitalmars-d-learn wrote: On Wed, Aug 13, 2014 at 06:31:32PM +, Gary Willoughby via Digitalmars-d-learn wrote: [...] I've used your advice and implemented a range over the list as suggested, the problem being i cannot get it to pass the isForwardRange check. Code: http://dpaste.dzfl.pl/cad89406bbcc#line-220 You'll notice the assert on line 220 fails. Any idea what i'm doing wrong? You need to put @property on .save. T Gah! Thanks, i need sleep. :) No worries, the only reason I could pinpoint this almost immediately was because I got bitten by exactly the same problem before, and it took me *hours* to figure out what was wrong. :-/ T Thinking about it why should that matter when not compiled using -property? I'm guessing the template enforces it should be a property?
Re: Linked list as a bidirectional range? I have some questions...
On Wed, Aug 13, 2014 at 07:58:49PM +, Gary Willoughby via Digitalmars-d-learn wrote: On Wednesday, 13 August 2014 at 19:43:20 UTC, H. S. Teoh via Digitalmars-d-learn wrote: On Wed, Aug 13, 2014 at 07:37:09PM +, Gary Willoughby via Digitalmars-d-learn wrote: On Wednesday, 13 August 2014 at 18:58:59 UTC, H. S. Teoh via Digitalmars-d-learn wrote: [...] You need to put @property on .save. [...] Gah! Thanks, i need sleep. :) No worries, the only reason I could pinpoint this almost immediately was because I got bitten by exactly the same problem before, and it took me *hours* to figure out what was wrong. :-/ T Thinking about it why should that matter when not compiled using -property? I'm guessing the template enforces it should be a property? The problem is that this test is used in isForwardRange: static assert (is(typeof(r1.save) == R)); where R is the type of the range. So if .save is not @property, then typeof(r1.save) would be a function pointer, rather than the type of the function's return value, and so the test will fail. T -- What do you mean the Internet isn't filled with subliminal messages? What about all those buttons marked submit??
Re: Linked list as a bidirectional range? I have some questions...
On Wednesday, 13 August 2014 at 20:27:29 UTC, H. S. Teoh via Digitalmars-d-learn wrote: On Wed, Aug 13, 2014 at 07:58:49PM +, Gary Willoughby via Digitalmars-d-learn wrote: On Wednesday, 13 August 2014 at 19:43:20 UTC, H. S. Teoh via Digitalmars-d-learn wrote: On Wed, Aug 13, 2014 at 07:37:09PM +, Gary Willoughby via Digitalmars-d-learn wrote: On Wednesday, 13 August 2014 at 18:58:59 UTC, H. S. Teoh via Digitalmars-d-learn wrote: [...] You need to put @property on .save. [...] Gah! Thanks, i need sleep. :) No worries, the only reason I could pinpoint this almost immediately was because I got bitten by exactly the same problem before, and it took me *hours* to figure out what was wrong. :-/ T Thinking about it why should that matter when not compiled using -property? I'm guessing the template enforces it should be a property? The problem is that this test is used in isForwardRange: static assert (is(typeof(r1.save) == R)); where R is the type of the range. So if .save is not @property, then typeof(r1.save) would be a function pointer, rather than the type of the function's return value, and so the test will fail. But wouldn't an be needed to get a function pointer?
Re: Linked list as a bidirectional range? I have some questions...
On Wed, Aug 13, 2014 at 08:52:32PM +, via Digitalmars-d-learn wrote: On Wednesday, 13 August 2014 at 20:27:29 UTC, H. S. Teoh via Digitalmars-d-learn wrote: On Wed, Aug 13, 2014 at 07:58:49PM +, Gary Willoughby via Digitalmars-d-learn wrote: On Wednesday, 13 August 2014 at 19:43:20 UTC, H. S. Teoh via Digitalmars-d-learn wrote: On Wed, Aug 13, 2014 at 07:37:09PM +, Gary Willoughby via Digitalmars-d-learn wrote: On Wednesday, 13 August 2014 at 18:58:59 UTC, H. S. Teoh via Digitalmars-d-learn wrote: [...] You need to put @property on .save. [...] Gah! Thanks, i need sleep. :) No worries, the only reason I could pinpoint this almost immediately was because I got bitten by exactly the same problem before, and it took me *hours* to figure out what was wrong. :-/ T Thinking about it why should that matter when not compiled using -property? I'm guessing the template enforces it should be a property? The problem is that this test is used in isForwardRange: static assert (is(typeof(r1.save) == R)); where R is the type of the range. So if .save is not @property, then typeof(r1.save) would be a function pointer, rather than the type of the function's return value, and so the test will fail. But wouldn't an be needed to get a function pointer? Sorry, my bad. It's just a function, not a function pointer. The type of a function is not the same as the type of its return value (obviously). T -- Study gravitation, it's a field with a lot of potential.
