dsimcha <dsimcha yahoo.com> writes:

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.

dflplot currently supports scatter plots, line plots, histograms, bar plots,
quantile-quantile plots and ROC curves.  It also supports subplots.  The
following limitations currently exist, which will hopefully be eliminated in
short order:

1. Rotated text for Y-Axis labels isn't available in DFL. Therefore, Y-Axis
labels are rendered in ugly columnar text.

2. There is currently no "proper" way to save a plot. This is because DFL's
Bitmap object doesn't provide a way to obtain the underlying pixels yet, and
core.stdc.windows doesn't seem to provide the necessary stuff to do it
manually via the Windows API. In the meantime, a workaround (at least for
manual, as opposed to programmatic, saving) is to take a screenshot using the
print screen key and save this.

3. Clipping isn't supported yet. If you set the axis limits of a plot such
that part of the plot would be cut off, an exception is thrown. Clipping will
likely be supported in the near future.

4. No options (such as axis limits, title, labels, etc.) are exposed yet via
the plot window GUI. This situation will be improved gradually, especially as
DFL improves.

5. Only works on Windows. Eventually, I'll abstract away a bunch of the GUI
logic and port this to gtkD when it matures, or (hopefully) DFL will be ported
to Linux.

The code is located at:  (Eventually this needs a full-fledged project)
http://dsource.org/projects/scrapple/browser/trunk/dflplot/dflplot.d

The docs are at:
http://cis.jhu.edu/~dsimcha/dflplot.html

For those who don't want to install dflplot, dfl and dstats (dstats is
necessary only for the demo/test function and is otherwise not a dependency)
but are curious what dflplot currently looks like, I've attached a screenshot
of a subplot window produced by the demo/test function.

Michal Minich <michal.minich gmail.com> writes:

On Sat, 10 Jul 2010 04:40:04 +0000, dsimcha wrote:

 2. There is currently no "proper" way to save a plot. This is because
 DFL's Bitmap object doesn't provide a way to obtain the underlying
 pixels yet, and core.stdc.windows doesn't seem to provide the necessary
 stuff to do it manually via the Windows API.

When using classical windows api, I'm almost entirely sure that only way 
to have accessible bitmap pixels, while still being able to draw them to 
window is using dib section.

HANDLE cDC;

HBITMAP hBitmap;

BITMAPINFO bmi;
bmi.bmiHeader.biSize = BITMAPINFOHEADER.sizeof;
bmi.bmiHeader.biWidth = w; // must  be rounded to 4
bmi.bmiHeader.biHeight = -h; // must  be rounded to 4
bmi.bmiHeader.biPlanes = 1;
bmi.bmiHeader.biBitCount = 24;
bmi.bmiHeader.biCompression = BI_RGB;

VOID* ppvBits;

HANDLE cDC = CreateCompatibleDC (hDC);

hBitmap = CreateDIBSection (cDC, &bmi, DIB_RGB_COLORS, &ppvBits, null, 0);

