Timeline for How to pass composite function list to SortBy?
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 25, 2012 at 18:55 | comment | added | Leonid Shifrin |
@J.M. Thanks. I used the opportunity to use Composition in a place where it seems natural (which is what you also suggested in that comment).
|
|
| Aug 25, 2012 at 17:59 | comment | added | J. M.'s missing motivation♦ | Quite nice! ${}$ | |
| Jun 21, 2012 at 5:17 | comment | added | alancalvitti | There's no question that you've solved the mathematical essence of the problem. But the solution does not preserve the transparent syntax SortBy displays for simple (ie, no tiebreaker) sort functions - that's all I meant by my earlier comments. Why don't we use assembly language or R? They're Turing complete, so they all capture the mathematics. | |
| Jun 20, 2012 at 22:18 | comment | added | Leonid Shifrin | @alancalvitti This will then be either a more narrow, point solution (since functions can also be represented as symbols, composite heads with sub-values, etc), or will be really complex and would require compile stage to be efficient. I do not exclude that this is possible, but I think that my solution captures the mathematical essence of the problem, which is, function's composition. And when possible, I value mathematical clarity over what may look like a better usability, because a real usability is in supporting the right abstractions. | |
| Jun 20, 2012 at 22:13 | comment | added | alancalvitti | Simpler from the user perspective is related to usability. Can you imagine an implementation of SortBy that recognizes List of Functions and maps Parts to Slot accordingly? Perhaps that's what you meant by the Rule approach. | |
| Jun 20, 2012 at 21:47 | comment | added | Leonid Shifrin | @alancalvitti Thanks for the accept. As for elegance, it seems that we have somewhat different perceptions on that (which is just fine, this is a very subjective matter). I feel that the first solution in the edit is the most elegant, and will be hard-pressed to see anything simpler than that. | |
| Jun 20, 2012 at 21:45 | vote | accept | alancalvitti | ||
| Jun 20, 2012 at 21:44 | comment | added | alancalvitti | sortFun[mySort, Identity] and sortFun[mySort, First] burn/spill highly important syntactic sugar. If the 1st can be somehow massaged into just sortFun, and the 2nd into sortFun[[1]], that would be elegant...But I'll accept your answer & +1 it. | |
| Jun 20, 2012 at 21:40 | history | edited | Leonid Shifrin | CC BY-SA 3.0 |
Added a more elegant version
|
| Jun 20, 2012 at 20:24 | comment | added | Leonid Shifrin |
@alancalvitti I actually don't find carrying sortFun around a big burden. It is a very general wrapper, and it minimally changes the syntax. One can use some shorter name if sortFun is too long. One could also add rules to SortBy, but I'd rather not do it.
|
|
| Jun 20, 2012 at 20:22 | comment | added | alancalvitti | @Leonid, you're a wizard, but I would not call this solution elegant despite your elegant code. Who wants to pass around sortFun and all that. This is something WRI should tackle. | |
| Jun 20, 2012 at 20:10 | comment | added | Leonid Shifrin | @Rojo Thanks :) We seem to be thinking very similarly :) | |
| Jun 20, 2012 at 20:09 | comment | added | Rojo | Superior to mine, +1 | |
| Jun 20, 2012 at 20:07 | history | answered | Leonid Shifrin | CC BY-SA 3.0 |