On Thursday, 28 October 2021 at 21:26:04 UTC, kyle wrote:
Okay I checked the phobos docs and it does say "Limitations
Does not work correctly for signed intergal types and value
Num.min." Should have looked there first, I know. Still seems
pretty silly.
I recommend to implement your own abs
On Thursday, 28 October 2021 at 21:23:15 UTC, kyle wrote:
```
void main()
{
import std.math : abs, sgn;
alias n_type = short; //or int, long, byte, whatever
assert(n_type.min == abs(n_type.min));
assert(sgn(abs(n_type.min)) == -1);
}
```
I stumbled into this fun today. I underst
On Thursday, 28 October 2021 at 09:54:44 UTC, Dennis wrote:
On Wednesday, 27 October 2021 at 16:54:49 UTC, Simon wrote:
What is the equivalent in D?
With LDC, you have:
```D
import ldc.intrinsics: llvm_debugtrap;
```
Combining that with previous answers, you can make something
like this:
`
On Friday, 29 October 2021 at 08:33:07 UTC, Imperatorn wrote:
Imo abs should never be able to return a negative value
Yes, but phobos defines it to return a signed type, so
theoretical it can return negative values. And they won't change
that.
I really think it should return an unsigned typ
On Friday, 29 October 2021 at 09:35:09 UTC, Dom DiSc wrote:
On Friday, 29 October 2021 at 08:33:07 UTC, Imperatorn wrote:
Imo abs should never be able to return a negative value
Yes, but phobos defines it to return a signed type, so
theoretical it can return negative values. And they won't
c
On Thursday, 28 October 2021 at 01:39:10 UTC, Thomas Gregory
wrote:
I am a maintainer of the
[dhtslib](https://github.com/blachlylab/dhtslib) package and I
have been running into issues with a new implementation of
reference counting we are using.
[...]
Postblit?
On Friday, 29 October 2021 at 11:05:14 UTC, Imperatorn wrote:
On Thursday, 28 October 2021 at 01:39:10 UTC, Thomas Gregory
wrote:
I am a maintainer of the
[dhtslib](https://github.com/blachlylab/dhtslib) package and I
have been running into issues with a new implementation of
reference countin
On Friday, 29 October 2021 at 09:32:07 UTC, bauss wrote:
} else version(D_InlineAsm_X86_64) {
just fyi but `int 3;` works just as well in 32 bit as 64
On Tuesday, 2 March 2021 at 04:30:27 UTC, bachmeier wrote:
On Monday, 1 March 2021 at 22:25:39 UTC, Rey Valeza wrote:
[...]
I have to agree with the comment about PDF files on Github. I
tried to read it on my i7 with 16 GB of RAM and my machine
froze. It looks like you wrote it up as a MS Wo
On Friday, 29 October 2021 at 11:36:13 UTC, Adam D Ruppe wrote:
On Friday, 29 October 2021 at 09:32:07 UTC, bauss wrote:
} else version(D_InlineAsm_X86_64) {
just fyi but `int 3;` works just as well in 32 bit as 64
Yeah, that's why I noted that there's also D_InlineAsm_X86 but I
jus
Unsigned integers aren't numbers.
assert(-abs(1)<0);
On 10/29/21 1:05 AM, Dom DiSc wrote:
> I recommend to implement your own abs function this way (was not
> accepted for phobos, as it now does NOT return the same type as the
> argument, which was considered a "breaking change" :-( ):
Combined with automatic type conversions we got from C, it can
On Friday, 29 October 2021 at 14:23:49 UTC, Kagamin wrote:
Unsigned integers aren't numbers.
assert(-abs(1)<0);
That's what I mean. The mapping between number classes and data
types are too vague.
On Friday, 29 October 2021 at 14:23:49 UTC, Kagamin wrote:
Unsigned integers aren't numbers.
assert(-abs(1)<0);
Unsigneds approximate whole numbers of course (truncated on one
side). Likewise signeds approximate integers (across a
restricted interval). As always, we need to be careful with
On Thursday, 28 October 2021 at 21:23:15 UTC, kyle wrote:
I stumbled into this fun today. I understand why abs yields a
negative value here with overflow and no promotion. I just want
to know if it should. Should abs ever return a negative number?
Thanks.
D has defined signed integers to be m
On Sunday, 24 October 2021 at 05:46:48 UTC, Dr Machine Code wrote:
I'd like that to some friends getting start with programming.
Sadly that platform doesn't support D.
I wouldn't mind helping out by reviewing code or answering
questions if they get stuck. My email is my username at
gmail.com.
I want to have a pointer to a value in an associative array. Does
AA guarantee that the value will remain at the same address all
the time unless I remove the corresponding key? I couldn't find
any guarantees similar to C++ iterator invalidation in D Language
Reference.
On Friday, 29 October 2021 at 17:40:38 UTC, Andrey Zherikov wrote:
I want to have a pointer to a value in an associative array.
Does AA guarantee that the value will remain at the same
address all the time unless I remove the corresponding key? I
couldn't find any guarantees similar to C++ iter
On Fri, Oct 29, 2021 at 05:58:24PM +, Paul Backus via Digitalmars-d-learn
wrote:
> On Friday, 29 October 2021 at 17:40:38 UTC, Andrey Zherikov wrote:
> > I want to have a pointer to a value in an associative array. Does AA
> > guarantee that the value will remain at the same address all the
>
On Thursday, 28 October 2021 at 21:23:15 UTC, kyle wrote:
```
void main()
{
import std.math : abs, sgn;
alias n_type = short; //or int, long, byte, whatever
assert(n_type.min == abs(n_type.min));
assert(sgn(abs(n_type.min)) == -1);
}
```
I stumbled into this fun today. I underst
On Friday, 29 October 2021 at 17:58:24 UTC, Paul Backus wrote:
No, the AA does not guarantee that the value will remain in the
same location. Inserting or removing *any* keys could cause the
AA to resize, which may change the locations of all of its
values.
However, you do not have to worry a
On 10/29/21 1:58 PM, Paul Backus wrote:
On Friday, 29 October 2021 at 17:40:38 UTC, Andrey Zherikov wrote:
I want to have a pointer to a value in an associative array. Does AA
guarantee that the value will remain at the same address all the time
unless I remove the corresponding key? I couldn't
I am currently writing a test program for a collision function,
that involves multithreading so I can simultaneously check for
collisions and move a skeleton at the same time. Because of
this, I had to use ```shared``` objects. The specific objects I
was using were declared in a file called "
On Friday, 29 October 2021 at 18:19:58 UTC, Salih Dincer wrote:
On Thursday, 28 October 2021 at 21:23:15 UTC, kyle wrote:
```
void main()
{
import std.math : abs, sgn;
alias n_type = short; //or int, long, byte, whatever
assert(n_type.min == abs(n_type.min));
assert(sgn(abs(n_t
On Friday, 29 October 2021 at 22:02:53 UTC, Ruby The Roobster
wrote:
I am currently writing a test program for a collision function,
that involves multithreading so I can simultaneously check for
collisions and move a skeleton at the same time. Because of
this, I had to use ```shared``` object
On Friday, 29 October 2021 at 23:32:38 UTC, Steven Schveighoffer
wrote:
On Friday, 29 October 2021 at 22:02:53 UTC, Ruby The Roobster
wrote:
I am currently writing a test program for a collision
function, that involves multithreading so I can simultaneously
check for collisions and move a skele
On Friday, 29 October 2021 at 21:00:48 UTC, Steven Schveighoffer
wrote:
This is incorrect, the buckets are each heap allocated. Just
the array of bucket pointers would change.
In addition, AAs do not deallocate the key/value pairs ever.
You are safe to obtain a pointer to a value and it will
On Saturday, 30 October 2021 at 00:49:04 UTC, Stanislav Blinov
wrote:
On Friday, 29 October 2021 at 21:00:48 UTC, Steven
Schveighoffer wrote:
This is incorrect, the buckets are each heap allocated. Just
the array of bucket pointers would change.
In addition, AAs do not deallocate the key/val
28 matches
Mail list logo
