Re: [ferret_users] Eddy tracking algorithm

[nuncio@xxxxxxxxx]

Hi all,
        Thats a very welcome move, Thanks Andrew
nuncio

Nuncio Murukesh, Ph.D
Research Scientist.
National Centre for Antarctic and Ocean Research
Headland Sada, Vasco Da Gama
Goa, 403804
India.
Ph: Cell-91 9890357423
    off- 91 832 2525428

----- Original Message -----
From: "Andrew Wittenberg" <Andrew.Wittenberg@xxxxxxxx>
To: "Ryo Furue" <furue@xxxxxxxxxx>
Cc: "Jaison Kurian" <jaison@xxxxxxxxxxxxxx>, "oar pmel ferret users" <oar.pmel.ferret_users@xxxxxxxx>
Sent: Friday, September 30, 2011 7:44:29 PM GMT +05:30 Chennai, Kolkata, Mumbai, New Delhi
Subject: Re: [ferret_users] Eddy tracking algorithm

Excellent comments from Jaison and Ryo.  Ferret has always been a fantastic and 
unique tool for many applications (huge datasets, remote datasets, quick 
exploration of NetCDF and OPeNDAP data, regridding, mapping, and anything 
requiring calendars, modulo longitude/time axes, and axis-broadcasting), but 
clunky for others (complex and iterative programming, element-by-element 
indexing, local scope (modules & namespaces), multi-variable returns from 
functions, and publication-quality graphics).

But stay tuned!  The Ferret developers are working on wrapping the Ferret code 
into a Python module, and already have a quite polished working prototype 
("Ferret 7") that some of us have been testing.  This is a HUGE development for 
both the Ferret and Python communities -- it means that we will soon have all of 
the above capabilities.

With Ferret7, one can easily switch back and forth between a standard Ferret 
environment and a Python prompt, and pass variables between the two.  One can 
also write scripts in either Ferret or Python, and even switch between languages 
inside of a single .jnl file or a single Python script.  And Ferret external 
functions can be written in Python, or any language that Python wraps -- 
allowing one to call, for example, any of the routines in NumPy, SciPy, or any 
other Python library, and have all of the variable & axis metadata carry through 
as we're used to.  Karl Smith has already ported many of the scipy.stats 
routines -- for finding PDFs and quantile functions, generating random deviates, 
parameter fitting, confidence intervals, statistical tests, etc. from a large 
number of distributions -- into Ferret external functions, and the results are 
impressive.  So we will soon be able to access all the power of Ferret, Python, 
PCMDI's CDAT, Matlab (via numpy+scipy+matplotlib), and Mathematica/Maple (via 
sympy and sage), in one place.

As they always have, the developers have taken care to maintain 
backwards-compatibility, so existing Ferret .jnl scripts will all work in 
Ferret7.  The Ferret prompt and environment are unchanged, and old-timers 
needn't even be aware of the Python capability if they don't want to.  But my 
goodness, if you know or learn Python, you'll now have all the control 
structures, object-oriented capability, and vast libraries of Python, including 
numerous fonts and 2d & 3d graphics libraries (matplotlib, sage, cdat, ncvtk).  
It's exciting to see the future of Ferret!

Andrew

On 09/29/2011 08:23 PM, Ryo Furue wrote:
> Hi,
>
> I agree that there are many problems which Ferret is not a suitable programming language to solve in.  Here I'd just like to comment on the following issue.
>
>> 1. Delayed mode evaluation
>>       Ferret evaluates all expressions only when it meets an action command (Ch3 Sec2.  EXPRESSIONS).
>>       This means that you cannot use expressions like
>>
>>             let var = var * something_else
>>
>>       One may think this is not a serious problem and a new variable name can be used for such steps.
>>       But in experience, this is a serious problem.
> That is a problem, for example, when you want to loop.  But, lazy evaluation is necessary in Ferret:
>
>    let speed = (u*u + v*v)^0.5 ! big 4D arrays
>    fill/k=1/l=1 speed ! I only need a slice
>
> Ferret computes only the necessary part of the big array, which is a blessing.  In an eager-evaluation language like C and Fortran, the first line would consume a lot of time and memory.  You can't do this
>
>    let var = var + something
>
> because the (partial) evaluation of the right-hand side occurs only when its value is required.  In other words, "let" is a "definition", not an "assignment", in Ferret.
>
> In Ferret, you don't usually use loops; you use functions.  In such a case, lazy evaluation saves time and memory because computation occurs only when necessary.  (There are computer languages that behave like that; Haskell is a primary example. You don't use loops in such a language; you use functions.)
>
>> Another aspect is that you cannot use a variable
>>       name which is already there in any of the opened datasets.
> I think this is a separate issue, and I agree that a fine-grained namespace would be very nice for programming.
>
> Regards,
> Ryo
>