== Quote from Nick Sabalausky (a@a.a)'s article
> "Philippe Sigaud" <philippe.sigaud@gmail.com> wrote in message news:mailman.310.1278794218.24349.digitalmars-d-announce@puremagic.com...
> > On Sat, Jul 10, 2010 at 17:42, dsimcha <dsimcha@yahoo.com> wrote:
> >
> >>
> >> This is perfectly feasible, technically speaking.  I'm just not sure what
> >> it would
> >> buy practically speaking.  I kind of like the way x's and o's look.
> >> Maybe
> >> it
> >> would be faster for scatter plots with huge amounts of points, though.  I
> >> don't know.
> >>
> >> I don't know either. It's just it'd give access to some new shapes. But
> > don't bother, you've much more important things on your plate.
> >
> >
> >
> >> (parenthesis in doc)
> >> Thanks.  Fixed.
> >>
> >
> > This is a tiring bug in DDoc. I mean, why does it not generate a doc with
> > a
> > missing parenthesis?
> > (I guess that's filed as bug 3554)
> >
> >
> > > As for bitmaps, I have a small module that load 24 bit RGB .bmp as
> >> > ubyte[3][][] to manipulate them and write an ubyte[3][][] on disk, but
> >> it's
> >> > quite brittle. You indeed need a generic way to save a form to disk as
> >> > an
> >> > image.
> >>
> >> I really want saving to work, but I have no idea what I'm doing Win32
> >> API-wise.
> >> I'd say lack of saving support is by far the biggest outstanding issue
> >> with
> >> DFLPlot.  I'd appreciate any help in this regard.
> >>
> >
> > Halas, not from me: I'm at the same stage than you. At max, I'd know how
> > to
> > draw a graph on an empty bitmap, as long as it can be done by lighting
> > individual pixels. And then saving it to disk.  But putting text in it
> > (with
> > D or any other language) is beyond my ken.
> >
> > I used this technics for a ray-tracer in D and for drawing L-systems, to
> > learn D :-)
> > In fact, the only way I found to save the raytracer images to disk was to
> > manage them as a an array of ubyte[3] and writing this to disk as a 24-but
> > RGB .bmp file.
> >
> > I'll let Win32 wizards answer...
> >
> I'm no Win32 expert, but I've recently looked into this sort of thing for a
> potential side-project, and came up with a few links that might help:
> Bitmaps, Device Contexts and BitBlt
> http://www.winprog.org/tutorial/bitmaps.html
> Drawing Text
> http://msdn.microsoft.com/en-us/library/dd162490(v=VS.85).aspx
> Capturing an Image
> http://msdn.microsoft.com/en-us/library/dd183402(v=VS.85).aspx
> Windows GDI Documentation
> http://msdn.microsoft.com/en-us/library/dd145203(v=VS.85).aspx
> One thing to remember if you don't know already is that having direct
> pixel-by-pixel access involves using an HDIB (Device Independent Bitmap),
> and all the of built-in drawing functions (like drawing text) involve using
> a HDC (Device Context) insetad. (Also, HDIBs and HDCs are handles that get
> passed into free functions, they're not classes or structs.) So there does
> need to be some converting between HDC and HDIB. I assume "Capturing an
> Image" covers that, but I didn't look closely.


Yeah, this is what I tried to do.  I couldn't get it to work because the stuff that needs to be defined in windows.d isn't.  Anyhow, I'm not going to waste too much time on anything that requires directly messing w/ the Win32 API, since long term this lib should be cross-platform anyhow (which might mean me porting dflplot to gtkD) and there should be an easy way of converting a Bitmap to an array of bytes in DFL w/o using the Win32 API directly (and hopefully this will get fixed).

If someone actually wrote me the code to get the bits out of a DFL Bitmap or MemoryGraphics object and gave it to me under the Boost license or something compatible, I'd absolutely include it and give credit, but it's not something I'm going to put tons of effort into writing myself.

When I saw David's announcement this morning, I remembered that he brought up this topic sometime ago(about half-year I think) and I promised to have a look at wrapping Qwt (http:// qwt.sourceforge.net/) as a part of QtD after we make next release. We never released the next version of QtD (as usual due to the lack of manpower and time), but we are still working on it and hopefully we'll make it soon. I decided not to wait until the release, and try to wrap Qwt with the development version of QtD. And it worked pretty well! I'm writing about it not to belittle David's fantastic work, which was written from scratch and for sure deserves admiration, but rather to do what I promised and I hope it will be useful.

So far I haven't ported all classes from the library, but the most difficult part of wrapping is done, and binding the rest of the classes should be easy, which I will complete shortly. I ported one of the Qwt examples from C++ to D to give a feel on how to use the binding, which is available here: http://dsource.org/projects/qtd/browser/examples/qwt/simpleplot . Also, screencapture of this little program in action: http://img13.imageshack.us/img13/6600/ simpleplot.png .

The binding is cross-platform, I tested it on Linux and Windows. For the latter, there are pre-built packages which can be downloaded from http://dsource.org/projects/qtd/wiki/ Packages . For linux it should not be difficult to build them from sources, most of the distributions contain Qwt. From what I read in the thread there is a problem with saving the plots, which isn't solved yet. With Qt there are no such problems, any QWidget can be saved to the pixmap object which you can manipulate as you wish.

There is at least one problem, the mentioned example crashes after you close the application. This problem is known and has nothing to do with Qwt, it's a QtD bug, which is currently being worked on and hopefully we'll resolve the issue.

This is just a result of my one-day experiment. Both dfl+dflplot and QtD+Qwt have their advantages. dfl has nicer API(I must admit I never used it), dflplot has also more Dish feel, while Qt and Qwt are more mature and I think more powerful. In the end, we are in the good position, because we have a choice.

== Quote from Eldar Insafutdinov (e.insafutdinov@gmail.com)'s article
> When I saw David's announcement this morning, I remembered that he brought up
this topic
> sometime ago(about half-year I think) and I promised to have a look at wrapping
Qwt (http://
> qwt.sourceforge.net/) as a part of QtD after we make next release. We never
released the next
> version of QtD (as usual due to the lack of manpower and time), but we are still
working on
> it and hopefully we'll make it soon. I decided not to wait until the release,
and try to wrap
> Qwt with the development version of QtD. And it worked pretty well! I'm writing
about it not
> to belittle David's fantastic work, which was written from scratch and for sure
deserves
> admiration, but rather to do what I promised and I hope it will be useful. So far I haven't ported all classes from the library, but the most difficult
part of wrapping
> is done, and binding the rest of the classes should be easy, which I will
complete shortly. I
> ported one of the Qwt examples from C++ to D to give a feel on how to use the
binding, which
> is available here:
http://dsource.org/projects/qtd/browser/examples/qwt/simpleplot . Also,
> screencapture of this little program in action:
http://img13.imageshack.us/img13/6600/
> simpleplot.png .
> The binding is cross-platform, I tested it on Linux and Windows. For the latter,
there are
> pre-built packages which can be downloaded from
http://dsource.org/projects/qtd/wiki/
> Packages . For linux it should not be difficult to build them from sources, most
of the
> distributions contain Qwt. From what I read in the thread there is a problem
with saving the
> plots, which isn't solved yet. With Qt there are no such problems, any QWidget
can be saved
> to the pixmap object which you can manipulate as you wish.
> There is at least one problem, the mentioned example crashes after you close the
application.
> This problem is known and has nothing to do with Qwt, it's a QtD bug, which is
currently
> being worked on and hopefully we'll resolve the issue.
> This is just a result of my one-day experiment. Both dfl+dflplot and QtD+Qwt
have their
> advantages. dfl has nicer API(I must admit I never used it), dflplot has also
more Dish feel,
> while Qt and Qwt are more mature and I think more powerful. In the end, we are
in the good
> position, because we have a choice.

Interesting, though from looking at your SimplePlot code and browsing the Qwt website, it looks like Qwt was designed much more as a set of low-level mechanisms with the "everything must be possible" philosophy.

dflplot was designed more with the goal of being as easy to use as, for example, Matlab, in an exploratory context.  It has a "simple things must be simple" philosophy.  It contains a significant amount of policies as well as mechanisms and has defaults for basically everything, and simple plots can be created in a single line of code.

Going off on a tangent a little, my work with dstats and dflplot has convinced me that, given the power of D's metaprogramming facilities, builtin strings and arrays, and fast compile times, there's no reason why, once dflplot and Lars Kyllingstad's SciD mature (I already consider dstats fairly mature), D can't rival Matlab and R in terms of ease of use for scientific and statistical computing, while at the same time being able to do "real" down-and-dirty programming in the same language.  I feel dstats has already accomplished this for the small area of 1-d statistics and dflplot is another step in that direction.  This vision is what's made me stick with D through all the compiler bugs, breaking spec changes and people looking at me funny when I tell them it's my language of choice.

That said, it might be interesting to eventually port my high-level stuff to Qwt, or port it all to qtD.  Unless DFL goes cross-platform soon, eventual goal for dflplot is to abstract away most of the GUI code (compile time abstraction; runtime abstraction would create way too much cruft) and port it to whichever cross-platform GUI lib becomes dominant in the D community.  The GUI backend would simply be set by a version statement.

dsimcha Wrote:

> Interesting, though from looking at your SimplePlot code and browsing the Qwt website, it looks like Qwt was designed much more as a set of low-level mechanisms with the "everything must be possible" philosophy.
> 
> dflplot was designed more with the goal of being as easy to use as, for example, Matlab, in an exploratory context.  It has a "simple things must be simple" philosophy.  It contains a significant amount of policies as well as mechanisms and has defaults for basically everything, and simple plots can be created in a single line of code.
> 
> Going off on a tangent a little, my work with dstats and dflplot has convinced me that, given the power of D's metaprogramming facilities, builtin strings and arrays, and fast compile times, there's no reason why, once dflplot and Lars Kyllingstad's SciD mature (I already consider dstats fairly mature), D can't rival Matlab and R in terms of ease of use for scientific and statistical computing, while at the same time being able to do "real" down-and-dirty programming in the same language.  I feel dstats has already accomplished this for the small area of 1-d statistics and dflplot is another step in that direction.  This vision is what's made me stick with D through all the compiler bugs, breaking spec changes and people looking at me funny when I tell them it's my language of choice.
> 
> That said, it might be interesting to eventually port my high-level stuff to Qwt, or port it all to qtD.  Unless DFL goes cross-platform soon, eventual goal for dflplot is to abstract away most of the GUI code (compile time abstraction; runtime abstraction would create way too much cruft) and port it to whichever cross-platform GUI lib becomes dominant in the D community.  The GUI backend would simply be set by a version statement.

To be honest, I've never used packages like Matlab or R, so I can't tell much, but I definitely understand what your intention is. I think it should be possible to use Qwt as a backend for your high level utilities. Let me know if you have any issues with it.

On Sat, 10 Jul 2010 20:51:15 +0000, dsimcha wrote:

> BTW, since my attachment didn't actually get attached, I've put up the latest screenshot, produced from my demo/testing function, at:
> 
> http://cis.jhu.edu/~dsimcha/dflplot.png


Wow, I'd say that's looking pretty polished already. :)  I think it's great that you've done this, it brings D another step closer to being a versatile numerics language.  I'm looking forward to the day this becomes available for *NIX too.

