RE: [Caml-list] Interactive technical computing

RE: [Caml-list] Interactive technical computing

[Robert Fischer]

> Putting aside the obvious cultural resistance to using a sensible
> language for this project, there is one technical hurdle: It needs to
> compile into a DLL which can be linked to other programs (in C and
> other languages).  I can't generate such code using ocamlopt, at least
> not without using unsupported out-of-tree extensions.
>
I don't think this is a real hurdle to general adoption of a language.
After all, Java and C# aren't intended to be used like that, yet they
certainly have wide-spread adoption.

I suppose there is gcj for Java, but that's not in 99+% of Java
development, and I'm not sure that will give you a lib at the end of the
day.  I don't know of an equivalent for that in C# -- in all the C#
development I've done, we've never even considered it.

~~ Robert.

-----Original Message-----
From: caml-list-bounces@yquem.inria.fr
[mailto:caml-list-bounces@yquem.inria.fr]On Behalf Of Richard Jones
Sent: Thursday, March 08, 2007 3:17 PM
To: Jim Miller
Cc: caml-list@inria.fr; skaller
Subject: Re: [Caml-list] Interactive technical computing


On Wed, Mar 07, 2007 at 10:36:18PM -0500, Jim Miller wrote:
> What's I think is the interesting point about this discussion is "What
are
> the hurdles toward acceptance of any new language, scripting or not,
into a
> given community?"  Obviously OCAML and the ML languages have deeply
> penetrated some markets but haven't even dented others.  There have
been
> lots of papers, studies, and discussion written on this (
> lambda-the-ultimate.org has many of them archived) so that's probably
> something for a different thread to be read wearing flame-retardant
> underthings.

I'm currently contributing to a 45KLOC C library which I'm sure would
be about 10 times smaller if written in a reasonable language.

Putting aside the obvious cultural resistance to using a sensible
language for this project, there is one technical hurdle: It needs to
compile into a DLL which can be linked to other programs (in C and
other languages).  I can't generate such code using ocamlopt, at least
not without using unsupported out-of-tree extensions.

Rich.

-- 
Richard Jones
Red Hat

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

RE: [Caml-list] Interactive technical computing

[skaller]

On Thu, 2007-03-08 at 15:26 -0600, Robert Fischer wrote:
> > Putting aside the obvious cultural resistance to using a sensible
> > language for this project, there is one technical hurdle: It needs to
> > compile into a DLL which can be linked to other programs (in C and
> > other languages).  I can't generate such code using ocamlopt, at least
> > not without using unsupported out-of-tree extensions.
> >
> I don't think this is a real hurdle to general adoption of a language.

It is in fact an utter and complete show stopper.
I've spent 6 years developing Felix precisely to solve this
problem: a high level language that can generate shared libraries
which can use and be used by other shared libraries.

Ocaml is great for stand-alone programs but a significant
fraction of software development is library building,
and Linux distros such as those based on Debian provide
a library component model which demands dynamic linkage
so the components can be upgraded without end user recompilation.

I expect this will eventually be solved too.

> After all, Java and C# aren't intended to be used like that, yet they
> certainly have wide-spread adoption.

They don't make binary shared libraries
because the architecture is a virtual machine driven by
bytecode .. they DO make dynamically linkable bytecode
libraries.


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Interactive technical computing

[Jon Harrop]

On Friday 09 March 2007 00:04, skaller wrote:
> On Thu, 2007-03-08 at 15:26 -0600, Robert Fischer wrote:
> > > Putting aside the obvious cultural resistance to using a sensible
> > > language for this project, there is one technical hurdle: It needs to
> > > compile into a DLL which can be linked to other programs (in C and
> > > other languages).  I can't generate such code using ocamlopt, at least
> > > not without using unsupported out-of-tree extensions.
> >
> > I don't think this is a real hurdle to general adoption of a language.
>
> It is in fact an utter and complete show stopper.

Agreed. This is blocking the development of third party libraries written in 
OCaml.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Interactive technical computing

[Jon Harrop]

On Thursday 08 March 2007 21:26, Robert Fischer wrote:
> > Putting aside the obvious cultural resistance to using a sensible
> > language for this project, there is one technical hurdle: It needs to
> > compile into a DLL which can be linked to other programs (in C and
> > other languages).  I can't generate such code using ocamlopt, at least
> > not without using unsupported out-of-tree extensions.
>
> I don't think this is a real hurdle to general adoption of a language.
> After all, Java and C# aren't intended to be used like that, yet they
> certainly have wide-spread adoption.

On the contrary, that is exactly how C# is intended to be used. Most libraries 
used from F# are written in C# (and the same for most other .NET languages).

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Interactive technical computing

[Richard Jones]

On Thu, Mar 08, 2007 at 03:26:03PM -0600, Robert Fischer wrote:
> > Putting aside the obvious cultural resistance to using a sensible
> > language for this project, there is one technical hurdle: It needs to
> > compile into a DLL which can be linked to other programs (in C and
> > other languages).  I can't generate such code using ocamlopt, at least
> > not without using unsupported out-of-tree extensions.
> >
> I don't think this is a real hurdle to general adoption of a language.
> After all, Java and C# aren't intended to be used like that, yet they
> certainly have wide-spread adoption.

It is a hurdle because not all programming is writing end-user
application code.

In fact what is somewhat sad is that OCaml (unlike Java and C#) can
compile to native code which really has very minimal "environmental
needs" - just a smallish library of functions and a GC which is
written on top of C's malloc.  So really it could be an ideal
replacement for libraries written in C, where the heavy lifting is
done in OCaml and there are some thin bindings to provide a C API.

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] Interactive technical computing

[Michael Vanier]

I agree 100%.  This is the biggest limitation to using ocaml for large projects. 
  If it were fixed, ocaml would become an unstoppable juggernaut ;-)

Here's a paper describing an approach to this problem for an extended version of 
Standard ML:

http://www.ps.uni-sb.de/Papers/abstracts/missing-link.html

This actually goes further than dynamic linking to provide a full component 
model.  What I wouldn't give to see this in ocaml.

Mike

