digitalmars.D - multidimensional interface generator
- Vlad Levenfeld (81/81) Jan 10 2015 Hoping to gauge interest and get some advice on this:
- bearophile (5/11) Jan 10 2015 Are those bugs in Bugzilla?
- Vlad Levenfeld (6/8) Jan 10 2015 Understandable, I'll change N to Nat and R to Real or something
Hoping to gauge interest and get some advice on this: Thanks to Kenji's multidimensional operators, I've managed to make a template library for generating multidimensional structures with arbitrary index types. It uses mixin templates that take some user-defined primitives as arguments and uses them to generate uniform-syntax interfaces in several layers (depending on how much functionality you feel like defining) from simple indexing to RAII-enabled buffers. I've been using it to unify GPU data, local arrays and procedurally generated data under generic algorithms and I'm pretty happy with how it works. Its very easy to use (though as the writer I am definitely biased so take that with some salt). Its got hooks for customization and optimization (e.g. transferring data between GPU arrays doesn't cross the PCI bus, you can make it so expensive-to-read data sources precache themselves before copying to target arrays, things like that), debug-build bounds checking (though I'd prefer to tie it to the noboundscheck flag if possible), support for negative and non-integer indices, and comes complete with a set of functional primitives, like the ones in Phobos but obviously had to be reimplemented to work with multidimensional structures. Regarding the functional bits - unittests are pretty extensive, map and zip and the like are capable of nogc, capturing frame pointers, CTFE, some other stuff I'm forgetting, and there's a full suite of type-level functional primitives too (like staticMap, I've got Sort and Reduce and pattern matching stuff, just things I needed to make the multidim stuff work but turned out to be pretty damn useful in their own right). Really there's a metric crapton of functionality all across the board, I've spent the last several months as a shut-in building this thing, and I really just need to get around to doccing it properly. The stuff I've listed just scratches the surface. Here's a little example of the syntax it enables - I make two procedurally-generated checkerboard textures of different coarseness and copy a subregion of one into the other: auto tex1 = ℕ[0..100].by (ℕ[0..100]).map!((i,j) => (i+j)%2? red: yellow).Texture; auto tex2 = ℕ[0..50].by (ℕ[0..50]).map!((i,j) => (i+j)%2? blue: green).grid (100,100).Texture; tex1[50..75, 25..75] = tex2[0..25, 0..50]; where "by" is a cartesian product, "N" is the natural numbers (I also have R), grid is a resampling operator (so you could ostensibly use some subset of R by R and then cast grid on it to discretize, but I've also implemented editable spaces with R and a stack of delegates, to be a bit like Mathematica). Which reminds me - making multidim structures doesn't necessarily involve using the mixins at all, plenty can be accomplished by functional composition. But I digress - like I said, scratching the surface. But the amount of possibilities and features means doccing all the features would be a major effort, and I'm pretty busy with school and stuff... I want to know what the interest is, because, reading the forums, it sounds to me like other people could use something like this, and if I'm right, then I'll definitely prioritize it. But the other problems are this - 1) there's a nontrivial amount of supporting code, some of which is basically reimplementations of some parts of Phobos (mostly std.algorithm, I don't use too many dirty hacks though, mostly workarounds for dmd bugs; its fairly idiomatic D although I haven't tested with immutable yet). I don't know how much of a problem this is, if it is a problem at all. 2) while the thing has been stable under my personal use, I have no idea how much it will need to change if/when others start using it (and I've heard that once you make the first release, you are locked into your public API, for better or worse). I've never tried to open source anything before or offer any kind of "public service" so this is sort of new world for me and I'm not sure what to expect. I feel I especially need some feedback in this area so I don't waste my efforts doing things that aren't useful. So, in summary: The point of this lib is to provide a level of standardization to multidimensional structures and operators while providing a suite of functional tools and handling the petty concerns to let the user focus on business logic. What I want to know is: Is there interest? What points should I have covered before I throw the lib into the outside world? Or should I just open it up and deal with issues as they arise? Any advice on how to go about creating documentation for it that will actually be helpful?
Jan 10 2015
Vlad Levenfeld:auto tex1 = ℕ[0..100].by (ℕ[0..100]).map!((i,j) => (i+j)%2? red: yellow).Texture; auto tex2 = ℕ[0..50].by (ℕ[0..50]).map!((i,j) => (i+j)%2? blue: green).grid (100,100).Texture; tex1[50..75, 25..75] = tex2[0..25, 0..50];The library seems nice, but I don't like Unicode identifiers.mostly workarounds for dmd bugs;Are those bugs in Bugzilla? Bye, bearophile
Jan 10 2015
On Saturday, 10 January 2015 at 22:56:28 UTC, bearophile wrote:The library seems nice, but I don't like Unicode identifiers.Understandable, I'll change N to Nat and R to Real or something and just make unicode aliases in my own code.Are those bugs in Bugzilla?They are, I tag them with // BUG followed by the url to the bugzilla issue, so when I get an email about a fix I can grep for them and clean up.
Jan 10 2015