-Lars

On Sun, Jul 11, 2010 at 13:52, Lars T. Kyllingstad <public@kyllingen.nospamnet> wrote:

> On Sat, 10 Jul 2010 20:51:15 +0000, dsimcha wrote:
>
> > BTW, since my attachment didn't actually get attached, I've put up the latest screenshot, produced from my demo/testing function, at:
> >
> > http://cis.jhu.edu/~dsimcha/dflplot.png<http://cis.jhu.edu/%7Edsimcha/dflplot.png>
>
>
> Wow, I'd say that's looking pretty polished already. :)  I think it's great that you've done this, it brings D another step closer to being a versatile numerics language.  I'm looking forward to the day this becomes available for *NIX too.
>
> -Lars
>

What's the last plot? Some kind of density plot, maybe a heat map?


Philippe

== Quote from Philippe Sigaud (philippe.sigaud@gmail.com)'s article
> --0016e6d77e7b9e1ca7048b1bb56b
> Content-Type: text/plain; charset=ISO-8859-1
> On Sun, Jul 11, 2010 at 13:52, Lars T. Kyllingstad
> <public@kyllingen.nospamnet> wrote:
> > On Sat, 10 Jul 2010 20:51:15 +0000, dsimcha wrote:
> >
> > > BTW, since my attachment didn't actually get attached, I've put up the latest screenshot, produced from my demo/testing function, at:
> > >
> > >
http://cis.jhu.edu/~dsimcha/dflplot.png<http://cis.jhu.edu/%7Edsimcha/dflplot.png>
> >
> >
> > Wow, I'd say that's looking pretty polished already. :)  I think it's great that you've done this, it brings D another step closer to being a versatile numerics language.  I'm looking forward to the day this becomes available for *NIX too.
> >
> > -Lars
> >
> What's the last plot? Some kind of density plot, maybe a heat map? Philippe