Richard Jones wrote:
> On Thu, Mar 08, 2007 at 03:26:03PM -0600, Robert Fischer wrote:
>>> Putting aside the obvious cultural resistance to using a sensible
>>> language for this project, there is one technical hurdle: It needs to
>>> compile into a DLL which can be linked to other programs (in C and
>>> other languages).  I can't generate such code using ocamlopt, at least
>>> not without using unsupported out-of-tree extensions.
>>>
>> I don't think this is a real hurdle to general adoption of a language.
>> After all, Java and C# aren't intended to be used like that, yet they
>> certainly have wide-spread adoption.
> 
> It is a hurdle because not all programming is writing end-user
> application code.
> 
> In fact what is somewhat sad is that OCaml (unlike Java and C#) can
> compile to native code which really has very minimal "environmental
> needs" - just a smallish library of functions and a GC which is
> written on top of C's malloc.  So really it could be an ideal
> replacement for libraries written in C, where the heavy lifting is
> done in OCaml and there are some thin bindings to provide a C API.
> 
> Rich.
> 

Re: [Caml-list] Interactive technical computing

[Jon Harrop]

On Saturday 10 March 2007 22:07, Michael Vanier wrote:
> I agree 100%.  This is the biggest limitation to using ocaml for large
> projects. If it were fixed, ocaml would become an unstoppable juggernaut
> ;-)

Concurrency has to be on that list as well though. F# inherits concurrency 
from .NET and it is vastly easier to use than the last time I tried 
concurrency (on a supercomputer, in Fortran).

However, a recent thread discussed the fledgling development of concurrency 
for OCaml and it sounded fascinating (although I still haven't found time to 
read it in detail!).

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Interactive technical computing

[Joel Reymont]

On Mar 29, 2007, at 1:33 AM, Jon Harrop wrote:

> However, a recent thread discussed the fledgling development of  
> concurrency
> for OCaml and it sounded fascinating (although I still haven't  
> found time to
> read it in detail!).

Where is this thread?

	Thanks, Joel

--
http://wagerlabs.com/

Re: [Caml-list] Interactive technical computing

[Jon Harrop]

On Thursday 29 March 2007 09:41, Joel Reymont wrote:
> On Mar 29, 2007, at 1:33 AM, Jon Harrop wrote:
> > However, a recent thread discussed the fledgling development of
> > concurrency
> > for OCaml and it sounded fascinating (although I still haven't
> > found time to
> > read it in detail!).
>
> Where is this thread?

Finally found it:

  http://tech.groups.yahoo.com/group/ocaml_beginners/message/7200

:-)

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

RE: [Caml-list] Interactive technical computing

[Robert Fischer]

Weird -- I thought F# was having all kinds of performance problems.  Got metrics?

~~ Robert.

-----Original Message-----
From: caml-list-bounces@yquem.inria.fr
[mailto:caml-list-bounces@yquem.inria.fr]On Behalf Of Jon Harrop
Sent: Friday, March 09, 2007 11:26 AM
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Interactive technical computing


On Friday 09 March 2007 14:13, Robert Fischer wrote:
> Performance of Ocaml's bytecode is slower than F#?  Really?

Performance of OCaml compiled to native code with ocamlopt is sometimes slower 
than F#, so yes.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

RE: [Caml-list] Interactive technical computing

[Robert Fischer]

Performance of using F# linking into native applications is better than using OCaml bytecode and linking into native applications?  Is F# faster than OCaml bytecode these days?  Is the OCaml bytecode's link into dynamic libraries somehow slowing things down?

I'm still having trouble seeing what you're getting at -- sorry if I'm being dense.

~~ Robert.

-----Original Message-----
From: caml-list-bounces@yquem.inria.fr
[mailto:caml-list-bounces@yquem.inria.fr]On Behalf Of skaller
Sent: Friday, March 09, 2007 9:22 AM
To: Robert Fischer
Cc: caml-list@inria.fr
Subject: RE: [Caml-list] Interactive technical computing


On Fri, 2007-03-09 at 08:13 -0600, Robert Fischer wrote:
> Performance of Ocaml's bytecode is slower than F#?  Really?

I wrote:
> > As long as you play within the bounds of their VM.  This is no different than Ocaml.
> 
> Performance is different :) That's why I use Ocaml native code
> exclusively, which doesn't support dynamic loading (yet :)

I have no idea about performance of F#: I'm talking about
using a Debian based Linux operating system which uses
dynamic loading of high performance machine binaries.

I once implement a Python interpreter in Ocaml, call Vyper.
One of the reasons I gave up was that to extend it with
the equivalent of Python's C modules, I had to write the
equivalent code in Ocaml and *statically* link it into
the program.

The main reason for doing this wasn't performance, but
to provide bindings to C libraries.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

RE: [Caml-list] Interactive technical computing

[Robert Fischer]

> Can you dynamically load code and get native performance? Not with OCaml.
>
> I've got a killer high-performance 2D and 3D visualization library written in 
> OCaml and I'd like to sell it, but I don't want to sell the source code 
> because I value it too much. What can I do? Well, I can port it to F# and 
> sell it there. In the mean time, OCaml users are stuck with GNUPlot.
>
Do you have metrics showing that performance is better with F# than OCaml in these two cases?

>From what I understand, F# has a major performance issue resulting from the way the .Net VM handles allocation.  Is that old info?

> Can you compile to a cross-platform format and keep native performance? Not 
> with OCaml.
>
F# goes to byte code, OCaml goes to byte code.  If you want to be "cross-platform", you're pretty much headed to a VM one way or another.

> Can you write an interactive environment (top level) and keep native 
> performance? Not with OCaml.
>
The top-level is something I've been hacking on a bit, and I am a bit cranky with it right now, too.  I'll post something on it later.

> Can you link to libraries (e.g. OpenGL) and be cross-platform? Not with OCaml 
> (I think, because you need a custom run-time).
>
What are you doing with F# where you see it as more "cross-platform" than OCaml?  I guess I don't understand the charge.

>From what I understand, your basic argument is "F# is cross-compatible with the .Net framework, and therefore better".  This is definitely something I agree with.  If I trusted the .Net framework to ever become and remain genuinely cross-platform (I expect Mono to be killed by vicious attack lawyers as soon as MS cares), I'd be a lot more inclined to use it.

~~ Robert.


-----Original Message-----
From: caml-list-bounces@yquem.inria.fr
[mailto:caml-list-bounces@yquem.inria.fr]On Behalf Of Jon Harrop
Sent: Friday, March 09, 2007 7:49 AM
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Interactive technical computing


On Friday 09 March 2007 13:33, Robert Fischer wrote:
> > They don't make binary shared libraries
> > because the architecture is a virtual machine driven by
> > bytecode .. they DO make dynamically linkable bytecode
> > libraries.
>
> As long as you play within the bounds of their VM.  This is no different
> than Ocaml.

On the contrary, it is very different:

Can you dynamically load code and get native performance? Not with OCaml.

Can you compile to a cross-platform format and keep native performance? Not 
with OCaml.

Can you write an interactive environment (top level) and keep native 
performance? Not with OCaml.

