Re: Can you simplify nested Indexed types?
On Tuesday, 27 December 2022 at 16:43:49 UTC, Ali Çehreli wrote: On 12/27/22 07:09, Sergei Nosov wrote: If what you are looking for is a way of defining a variable for "any InputRange that produces a specific type (size_t in this case)", then there is inputRangeObject, which uses OOP: https://dlang.org/phobos/std_range_interfaces.html#InputRange I have an additional example here: http://ddili.org/ders/d.en/ranges_more.html#ix_ranges_more.inputRangeObject Ali Thanks, everyone! I guess, this answer is the closest to what I was looking for. Somehow, I missed the range interfaces (and was considering to use `Variant` or smth). It does seem to answer the original question, albeit with layer(s) of indirection. ``` auto indicies = iota(3); RandomAccessFinite!int ai = indexed(a, indicies).inputRangeObject; ai = indexed(ai, iota(2)).inputRangeObject; ``` Still, my gut feel is that some compile-time solution is possible - will, probably, tinker with it for a little more. Why not use filter(), isn't it important to filter out what's in range? That does something different. Well, pretty sure this isn't what you meant by "same variable" but since it technically does what you want, I decided to share it: Basically I'm abusing array and this thing might be pretty memory heavy... Yeah, using arrays is another alternative, but as you mention, it uses more memory and makes index evaluation eager (vs lazy).
Why not allow elementwise operations on tuples?
Hey, everyone!
I was wondering if there's a strong reason behind not
implementing elementwise operations on tuples?
Say, I've decided to store 2d points in a `Tuple!(int, int)`. It
would be convenient to just write `a + b` to yield another
`Tuple!(int, int)`.
I can resort to using `int []` arrays and write elementwise
operations as `c[] = a[] + b[]` which is almost fine - but it
uses dynamic allocation and forces the user to create an explicit
destination variable.
It seems a bit awkward given that it's fairly straightforward to
write smth as
```
T opBinary(string op, T)(T lhs, T rhs)
if (isTuple!T)
{
T result;
static foreach (i; 0 .. T.Types.length)
{
mixin("result.field[i] =
lhs.field[i]"~op~"rhs.field[i];");
}
return result;
}
```
You only need to turn it into a member function to make it work.
You can even make it more general and allow such operations for
different, but compatible tuple types (there's a function
`areCompatibleTuples` to check for such compatibility). Yet,
there's only a specialization for tuple concatenation of
`opBinary` (and an implementation of `opCmp` and `opAssign`).
So, to repeat the question - is this a deliberate decision to not
implement the default elementwise operation?
Re: Can you simplify nested Indexed types?
On Tuesday, 27 December 2022 at 15:20:24 UTC, Salih Dincer wrote: On Tuesday, 27 December 2022 at 15:09:11 UTC, Sergei Nosov wrote: Consider, I have the following code: ```d auto a = [3, 6, 2, 1, 5, 4, 0]; auto indicies = iota(3); auto ai = indexed(a, indicies); //ai = indexed(ai, iota(2)); writeln(ai); ``` I confuse about comment line that I mark... SDB@79 Not sure I'll be more helpful, but I'll try to add more details. I have an array and I use `indexed` on it. Conceptually, I now have a second array, but it doesn't exist in memory explicitly - only a function to map indicies from "second array" to "first array" is stored; all the values are stored once - in the "first array". Now, I want to have third array that will do the same trick with the second array. The problem is that the second array is not really an array (but, conceptually, it is an array with random access). If I create a new variable with `auto` as type - obviously, it works. But can I use the same variable I used to store the "second array"? (In the provided code that doesn't work because of the type mismatch).
Re: Why not allow elementwise operations on tuples?
On Friday, 13 January 2023 at 15:27:26 UTC, H. S. Teoh wrote: On Fri, Jan 13, 2023 at 02:22:34PM +, Sergei Nosov via Digitalmars-d-learn wrote: Hey, everyone! I was wondering if there's a strong reason behind not implementing elementwise operations on tuples? Say, I've decided to store 2d points in a `Tuple!(int, int)`. It would be convenient to just write `a + b` to yield another `Tuple!(int, int)`. I've written a Vec type that implements precisely this, using tuples behind the scenes as the implementation, and operator overloading to allow nice syntax for vector arithmetic. Yeah, that's clear that such an implementation is rather straightforward. Although, I'm a bit confused with your implementation - 1. it doesn't seem to use tuples behind the scenes despite your claim (it uses static array) 2. `alias impl this;` introduces some unexpected interactions (e.g. `~` and `toString` are "intercepted" by the array implementation and yield "wrong" results). Anyway, my original question was primarily about reasoning - why there's no implementation specifically for `std.Tuple`? If it's a "feature, not a bug" - what's the best way to provide an implementation on the client side?
Re: Why not allow elementwise operations on tuples?
On Wednesday, 18 January 2023 at 16:42:00 UTC, JG wrote: I guess such a method wouldn't be particularly generic since a tuple does not need to consist of types that have the same operations e.g. Tuple!(int,string) etc That's where `areCompatibleTuples` function comes in!
