Java 1.5: mathematical formula parser - java

Hello i often develop JTableModels in which some cells must contain the result of apliying a certain simple mathematical formula. This formulas can have:
Operators (+,-,*,/)
Number constants
Other cell references (which contains numbers)
Parameters (numbers with a reference name like "INTEREST_RATE")
I often resolve it making a little calculator class which parses the formula, which syntax i define. The calculator class uses a stack for the calcs, and the syntax uses allways a Polish notation.
But the Polish notation is unnatural for me and for my users. So my question is...
Is there a lib which runs in 1.5 jvm's and can handle my requeriments and use normal notation (with brackets, i don't know the name of this notation style) for formulas?
P.D it's supposed that the formulas are allways syntax correct and i can preprocess the numbers that are not constants to provide their values

Have you thought about the benefits of JSR-223 ? in a few words, this spec allows Java developers to integrate with great ease dynamic languages and their parsers. Using such parser, your need for defining a parser transforms into the need for defining an internal DSL, which resolves into creating simply a good API, and letting your user choose wether they prefer Javascript/Groovy/Scala/WTF syntax they happen to prefer.

Try JEP.
You can define new variables to the parser hence it can contain reference names like "INTEREST_RATE".But you have to define it before hand.
As for cell references you will have to extract the number's and edit the expression accordingly or probably there might be some options which I'm not yet aware of.

If you can't use Java 6 and its scripting support then have a look at the Apache Bean Scripting Framework (BSF). From that page:
... BSF 3.x will run on Java 1.4+, allowing access to JSR-223 scripting for Java 1.4 and Java 1.5.

i released an expression evaluator based on Dijkstra's Shunting Yard algorithm, under the terms of the Apache License 2.0:
http://projects.congrace.de/exp4j/index.html

There's a commercial tool called formula4j which may be useful to some.
It has no direct help for cell references. You would have to handle those yourself, and translate the cell references into values.

Related

What are textual UML class diagrams? [duplicate]