Can you link to libraries (e.g. OpenGL) and be cross-platform? Not with OCaml 
(I think, because you need a custom run-time).

I've got a killer high-performance 2D and 3D visualization library written in 
OCaml and I'd like to sell it, but I don't want to sell the source code 
because I value it too much. What can I do? Well, I can port it to F# and 
sell it there. In the mean time, OCaml users are stuck with GNUPlot.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

RE: [Caml-list] Interactive technical computing

[Robert Fischer]

Performance of Ocaml's bytecode is slower than F#?  Really?

~~ Robert.

-----Original Message-----
From: skaller [mailto:skaller@users.sourceforge.net]
Sent: Friday, March 09, 2007 7:54 AM
To: Robert Fischer
Cc: caml-list@inria.fr
Subject: RE: [Caml-list] Interactive technical computing


On Fri, 2007-03-09 at 07:33 -0600, Robert Fischer wrote:
> >> After all, Java and C# aren't intended to be used like that, yet they
> >> certainly have wide-spread adoption.
> >
> > They don't make binary shared libraries
> > because the architecture is a virtual machine driven by
> > bytecode .. they DO make dynamically linkable bytecode
> > libraries.
> >
> As long as you play within the bounds of their VM.  This is no different than Ocaml.

Performance is different :) That's why I use Ocaml native code
exclusively, which doesn't support dynamic loading (yet :)

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

RE: [Caml-list] Interactive technical computing

[skaller]

On Fri, 2007-03-09 at 08:13 -0600, Robert Fischer wrote:
> Performance of Ocaml's bytecode is slower than F#?  Really?

I wrote:
> > As long as you play within the bounds of their VM.  This is no different than Ocaml.
> 
> Performance is different :) That's why I use Ocaml native code
> exclusively, which doesn't support dynamic loading (yet :)

I have no idea about performance of F#: I'm talking about
using a Debian based Linux operating system which uses
dynamic loading of high performance machine binaries.

I once implement a Python interpreter in Ocaml, call Vyper.
One of the reasons I gave up was that to extend it with
the equivalent of Python's C modules, I had to write the
equivalent code in Ocaml and *statically* link it into
the program.

The main reason for doing this wasn't performance, but
to provide bindings to C libraries.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Interactive technical computing

[Jon Harrop]

On Friday 09 March 2007 14:13, Robert Fischer wrote:
> Performance of Ocaml's bytecode is slower than F#?  Really?

Performance of OCaml compiled to native code with ocamlopt is sometimes slower 
than F#, so yes.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Interactive technical computing

[Jon Harrop]

On Friday 09 March 2007 14:13, Robert Fischer wrote:
> Performance of Ocaml's bytecode is slower than F#?  Really?

Sum 1/x for x in [1 .. 10^6]. In OCaml:

time (Array.fold_left (+.) 0.)
  (Array.init 1000000 (fun i -> 1. /. float(i+1)));;

In F#:

time (Array.fold_left (+) 0.)
  (Array.map ((/) 1.) [|1. .. 1000000.|]);;

OCaml takes 0.256s, F# takes only 0.047s => F# more than 5x faster than OCaml 
bytecode.


On numerical code, F# can be faster than native-code compiled OCaml. For 
example, a naive 2^n FFT:

let fft a =
  let n = Array.length a in 
  let j = ref 0 in
  for i = 0 to n-2 do
    if i < !j then
      (let t = a.(!j) in
       a.(!j) <- a.(i);
       a.(i) <- t);
    let m = ref (n/2) in
    while !m <= !j do
      j := !j - !m;
      m := !m/2
    done;
    j := !j + !m
  done;
  let j = ref 1 in
  let b = ref (neg c1) in
  while !j<n do
    let w = ref c1 in
    for m = 0 to !j-1 do
      let i = ref m in
      while !i < n do 
	let t = !w *@ a.(!i + !j) in
	a.(!i + !j) <- a.(!i) -@ t;
	a.(!i) <- a.(!i) +@ t;
	w := !w *@ !b;
	i := !i + !j + !j
      done
    done;
    j := !j + !j;
    b := sqrt !b
  done;
  a;;

n=1<<15
ocamlopt: 0.164s
F#: 0.134s

F# is 22% faster, probably thanks to complex numbers in the language.


Discrete wavelet transform (4-tap Daubechies, n=2^20), OCaml is 25% faster:

ocamlopt: 2.03s
F#: 2.53s

Note that this is apples and oranges because my Windows environment is still 
only 32 bit. If .NET shows the same performance improvement moving from 

> From what I understand, F# has a major performance issue resulting from the
> way the .Net VM handles allocation.  Is that old info? 

Allocation is slower in F# for two main reasons:

