Re: dflplot 0.01

2010-07-11 Thread Don 

dsimcha wrote:

== Quote from Don (nos...@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. 


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


Personal use only, never intended for release.

Re: dflplot 0.01

2010-07-11 Thread dsimcha 
== Quote from Don (nos...@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.  library />

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

Re: dflplot 0.01

2010-07-11 Thread Don 

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

Re: dflplot 0.01

2010-07-11 Thread dsimcha 
== Quote from Lars T. Kyllingstad (pub...@kyllingen.nospamnet)'s article
> On Sat, 10 Jul 2010 20:51:15 +, 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.

Re: dflplot 0.01

2010-07-11 Thread dsimcha 
== Quote from Philippe Sigaud (philippe.sig...@gmail.com)'s article
> --0016e6d77e7b9e1ca7048b1bb56b
> Content-Type: text/plain; charset=ISO-8859-1
> On Sun, Jul 11, 2010 at 13:52, Lars T. Kyllingstad
>  wrote:
> > On Sat, 10 Jul 2010 20:51:15 +, 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
> >
> 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.

Re: dflplot 0.01

2010-07-11 Thread Philippe Sigaud 
On Sun, Jul 11, 2010 at 13:52, Lars T. Kyllingstad
 wrote:

> On Sat, 10 Jul 2010 20:51:15 +, 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
>

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


Philippe

Re: dflplot 0.01

2010-07-11 Thread Lars T. Kyllingstad 
On Sat, 10 Jul 2010 20:51:15 +, 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

Re: dflplot 0.01

2010-07-11 Thread Eldar Insafutdinov 
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.

Re: dflplot 0.01

2010-07-10 Thread dsimcha 
== Quote from Eldar Insafutdinov (e.insafutdi...@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.

Re: dflplot 0.01

2010-07-10 Thread Eldar Insafutdinov 
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.

Re: dflplot 0.01

2010-07-10 Thread dsimcha 
== Quote from Nick Sabalausky (a...@a.a)'s article
> "Philippe Sigaud"  wrote in message
> news:mailman.310.1278794218.24349.digitalmars-d-annou...@puremagic.com...
> > On Sat, Jul 10, 2010 at 17:42, dsimcha  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.

Re: dflplot 0.01

2010-07-10 Thread Nick Sabalausky 
"Philippe Sigaud"  wrote in message 
news:mailman.310.1278794218.24349.digitalmars-d-annou...@puremagic.com...
> On Sat, Jul 10, 2010 at 17:42, dsimcha  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.

Re: dflplot 0.01

2010-07-10 Thread dsimcha 
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

Re: dflplot 0.01

2010-07-10 Thread Philippe Sigaud 
On Sat, Jul 10, 2010 at 17:42, dsimcha  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

Re: dflplot 0.01

2010-07-10 Thread dsimcha 
== Quote from Philippe Sigaud (philippe.sig...@gmail.com)'s article
> --0016e6d975ba9ee1ba048b09a55f
> Content-Type: text/plain; charset=ISO-8859-1
> On Sat, Jul 10, 2010 at 15:46, dsimcha  wrote:
> > == Quote from Philippe Sigaud (philippe.sig...@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.

Re: dflplot 0.01

2010-07-10 Thread Philippe Sigaud 
On Sat, Jul 10, 2010 at 15:46, dsimcha  wrote:

> == Quote from Philippe Sigaud (philippe.sig...@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

Re: dflplot 0.01

2010-07-10 Thread dsimcha 
== Quote from Philippe Sigaud (philippe.sig...@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
> Hmm, my first reply seems lost in limbo...=
> <=
> div class=3D"gmail_quote">On Sat, Jul 10, 2010 at 06:40, dsimcha  =3D"ltr">dsim...@yahoo.com>=
>  wrote:
>  x #ccc solid;padding-left:1ex;">In the spirit of making D2 a first-rate sci=
> entific computing language, I have
> just uploaded the first usable version of my DFL-based dflplot =A0plotting<=
> br>
> library to Scrapple.
> For those who don't want to install dflplot, dfl and dstats (dstats is<=
> br>
> 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 scre=
> enshot
> of a subplot window produced by the demo/test function.
> Hey, cool!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...
> Dflplots works quite well for me and is very simple to =
> use. Good work, David!import std.random; v>import dflplot;void main() {
> =A0=A0 =A0auto rnd =3D uniformDistribution(1000);=
> =A0=A0 =A0auto rnd2 =3D uniformDistribution(1000); >=A0=A0 =A0auto scat =3D ScatterPlot(rnd, rnd2);=A0=A0 =A0scat.p=
> ointSymbol =3D '.';
> =A0=A0 =A0scat.toFigure.showAsMain();}=
> 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=
> , and maybe that's why it didn't pass.
> Out of curiosity, as I don't know DFL, why do you d=
> raw everything as text in a scatterplot instead of using small rectangles o=
> r lines?This made me laugh:
> /**Hack around ddoc issues.)*/void dummy() {} iv>Do you have a missing ')' parenthesis somewh=
> ere?Philippe
> --0022158c15717b3d1b048b047257--

Re: dflplot 0.01

2010-07-10 Thread dsimcha 
== Quote from Michal Minich (michal.min...@gmail.com)'s article
> On Sat, 10 Jul 2010 04:40:04 +, 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.

Re: dflplot 0.01

2010-07-10 Thread Philippe Sigaud 
Hmm, my first reply seems lost in limbo...


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

Re: dflplot 0.01

2010-07-10 Thread Michal Minich 
On Sat, 10 Jul 2010 04:40:04 +, 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);

dflplot 0.01

2010-07-09 Thread dsimcha 
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.