UML classdiagrams are a standard graphical notation to describe classes and their relationships.
Is there a standard textual notation (DSL) to describe the same? Don't say XMI or EMF;-)
I think you could do that with Corba IDL and use Interfaces for classes, but this is somehow too much on the Corba side. You could use Java Interfaces, but this is too Java.
Background of my question is writing generators. I think it is easier to write a generator based on the syntax tree of a DSL than to parse a graphical notation. A graphical notation first has to be translated into a syntax tree (that would be the same you'd get from the corresponding DSL). I think translating a graphical notation into the syntax tree is harder than to translate a DSL (where you can use ANTLR).
You've got the answer already, but I'd like to clarify. There is a standard notation, it's called HUTN, and nobody uses it.
Check this complete list of textual notations to describe UML models. Btw, the reasons to create one of these tools (in particular TextUML) can be find here.
It is no coincidence that UML separates abstract and concrete syntax.
Tying up code generation to a user-facing notation is a bad idea. Tools (code generators) and people (modelers) have totally distinct needs, so no single syntax can serve both audiences well. Not to mention you lose the ability of applying the same code generator to models created using different notations.
TextUML is a concrete syntax tailored to modelers. XMI is a much better notation for tools, and the UML2 object model makes it very easy to handle.
Rafael
http://abstratt.com/blog
No standard notation to my knowledge but a good summary of options here.
hth.

"built in dependency injection" in scala

Hi the following post says there is "built in dependency injection" in scala
"As a Scala and Java developer, I am not even slightly tempted to
replace Scala as my main language for my next project with Java 8. If
I'm forced to write Java, it might better be Java 8, but if I have a
choice, there are so many things (as the OP correctly states) that
make Scala compelling for me beyond Lambdas that just adding that
feature to Java doesn't really mean anything to me. Ruby has Lambdas,
so does Python and JavaScript, Dart and I'm sure any other modern
language. I like Scala because of so many other things other than
lambdas that a single comment is not enough.
But to name a few (some were referenced by the OP)
Everything is an expression, For
comprehensions (especially with multiple futures, resolving the
callback triangle of death in a beautiful syntax IMHO), Implicit
conversions, Case classes, Pattern Matching, Tuples, The fact that
everything has equals and hashcode already correctly implemented (so I
can put a tuple, or even an Array as a key in a map), string
interpolation, multiline string, default parameters, named parameters,
built in dependency injection, most complex yet most powerful type
system in any language I know of, type inference (not as good as
Haskell, but better than the non existent in Java). The fact I always
get the right type returned from a set of "monadic" actions thanks to
infamous things like CanBuildFrom (which are pure genius). Let's not
forget pass by name arguments and the ability to construct a DSL.
Extractors (via pattern matching). And many more.
I think Scala is
here to stay, at least for Scala developers, I am 100% sure you will
not find a single Scala developer that will say: "Java 8 got lambdas?
great, goodbye scala forever!". Only reason I can think of is compile
time and binary compatibility. If we ignore those two, all I can say
is that this just proves how Scala is in the right direction (since
Java 8 lambdas and default interface methods and steams are so clearly
influenced)
I do wish however that Scala will improve Java 8
interoperability, e.g. support functional interfaces the same way. and
add new implicit conversions to Java 8 collections as well as take
advantage to improvements in the JVM.
I will replace Scala as soon as
I find a language that gives me what Scala does and does it better. So
far I didn't find such a language (examined Haskell, Clojure, Go,
Kotlin, Ceylon, Dart, TypeScript, Rust, Julia, D and Nimrod, Ruby
Python, JavaScript and C#, some of them were very promising but since
I need a JVM language, and preferably a statically typed one, it
narrowed down the choices pretty quickly)
Java 8 is by far not even
close, sorry. Great improvement, I'm very happy for Java developers
that will get "permission" to use it (might be easier to adopt than
Scala in an enterprise) but this is not a reason for a Scala shop to
consider moving back to Java." [1]
what is exactly the built in dependency injection in scala?
It's not a discrete language feature. I think the author was referring to the fact that Scala's feature set is flexible enough to support a number of techniques that could be said to accomplish DI:
the cake pattern, building on the trait system
the Reader monad, building on higher-kinded types
DI through currying, building on functional techniques
using implicit class parameters, building on Scala's concept of implicits
in my own project, we accomplish DI by requiring function values in the class constructor explicitly
This diversity is rather emblematic of Scala. The language was designed to implement a number of very powerful concepts, mostly orthogonally, resulting in multiple valid ways to solve many problems. The challenge as a Scala programmer is to understand this breadth and then make an intelligent choice for your project. A lot of times, that choice depends on what paradigms are being used internally to implement your components.

library to convert string to operations

Is there a Java library I can use to convert conditions into actual code instead of using a lot of case statement for all the cominations?
Eg: "GT value1 LT value2" and it should return true/false based on the input values I give.
I guess you need to look at ANTLR framework.
ANTLR website
Just for the headsup:
ANTLR: Is there a simple example?
This isn't a trivial task, what you're asking for is a scripting language interpreter for Java.
You could look at OGNL or the JSR api. These both require fairly extensive knowledge of syntax; so depending on what you want to do may not fill the brief.
However, without some structured syntax you are relying wholly on the structure of the English language - you are getting into the realms of NLP.
You could just use a scripting language like Groovy if all you are looking for is a way to change behaviour at runtime.

java keywords in javascript

according to this page
http://www.quackit.com/javascript/javascript_reserved_words.cfm
javascript has some keywords which are from java, reserved. I also notice that with the highlighting in my editor. Is this to be future proof? Are they planning to implement some more OOP style operators into javascript?
I would love to se interfaces, abstract classes and things like that coming to js, but does the reservation of these words indicate anything?
From the ECMA-262 spec, §7.6.1.2 (Future Reserved Words):
And, from §2 (Conformance):
A conforming implementation of ECMAScript is permitted to support program and regular expression syntax not described in this specification. In particular, a conforming implementation of ECMAScript is permitted to support program syntax that makes use of the "future reserved words" listed in 7.6.1.2 of this specification.
The words are reserved only to offer the original author (Brendan Eich) a starting point on which to build keywords.
In addition, JavaScript was designed
with Java's syntax and standard
library in mind. In particular, all
Java keywords were reserved in
original JavaScript, JavaScript's
standard library follows Java's naming
conventions, and JavaScript's Math and
Date objects are based on classes from
Java 1.0.
"JS had to “look like Java” only less so, be Java’s dumb kid brother or boy-hostage sidekick. Plus, I had to be done in ten days or something worse than JS would have happened" — Brendan Eich
There are currently no plans to integrate specific Java features into Javascript. The current roadmap suggests these features:
Classes
A module system
Optional type annotations and static typing, probably using a structural type system
Generators and iterators
Destructuring assignment
Algebraic data types
No they don't guarantee anything, they were originally reserved "just in case" and have stuck in the language since then. They may or may not get used but most will not be used in the near future.
#Andy and #OriginalSyn already answered your question and I just wanted to answer to this:
I would love to se interfaces, abstract classes and things like that coming to js, but does the reservation of these words indicate anything?
It's very unlikely that these constructions have ever appear in JavaScript. JS follows prototype-based OOP model which doesn't use things like classes. This model has some advantages over classical, class-based model and you'll have to love it or stop using JS as there is no real alternative for this language. ;)