1. The run-time is optimised for C# code that has quite different expected 
value lifetimes (far fewer very short-lived objects compared to F#).

2. F# supports concurrency, which incurs a big performance cost in allocation 
and GC.

but the consequence of this is that very allocation-heavy code (e.g. symbolic 
rewriting) is up to 4x slower in F#. Lists are also more heavyweight in F#.

However, F# regains a lot of performance by having a much faster stdlib.

For example, creating a 2^16-element set is an allocation-intensive task. In 
OCaml:

# module Int = struct
    type t = int
    let compare = compare
  end;;
# module IntSet = Set.Make(Int);;
...
# time (Array.fold_right IntSet.add (Array.init 65536 (fun i -> i)))
    IntSet.empty;;
0.744047s

Compiled with ocamlopt I get 0.065s.

For F# I get 0.240s. That's 3.7x slower than native-code OCaml.

However, it is worth noting that the F# equivalent is much more concise, just:

  time (Array.fold_right Set.add [|0 .. 65535|])
    Set.empty;;

primarily because no functors are involved when making a set. The comparison 
function is taken from the element type.

> > I've got a killer high-performance 2D and 3D visualization library
> > written in OCaml and I'd like to sell it, but I don't want to sell the
> > source code because I value it too much. What can I do? Well, I can port
> > it to F# and sell it there. In the mean time, OCaml users are stuck with
> > GNUPlot.
>
> Do you have metrics showing that performance is better with F# than OCaml
> in these two cases?

In theory, performance should be very close because so much work is done by 
the graphics card and not the CPU. In practice, I only just figured out how 
to render static geometry optimally from DirectX, so my F# version still 
sucks.

Once I've integrated that into my purely-functional scene graph I'll let you 
know what the performance is like. I expect F# to win because I'm exploiting 
concurrency and the application is more numerical than allocation intensive.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

RE: [Caml-list] Interactive technical computing

[Robert Fischer]

>> After all, Java and C# aren't intended to be used like that, yet they
>> certainly have wide-spread adoption.
>
> They don't make binary shared libraries
> because the architecture is a virtual machine driven by
> bytecode .. they DO make dynamically linkable bytecode
> libraries.
>
As long as you play within the bounds of their VM.  This is no different than Ocaml.

~~ Robert.

-----Original Message-----
From: skaller [mailto:skaller@users.sourceforge.net]
Sent: Thursday, March 08, 2007 6:04 PM
To: Robert Fischer
Cc: caml-list@inria.fr
Subject: RE: [Caml-list] Interactive technical computing


On Thu, 2007-03-08 at 15:26 -0600, Robert Fischer wrote:
> > Putting aside the obvious cultural resistance to using a sensible
> > language for this project, there is one technical hurdle: It needs to
> > compile into a DLL which can be linked to other programs (in C and
> > other languages).  I can't generate such code using ocamlopt, at least
> > not without using unsupported out-of-tree extensions.
> >
> I don't think this is a real hurdle to general adoption of a language.

It is in fact an utter and complete show stopper.
I've spent 6 years developing Felix precisely to solve this
problem: a high level language that can generate shared libraries
which can use and be used by other shared libraries.

Ocaml is great for stand-alone programs but a significant
fraction of software development is library building,
and Linux distros such as those based on Debian provide
a library component model which demands dynamic linkage
so the components can be upgraded without end user recompilation.

I expect this will eventually be solved too.

> After all, Java and C# aren't intended to be used like that, yet they
> certainly have wide-spread adoption.

They don't make binary shared libraries
because the architecture is a virtual machine driven by
bytecode .. they DO make dynamically linkable bytecode
libraries.


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Interactive technical computing

[Jon Harrop]

On Friday 09 March 2007 13:33, Robert Fischer wrote:
> > They don't make binary shared libraries
> > because the architecture is a virtual machine driven by
> > bytecode .. they DO make dynamically linkable bytecode
> > libraries.
>
> As long as you play within the bounds of their VM.  This is no different
> than Ocaml.

On the contrary, it is very different:

Can you dynamically load code and get native performance? Not with OCaml.

Can you compile to a cross-platform format and keep native performance? Not 
with OCaml.

Can you write an interactive environment (top level) and keep native 
performance? Not with OCaml.

Can you link to libraries (e.g. OpenGL) and be cross-platform? Not with OCaml 
(I think, because you need a custom run-time).

I've got a killer high-performance 2D and 3D visualization library written in 
OCaml and I'd like to sell it, but I don't want to sell the source code 
because I value it too much. What can I do? Well, I can port it to F# and 
sell it there. In the mean time, OCaml users are stuck with GNUPlot.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

RE: [Caml-list] Interactive technical computing

[skaller]

On Fri, 2007-03-09 at 07:33 -0600, Robert Fischer wrote:
> >> After all, Java and C# aren't intended to be used like that, yet they
> >> certainly have wide-spread adoption.
> >
> > They don't make binary shared libraries
> > because the architecture is a virtual machine driven by
> > bytecode .. they DO make dynamically linkable bytecode
> > libraries.
> >
> As long as you play within the bounds of their VM.  This is no different than Ocaml.

Performance is different :) That's why I use Ocaml native code
exclusively, which doesn't support dynamic loading (yet :)

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Interactive technical computing

[Jon Harrop]

Being a user of both OCaml and Mathematica, playing with the new F# language 
from Microsoft and watching tutorial videos about VPython:

  http://showmedo.com/videos/series?name=pythonThompsonVPythonSeries

has given me a lot of inspiration about interactive technical computing 
environments. This class of applications is hugely useful for working 
scientists and engineers because it lets you slice and dice your data in 
interesting ways whilst also giving you visual throwback and even letting you 
do some fancy visualisations.

For example, I'm in the process of updating my ray tracer language comparison:

  http://www.ffconsultancy.com/languages/ray_tracer/index.html

and I'm using a mix of OCaml (to fire off compilation and execution commands) 
and Mathematica (to dissect the results, compute verbosity using regexps and 
plot graphs):

  http://www.ffconsultancy.com/tmp/mathematica.png

Mathematica's equivalent of the OCaml top-level is called a notebook. It 
provides expression input and result output, just like OCaml, but integrates 
graphics, adds typesetting and lots of mathematical functions. However, it is 
widely used for more general purpose programming despite being very slow.

Using F# from Visual Studio 2005 provides some of this functionality. The 
following screenshots illustrate 2D and 3D graphics spawned from an F# 
interactive session using a little of my own code and DirectX/ComponentsXtra:

  http://www.ffconsultancy.com/tmp/fs_xygraph.png
  http://www.ffconsultancy.com/tmp/fs_3dplot.png

For all non-trivials examples in F# it is necessary to spawn a separate thread 
to handle the GUI of the visualization, or the GUI will hang when the 
top-level is doing an intensive computation.

I think F# has a great future because of its ability to spawn visualizations 
from a running interactive session. Expensive commercial offerings like 
Matlab and Mathematica are ok when you're doing something they have built-in 
(e.g. a Fourier transform) but when you're problem is not trivially 
decomposed into their built-in operators (e.g. a wavelet transform), F# and 
OCaml are typically 2-5x faster, and when you must resort to more general 
purpose programming F# and OCaml are often 100x faster.

However, there is a lot of work to be done in getting competitive charting and 
visualization tools into F# and I'm thinking that OCaml could benefit from a 
joint venture here. Low-level routines would target DirectX in F# and OpenGL 
in OCaml but high-level routines could be language and platform agnostic, 
handling a scene graph that is essentially a typed version of Mathematica's 
to provide much faster graphics and even interactive visualisation 
(Mathematica is software rendered and not interactive!).

This raises several questions:

. What OCaml programs currently allow OpenGL-based visualizations to be 
spawned from the top-level?

. Has anyone tried to write an IDE that mixes OCaml code with graphics?

. Would anyone here be interested in a low-cost cross-platform technical 
computing environment based upon the OCaml and F# languages?

Obviously I'm interested in this from a commercial perspective. That looks 
easy for F# but not so easy for OCaml. Compiled OCaml+OpenGL code is not as 
portable (between machines) as F#+DirectX. Also, I can sell F# DLLs and even 
make the library available to other .NET languages (albeit with a 
significantly less productive API).

Finally, I'd like to note that operator overloading is probably the single 
biggest difference between my F# and OCaml code. The ability to apply + and - 
to many types, particularly vectors and matrices, makes this kind of work so 
much easier. Even if you have to add the odd type annotation. So I'd love to 
see a compatible implementation of overloading introduced into OCaml.

