[ndslice] Math Index Order

[9il]

libmir/mir#9

[JackStouffer]

Maybe this is a good opportunity to move this to a unit test example?

[9il]

No

[dnadlinger]

Why not?

[9il]

1. I want this example be in the beginning
2. DDOC unittest do not work with module declarations
3. The same unittest already exists without DDOC

[quickfur]

This is a known limitation: https://issues.dlang.org/show_bug.cgi?id=14383

[quickfur]

There is now a fix for this, that will allow (finally!!!) ddoc's unittests to work with module declarations: dlang/dmd#5465

[quickfur]

FYI, dlang/dmd#5465 has been merged, so you can now use ddoc'd unittests for the module docs.

[timotheecour]

Why not simply:

  auto ref opCall(Indexes...)(Indexes _indexes){
    import std.meta;
    return opIndex(Reverse!_indexes);
  }

there should be no runtime penalty in doing so

[9il]

there should be no runtime penalty in doing so

Yes, but

1. Error message should be another
2. Penalty if index is defined as static array
3. This will work a little bit faster in mode without inlining (for indexing it is matter)

[timotheecour]

1. Error message should be another

This is easy to address: simply passing along a CT parameter bool isMathMode to tell how to format error message

[9il]

This is easy to address: simply passing along a CT parameter bool isMathMode to tell how to format error message

pragma(msg, (5-2).stringof); prints 5-2. So, an additional template should be defined :
Code is already small and clear after message refactoring.

[timotheecour]

will it generalize to arbitrary indexing situations without additional code duplication?
(beyond scalar indexes: I'm thinking about this: libmir/mir#10)

the advantage of opIndex(Reverse!_indexes) is that it would work in all indexing situations.

Another advantage could be more code reuse, therefore smaller generated code and less instruction cache miss.

pragma(msg, (5-2).stringof); prints 5-2. So, an additional template should be defined :\

sorry I don't understand what you mean here

[9il]

will it generalize to arbitrary indexing situations without additional code duplication?

According to the index type definitions

1. math fully defined indexes are implemented in this PR
2. math fully defined slices can be implemented in the future with something like allow strided slice indexing: m[0, 0..5, _, R(0, $, 2), R($-1, 0, -2) ] libmir/mir#10
3. math partially defined slices are not defined

fully defined slices can be implemented without code duplication.

[9il]

... continue

the advantage of opIndex(Reverse!_indexes) is that it would work in all indexing situations.

Yes (excluding static arrays), I don't want it for now.

Another advantage could be more code reuse, therefore smaller generated code and less instruction cache miss.

The amount of code in the release mode is obviously the same (because inlining).
Code duplication will be faster for debug mode.

To make this code reusable I need to write additional templates because opIndex(Reverse!_indexes) would not work for static arrays. After all, amount of lines of code would be bigger with generic solution.

[9il]

In addition, this function declaration is good for documentation.

[quickfur]

I trust that @9il knows what he's doing with the ndslice module, plus this is still under experimental, so I'm merging this. Nitpicks can be fixed later.

[9il]

Thx!

[quickfur]

Auto-merge toggled on