Java -> Python?

Besides the dynamic nature of Python (and the syntax), what are some of the major features of the Python language that Java doesn't have, and vice versa?
List comprehensions. I often find myself filtering/mapping lists, and being able to say [line.replace("spam","eggs") for line in open("somefile.txt") if line.startswith("nee")] is really nice.
Functions are first class objects. They can be passed as parameters to other functions, defined inside other function, and have lexical scope. This makes it really easy to say things like people.sort(key=lambda p: p.age) and thus sort a bunch of people on their age without having to define a custom comparator class or something equally verbose.
Everything is an object. Java has basic types which aren't objects, which is why many classes in the standard library define 9 different versions of functions (for boolean, byte, char, double, float, int, long, Object, short). Array.sort is a good example. Autoboxing helps, although it makes things awkward when something turns out to be null.
Properties. Python lets you create classes with read-only fields, lazily-generated fields, as well as fields which are checked upon assignment to make sure they're never 0 or null or whatever you want to guard against, etc.'
Default and keyword arguments. In Java if you want a constructor that can take up to 5 optional arguments, you must define 6 different versions of that constructor. And there's no way at all to say Student(name="Eli", age=25)
Functions can only return 1 thing. In Python you have tuple assignment, so you can say spam, eggs = nee() but in Java you'd need to either resort to mutable out parameters or have a custom class with 2 fields and then have two additional lines of code to extract those fields.
Built-in syntax for lists and dictionaries.
Operator Overloading.
Generally better designed libraries. For example, to parse an XML document in Java, you say
Document doc = DocumentBuilderFactory.newInstance().newDocumentBuilder().parse("test.xml");
and in Python you say
doc = parse("test.xml")
Anyway, I could go on and on with further examples, but Python is just overall a much more flexible and expressive language. It's also dynamically typed, which I really like, but which comes with some disadvantages.
Java has much better performance than Python and has way better tool support. Sometimes those things matter a lot and Java is the better language than Python for a task; I continue to use Java for some new projects despite liking Python a lot more. But as a language I think Python is superior for most things I find myself needing to accomplish.
I think this pair of articles by Philip J. Eby does a great job discussing the differences between the two languages (mostly about philosophy/mentality rather than specific language features).
Python is Not Java
Java is Not Python, either
One key difference in Python is significant whitespace. This puts a lot of people off - me too for a long time - but once you get going it seems natural and makes much more sense than ;s everywhere.
From a personal perspective, Python has the following benefits over Java:
No Checked Exceptions
Optional Arguments
Much less boilerplate and less verbose generally
Other than those, this page on the Python Wiki is a good place to look with lots of links to interesting articles.
With Jython you can have both. It's only at Python 2.2, but still very useful if you need an embedded interpreter that has access to the Java runtime.
Apart from what Eli Courtwright said:
I find iterators in Python more concise. You can use for i in something, and it works with pretty much everything. Yeah, Java has gotten better since 1.5, but for example you can iterate through a string in python with this same construct.
Introspection: In python you can get at runtime information about an object or a module about its symbols, methods, or even its docstrings. You can also instantiate them dynamically. Java has some of this, but usually in Java it takes half a page of code to get an instance of a class, whereas in Python it is about 3 lines. And as far as I know the docstrings thing is not available in Java

Categories