Re: InputRange in arrays
On Friday, 31 March 2023 at 04:15:24 UTC, Salih Dincer wrote: ...has it always been possible for arrays to be used as if they were ranges? Playground is a very useful tool, it responds right away :) Up to 2.078.3: Failure with output: - onlineapp.d(4): Error: no property 'popFront' for type 'int[]' onlineapp.d(6): Error: no property 'front' for type 'int[]' - 2.079.1 to 2.087.1: Failure with output: - onlineapp.d(4): Error: no property `popFront` for type `int[]` onlineapp.d(6): Error: no property `front` for type `int[]` - Since 2.088.1: Failure with output: - onlineapp.d(4): Error: no property `popFront` for type `int[]`, perhaps `import std.range;` is needed? onlineapp.d(6): Error: no property `front` for type `int[]`, perhaps `import std.range;` is needed? - SDB@79
Re: InputRange in arrays
On Friday, 31 March 2023 at 03:39:51 UTC, Salih Dincer wrote: May be somewhere D compiler between v2.087 and v2.096 (works) but definitely not before v2.087 (including)... Edit: The Phobos library I'm using is corrupted. That's why the last line was giving an error. But has it always been possible for arrays to be used as if they were ranges? Thanks... SDB@79
InputRange in arrays
Hi, there is a feature when working with the InputRange. I don't
know when it released available. May be somewhere D compiler
between v2.087 and v2.096 (works) but definitely not before
v2.087 (including)...
Anyone know this?
```d
import std.range.primitives;
void main()
{
auto arr = [0, 1];
arr.popFront;
assert(arr.front == 1);
assert(isInputRange!(typeof(arr)));
}
```
SDB@79
Re: The Phobos Put
On 3/30/23 11:44 AM, Paul Backus wrote: It should be fine to have both a `ref` and non-`ref` overload for `put`, though, right? If the non-`ref` overload is only called with rvalues, then it's fine to leave them in an undetermined state, because nothing can access them afterward anyway. There's a certain attempt in phobos in some places to try and ensure code that is going to confuse will not compile. I think this is one of those attempts. Consider that if you pass a slice into `put`, then it returns nothing. There is no indication of what actually was written. It's essentially an inconclusive call, because the "result" is the output range itself. How many elements were written? You can't tell. I'd argue that the way input ranges are used as output ranges today is extremely confusing. It makes sort of a logical sense, but the fact that you need to store your "original" range, and then do some length math to figure out what was written makes such code very awkward all around. The output is decipherable, but not obvious. I stand by my assertion that probably lvalue input ranges should never have been treated as output ranges implicitly. They should have had to go through some sort of wrapper. -Steve
Re: Step by step tutorials for using bindings in D
On Monday, 27 March 2023 at 00:45:28 UTC, Salih Dincer wrote: Likes **17** Views **265** Released on March **8, 2023** I'm surprised that you can get 300 views in a month on a primarily D video, but it's nice to see
Re: The Phobos Put
On Thursday, 30 March 2023 at 13:27:33 UTC, Steven Schveighoffer
wrote:
But you can do `dig.copy(buf[])` since a dynamic array is.
Apparently, we will not be able to get rid of the necessity of
using slices. Neither with "copy" nor with "put"...
```d
import std.algorithm.mutation : copy;
import std.range.primitives : put;
void main()
{
int[8] buf;// = new int[8];
auto dig = [1, 2, 3, 4];
//dig.copy(buf[2..$-2]);/*
auto slice = buf[2..$-2];
dig.copy(slice);
assert(buf == [0, 0, 1, 2, 3, 4, 0, 0]);
buf = 0;
slice.put(dig);//*/
assert(buf == [0, 0, 1, 2, 3, 4, 0, 0]);
}
```
SDB@79
Re: The Phobos Put
On Wednesday, 29 March 2023 at 20:50:04 UTC, Steven Schveighoffer wrote: On 3/29/23 4:29 PM, ag0aep6g wrote: But regardless of Salih's exact intent, the broader point is: a non-ref overload could be added to Phobos. And that would enable `a[1..$-1].phobos_put([2, 3])`. Which is what he asked about originally. I think the idea of requiring ref output ranges is that you can then let the range keep track of its output state. An input range with lvalue elements is therefore an output range, but only if it's accepted via ref, since it has to be iterated as it goes. If you iterate it only internally, then it's either in an undetermined state when you exit `put`, or it is a forward range that was copied without using `save`. It's not the greatest situation. I feel like we probably shouldn't have made lvalue input ranges be output ranges automatically. It should be fine to have both a `ref` and non-`ref` overload for `put`, though, right? If the non-`ref` overload is only called with rvalues, then it's fine to leave them in an undetermined state, because nothing can access them afterward anyway.
Re: The Phobos Put
On 3/29/23 11:01 PM, Salih Dincer wrote:
```d
import std.algorithm.mutation : copy;
void main()
{
int[8] buf;
auto dig = [1, 2, 3, 4];
auto rem = dig.copy(buf);
assert(rem.length == 4);
}
```
Looks like 'copy' has the same overload issue.
A static array is not a range of any kind. What would `popFront` do on a
static array, since the length is part of the type?
But you can do `dig.copy(buf[])` since a dynamic array is.
-Steve
Re: Is this code correct?
On Thursday, 30 March 2023 at 10:29:25 UTC, z wrote: Is this code correct or logically sound? You need to be exact on what 'correct' is. The comment above `triangleFacesCamera` says: Indicates wether a triangle faces an imaginary view point. There's no view point / camera position defined anywhere in your code. Instead, all it's doing is comparing the angle of one triangle side (A->B) with another (B->C) in the XZ plane. This suggests you want to know the triangle winding order: clockwise or counter clockwise. If you search for "triangle winding order" you'll find simple and correct ways to do that. Your code needlessly computes angles, only considers the XZ plane, and doesn't compare the angles correctly. r2 -= r1; return r2 > 0; You need to wrap (r2 - r1) into [-τ/2, τ/2] range, then you can compare with 0.
Is this code correct?
Is this code correct or logically sound?
```D
import std;
enum {side/depth/height and side/height
x,//0
y,//1
z //2
}
/**
Indicates wether a triangle faces an imaginary view point.
*/
bool triangleFacesCamera(float[3] tA, float[3] tB, float[3] tC) {
float r1, r2;
r1 = atan2(tB[x] - tA[x], tB[z] - tA[z]);//tried swapping
parameters without success
r2 = atan2(tC[x] - tB[x], tC[z] - tB[z]);//also tried with tA as
substraction 2nd operand, with same/similar results.
//trying with both is still broken, but appears to change the
breakage pattern.
r2 -= r1;
return r2 > 0;
}
```
For context, it is trying to reproduce an old algorithm that does
the same thing :
```D
//in D pseudo code
extern short sus(byte A, byte B){
r0 = sus(tB[y] - tA[y], tB[x] - tA[x]);
r1 = sus(tC[y] - tA[y], tC[x] - tA[x]);
r1 -= r0;
return r1 > 0;
}
```
`sus` is named so because it makes use of `atan` and a premade
table that *looks like* `tan(a*(a*5.09...))` but is impossible to
exactly reproduce for me.(on a graph it looks like tan but
crammed to loop only four/sixteen/sixtyfour times at τ/4,π,τ)
Trying to parse both `atan2` and `sus` with `(sin(angle),
cos(angle))` as arguments[1] shows that atan2 outputs it as an
angle in `-π~π` angle representation but `sus`'s output differs
in that it looks like `sin(x*2)`.
I'd add images to better illustrate it but do not know how...
Big thanks
[1] https://run.dlang.io/is/xR8TcE
ps: is it normal that sometimes posting has a very long delay?
when it happens it is as if the post has gone nowhere but then it
suddenly appears much later, which can cause confusion and
duplicate posting, oof.