if (hBitmap == NULL || ppvBits == NULL)
    throw new Exception ("Failed to Create Device Independed Bitmap 
(DIB)");

HGDIOBJ selectObj = SelectObject (cDC, hBitmap);

if (selectObj == NULL)
    throw new Exception ("Failed to SelectObject the DIB");

ColorBgr* pixRgb = cast (ColorBgr*) ppvBits; // ppvBits are initialized 
bitmap data

//struct ColorBgr { ubyte blue; ubyte green; ubyte red; }


// to display
BITMAPINFO bi;

bi.bmiHeader.biSize = BITMAPINFO.sizeof;
bi.bmiHeader.biWidth = image.size.width;
bi.bmiHeader.biHeight = 0 - image.size.height;
bi.bmiHeader.biPlanes = 1;
bi.bmiHeader.biBitCount = 24;

SetDIBitsToDevice (hDC, 
      0, 0,
      image.size.width, image.size.height,
      0, image.size.height, 
      image.size.height, image.size.height, 
      &image.pixels[0], &bi, DIB_RGB_COLORS);

dsimcha <dsimcha yahoo.com> writes:

== Quote from Michal Minich (michal.minich gmail.com)'s article
 On Sat, 10 Jul 2010 04:40:04 +0000, dsimcha wrote:
 2. There is currently no "proper" way to save a plot. This is because
 DFL's Bitmap object doesn't provide a way to obtain the underlying
 pixels yet, and core.stdc.windows doesn't seem to provide the necessary
 stuff to do it manually via the Windows API.

 When using classical windows api, I'm almost entirely sure that only way
 to have accessible bitmap pixels, while still being able to draw them to
 window is using dib section.
 HANDLE cDC;
 HBITMAP hBitmap;
 BITMAPINFO bmi;
 bmi.bmiHeader.biSize = BITMAPINFOHEADER.sizeof;
 bmi.bmiHeader.biWidth = w; // must  be rounded to 4
 bmi.bmiHeader.biHeight = -h; // must  be rounded to 4
 bmi.bmiHeader.biPlanes = 1;
 bmi.bmiHeader.biBitCount = 24;
 bmi.bmiHeader.biCompression = BI_RGB;
 VOID* ppvBits;
 HANDLE cDC = CreateCompatibleDC (hDC);
 hBitmap = CreateDIBSection (cDC, &bmi, DIB_RGB_COLORS, &ppvBits, null, 0);
 if (hBitmap == NULL || ppvBits == NULL)
     throw new Exception ("Failed to Create Device Independed Bitmap
 (DIB)");
 HGDIOBJ selectObj = SelectObject (cDC, hBitmap);
 if (selectObj == NULL)
     throw new Exception ("Failed to SelectObject the DIB");
 ColorBgr* pixRgb = cast (ColorBgr*) ppvBits; // ppvBits are initialized
 bitmap data
 //struct ColorBgr { ubyte blue; ubyte green; ubyte red; }
 // to display
 BITMAPINFO bi;
 bi.bmiHeader.biSize = BITMAPINFO.sizeof;
 bi.bmiHeader.biWidth = image.size.width;
 bi.bmiHeader.biHeight = 0 - image.size.height;
 bi.bmiHeader.biPlanes = 1;
 bi.bmiHeader.biBitCount = 24;
 SetDIBitsToDevice (hDC,
       0, 0,
       image.size.width, image.size.height,
       0, image.size.height,
       image.size.height, image.size.height,
       &image.pixels[0], &bi, DIB_RGB_COLORS);

Right.  DFL can give access to the underlying handle for its Bitmap objects
(which
are basically wrappers around the awful Win32 API).  I have never used the
Win32API directly before and tried to paste together some code from MSDN to use
GetDIBits.  It didn't work because not all the necessary stuff is declared in
core.stdc.windows, so I gave up for now and decided to hope either someone
submits
a patch to me, or the DFL maintainers wrap GetDIBits in their Bitmap object.

In general, I want to eventually make this lib cross-platform (when gtkD
matures,
maybe) so I don't want to rely too directly on native OS APIs anyhow.

Philippe Sigaud <philippe.sigaud gmail.com> writes:

Hmm, my first reply seems lost in limbo...


On Sat, Jul 10, 2010 at 06:40, dsimcha <dsimcha yahoo.com> 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.


 For those who don't want to install dflplot, dfl and dstats (dstats is
 necessary only for the demo/test function and is otherwise not a
 dependency)
 but are curious what dflplot currently looks like, I've attached a
 screenshot
 of a subplot window produced by the demo/test function.

Hey, cool!

I had no trouble installing DFL. Man, I tried that 2-3 times in the past 2
years, to no avail. Now it works, woohoo! Now to get some keyboard shortcut
on Code::Blocks to compile with DFL instead of DMD...

Dflplots works quite well for me and is very simple to use. Good work,
David!

import std.random;
import dflplot;

void main() {

    auto rnd = uniformDistribution(1000);
    auto rnd2 = uniformDistribution(1000);

    auto scat = ScatterPlot(rnd, rnd2);
    scat.pointSymbol = '.';
    scat.toFigure.showAsMain();
}

As you can see, I use a dot for symbol, it give nice graphics. Maybe with
slightly excentered points... I attached a jpeg to my first reply, and maybe
that's why it didn't pass.

Out of curiosity, as I don't know DFL, why do you draw everything as text in
a scatterplot instead of using small rectangles or lines?

This made me laugh:

/**Hack around ddoc issues.)*/
void dummy() {}

Do you have a missing ')' parenthesis somewhere?

Philippe

dsimcha <dsimcha yahoo.com> writes:

== Quote from Philippe Sigaud (philippe.sigaud gmail.com)'s article
 Out of curiosity, as I don't know DFL, why do you draw everything as text in
 a scatterplot instead of using small rectangles or lines?

This is to give customizability as to what the points look like.

 This made me laugh:
 /**Hack around ddoc issues.)*/
 void dummy() {}
 Do you have a missing ')' parenthesis somewhere?

Probably.  I was getting weird DDoc behavior until I added this, but I can't
find
the missing ) so I just hacked around it.

 Philippe
 --0022158c15717b3d1b048b047257
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 <div class=3D"gmail_quote">Hmm, my first reply seems lost in limbo...</div>=
 <div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote"><br></div><=
 div class=3D"gmail_quote">On Sat, Jul 10, 2010 at 06:40, dsimcha <span dir=
 =3D"ltr">&lt;<a href=3D"mailto:dsimcha yahoo.com">dsimcha yahoo.com</a>&gt;=
 </span> wrote:<br>
 <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
 x #ccc solid;padding-left:1ex;">In the spirit of making D2 a first-rate sci=
 entific computing language, I have<br>
 just uploaded the first usable version of my DFL-based dflplot =A0plotting<=
 br>
 library to Scrapple.<br><br><br>

 br>
 necessary only for the demo/test function and is otherwise not a dependency=
 )<br>

 enshot<br>
 of a subplot window produced by the demo/test function.<br>
 </blockquote></div><br><div>Hey, cool!</div><div><br></div><div>I had no tr=
 ouble installing DFL. Man, I tried that 2-3 times in the past 2 years, to n=
 o avail. Now it works, woohoo! Now to get some keyboard shortcut on Code::B=
 locks to compile with DFL instead of DMD...</div>
 <div><br></div><div>Dflplots works quite well for me and is very simple to =
 use. Good work, David!</div><div><br></div><div><div>import std.random;</di=
 v><div>import dflplot;</div><div><br></div><div>void main() {</div><div>
 <br></div><div>=A0=A0 =A0auto rnd =3D uniformDistribution(1000);</div><div>=
 =A0=A0 =A0auto rnd2 =3D uniformDistribution(1000);</div><div><br></div><div=
=A0=A0 =A0auto scat =3D ScatterPlot(rnd, rnd2);</div><div>=A0=A0 =A0scat.p=


 <div>=A0=A0 =A0scat.toFigure.showAsMain();</div><div>}</div></div><div><br>=
 </div><div>As you can see, I use a dot for symbol, it give nice graphics. M=
 aybe with slightly excentered points... I attached a jpeg to my first reply=


 raw everything as text in a scatterplot instead of using small rectangles o=
 r lines?</div><div><br></div><div>This made me laugh:</div><div><br></div>
 <div><div>/**Hack around ddoc issues.)*/</div><div>void dummy() {}</div></d=

 ere?</div><div><br></div><div>Philippe</div><div><br></div><div><br></div>
 --0022158c15717b3d1b048b047257--

