But is my API really useful?

[Maulin Vasavada]

Hi all,
As you would observe from my couple of recent post I am trying to put up API+Impl for basic expression eval in Java. I started with basic infix expression but now I think I would put more things in there.
So, I am really wondering how much this API is useful? I saw couple of people posting need of expression evaluating in Java and thats why I started it but initially it all started with simple Infix support but now I am thinking of having Support for function operators like Sin, Cos, Max, Min etc (which can map to Math class's corresponding method). I am not planning to support complex expressions in default impl of my parser (like sin(cos(tan())) nested things you know) for the expression but I guess it would be good to put the support for basic function operators.
Please give me your feedback if I should go put time in this or not.
Mostly this would be useful to academic fields I guess.
Moderators, I was not sure where to post this question as such so I have posted it here but feel free to shift it to where it can get more responses.
Thank you
Maulin.

[Valentin Crettaz]

Moving this to the Other Open Source Projects forum. Please continue this discussion there. Thank you

[Ernest Friedman-Hill]

Can you compare and contrast your API with, say, the BeanShell, or Groovy, or some of the other Java scripting tools?

[Maulin Vasavada]

Hi Ernest
I wasn't aware of those APIs. I will look into them and then provide my feedback here. I seriously don't want to put "yet another API".
Also, you know I got confused myself about what exactly I wanted to do. I found http://jep.sourceforge.net/ project which does very good job and my parser simply can't be compared to that. So, what I think is I will restrict my API to just pure infix2postfix framework with simple parsing. If users really want complex math evals they must use other tools like JEP.
I just want to create simple API that is probably useful to academics probably where they want to have UI demo of things to explain datastructures. Its a different story that I am using this in my application using CollectionPostfixEval I have put up.
Thanks
Maulin

[Frank Carver]

When you take the development of an expression evaluator to its logical limit you end up with some sort of "functional language". Is this your goal, or do you have another end result in mind? If you want to end up with something different, you need to think now about how you plan to get there.
Do you have a specific domain in mind for this development? Ideally this would be a domain with specialist functions and expressions, where there is a need for a computerised expression evaluator.
These are the sort of questions that might help you decide whether the API is (or might become) useful. In the short term, it is also useful to help you practice your skills, of course.

[Maulin Vasavada]

HI Ernest,
I saw BeanShell and Groovy. They are way bigger than my little API. I don't want complex shell or scripting things. I just want,
- simple API that can take boolean OR math expressions in infix form
- simple API that supports postfix evaluations
- API that can be extended little bit to do little different thing
I know this is not a big thing at all but it might be helpful to many people who don't want to re-write or customize the external code a lot OR don't need to download whole complex thing just to get Infix2Postfix working with simple examples.
Of course you might be interested why I had to use it (probably you already guessed while I am writing this) in my application if I tell you I am working on building rule component
Thanks
Maulin

[Maulin Vasavada]

HI Ernest,
I saw BeanShell and Groovy. They are way bigger than my little API. I don't want complex shell or scripting things. I just want,
- simple API that can take boolean OR math expressions in infix form
- simple API that supports postfix evaluations
- API that can be extended little bit to do little different thing
I know this is not a big thing at all but it might be helpful to many people who don't want to re-write or customize the external code a lot OR don't need to download whole complex thing just to get Infix2Postfix working with simple examples.
Of course you might be interested why I had to use it (probably you already guessed while I am writing this) in my application if I tell you I am working on building rule component
Thanks
Maulin

[Maulin Vasavada]

Hi Frank,
I agree with your view point. I don't want to re-create expression eval. Its there in JEP. My goal is not to provide this to science labs as they have better tools than this probably.
My view is- even if there is minimal need of welldefined infix expression conversion to postfix why one have to re-write? I think it in the following manner,
1. there is a student who has some application and needs to eval simple expression in one part of it by a program (of course java)
2. what are the options?
- Does he need JEP?
- Does he need Groovy?
- Does he need BeanShell?
-- I would say NO. He just wants 5-6 classes that can do the job. Less than 14K of code.
Here are my points in favor of this API,
----------------------------------------
1. I can easily add custom binary operator easily just by calling addOperator() and passing anonymous class new Operator() and writing what to do if that operator is there with two operands
- I can also remove support of any binary operator just by,
removeOperator("+");
2. I can eval boolean infix expressions like,
true & true | false & true ^ false & true
with equal easiness in following manner,
BooleanClient boolClient = new BooleanClient();
S.o.p(booleanClient.evaluate("true & true | false & true ^ false & true"));
3. I have generic Postfix Evaluation API that uses "Template Pattern" to deleage basic call of evaluate(operand1, op, operand2) (Binary) or evaluate(operand,op) (Unary) to the child class and hides all stacking things and all
So, so far from this discussion I see that its not lot worth but still useful to a very minority group and that might make it prone to "not to be further pursed for development" scenario
Lemme do one thing. Let me create javadocs for my classes and replace the one exist currently on my geocities site. I am really novice compared to all of you so , you would be able to measure it quite quickly. And I don't have so many confusing classes so it should not be hard.
Thanks
Maulin

[Frank Carver]

So, so far from this discussion I see that its not lot worth but still useful to a very minority group and that might make it prone to "not to be further pursed for development" scenario
I didn't mean to imply that your project is almost worthless. Far from it. I like the idea of run-time pluggable operators, and this flexibility just might be that this will help me with a problem I have had "on the back burner" for years.
The main aim of my questions was to help you think about where you want to take this project. If (as it seems from your reply, above) it's main USP ("unique selling point") is this pluggability of operators, maybe this should be the aspect you continue to develop. For example, can it parse (and can you add/remove) ternary operators, such as C and Java's "?:" ? Can you change the precedence of operators at run time ? Can it recognize and apply the common mathematical convention of "adjacency" as an operator (ie. 4 a implies 4 * a) ? Can it work accurately with integers bigger than MAXINT ? Can it work with floats and doubles in regular and exponential notation ? Can it work with numbers in other bases ?
I'll take a good look at your code over the next few days, and see what else occurs to me.

[Maulin Vasavada]

Hi Frank,
Here are my response to your questions,
1. Can it parse (and can you add/remove) ternary operators?
- No. This would be pretty difficult to do given my parser using just a loop.
2. Can you change the precedence of operators at run time ?
- How this would be helpful?
3. Can it recognize and apply the common mathematical convention of "adjacency" as an operator (ie. 4 a implies 4 * a)?
- I guess I can do this. Currently I don't have it in place but doesn't seem lot of work.
- Also, I don't have support for variables but I would think how to support it in better way
4. Can it work accurately with integers bigger than MAXINT ?
- Well, I convert things in Double so I don't have float,int, short, byte things. We get result in double format. Though in this new API I have (not published yet) we can easily change to other format of int or float by looking at MathClient Source (may be extend or modify)
5. Can it work with floats and doubles in regular and exponential notation ?
- My response to 4th question can be place here as well
6. Can it work with numbers in other bases ?
- This is interesting. I would think what it takes to do this.
So support for variables and "adjacency" thing seems a good thing.
What I feel is- if I keep (which I have) my parser method extensible then its good. For e.g. to support ternary operator we might have to lookahead/back things but the result would be pushed on the stack only. So, - we can override my parser method (that is split() currently but I am gonna change its name)
- override evaluate(postfix) in Postfix eval to take care of ternary paramters pops (as we have to pop more data than just 'two' now)
- add handling of '>=' , '<=' etc operators used in ternary than
it should work.
This would be writing much code for sure but still we would have basic framework in place.
I will start working on this new API's Javadocs ASAP so you can view what exactly I have currently (its really different and more useful than its currently up on my geocities).
Thanks
Maulin

[Frank Carver]

4. Can it work accurately with integers bigger than MAXINT ?
- Well, I convert things in Double so I don't have float,int, short, byte things.
Just as I thought.
So what do you get if you add 4 000 000 000 000 and 1 ? Is it what you expected

[Maulin Vasavada]

Hi Frank

I want to keep this thread alive so this post is here...

I am tied up in jobwork but I thought about specific support for int,double,float etc. I can't do it pluggable way I want so I don't plan on that for now.

I have started thinking about supporting,
1. variables,
2. that multiplication operator's adjacency..

In Variables support I would have the following model,
1. Valid variables list
2. Source interface where one can get runtime values for those variables

More later...

Regards
Maulin

[Maulin Vasavada]

okay..

I added following to my code,

1. support for variables
2. support for specific data type out of four-int,long,float,double (I can add more like short or byte but that doesn't sound so much needed)
3. support for specific radix type (whatever is supported by Character.MIN,MAX radix things)

I am starting writing Javadocs and will put the source + javadocs on my site soon.

I have not tested the code yet about what happens when I end up going beyond the limit of int , float etc while using those as data types but I will do that before posting it online...

Thanks
Maulin

[joe bonds]

Have you considered ruby, jruby?

[Maulin Vasavada]

Hi Joe,

I don't intend to build "scripting language". I am just going to have a java program that can take an expression in infix and process it.

Again as I have mentioned it earlier it is just probably helpful to bunch of people who want simple infix expression evaluation. I don't want to make "yet another scripting language". I am advocate of "reusable code" and I would be cautious that I don't end up having duplicate efforts.

I guess I would have to write javadocs ASAP to get it up on site so I can know if it, what I am doing , really sounds like "scripting language"?

Thank you for your suggestions. They are helping me.

Maulin

[Maulin Vasavada]

Hi all,

Finally, I prepared Javadocs and README etc and uploaded to,

http://www.geocities.com/maulin_v

Please review it and lets see if it sounds like I can keep it online for people to use

Thanks so much for your inputs so far.

Regards
Maulin

[Frank Carver]

OK, I've had a very brief look, and here are a few comments...

You wrote: Why this package supports "max" like function operators if it is supposed to only support "infix" expressions. (Note: 'max' is not an infix operator) - why not support "max" as an infix operator e.g (3 max 4) ?

You wrote: I have kept this package simple and hence I have not included ... JUnit test cases - To my mind this is one of the biggest omissions. Test cases would really help readers understand what to expect with running this, give some real big hints ion how to use it, and also allow an easy way to suggest added features and tell you about bugs. If I'm feeling keen, I might add a few JUnit test cases for you as I look around the code.

I was especially intrigued by your earlier suggestion of dynamic addition of operators, but I can't seem to find how to do this in your (very small) test harness. Suggestions?

I don't want to load down your operator definitions any more than they are already, but BigDecimal (and maybe BigInteger) seem a good and flexible fit for this sort of thing - you might be able to get away without Double and Float.

maybe more later, as I look deeper...

[Maulin Vasavada]

Hi Frank,

1. In max operator thing, we can easily support 3 max 4 format (this I will mention in how to add operators comment) but the reason we need specific max(2,4) thing is- usually math input will have it in this format. Now if I force user to change that to 2 max 4 then it would be additional step for them and that did sound little uncomfortable to me. So I went ahead with usual math input format for max(2,4) (You will notice in my code that I had to specially include comma as well to support it. It was easier for me to have max(2 4) but I preferred that it should be able to accept comma as its a natural thing to come in such operator)

2. Okay. I thought that I should have mentioned how to 'add' operators in my read me. I will do that ASAP. For quick pointer if you look at addDefaultOperators() method in the Math/Boolean client you would know what to do of course but I would do it explictly in my README.

It was Friday and I wanted to get API up asap for review so I lacked a little in providing details which I should have.

3. Again in JUnit thing I would have to first come up with test cases (I understand it would be lot easier for users to follow with JUnit test cases even if they don't have JUnit running...) and then I would put up. I plan to do that but again partially Friday factor enticed me to ignore it

4. Frankly, I have not used BigDecimal things before. I would look into them and see if its something that attracts me. Even being a CS Major I don't do much numbering and stuff you know so I kinda feel lazy sometimes

Thanks again for comments. For the first time I am taking such proper approach I would say

Next things for me to do are,
1. Write sample about how to add operators
2. Write JUnit test cases
3. Prepare class diagram

One problem I would like to mention in current implementation is though,
As you would notice in my code of MathClient, I add two int , two long etc. Now, when two int gets added and it overflows limit of int in java it would wrap and make the number -ve. This would produce unexpected results as the expression might be long and result of half of the expression is overflowing so rest half would get operated on -ve result from previous part and the end result is totally wierd

Lot to have fun in this weekends so it might take end of next week to do all of these...

Regards,
Maulin

[Maulin Vasavada]

Hi all,

While writing addOperator documentation I realized the implementation is buggy It will not really work easily for addOperator() so I am updating it to work easily.

If we look at addOperator() called from addDefaultOperators() from MathClient then we realize that we have to use convertForRadix() etc methods which are protected and also the operandManager instance member which is protected. This will disable us to add an operator from Test.java by mathClient.addOperator() which defeats the purpose of addOperator.

I would modify it and let you know. Also I am 50% done with class diagram.

Thanks
Maulin

[Maulin Vasavada]

Hi Frank,

Sorry for getting "Lost in translation"

I have modified my code little bit to make it possible to addOperator externally and remove it externally but I have not put it on site..

I am struggling to work on it while other developments but I am still active.

Thanks
Maulin

[Maulin Vasavada]

Hi all,

Again I have uploaded new zip file on the site (you see link in my signature).

I have included,
1. In README how to add operators/remove operators
2. Design folder where I have Poseidon created diagrams for my application
3. Updated Javadocs for my project

Thanks
Maulin

[Maulin Vasavada]

I found one more place of use of this API

So there are two places I use it currently,
1. Building rule expression for execution
2. In the rule if we want to have a condition like,
IF field1.value < (field2.value + field.value) * 2
THEN...

Thanks
Maulin