I'd like to hear everyone's opinions on this as, it seems to me, we're sitting 
on the foundations of a great technical computing system.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Interactive technical computing

[Jim Miller]

[-- Attachment #1: Type: text/plain, Size: 6002 bytes --]

I think that this would be a potentially fantastic application!  As a
physicist I am frequently faced with the option of using an interactive tool
that supports graphics (PV-WAVE, IDL, R, and Matlab/Octave are very popular)
but is VERY slow or doing things in a fast but tedious language (C/C++ are
currently the rage with a few individuals that still do Fortran 9X).

Having an OCaml based language that combines a top level command line loop
that allows me to interactive explore data and develop scripts but that
allows me to compile those into something fast could be a very, very useful
tool.  My particular domains are atmospheric photochemistry as well as
satellite mission planning and imagery exploitation.  We tend to do a LOT
less with 3D visualizations and much more with traditional line, contour,
and scatter plots.  We also do a lot of false color imagery.

The closest that I have come to this is a quick module that allows me to
spawn a gnuplot program and pass command strings, via a pipe.  A few
functions to ensure that data is formatted properly and I have something
that's manageable.

I'd be interested in conspiring/planning on something in this space.  It
would also be useful to see if there's a useful way to bridge this with R,
which is my current favorite language for doing statistical data analysis
and plot generation but it still suffers from the problems of speed.

On 3/7/07, Jon Harrop <jon@ffconsultancy.com> wrote:
>
>
> Being a user of both OCaml and Mathematica, playing with the new F#
> language
> from Microsoft and watching tutorial videos about VPython:
>
>   http://showmedo.com/videos/series?name=pythonThompsonVPythonSeries
>
> has given me a lot of inspiration about interactive technical computing
> environments. This class of applications is hugely useful for working
> scientists and engineers because it lets you slice and dice your data in
> interesting ways whilst also giving you visual throwback and even letting
> you
> do some fancy visualisations.
>
> For example, I'm in the process of updating my ray tracer language
> comparison:
>
>   http://www.ffconsultancy.com/languages/ray_tracer/index.html
>
> and I'm using a mix of OCaml (to fire off compilation and execution
> commands)
> and Mathematica (to dissect the results, compute verbosity using regexps
> and
> plot graphs):
>
>   http://www.ffconsultancy.com/tmp/mathematica.png
>
> Mathematica's equivalent of the OCaml top-level is called a notebook. It
> provides expression input and result output, just like OCaml, but
> integrates
> graphics, adds typesetting and lots of mathematical functions. However, it
> is
> widely used for more general purpose programming despite being very slow.
>
> Using F# from Visual Studio 2005 provides some of this functionality. The
> following screenshots illustrate 2D and 3D graphics spawned from an F#
> interactive session using a little of my own code and
> DirectX/ComponentsXtra:
>
>   http://www.ffconsultancy.com/tmp/fs_xygraph.png
>   http://www.ffconsultancy.com/tmp/fs_3dplot.png
>
> For all non-trivials examples in F# it is necessary to spawn a separate
> thread
> to handle the GUI of the visualization, or the GUI will hang when the
> top-level is doing an intensive computation.
>
> I think F# has a great future because of its ability to spawn
> visualizations
> from a running interactive session. Expensive commercial offerings like
> Matlab and Mathematica are ok when you're doing something they have
> built-in
> (e.g. a Fourier transform) but when you're problem is not trivially
> decomposed into their built-in operators (e.g. a wavelet transform), F#
> and
> OCaml are typically 2-5x faster, and when you must resort to more general
> purpose programming F# and OCaml are often 100x faster.
>
> However, there is a lot of work to be done in getting competitive charting
> and
> visualization tools into F# and I'm thinking that OCaml could benefit from
> a
> joint venture here. Low-level routines would target DirectX in F# and
> OpenGL
> in OCaml but high-level routines could be language and platform agnostic,
> handling a scene graph that is essentially a typed version of
> Mathematica's
> to provide much faster graphics and even interactive visualisation
> (Mathematica is software rendered and not interactive!).
>
> This raises several questions:
>
> . What OCaml programs currently allow OpenGL-based visualizations to be
> spawned from the top-level?
>
> . Has anyone tried to write an IDE that mixes OCaml code with graphics?
>
> . Would anyone here be interested in a low-cost cross-platform technical
> computing environment based upon the OCaml and F# languages?
>
> Obviously I'm interested in this from a commercial perspective. That looks
> easy for F# but not so easy for OCaml. Compiled OCaml+OpenGL code is not
> as
> portable (between machines) as F#+DirectX. Also, I can sell F# DLLs and
> even
> make the library available to other .NET languages (albeit with a
> significantly less productive API).
>
> Finally, I'd like to note that operator overloading is probably the single
> biggest difference between my F# and OCaml code. The ability to apply +
> and -
> to many types, particularly vectors and matrices, makes this kind of work
> so
> much easier. Even if you have to add the odd type annotation. So I'd love
> to
> see a compatible implementation of overloading introduced into OCaml.
>
> I'd like to hear everyone's opinions on this as, it seems to me, we're
> sitting
> on the foundations of a great technical computing system.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.
> OCaml for Scientists
> http://www.ffconsultancy.com/products/ocaml_for_scientists
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 7166 bytes --]

Re: [Caml-list] Interactive technical computing

[skaller]

On Wed, 2007-03-07 at 20:49 -0500, Jim Miller wrote:
> I think that this would be a potentially fantastic application! 

The question is whether you would get a sufficient grant to
actually pay for it.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Interactive technical computing

[Jim Miller]