Philippe Sigaud <philippe.sigaud gmail.com> writes:

On Sat, Jul 10, 2010 at 15:46, dsimcha <dsimcha yahoo.com> wrote:

 == Quote from Philippe Sigaud (philippe.sigaud gmail.com)'s article
 Out of curiosity, as I don't know DFL, why do you draw everything as text

 in
 a scatterplot instead of using small rectangles or lines?

 This is to give customizability as to what the points look like.

Maybe you can encapsulate the drawing in a small function that would draw a
specific shape and let the user discriminate with an enum?

enum PointShape {circle, square, cross, ...}

Is it possible to cache a small drawing in DFL, to reuse it at will?


 This made me laugh:
 /**Hack around ddoc issues.)*/
 void dummy() {}
 Do you have a missing ')' parenthesis somewhere?

 Probably.  I was getting weird DDoc behavior until I added this, but I
 can't find
 the missing ) so I just hacked around it.


Try line 1022 and lines 1988-1990.

For one big file, this irked me so much that I almost wrote a small script
that would find docs comments and count parenthesis and brackets in them.
But I found the culprit before that :)


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.

Philippe

dsimcha <dsimcha yahoo.com> writes:

== Quote from Philippe Sigaud (philippe.sigaud gmail.com)'s article
 --0016e6d975ba9ee1ba048b09a55f
 Content-Type: text/plain; charset=ISO-8859-1
 On Sat, Jul 10, 2010 at 15:46, dsimcha <dsimcha yahoo.com> wrote:
 == Quote from Philippe Sigaud (philippe.sigaud gmail.com)'s article
 Out of curiosity, as I don't know DFL, why do you draw everything as text

 in
 a scatterplot instead of using small rectangles or lines?

 This is to give customizability as to what the points look like.

 Maybe you can encapsulate the drawing in a small function that would draw a
 specific shape and let the user discriminate with an enum?
 enum PointShape {circle, square, cross, ...}
 Is it possible to cache a small drawing in DFL, to reuse it at will?


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.

 This made me laugh:
 /**Hack around ddoc issues.)*/
 void dummy() {}
 Do you have a missing ')' parenthesis somewhere?

 Probably.  I was getting weird DDoc behavior until I added this, but I
 can't find
 the missing ) so I just hacked around it.

 Try line 1022 and lines 1988-1990.
 For one big file, this irked me so much that I almost wrote a small script
 that would find docs comments and count parenthesis and brackets in them.
 But I found the culprit before that :)

Thanks.  Fixed.

 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.

Philippe Sigaud <philippe.sigaud gmail.com> writes:

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...

Philippe

"Nick Sabalausky" <a a.a> writes:

"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.

dsimcha <dsimcha yahoo.com> writes:

== 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.

dsimcha <dsimcha yahoo.com> writes:

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

"Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:

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

Philippe Sigaud <philippe.sigaud gmail.com> writes:

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

dsimcha <dsimcha yahoo.com> writes:

== 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.

dsimcha <dsimcha yahoo.com> writes:

== 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.

Eldar Insafutdinov <e.insafutdinov gmail.com> writes:

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/exa
ples/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.

dsimcha <dsimcha yahoo.com> writes:

== 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.

Eldar Insafutdinov <e.insafutdinov gmail.com> writes:

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.

Don <nospam nospam.com> writes:

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 />

dsimcha <dsimcha yahoo.com> writes:

== 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?

Don <nospam nospam.com> writes:

dsimcha wrote:
 == 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?

Personal use only, never intended for release.