Yes, that was just checked in yesterday.  in dflplot it's called a HeatScatter, and it's a subclass of HeatMap.  It's also known as a 2-d histogram.  It's useful if you want to visualize a joint distribution between two variables, but you have a large sample size, so using a scatter plot would produce an overwhelming number of points.

Each cell is either dark (high probability) or light(low probability).  The "hot"
and "cold" color are customizable.  In this case each sample is distributed
Normal(1, 1) on the y-axis and Normal(-2, 1) + x_i on the x-axis.

== Quote from Lars T. Kyllingstad (public@kyllingen.NOSPAMnet)'s article
> On Sat, 10 Jul 2010 20:51:15 +0000, dsimcha wrote:
> > BTW, since my attachment didn't actually get attached, I've put up the latest screenshot, produced from my demo/testing function, at:
> >
> > http://cis.jhu.edu/~dsimcha/dflplot.png
> Wow, I'd say that's looking pretty polished already. :)  I think it's great that you've done this, it brings D another step closer to being a versatile numerics language.  I'm looking forward to the day this becomes available for *NIX too.

Give me a GUI lib that supports *NIX, is reasonably stable/mature in its D2 version, and has a nice API and a *NIX port will happen.  I used DFL for the first iteration because all the computers that I use physically (as opposed to via SSH) have Windows and DFL has all of these properties except *NIX support.