[-- Attachment #1: Type: text/plain, Size: 1380 bytes --]

I have no doubt that nobody would give you a grant do to this.  The
immediate question my sources would ask is "WHY?" when there are so many
other languages out there.  The number of research scientists that I know of
that are asking for anything like this is exceedingly low.

On a side note, this is the most frustrating thing about the physics
community I work with.  I'm involved at GMU in the COMPUTATIONAL physics
department. We are supposed to be applying cutting edge technology to
problems and yet the application of new languages gets VERY little traction
there.  Every argument I've ever made to the faculty there about the ability
for an O'Caml type language to improve our productivity and confidence in
the answers it produces tends to fall on deaf ears.

Of course, I am just a student there, but I'm also an experienced (15 years)
professional programmer that might know a thing or two about programming ...
sigh.

Most research physicists that I work with (NRL in particular) are worse.

On 3/7/07, skaller <skaller@users.sourceforge.net> wrote:
>
> On Wed, 2007-03-07 at 20:49 -0500, Jim Miller wrote:
> > I think that this would be a potentially fantastic application!
>
> The question is whether you would get a sufficient grant to
> actually pay for it.
>
> --
> John Skaller <skaller at users dot sf dot net>
> Felix, successor to C++: http://felix.sf.net
>

[-- Attachment #2: Type: text/html, Size: 1791 bytes --]

Re: [Caml-list] Interactive technical computing

[skaller]

On Wed, 2007-03-07 at 22:00 -0500, Jim Miller wrote:
> I have no doubt that nobody would give you a grant do to this. 

That isn't the question. If Harrop developed it and sold it
for $US 5000.00 would your grant cover it?

Harrop can estimate the market by surveying researchers
and finding what their financial situations could support.

One grant isn't expected to cover the whole development!

BTW: I did some computational atmospheric photochemistry
in the 1970s, looking at ozone and effects of SSTs,
but mainly studying the socio-political role of 
funding of those studies .. (most of the money came
from people with vested interests :)


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Interactive technical computing

[skaller]

On Wed, 2007-03-07 at 22:19 -0500, Jim Miller wrote:
> Ah, I misunderstood ...
> 
> I would say that with the researchers I know of and work with, the
> answer would be no.  $5K these days is a lot of money for most of the
> scientists I'm working with, to the point that they're actually using
> Octave and R (free) and moving away from buying their analysis
> packages. 

So how about $500? I just picked a random number out of the air.

Don't forget .. the general framework Harrop describes isn't
restricted to the science market, certainly not just atmospherics.

Although with the current hype about global warming, atmospheric
modelling might get additional funds pumped in .. :)

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Interactive technical computing

[Jim Miller]

[-- Attachment #1: Type: text/plain, Size: 1930 bytes --]

>From a marketing perspective a price point in the 100s is definitely more
reasonable than the thousands, obviously :-)

What's I think is the interesting point about this discussion is "What are
the hurdles toward acceptance of any new language, scripting or not, into a
given community?"  Obviously OCAML and the ML languages have deeply
penetrated some markets but haven't even dented others.  There have been
lots of papers, studies, and discussion written on this (
lambda-the-ultimate.org has many of them archived) so that's probably
something for a different thread to be read wearing flame-retardant
underthings.

Professionally I'm in a community that could deeply benefit from the type of
language that would allow for scripting, data analysis, etc, that could then
be directly compiled into tight executable code.  While the barriers to
entry to that market could be high, I'm in a position where I could see
selling it.  I could actually get really excited about this.

Probably something to take off list if this is something to pursue

On 3/7/07, skaller <skaller@users.sourceforge.net> wrote:
>
> On Wed, 2007-03-07 at 22:19 -0500, Jim Miller wrote:
> > Ah, I misunderstood ...
> >
> > I would say that with the researchers I know of and work with, the
> > answer would be no.  $5K these days is a lot of money for most of the
> > scientists I'm working with, to the point that they're actually using
> > Octave and R (free) and moving away from buying their analysis
> > packages.
>
> So how about $500? I just picked a random number out of the air.
>
> Don't forget .. the general framework Harrop describes isn't
> restricted to the science market, certainly not just atmospherics.
>
> Although with the current hype about global warming, atmospheric
> modelling might get additional funds pumped in .. :)
>
> --
> John Skaller <skaller at users dot sf dot net>
> Felix, successor to C++: http://felix.sf.net
>

[-- Attachment #2: Type: text/html, Size: 2441 bytes --]

Re: [Caml-list] Interactive technical computing

[Richard Jones]

On Wed, Mar 07, 2007 at 10:36:18PM -0500, Jim Miller wrote:
> What's I think is the interesting point about this discussion is "What are
> the hurdles toward acceptance of any new language, scripting or not, into a
> given community?"  Obviously OCAML and the ML languages have deeply
> penetrated some markets but haven't even dented others.  There have been
> lots of papers, studies, and discussion written on this (
> lambda-the-ultimate.org has many of them archived) so that's probably
> something for a different thread to be read wearing flame-retardant
> underthings.

I'm currently contributing to a 45KLOC C library which I'm sure would
be about 10 times smaller if written in a reasonable language.

Putting aside the obvious cultural resistance to using a sensible
language for this project, there is one technical hurdle: It needs to
compile into a DLL which can be linked to other programs (in C and
other languages).  I can't generate such code using ocamlopt, at least
not without using unsupported out-of-tree extensions.

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] Interactive technical computing

[Matthieu Dubuget]

Richard Jones a écrit :
>> Putting aside the obvious cultural resistance to using a sensible
>> language for this project, there is one technical hurdle: It needs to
>> compile into a DLL which can be linked to other programs (in C and
>> other languages).  I can't generate such code using ocamlopt, at least
>> not without using unsupported out-of-tree extensions.
>>   
>>     
Could you please give us some details? What kind of extensions?

I'm mainly producing DLLs with ocamlopt.
My only concern is the fact that I am to avoid some standard modules
(Thread at least),
to avoid crashes that occurs after the calling app has unloaded my DLLs.


Salutations

Matthieu

Re: [Caml-list] Interactive technical computing

[Richard Jones]

On Fri, Mar 09, 2007 at 08:43:50AM +0100, Matthieu Dubuget wrote:
> 
> Richard Jones a écrit :
> >> Putting aside the obvious cultural resistance to using a sensible
> >> language for this project, there is one technical hurdle: It needs to
> >> compile into a DLL which can be linked to other programs (in C and
> >> other languages).  I can't generate such code using ocamlopt, at least
> >> not without using unsupported out-of-tree extensions.
> >>   
> >>     
> Could you please give us some details? What kind of extensions?
> 
> I'm mainly producing DLLs with ocamlopt.

You're doing this on Windows with ODLL?

I want to generate Unix .so files, and as you might guess from my
company affiliation, I'm not too worried about Windows :-)

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] Interactive technical computing

[Gerd Stolpmann]

Am Donnerstag, den 08.03.2007, 14:27 +1100 schrieb skaller:
> On Wed, 2007-03-07 at 22:19 -0500, Jim Miller wrote:
> > Ah, I misunderstood ...
> > 
> > I would say that with the researchers I know of and work with, the
> > answer would be no.  $5K these days is a lot of money for most of the
> > scientists I'm working with, to the point that they're actually using
> > Octave and R (free) and moving away from buying their analysis
> > packages. 
> 
> So how about $500? I just picked a random number out of the air.
> 
> Don't forget .. the general framework Harrop describes isn't
> restricted to the science market, certainly not just atmospherics.
> 
> Although with the current hype about global warming, atmospheric
> modelling might get additional funds pumped in .. :)

Hehe, scientists and business...

