Hi Aaron,

Your points are quite relevant.
I am involved in the development of the application MathScript, which
you had mentioned before.

The entire keypad layout is done with a similar class structure as I
had described in previous mail. But, it is not complete yet.

We recently enabled google analytics in the app. It is quite
interesting to note that more than 80% of people use this as a
scientific calculator, with an average time of around 6 minutes spent
on the application (increased from 3 to 6 minutes in last week). Only
a fraction of users use advanced functions. The most common being
"solve" an "integrate".

As you rightly pointed out, SymPy has tons of functions, which are
gradually expanding. But, as a new user, it is hard for one to know
which does what. Categorization of functions would help them in
getting things going smoothly.

The contextual intelligence is one thing we want to implement too. In
fact, I am considering two methods of input. The first one would be
just like a text editor with buttons to insert predefined text. The
second one would be an intelligent input with a recursive layout
involving blocks of commands.
Example:
integrate(sin(x),x)
would appear as a box titled integrate(##,##) where ## are fields/
boxes that can be recursed in the same way. The user clicks on the
field to edit it. Each field can optionally have a set of rules/hints.
The advantage is that, the system can now easily guide the user and
check for any mistakes by evaluating the fields recursively. It would
then be impossible for the user to make a mistake when entering the
commands. I think we would be effectively writing a parser in this
case, as we need to read an arbitrary python code into the system.

There was an option similar to tab completion for the application. It
was done using a button to list all the member functions for a
keyword. But, the users were often confused about the huge list of
functions and did not use it. I think we have far too many member
functions than required. One way to avoid it is to use another set of
custom defined class (same as the keypad class) with children
functions/classes.

The function "sympify" is a very good idea. I will have a look into
it.

Meanwhile, I think I can contribute some of the source code (keypad
layout and 2d plotting) to SymPy. I will do it as soon as possible.


Shyam

On Apr 16, 4:34 am, "Aaron S. Meurer" <[email protected]> wrote:
> Hi.
>
> I can't really tell much about your application from what you wrote, so I 
> hope my responses are relevant.
>
> On Apr 14, 2011, at 12:33 AM, Shyam wrote:
>
> > Dear All,
> > I am involved in developing SymPy based application.
>
> Is this a mobile application or a desktop application?  
>
>
>
> > Python being a very powerful tool by itself, I am leveraging on its
> > simplicity for creating user interfaces for SymPy. The context of
> > currentlayoutis to design some thing like a calculator with buttons.
> > Please feel free to give me your views in designing thekeypadlayout.
> > If you know any otherlayoutlike this kindly let me know.
>
> The only one that I know of is in this Android app that someone made for 
> SymPy:https://market.android.com/details?id=com.funmath.mathscript.
>
>
>
>
>
>
>
>
>
>
>
> > Objectives::
> > To create an user interface for people in all levels
> > By default, it should be like a calculator
> > Two modes possible:
> > **Calculator mode: (the input box can be edited only with buttons,
> > just like a calc.)
> > **CAG Mode: (more like a command prompt, along with buttons to insert
> > predefined texts and provides hints)
>
> > With that in mind, I have categorized thekeypadas a nested class.
> > For now, the class (schematically) looks like this
> > =================================
> > Class:: Function:
> > Members::
> > * Name (ex: 'integrate')
> > * Function (ex: 'integrate')
> > * Syntax (ex: '(,)' )
> > * Variable Hint (ex: ['function', 'variable'])
> > * Example (ex: 'var('x'); integrate(sin(x),x)' )
> > * arguments []
> > * Children Functions[] (if child present, clicking the function will
> > open another window of functions)
>
> > * Button properties (size, position etc.)
>
> > Member Methods::
> > IsValid( ) :: Check the arguments recursively if they are valid
> > (returns true or false)
> > evalfunc() :: Evaluate the function (throws exception if not valid)
> > AddChild(Function e):: add the function to the children functions
> > making this instance aKeyPad.
> > =================================
>
> I can't say much about good object oriented design.
>
>
>
> > Thelayoutwill have many categorized Pads (like algebra, calculus
> > etc.) with relevant functions in them. The default pad will resemble
> > an ordinary calculator.
>
> This is a good idea.  SymPy has a ton of functions, and most users will only 
> care about a small subset of them.
>
> Another idea, which would be much more difficult to implement, is to make the 
> keyboard "smart".  So that it "learns" what functions you use and puts them 
> up front, and also has some contextual intelligence (for example, the second 
> argument of functions like integrate and diff should be a defined Symbol, and 
> if you have a . after something, it means you are going to call a method).  
>
> Also, some kind of "tab completion" would be helpful (like IPython has).
>
> This is unrelated to the keyboard, but you might consider at least making it 
> an option to pass everything as a string through sympify(), so that the user 
> doesn't have to worry about symbol instantiation (especially if it is a 
> mobile application).  This will also make it handle fractions (like 1/2) 
> correctly.
>
> Aaron Meurer
>
>
>
>
>
>
>
>
>
> > Thanks in advance for your views.
>
> > Regards,
> > Shyam
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "sympy" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to 
> > [email protected].
> > For more options, visit this group 
> > athttp://groups.google.com/group/sympy?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Reply via email to