We've captured the moments from FabCon & SQLCon that everyone is talking about, and we are bringing them to the community, live and on-demand. Starts on April 14th. Register now
Hi,
I was comparing the the standard way of an accumulation with list.generate ; but using a third variable,
but it does not work and im not sure why, can someone help of point me in the direction of some theory on
this; so
here A; works, and B; does not, so [y ] + alist {x} <> [y] + y where y = alist {x}
A;
= let alist =
{2,1,2,3,2,2,1,2,3,1,2,2,1,2,3,2,3,2,1,2}
in
List.Generate( ()=> [ x = 0 , y = alist{0}] ,
each [x] < List.Count( alist),
each [x = [x] + 1, y = [y] + alist{x} ],
each [y] )
B:
let alist =
{2,1,2,3,2,2,1,2,3,1,2,2,1,2,3,2,3,2,1,2}
in
List.Generate( ()=> [ x = 0, y = alist{0}, z = y ],
each [x] < List.Count( alist),
each [x = [x] + 1, y = alist{x} , z = [y] + y ] , each [z] )Richard
Solved! Go to Solution.
In the second example, by substituting, we can see that
z = [y] + y
= alist{[x]} + alist{x}
= alist{[x]} + alist{[x]+1}
Thus z is always the sum of the trailing two alist items.
In the first example, y adds onto it's prior accumulated value rather than resetting as alist{x}. Let each set of [brackets] denote the value from the previous iteration. Then
y = [y] + alist{x}
= [y] + alist([x]+1}
= [[y]] + alist{[x]} + alist{[x]+1}
= [[[y]]] + alist{[[x]]} + alist{[x]} + alist{[x]+1}
= ...
= alist{0} + ... + alist{[x]} + alist{[x]+1}
This is a cumulative sum rather than just the trailing two items.
The key difference is a self-referential update step. z doesn't accumulate because it never refers to its value from prior iterations.
Here's what the iterations look like as a table:
Hi @Dicken ,
@AlexisOlson has already provided a great explanation of why your two List.Generate approaches behave differently. If you’re interested in even more flexibility or want to experiment with more advanced accumulations, here are some extra tips:
If you have a specific accumulation or algorithm in mind beyond what’s already solved, feel free to share it—happy to dive deeper or optimize it together!
Happy coding!
translation and formatting supported by AI
Hi @Dicken ,
@AlexisOlson has already provided a great explanation of why your two List.Generate approaches behave differently. If you’re interested in even more flexibility or want to experiment with more advanced accumulations, here are some extra tips:
If you have a specific accumulation or algorithm in mind beyond what’s already solved, feel free to share it—happy to dive deeper or optimize it together!
Happy coding!
translation and formatting supported by AI
Thnks you both will follow up the link.
Richard.
In the second example, by substituting, we can see that
z = [y] + y
= alist{[x]} + alist{x}
= alist{[x]} + alist{[x]+1}
Thus z is always the sum of the trailing two alist items.
In the first example, y adds onto it's prior accumulated value rather than resetting as alist{x}. Let each set of [brackets] denote the value from the previous iteration. Then
y = [y] + alist{x}
= [y] + alist([x]+1}
= [[y]] + alist{[x]} + alist{[x]+1}
= [[[y]]] + alist{[[x]]} + alist{[x]} + alist{[x]+1}
= ...
= alist{0} + ... + alist{[x]} + alist{[x]+1}
This is a cumulative sum rather than just the trailing two items.
The key difference is a self-referential update step. z doesn't accumulate because it never refers to its value from prior iterations.
Here's what the iterations look like as a table:
If you have recently started exploring Fabric, we'd love to hear how it's going. Your feedback can help with product improvements.
A new Power BI DataViz World Championship is coming this June! Don't miss out on submitting your entry.
Share feedback directly with Fabric product managers, participate in targeted research studies and influence the Fabric roadmap.
| User | Count |
|---|---|
| 5 | |
| 3 | |
| 3 | |
| 2 | |
| 2 |
| User | Count |
|---|---|
| 10 | |
| 8 | |
| 7 | |
| 7 | |
| 5 |