dsimcha wrote:
> In the spirit of making D2 a first-rate scientific computing language, I have
> just uploaded the first usable version of my DFL-based dflplot  plotting
> library to Scrapple.
> 
> Right now dflplot is still a work in progress, but it's good enough to be
> useful for basic exploratory plotting in a scientific or statistical computing
> context, especially in conjunction with other scientific libs like SciD and
> dstats.  I'm sure of this because I've been eating my own dogfood with
> pre-release versions for the past few days and am amazed at how much more I
> like plotting stuff when I can do it w/o having to write stuff out to a text
> file and read it back in Python or Octave and instead can plot it directly from D.

This is great stuff, and really valuable for D. <Ditches own plotting library />

== Quote from Don (nospam@nospam.com)'s article
> dsimcha wrote:
> > In the spirit of making D2 a first-rate scientific computing language, I have just uploaded the first usable version of my DFL-based dflplot  plotting library to Scrapple.
> >
> > Right now dflplot is still a work in progress, but it's good enough to be
> > useful for basic exploratory plotting in a scientific or statistical computing
> > context, especially in conjunction with other scientific libs like SciD and
> > dstats.  I'm sure of this because I've been eating my own dogfood with
> > pre-release versions for the past few days and am amazed at how much more I
> > like plotting stuff when I can do it w/o having to write stuff out to a text
> > file and read it back in Python or Octave and instead can plot it directly from D.
> This is great stuff, and really valuable for D. <Ditches own plotting library />

Since when did you ever have a plotting library?  Or was it not of releasable quality?