Here is a way that could work (because it already worked for me):

- Make the product open-source (this is a door-opener!)
- Make a good web site, with add-ons etc.
- Announce yourself as the guy who increases the productivity of the
highly-paid scientists, and offer your consultancy services

I say that because it is not so easy to sell licenses for money (high
costs to even be recognised as a product vendor). It is not so easy to
get rich these days...

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------

Re: [Caml-list] Interactive technical computing

[Christophe TROESTLER]

Hi,

I certainly am interested in such a project (even to contribute though
my time is limited).

> On Thu, 8 Mar 2007, Jon Harrop <jon@ffconsultancy.com> wrote:
> > 
> > I think F# has a great future because of its ability to spawn
> > visualizations from a running interactive session.  [...]

I have written a Gnuplot module that allows that.  Here is the
compulsory screenshot :)

  ftp://ftp.umh.ac.be/pub/ftp_san/Ocaml-gnuplot.png

Code :

  # load "gnuplot.cma";;
  # module G = Gnuplot.Array;;
  # let g = G.init G.X;;
  # G.box g;;
  # G.pen g 1;;
  # G.fx g sin (-1.) 20.;;

It definitely needs some further work but I do not have much time for
that now.  Also, I need to be able to plot data defined on triangular
meshes (and non square domains) and Gnuplot does not allow that so I
am looking for a solution viable for a longer term.

Maybe a wrapper for VTK (http://www.vtk.org/) could be a good start --
and trivially solves the portability issues.

> > Obviously I'm interested in this from a commercial
> > perspective. That looks easy for F# but not so easy for OCaml.
> > [...]
On Thu, 08 Mar 2007, Gerd Stolpmann <info@gerd-stolpmann.de> wrote:
> 
> - Make the product open-source (this is a door-opener!)

Unless it is open source, I would not use such a product.  Having it
open source is the only waranty for long term security.  I would not
develop codes that cannot run 5 years later because, say, you
unfortunately went to bankruptcy... or you became crazy and ask 10
times more money... or...

> > Finally, I'd like to note that operator overloading is probably
> > the single biggest difference between my F# and OCaml code. The
> > ability to apply + and - to many types, particularly vectors and
> > matrices, makes this kind of work so much easier.

That would not completely remove the problem of adding some operators
but I was thinking of a possibly generic solution using Camlp4:
writing [X.(a + b)] where [X] is a module would become [X.add a b].
Now for matrices, one still needs + (for matrix addition), * (for
matrix multiplication) and, say, .* (for scalar product).  So to be
generic, one needs to be able to specify a set of operators (with
precedences) and a way to transform an AST of that mini language into
Caml code (that would possibly allow some optimisations, analysing the
expression at compile time to reduce de number of intermediate
matrices allocated).  A slicing notation also needs to be developed,
say [a.{1, 2:3:7}], as well as a good ASCII pretty printer for
matrices (they must be bigarrays to be able to use interesting
libraries).

Cheers,
ChriS

Re: [Caml-list] Interactive technical computing

[Jon Harrop]

On Thursday 08 March 2007 14:24, Christophe TROESTLER wrote:
> I have written a Gnuplot module that allows that.  Here is the
> compulsory screenshot :)
>
>   ftp://ftp.umh.ac.be/pub/ftp_san/Ocaml-gnuplot.png

Great stuff. Thanks. :-)

> Unless it is open source, I would not use such a product.  Having it
> open source is the only waranty for long term security.  I would not
> develop codes that cannot run 5 years later because, say, you
> unfortunately went to bankruptcy... or you became crazy and ask 10
> times more money... or...

I can't justify the time unless I get to sell something. :-)

> > > Finally, I'd like to note that operator overloading is probably
> > > the single biggest difference between my F# and OCaml code. The
> > > ability to apply + and - to many types, particularly vectors and
> > > matrices, makes this kind of work so much easier.
>
> That would not completely remove the problem of adding some operators
> but I was thinking of a possibly generic solution using Camlp4:
> writing [X.(a + b)] where [X] is a module would become [X.add a b].
> Now for matrices, one still needs + (for matrix addition), * (for
> matrix multiplication) and, say, .* (for scalar product).  So to be
> generic, one needs to be able to specify a set of operators (with
> precedences) and a way to transform an AST of that mini language into
> Caml code (that would possibly allow some optimisations, analysing the
> expression at compile time to reduce de number of intermediate
> matrices allocated).  A slicing notation also needs to be developed,
> say [a.{1, 2:3:7}], as well as a good ASCII pretty printer for
> matrices (they must be bigarrays to be able to use interesting
> libraries).

I don't think you can obtain F#'s brevity/clarity that way because you need to 
affect type inference and macros can't do that.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Interactive technical computing

[Christophe TROESTLER]

On Thu, 8 Mar 2007, Jon Harrop <jon@ffconsultancy.com> wrote:
> 
> I can't justify the time unless I get to sell something. :-)

I understand that, that why I put Gerd's quote first.

> I don't think you can obtain F#'s brevity/clarity that way because
> you need to affect type inference and macros can't do that.

No but macros can locally change what '+' means.  With some Camlp4
hackery and using the Vec.t type of Lacaml (which is a shorthand for
(float, Bigarray.float64_elt, Bigarray.fortran_layout)
Bigarray.Array1.t), your F# example could look :

  # let a = {| 1.; 2.; 3. |} and b = {| 2.; 3.; 4. |};;
  val a : Vec.t = {| 1.; 2.; 3. |}
  val b : Vec.t = {| 2.; 3.; 4. |}
  # Vec.(a + b);;
  - : Vec.t = {| 3.; 5.; 7. |}

Of course, when mixing vectors and matrices, we will not be able to
stay with only + and * but I am not sure that having to put type
annotations will compare favorably to put the expression in Mat.(...)
and inventing a _few_ additional operators.

Moreover I think that, in some respects, it is even better than
overloading!  For example if you write

  # Vec.(a + b + c)

