[proFit-list] alpha testers wanted

Sat May 2 17:26:05 CDT 2009

Sorry forget my previous emails. I forgot to use the color schem I had
previously defined... It is getting late here.

Grussen

On 4/27/09 11:19 PM, "pro Fit Support" <profit at quansoft.com> wrote:

> Dear pro Fit users
> 
> We did expect Python to be a controversial issue, but it was not a decision
> that we took lightly. The language that we were to adopt had to fulfill the
> following criteria:
> 
> 1) The language should be available on a default MacOS without the need to
> install any special software.
> 
> 2) The language should provide a convenient mechanism to pass named arguments
> to functions. Think of a function such as PlotData, which has nearly 100
> possible arguments, such as the color of the plot, the line style, the point
> style, etc. etc. In a language that does not support named arguments, such as
> C, you would have to pass all 100 of them each time you call PlotData. A call
> to PlotData would e.g. look as follows:
> 
>  PlotData(scatterPlot, 1, 2, 0, FrontWindow, true, true, false, 0, 1, 0, 1, 0,
> 1, linScaling, linScaling, linScaling, ...etc)
> 
> With named arguments, you only pass the arguments whose default values you
> want to change, such as
>  PlotData(xColumn 1, yColumn 2)
> 
> 3) It should be possible to integrate the language into our built-in debugger.
> therefore, the language should provide a reasonably easy to use mechanism to
> obtain the names and values of variables, to set breakpoints, etc.
> 
> 4) The language should be such that it is at least difficult to make pro Fit
> crash or hang.
> 
> 5) The language should be suited for scientific use, should have a large base
> of users in scitech and there should be a large pool of readily available
> scitech software for it.
> 
> When evaluating the languages, we did not have any bias ourselves. (In fact,
> personally, I do not really adore Python's indentation-based syntax, but after
> having worked with it for some time I see that it does have its advantages.)
> 
> Basically, the languages fulfilling criteria 1 through 4 are Python, Ruby,
> JavaScript, Apple Script and PHP. In addition, Python excels in criterion 5
> (it supports a rich math library, complex numbers, and there are very powerful
> packages for numerical analysis, such as numpy (which is installed by default
> in MacOS 10.5) and scipy). Ruby was close, but definitely second, and Java
> Script also had its appeal because it is bound to see some major speed
> optimizations in the near future. (PHP is too web centric in our view, and
> Apple Script provides poor numerical capabilities and is slowish.)
> 
> When integrating Python into pro Fit, we redesigned the pro Fit scripting
> architecture in such a way that most of the application is agnostic of the
> actual scripting language in use, with a defined interface between pro Fit and
> the scripting language. Hence, the integration of a third language in the
> future should be much easier. Therefore, if you provide us with good reasons
> to integrate a further scripting language, we may consider this. However,
> first we will first work on optimizing the Python and Pascal scripting.
> 
> And please, as mentioned by Chris, do not start a language war here. There are
> enough of these out there.
> 
> Regards
> 
> Kurt Sutter
> QuantumSoft
> 
> 
> On 27.04.2009, at 08:17, Chris Lee wrote:
> 
>> I am not going to start a language war, but I think there are some very good
>> reasons for choosing python. It gives you a lot of language integration for
>> free. You can call C and fortran code with ease and receive the results as a
>> python type variable. So, depending on what the final implementation looks
>> like, this will actually do exactly what you want with a lot less work for
>> the quantumSoft dudes.
>> 
>> Another reason for choosing python might be numpy, scipy and scientific.
>> These three libraries basically give you an open source matlab (sans
>> visualization... you need other packages for that). It handles arrays and
>> complicated operations much more cleanly than current pro fit coding
>> operations. By integrating python pro fit can take advantage of all of this
>> without having to reinvent the wheel.
>> 
>> That said, there are good reasons for including other languages as well.
>> 
>> Cheers
>> Chris
>> 
>> On Apr 26, 2009, at 10:54 PM, s.g. prussin wrote:
>> 
>>>  Thank you for this. Once again, I'd like to ask that you consider the
>>> direct importing of FORTRAN code. For many in the scientific and engineering
>>> community, we still use this language and it must be so because of the very
>>> many legacy codes that are the basis of many calculations. I know it's a big
>>> request but please consider it - sgp
>>> 
>>> 
>>> On Apr 26, 2009, at 3:32 AM, pro Fit Support wrote:
>>> 
>>>> Dear pro Fit users
>>>> 
>>>> We at QuantumSoft are presently working hard on the next version of pro
>>>> Fit, which will be version 6.2. The release date of that version is still
>>>> uncertain, but my guess is that it will be sometime in late 2009 or in
>>>> 2010, so don't hold your breath. It will provide a number of interesting
>>>> new features.
>>>> 
>>>> One of these new features will be integrated support for the Python
>>>> programming language for defining Programs (Macros) and pro Fit functions,
>>>> as an alternative to pro Fit's own Pascal-like compiler.
>>>> 
>>>> We feel that some user feedback would be valuable at this time. We
>>>> therefore have decided to run an "alpha" testing program with version 6.2,
>>>> with emphasis on its Python programming capabilities. So, if you have some
>>>> Python knowledge, or if you are an experienced pro Fit user willing to
>>>> spend some time digging into Python and testing pro Fit with it, please
>>>> send us a note to
>>>> 
>>>> profit at quansoft.com,
>>>> 
>>>> with a brief description of who you are and why you feel you could
>>>> contribute to the alpha testing. If you are accepted to the alpha testing
>>>> program, we will then send you a pro Fit build to test.
>>>> 
>>>> Please do not expect the build that we will send you to be fit for normal
>>>> use. It will be an internal build that has not undergone much testing and
>>>> that will have various parts unfinished or disabled. It is for testing
>>>> only. It will require MacOS 10.5.6 or better.
>>>> 
>>>> Best regards
>>>> 
>>>> Kurt Sutter
>>>> QuantumSoft
>>>> 
>>>> 
>>>> _______________________________________________
>>>> proFit-list mailing list
>>>> proFit-list at quantum-soft.com
>>>> http://quantum-soft.com/mailman/listinfo/profit-list_quantum-soft.com
>>>>  
>>> 
>>>  
>>> S.G Prussin
>>> Department of Nuclear Engineering
>>> University of California
>>> Berkeley, California 94720
>>> 
>>> prussin at berkeley.edu
>>> 
>>> 
>>>  
>>> 
>>> _______________________________________________
>>> proFit-list mailing list
>>> proFit-list at quantum-soft.com
>>> http://quantum-soft.com/mailman/listinfo/profit-list_quantum-soft.com
>> 
>> _______________________________________________
>> proFit-list mailing list
>> proFit-list at quantum-soft.com
>> http://quantum-soft.com/mailman/listinfo/profit-list_quantum-soft.com
> 
>  
> Best regards
> 
> Kurt Sutter
> QuantumSoft
> 
>  
> 
> 
> 
> _______________________________________________
> proFit-list mailing list
> proFit-list at quantum-soft.com
> http://quantum-soft.com/mailman/listinfo/profit-list_quantum-soft.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://quantum-soft.com/pipermail/profit-list_quantum-soft.com/attachments/20090503/498a524a/attachment.html>