Hi, I’m playing around with NTuple to better familiarize myself with variable length function argument etc. In the process, I encountered an example where type inference failed. Here is a minimal example. function test() tuple = (2,2,2) return tuple[1:2] end @code_warntype test() This ou…

You may also consider using the Base functions first, tail and sometimes the odd reverse(Base.tail(reverse(tup))). These are type stable

While we are waiting for the explanation, you may actually circumvent this problem by giving hint to compiler (actually, I was surprised that you can pass function to the type definition without any performance issues) function test() tuple = (2,2,2) return tuple[1:2] end function test2() …

NTuple{length(1:2), Int is a pretty neat trick! Thanks! For now I will use type hinting as suggested.

Ah thanks! Looks like first, last, Base.tail, Base.front are exactly what I need for the particular use case I have in mind.

For future references. Instead of reverse, tail trick, one may use more straightforward approach with @generated functions @generated function droplast(t::NTuple{N}) where N ex = :() for i in 1:N-1 ex = :($ex..., t[$i]) end return ex end droplast((1, 2, 3, 4)) # (1, 2, 3) I…

Thank you for the link! It is very informative. But how one can avoid generated functions in this case, except of reverse/tail trick which looks odd?

It may look unfamiliar, but it is a very idiomatic solution for these kind of problems. Check out [image] GitHub - mitmath/18S096: 18.S096 three-week course at MIT 18.S096 three-week course at MIT. Contribute to mitmath/18S096 development by creating an account on GitHub. …

[image] Skoffer: But how one can avoid generated functions in this case, except of reverse/tail trick which looks odd? Just writing it explicitly with ntuple often works fine, these seem pretty much indistinguishable: droplast2(t) = ntuple(i -> t[i], length(t)-1) droplast3(t) = reverse(Base…

In one of my real application (a recursive function), I find the performance ntuple > indexing, e.g. t[2:end] > apply multiple Base.tail. The code is type stable (but Cthulhu shows this function is deoptimized). It is wield the Base.tail is so slow.

Type inference with a tuple slice

General Usage

Tamas_Papp February 9, 2020, 4:52pm 7

Generally one would avoid generated functions whenever possible (and here it is possible). See

Topic		Replies	Views
Avoiding type instability when slicing a tuple Performance	10	828	May 2, 2020
Constants not propagated when taking a slice of a tuple General Usage bug	11	749	December 14, 2018
Make this Tuple code faster Performance	11	2099	June 13, 2021
Inference failure on tuple General Usage	10	915	September 4, 2017
Failure in type inference when indexing Tuple with UnitRange (?) General Usage	2	426	November 29, 2016

Type inference with a tuple slice

Related topics