then Camlp4 could generate code that only needs to create 1 temporary
vector to hold the result instead of 2 (as is the case in F#).

Cheers,
ChriS

Re: [Caml-list] Interactive technical computing

[Jon Harrop]

On Thursday 08 March 2007 20:34, Christophe TROESTLER wrote:
> Of course, when mixing vectors and matrices, we will not be able to
> stay with only + and * but I am not sure that having to put type
> annotations will compare favorably to put the expression in Mat.(...)
> and inventing a _few_ additional operators.

Many arithmetic expressions mix different types.

> Moreover I think that, in some respects, it is even better than
> overloading!  For example if you write
>
>   # Vec.(a + b + c)
>
> then Camlp4 could generate code that only needs to create 1 temporary
> vector to hold the result instead of 2 (as is the case in F#).

I would expect the compiler to automate that deforesting.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Interactive technical computing

[Christophe TROESTLER]

On Fri, 9 Mar 2007, Jon Harrop <jon@ffconsultancy.com> wrote:
> 
> >   # Vec.(a + b + c)
> >
> > then Camlp4 could generate code that only needs to create 1 temporary
> > vector to hold the result instead of 2 (as is the case in F#).
> 
> I would expect the compiler to automate that deforesting.

And how could it do that, not even knowing how to allocate a vector,
less how to pass a preallocated vector to an « add » operation
(because this, of course, depends on what « + » means...) ?

ChriS

Re: [Caml-list] Interactive technical computing

[Erik de Castro Lopo]

Jon Harrop wrote:

> Finally, I'd like to note that operator overloading is probably the single 
> biggest difference between my F# and OCaml code. The ability to apply + and - 
> to many types, particularly vectors and matrices, makes this kind of work so 
> much easier. Even if you have to add the odd type annotation. So I'd love to 
> see a compatible implementation of overloading introduced into OCaml.

I'm mainly a Linux guy so the chances of me getting up close and personal
with F# are exactly zero :-). However, I am interested in hearing about
the differences between F# and Ocaml wrt operator overloading. Care to
clue me (and everyone else) in?

Cheers,
Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo
+-----------------------------------------------------------+
"Reality is just a crutch for people that can't handle CyberSpace!!"
- Hank Duderstadt

Re: [Caml-list] Interactive technical computing

[Andrej Bauer]

Jon Harrop wrote:
> I'd like to hear everyone's opinions on this as, it seems to me, we're sitting 
> on the foundations of a great technical computing system.

I would be very much interested in participating in an effort to develop 
an interactive environment for ocaml that surpases the currect toplevel.

I have in mind a toplevel that can be used *easily* as part of an 
application, has support for line-editing, fancy typesetting and 
graphics display. Intelligent pretty-printing would probably be a 
natural consequence of such desires (so that we graphics is just a fancy 
pretty printer).

As far as symbolic computation and manipulation of mathematical 
expressions is concerned: I am not sure that overloading operators and 
doing other kinds of violence to ocaml is the right way to go. It might 
be better to have instead a specific language for symbolic computation 
_on top_ of ocaml. The symbolic computation language would swallow the 
horrible and nasty notation that is used in mathematics, digest it, and 
pass it on to ocaml.

Best regards,

Andrej

Re: [Caml-list] Interactive technical computing

[Vu Ngoc San]

You probably know it already, but it is very easy to spawn opengl 
graphics directly from the toplevel using sdl. Then if you use the 
toplevel inside emacs, you get something very similar to the screenshots 
you had.

And since you are into screenshots, here is one :-)

http://www-fourier.ujf-grenoble.fr/~svungoc/prog/oplot/toplevel_plot.png

San

Re: [Caml-list] Interactive technical computing

[Jon Harrop]

On Thursday 08 March 2007 11:59, Vu Ngoc San wrote:
> You probably know it already, but it is very easy to spawn opengl
> graphics directly from the toplevel using sdl. Then if you use the
> toplevel inside emacs, you get something very similar to the screenshots
> you had.
>
> And since you are into screenshots, here is one :-)
>
> http://www-fourier.ujf-grenoble.fr/~svungoc/prog/oplot/toplevel_plot.png

This is just the kind of thing that I'd like to hear about!

How exactly do you do that? Can you post a complete working example?

Looks great... :-)

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Interactive technical computing

[Vu Ngoc San]

Jon Harrop a écrit :

> How exactly do you do that? Can you post a complete working example?
> 
> Looks great... :-)
> 
Thanks :-)

The idea is that sdl (contrary to glut or lablgtk2), does not have a 
"main loop": so you can write your own. This allows you to open an 
opengl window from the toplevel, and when you quit your mainloop, you 
get back nicely to the toplevel. You can even let the window open when 
you are back to toplevel, but then the graphics are not updated anymore.
Nice enough: you can later update the sdl window (no need to close it 
and open another one !).
If you really need interaction in the window and in the toplevel at the 
same time, you can launch the sdl mainloop in a separate thread. It 
really works. But I wouldn't try to open two sdl windows at the same 
time (??).

I don't have the courage -- and time -- to give you a "working example" 
(see below) but the initialisation is like this:

  Sdl.init [ `VIDEO ];
  Sdlvideo.set_video_mode !window_width !window_height [ `DOUBLEBUF ; 
`OPENGL ; `RESIZABLE]);
  Sdlwm.set_caption "Oplot - SDL Window" "";

Then you can issue any openGL command you wish. Even from the toplevel !

You can also use Sdlttf to handle any ttf font.

.....

Now, since you sort of asked for it, here it is:

I have written a small graphics library that does all of this. But this 
is my first ocaml program, first use of openGL etc.. so I'm not 
particularly proud of it. It is quite messy, and in a state of perpetual 
development. You can find a (not so recent) version at

http://www-fourier.ujf-grenoble.fr/~svungoc/prog/oplot/index.html

This lib is actually useful (to me) because you can insert LaTeX 
formulas and export directly to xfig (or postscript). It produces 
postscript of better quality than maple :-)

There is a (very recent) GUI for this at

http://www-fourier.ujf-grenoble.fr/~svungoc/prog/goplot/index.html

which uses lablgtk2 and launches sdl in a separate thread... (yep. my 
first use of GTK and of threads.. don't be too harsh if you read my 
code... -:) ). However, and even though I'm not a programmer (I do this 
for learning ocaml during my spare time), I'd be happy to have some 
feedback. There is a package with precompiled binaries that works on at 
least three linux machines :-)


San

Re: [Caml-list] Interactive technical computing

[skaller]

On Thu, 2007-03-08 at 22:28 +0100, Vu Ngoc San wrote:

> If you really need interaction in the window and in the toplevel at the 
> same time, you can launch the sdl mainloop in a separate thread. It 
> really works. 

No it doesn't. It works on Linux, but not on Windows.
Messages on Windows go to the thread that creates the
window, and fetches are done by default on the current
thread's message queue. X maintains a queue per
process, so it works on Linux (but be careful because
even re-entrant X isn't really re-entrant).

SDL has a serious design bug: it can't be used as a library,
it insists on providing the mainline (you can hack around
this though). On Linux, you don't have to do this because
the SDL mainline does nothing.

OpenGL has an even more serious design bug: contexts
are implicit. This is extremely bad design: it was
designed to work with serial code and optimise use
of a single video card.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net