Q1. I would use BigInt. BigNat is really an internal type and it should be hidden.

Q2. You are right there is no overload "bigint". The BigInt module has the to_int32, of_int32 etc. functions you need.

Q3. re:

I read ... that is possible to have infinite seq ... { 0 .. }

This was marked with a "Not Yet Implemented" comment. Just use Seq.init_infinite.

Q4. in some procedure i have to visit some trees ad I would like have something like "break" or "continue" in c#. There are something similar in F# to break the execution of for / while ?

In this situation you should almost certainly recode the function as a recursive function. It's an important technique to learn, and you will find yourself using a lot less mutable local state once you learn it. e.g.

1
2
3
4
5
6
 

   let rec loop n = 

      if n > LIM then ... else loop (n+1)

etc.

Q5. I would like to plot data from the simulation engine in real time (each concentration have to be computed on request)

I assume you want your simulation to run "full throttle", computing the results at the maximum rate while having them visualized in some way.

A major choice you will have is whether to go multi-threaded or single-threaded. The DirectX 3D visualization demo is single threaded: the paint loop endlessly repaints and the simulation is computed on the GUI thread. This is not a bad choice when prototyping. However if any single step of the computation becomes too long then it causes real problems with a non-responsive or "messed up" GUI.

So ultimately you should be prepared to build a worker that runs in its own thread. This can either "push" results back to a GUI control (e.g. by raising events on the GUI thread) or write its results into some other "sink" for the data (e.g. a queue of pending updates). In the first case the GUI adds event handlers to the events, and in the second case can query the worker (e.g. dequeue updates from the queue) whenever it's able to do a redraw. Note that:

  • Uncontrollable computations are a real pain. The worker should almost certainly respond to signals such as "pause" and "cancel", which get triggered by buttons. This can be done by checking shared state flags or by looking at a message queue.
  • If the worker is producing results very rapidly you may have to slow it down or reduce the reported result rate to ensure a good response from the GUI. It's very important you keep a good user experience in this kind of application - often more important than producing results at the fastest rate possible.

Chapter 14 of the Expert F# book deals with some of these topics, though not in nearly as much depth as I would wish - I have a draft available that I can send you if you would like to read it - I'd actually really like feedback on this chapter from people interested in building simulations as it is a main application area for F#. Send me your email address (mine is dsyme AT microsoft DOT com).

The ConcurrentLife sample in the F# distribution also does something like this. I've jsut updated that sample in our code tree and can send it to you.

The System.ComponentModel.BackgroundWorker class may also be of use to you.

regards

Don

By on 5/14/2007 2:55 PM ()

Many thanks; I did not hope of having an answer so complete, clear, and quick.
Your suggestions are always very useful.
Best regards and best wishes. gs

By on 5/15/2007 9:22 AM ()
IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy
Built with WebSharper