Re: Does associative array change the location of values?
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/value pairs ever. You are safe to obtain a pointer to a value and it will stay there, even if you remove the key. Who's going to document these implementation details? ;) I mean, if no one, then the above shouldn't be stated. Wouldn't you agree? Given the premise of the question at hand, it does seem useful to know these. But at least one should stress what is and isn't subject to change (even if unlikely). This should be documented for sure
Re: Does associative array change the location of values?
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 stay there, even if you remove the key. Who's going to document these implementation details? ;) I mean, if no one, then the above shouldn't be stated. Wouldn't you agree? Given the premise of the question at hand, it does seem useful to know these. But at least one should stress what is and isn't subject to change (even if unlikely).
Re: Strange multithreading error
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 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 "skeleton.d." In a function I wrote for moving the skeletons, it uses operator overloading, which produces the following output: [...] In order for a member function to be called on a shared object, the function has to be marked shared. Typically done like ```d void opAssign(shared Skeleton rhs) shared ``` -Steve Thank you, this solved my problem.
Re: Strange multithreading error
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``` objects. The specific objects I was using were declared in a file called "skeleton.d." In a function I wrote for moving the skeletons, it uses operator overloading, which produces the following output: [...] In order for a member function to be called on a shared object, the function has to be marked shared. Typically done like ```d void opAssign(shared Skeleton rhs) shared ``` -Steve
Re: abs and minimum values
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_type.min)) == -1);
}
```
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.
this should work on all types:
```d
auto sign(T)(T n) {
return abs(n) / n;
}
```
Surprisingly, no.
sign(short.min) == 1
Strange multithreading error
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 "skeleton.d." In a
function I wrote for moving the skeletons, it uses operator
overloading, which produces the following output:
```d
physics.d(85): Error: none of the `opOpAssign` overloads of
`Point` are callable for `j` of type `shared(Point)`
physics.d(87): Error: none of the `opOpAssign` overloads of
`Point` are callable for `k.start` of type `shared(Point)`
physics.d(88): Error: none of the `opOpAssign` overloads of
`Point` are callable for `k.stop` of type `shared(Point)`
physics.d(90): Error: none of the `opOpAssign` overloads of
`Point` are callable for `i.center` of type `shared(Point)`
physics.d(92): Error: none of the `opOpAssign` overloads of
`Point` are callable for `tomove.center` of type `shared(Point)`
physics.d(112): Error: none of the `opOpAssign` overloads of
`Point` are callable for `k` of type `shared(Point)`
physics.d(114): Error: none of the `opOpAssign` overloads of
`Point` are callable for `j.start` of type `shared(Point)`
physics.d(115): Error: none of the `opOpAssign` overloads of
`Point` are callable for `j.stop` of type `shared(Point)`
physics.d(117): Error: none of the `opOpAssign` overloads of
`Point` are callable for `i.center` of type `shared(Point)`
physics.d(119): Error: none of the `opOpAssign` overloads of
`Point` are callable for `ori.center` of type `shared(Point)`
physics.d(120): Error: none of the overloads of `opAssign` are
callable using a `shared` object
skeleton.d(81):Candidates are:
`skeleton.Skeleton.opAssign(Skeleton rhs)`
skeleton.d(88):
`skeleton.Skeleton.opAssign(shared(Skeleton) rhs)`
physics.d(136): Error: mixin `physics.move.__mov__general__!"n"`
error instantiating
```
This is clearly wrong, as type ```Point``` is not the same as
type ```Skeleton```.
For reference, here are the files:
test.d:
```d
import physics;
void main() {
Skeleton cube;
Face[] cubefaces;
cubefaces.length = 1;
cubefaces[0].lines ~= Line([Point(0,0.25,0), Point(0,0.5,0),
Point(0,0.75,0)], Point(0,0,0), Point(0,1,0));
cubefaces[0].lines ~= Line([Point(0.25,0,0), Point(0.5,0,0),
Point(0.75,0,0)], Point(0,0,0), Point(1,0,0));
cubefaces[0].lines ~= Line([Point(1,0.25,0), Point(1,0.5,0),
Point(1,0.75, 0)], Point(1,0,0), Point(1,1,0));
cubefaces[0].lines ~= Line([Point(0.25,1,0), Point(0.5,1,0),
Point(0.75,1,0)], Point(0,1,0), Point(1,1,0));
cubefaces[0].center = Point(0.5,0.5,0);
cube.faces = cubefaces.dup;
cube.center = Point(0.5,0.5,0);
auto cube2 = cube;
move(Point(99,0,0), 0, cast(shared(Skeleton))cube, 99);
import std.stdio;
import std.concurrency;
spawn(&test1, cast(shared(Skeleton))cube2,
cast(shared(Skeleton))cube);
spawn(&move,Point(-99,0,0), 5, cast(shared(Skeleton))cube, 1);
bool b = receiveOnly!bool;
writeln(b);
}
void test1(shared ref Skeleton cube2, shared ref Skeleton cube) {
import std.concurrency;
if(detectCollision(cast(shared(Skeleton[]))[cube2],
cast(shared(Skeleton))cube, real.infinity))
send(ownerTid(), true);
}
```
skeleton.d:
```d
/*skeleton.d by Ruby The Roobster*/
/*Version 1.0 Release*/
/*Module for representing skeletons in the D Programming Language
2.0*/
/*This program is free software: you can redistribute it and/or
modify
it under the terms of the GNU General Public License as published
by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see
Re: Does associative array change the location of values?
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 find any guarantees similar to C++ iterator invalidation in D Language Reference. 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 about undefined behavior, because the garbage collector will keep the "stale" copy of the value alive as long as you hold a pointer to it. 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 stay there, even if you remove the key. -Steve
Re: Does associative array change the location of values?
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 about undefined behavior, because the garbage collector will keep the "stale" copy of the value alive as long as you hold a pointer to it. Thanks a lot for clarification
Re: abs and minimum values
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 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.
this should work on all types:
```d
auto sign(T)(T n) {
return abs(n) / n;
}
```
Re: Does associative array change the location of values?
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 > > time unless I remove the corresponding key? I couldn't find any > > guarantees similar to C++ iterator invalidation in D Language > > Reference. > > 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 about undefined behavior, because > the garbage collector will keep the "stale" copy of the value alive as > long as you hold a pointer to it. One way to achieve what the OP wants is to store a pointer to a heap-allocated object in the AA. Then AA rehashing won't change the value of the pointer. T -- Designer clothes: how to cover less by paying more.
Re: Does associative array change the location of values?
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++ iterator invalidation in D Language Reference. 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 about undefined behavior, because the garbage collector will keep the "stale" copy of the value alive as long as you hold a pointer to it.
Does associative array change the location of values?
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.
Re: Are there anything like leetcode.com but that supports D?
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'm not a great D developer, but I've been doing development for 17 years and I started casually using D about 2 years later. Let me know if I can help!
Re: abs and minimum values
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 modular, so it represent numbers mapped to a circle rather than a line. Is that a good idea? No, but that is what you have.
Re: abs and minimum values
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 approximations.
Re: abs and minimum values
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.
Re: abs and minimum values
Unsigned integers aren't numbers. assert(-abs(1)<0);
Re: abs and minimum values
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 cause
unexpected results as well. One might expect the following program to
print -1 when that definition of abs() is used in an expression:
import std.traits;
import std.stdio;
/// get the absolute value of x as unsigned type. always succeeds, even
for T.min
Unsigned!T abs(T)(const(T) x) if(isIntegral!T)
{
static if(isSigned!T) if(x < 0) return cast(Unsigned!T)-x;
return x;
}
void main() {
int a = -5;
int b = -4;
writeln(a + abs(b)); // -5 + 4 == -1? (No!)
}
The program prints uint.max.
Ali
Re: What is D's "__debugbreak()" equivalent?
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
just didn't bother adding it.
Re: Vibe.d tutorial
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 Word document. You could enable Github Pages on your repo, export from Word to html, upload that document to the repo, and then let Github Pages handle the rest. You appear to have put a lot of work into it, but posting it as a PDF on Github may reduce your readership. Don't bother reading from GitHub, select the three dot icons on the upper left and click `Download`
Re: What is D's "__debugbreak()" equivalent?
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
Re: Linker issues with struct 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 counting we are using. [...] Postblit? https://dlang.org/spec/struct.html#struct-postblit
Re: Linker issues with struct postblit
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?
Re: abs and minimum values
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 change that. I really think it should return an unsigned type, but that's a "breaking change". Bullshit policy! Eeh... Why does it return unsigned in phobos? Is it just to stay compatible with C? 🤔
Re: abs and minimum values
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 type, but that's a "breaking change". Bullshit policy!
Re: What is D's "__debugbreak()" equivalent?
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:
```D
void debugbreak() nothrow @nogc @trusted {
version(D_InlineAsm_X86_64) {
asm nothrow @nogc {
int 3;
}
} else version(LDC) {
import ldc.intrinsics: llvm_debugtrap;
llvm_debugtrap();
} else {
assert(0); // No `breakPoint` for this compiler configuration
}
}
```
Shouldn't it be this instead, unless D_InlineAsm_X86_64 isn't
available for ldc?
There's also D_InlineAsm_X86 btw.
```D
void debugbreak() nothrow @nogc @trusted {
version(LDC) {
import ldc.intrinsics: llvm_debugtrap;
llvm_debugtrap();
} else version(D_InlineAsm_X86_64) {
asm nothrow @nogc {
int 3;
}
} else {
assert(0); // No `breakPoint` for this compiler configuration
}
}
```
Re: abs and minimum values
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 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.
Depends on how you view it. Imo abs should never be able to
return a negative value since it should be the distance/length
from 0 and alternaticely root of x^2 .
Re: abs and minimum values
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 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" :-( ):
```D
/// get the absolute value of x as unsigned type. always
succeeds, even for T.min
Unsigned!T abs(T)(const(T) x) if(isIntegral!T)
{
static if(isSigned!T) if(x < 0) return cast(Unsigned!T)-x;
return x;
}
```
