How can I restrict the input of a TextFieldsuch that it can only contain mathematical expressions?
Accepted inputs would be:
"3+5"
"-5 + 6"
"3/2(6*4)"
"6--5"
"+5-3"
etc..
And rejected inputs would be:
"5+++3"
"6(7)"
"6-6-+-7"
and so on.
Basically; the syntax I want it to be restricted to is the kind of syntax that programming languages normally use for evaluating mathematical expressions, kinda like the syntax input you'd expect from your everyday calculator.
I'm making a program in which I want the user to be able to input numbers and/or calculations into a text box, instead of having to use a calculator to do it and then arduously type out a number with 7 decimal places.
I've done a little look around and I've seen a lot of stuff involving Regex, postfix, BNF, and the like. A lot of it looked very complicated, too complex for my understanding, and none of it had anything to do with AS3.
However, I've had a thought about making this problem a whole lot simpler by just converting the string into a mathematical expression that AS3 can understand, and let Flash handle the errors using try catch, but I don't know how to do that either (Number("3+5")resulted to NaN).
I'm currently restricting text input to just numbers using Event.CHANGE, like this:
function Restrict(event:Event):void
{
if (event.currentTarget.text.indexOf(".") == -1)
{
event.currentTarget.restrict = "0-9.";
}
else
{
event.currentTarget.restrict = "0-9";
}
}
and it's seemed to work well so far.
I intend to implement this new restriction in this manner, but if there is a much more efficient way of restricting text input, please feel free to include it in a response.
Just to reiterate for clarity, I am asking how to implement functionality that will enable someone to input a mathematical expression into a TextField, and the program will register that input as an expression and calculate it.
Thanks for reading.
EDIT: I've done a bit more research and I've stumbled upon a Reverse Polish Notation calculator/parser/utility class/library/thingy that looks very useful. Seems kinda similar to the Executer class that fsbmain mentioned, but it looks a lot simpler to use and easier for me to understand.
However the problem still remains that I'd have to find an efficient way to restrict the syntax of user input to mathematical expressions, but at least now I have at least two ways of converting the string into a number for calculations.
That's quite a tough question actually, even definition for valid mathematical expressions which you mentioned is very complicated itself, i.e. expression 6-6-+-7 is a valid from as3 syntax point of view and gives result 7.
Regarding second part of your question:
converting the string into a mathematical expression that AS3 can understand
That's not possible to do with only native as3 means since eval-like functions are gone since as2 time, but you can try to use some as3-written syntax translator, i.e. Executer from flash-console project:
var exec:Executer = new Executer();
var res:* = exec.exec(this, "6-7");
trace("exec = " + res); //output "-1"
Although it's failed with some complex expressions from your question:
var exec:Executer = new Executer();
var res:* = exec.exec(this, "6-6-+-7");
trace("exec = " + res); //output "- 7"
Related
Let X be a square matrix. We want to force it to be Hermitian, that is: self-conjugate-transpose. X = X^H = conj(X^T). To do this in Python with numpy is easy:
X = 0.5*(X + np.conj(X.T))
I haven't found in NumPy a single function that does it in a single experssion f(x).
The question is should I define a new function to do it? E.g.
def make_hermitian(X):
return 0.5*(X + np.conj(X.T))
(one can come up with short name, e.g. "make_h" or "herm" or "selfconj").
Pros: more readable code, one operation in shorter form. If one uses shorter name it saves writing when repeated many times, and makes modification in this operation far more easy and comfortable (need to change only in place).
Cons: replaces a very short and straight-forward expression which is self-evident.
What is more appropriate way of programming: define a new function or just write the explicit expression repeatedly?
I would say it depends on how many times you need to reuse that function.
If it's more than twice, then definitely make a function. If it's only once or twice, I would say it's up to you. If you choose to go with no function, add a short comment specifying what such piece of code is supposed to do.
My preference in any case would be defining a function with a meaningful name, because if anyone else is going to / supposed to read the code, they may not know or remember how to achieve a Hermitian matrix, and hence the math alone ain't going to be sufficient.
On the other hand, a meaningful function name will tell them clearly what it's going on, and they can google after what a Hermitian matrix is.
I faced difficulties to replace a string.
var expression:String = '2X3';
var inString:String = expression;
inString=inString.replace("รท","/");
inString=inString.replace("X","*");
trace('Result.....',inString);
Output:-
Result.....2*3
Its alright.
But the problem was when i tried to give input as
var expression:String = '2X3X3X4X5X6';
output:-
Result.....2*3X3X4X5X6
But i need it in form of
Result.....2*3*3*4*5*6
and same for division.
Thanks & Regards
I use this for replacing all
var result:String=inString.split("X").join("*");
I know you've already selected a answer, but it lacked an explanation and a proper solution. The reason you see this happening is that String.replace(), when the pattern is a String, only replaces the first result. The solution is to use RegEx:
var expression:String = '2x3X3x4X5X6';
var result:String = expression.replace(/x/ig, "*");
trace(result); // output 2*3*3*4*5*6
The pattern uses two flags, global and case-insensitivity. That will grab all instances of the letter X, regardless of case, and search the entire string. The benefit with RegEx is that is extremely low level. There is little-to-no overhead when using a regular expression meaning they are incredibly fast. String.split and String.join use loops to function, I believe, which are considerably slower. Additionally, you have to store an additional array in memory.
Granted, these are negligible in most cases (difference in the 10's of microseconds, maybe), but not all. I had a project the required files to be scrambled. Unfortunately, the files were too large (200MB minimum) and the doing the replace().join() method was 4-5 slower than the RegEx method. With RegEx, I managed to reduce the lag while scrambling from a few seconds to 2-3 frames.
did you try inString=inString.replaceAll("X","*");? notice the "All" suffix!
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Specific functions vs many Arguments vs context dependent
So I've been developing for 3-4 years now, know a wide range of languages, know some impressive (to the small minded :P ) stuff.
But something I've always wondered; when I make a function should it be for a specific purpose, or should it be moulded to be re-usable, even if I have no need for it to be?
E.G:
//JS, but could be any language really
//specific
function HAL(){
alert("I'm afraid I can't let you do that, " + document.getElementById("Name").value + ".");
}
//generic
function HAL(nme){
alert("I'm afraid I can't let you do that, " + nme + ".");
}
//more generic
function HAL(msg, nme){
alert(msg + " " + nme + ".");
}
Yes, very simple example, but conveys the point I want to make. If we take this example, would I ever use it outside of the first? Probably not, so I'd be tempted to make it this way, but then common sense would (now) convince me to make it the second, yet I can't see any benefit of this way, if I know it's not going to be used in any other way, i.e. It's always going to use the input's value (Yes I would put that into a global variable normally).
Is it just a case of whatever I feel makes the most sense at the time, or should I follow the 2nd pattern as best I can?
In that particular case, I would write the first function for now (YAGNI, right?), and probably never need to change it. Then, if it turned out I did need to support alternate names, I'd make the current behavior the default, but allow an optional parameter to specify a name. Likewise with the message.
# In Ruby, but like you say, could be in anything:
// specific
def hal()
puts "I'm afraid I can't let you do that, #{fetch_name}."
end
// genericized refactoring
def hal( name = fetch_name )
puts "I'm afraid I can't let you do that, #{name}."
end
Typically, that's the approach I prefer to take: create functions at whatever is the most convenient degree of specificity for my current needs, but leave the door open for a more generalized approach later.
It helps that I use languages like Ruby that make this easy, but you can take the same approach to some extent even in Java or C. For example, in Java you might make a specific method with no parameters first, and then later refactor to a more generalized method with a "name" parameter and a no-parameter wrapper that filled in the default name.
A rule of thumb is that a function should have minimal side effects.
So, really, it would look something like this:
//By the way - don't call functions nouns. functions are verbs. data are nouns
void HAL(string s)
{
voicetype_t vt = voice.type();
voice.type(VOICE_OF_DOOM);
voice.say(s);
voice.type(vt);
}
A function shouldn't be just a series of statements to call them in some other context. It should be a unit of functionality that you want to abstract. Making a function to be specific is good, but making it context sensitive is bad. What you should do, is to use the generic way(last one) presented in your post, but provide the messages as constants. The language you use has some way to declare constants right?
In your example, I wouldn't make it generic. If a functionality can be used in many cases, make it generic so you can use it all the time without "copy, paste, make minor change, repeat". But telling the user he can't do that and adressing it as [contents of certain input field] is useful for only one case. Plus, the last shot is pointless.
However, I generally prefer my code to be as generic as feasible. Well, as long as the odds are I will need it one day... let's not violate YANGI too hard. But if it can be generic without hassle, why not?
In my opinion, functions should be genericized only to the extent that their purposes need to be. In other words, you should concede to the fact that, although we want to think differently, not everything is reusable, and thus, you shouldn't go out of your way to implement everything to be like that. Programmers should be conscious of the scope (and possibly the future development) of the product, so ultimately one should use their intuition as to how far to take generalizations of functions.
As for your examples, #3 is completely worthless as it only affixes a space between two strings and appends a period at the end--why would someone do this with a special function? I know that's only an example, but if we're talking about how far to generalize a method, something like that's taking it too far--almost to the point where it's just wasted LOC, and that is never something to sacrifice for the sake of generalizing.
I do not understand why Java's [String.substring() method](http://java.sun.com/j2se/1.5.0/docs/api/java/lang/String.html#substring(int,%20int%29) is specified the way it is. I can't tell it to start at a numbered-position and return a specified number of characters; I have to compute the end position myself. And if I specify an end position beyond the end of the String, instead of just returning the rest of the String for me, Java throws an Exception.
I'm used to languages where substring() (or substr()) takes two parameters: a start position, and a length. Is this objectively better than the way Java does it, and if so, can you prove it? What's the best language specification for substring() that you have seen, and when if ever would it be a good idea for a language to do things differently? Is that IndexOutOfBoundsException that Java throws a good design idea, or not? Does all this just come down to personal preference?
There are times when the second parameter being a length is more convenient, and there are times when the second parameter being the "offset to stop before" is more convenient. Likewise there are times when "if I give you something that's too big, just go to the end of the string" is convenient, and there are times when it indicates a bug and should really throw an exception.
The second parameter being a length is useful if you've got a fixed length of field. For instance:
// C#
String guid = fullString.Substring(offset, 36);
The second parameter being an offset is useful if you're going up to another delimited:
// Java
int nextColon = fullString.indexOf(':', start);
if (start == -1)
{
// Handle error
}
else
{
String value = fullString.substring(start, nextColon);
}
Typically, the one you want to use is the opposite to the one that's provided on your current platform, in my experience :)
I'm used to languages where
substring() (or substr()) takes two
parameters: a start position, and a
length. Is this objectively better
than the way Java does it, and if so,
can you prove it?
No, it's not objectively better. It all depends on the context in which you want to use it. If you want to extract a substring of a specific length, it's bad, but if you want to extract a substring that ends at, say, the first occurrence of "." in the string, it's better than if you first had to compute a length. The question is: which requirement is more common? I'd say the latter. Of course, the best solution would be to have both versions in the API, but if you need the length-based one all the time, using a static utility method isn't that horrible.
As for the exception, yeah, that's definitely good design. You asked for something specific, and when you can't get that specific thing, the API should not try to guess what you might have wanted instead - that way, bugs become apparent more quickly.
Also, Java DOES have an alternative substring() method that returns the substring from a start index until the end of the string.
second parameter should be optional, first parameter should accept negative values..
If you leave off the 2nd parameter it will go to the end of the string for you without you having to compute it.
Having gotten some feedback, I see when the second-parameter-as-index scenario is useful, but so far all of those scenarios seem to be working around other language/API limitations. For example, the API doesn't provide a convenient routine to give me the Strings before and after the first colon in the input String, so instead I get that String's index and call substring(). (And this explains why the second position parameter in substr() overshoots the desired index by 1, IMO.)
It seems to me that with a more comprehensive set of string-processing functions in the language's toolkit, the second-parameter-as-index scenario loses out to second-parameter-as-length. But somebody please post me a counterexample. :)
If you store this away, the problem should stop plaguing your dreams and you'll finally achieve a good night's rest:
public String skipsSubstring(String s, int index, int length) {
return s.subString(index, index+length);
}
Similar to Is hard-coding literals ever acceptable?, but I'm specifically thinking of "magic strings" here.
On a large project, we have a table of configuration options like these:
Name Value
---- -----
FOO_ENABLED Y
BAR_ENABLED N
...
(Hundreds of them).
The common practice is to call a generic function to test an option like this:
if (config_options.value('FOO_ENABLED') == 'Y') ...
(Of course, this same option may need to be checked in many places in the system code.)
When adding a new option, I was considering adding a function to hide the "magic string" like this:
if (config_options.foo_enabled()) ...
However, colleagues thought I'd gone overboard and objected to doing this, preferring the hard-coding because:
That's what we normally do
It makes it easier to see what's going on when debugging the code
The trouble is, I can see their point! Realistically, we are never going to rename the options for any reason, so about the only advantage I can think of for my function is that the compiler would catch any typo like fo_enabled(), but not 'FO_ENABLED'.
What do you think? Have I missed any other advantages/disadvantages?
If I use a string once in the code, I don't generally worry about making it a constant somewhere.
If I use a string twice in the code, I'll consider making it a constant.
If I use a string three times in the code, I'll almost certainly make it a constant.
if (config_options.isTrue('FOO_ENABLED')) {...
}
Restrict your hard coded Y check to one place, even if it means writing a wrapper class for your Map.
if (config_options.isFooEnabled()) {...
}
Might seem okay until you have 100 configuration options and 100 methods (so here you can make a judgement about future application growth and needs before deciding on your implementation). Otherwise it is better to have a class of static strings for parameter names.
if (config_options.isTrue(ConfigKeys.FOO_ENABLED)) {...
}
I realise the question is old, but it came up on my margin.
AFAIC, the issue here has not been identified accurately, either in the question, or the answers. Forget about 'harcoding strings" or not, for a moment.
The database has a Reference table, containing config_options. The PK is a string.
There are two types of PKs:
Meaningful Identifiers, that the users (and developers) see and use. These PKs are supposed to be stable, they can be relied upon.
Meaningless Id columns which the users should never see, that the developers have to be aware of, and code around. These cannot be relied upon.
It is ordinary, normal, to write code using the absolute value of a meaningful PK IF CustomerCode = "IBM" ... or IF CountryCode = "AUS" etc.
referencing the absolute value of a meaningless PK is not acceptable (due to auto-increment; gaps being changed; values being replaced wholesale).
.
Your reference table uses meaningful PKs. Referencing those literal strings in code is unavoidable. Hiding the value will make maintenance more difficult; the code is no longer literal; your colleagues are right. Plus there is the additional redundant function that chews cycles. If there is a typo in the literal, you will soon find that out during Dev testing, long before UAT.
hundreds of functions for hundreds of literals is absurd. If you do implement a function, then Normalise your code, and provide a single function that can be used for any of the hundreds of literals. In which case, we are back to a naked literal, and the function can be dispensed with.
the point is, the attempt to hide the literal has no value.
.
It cannot be construed as "hardcoding", that is something quite different. I think that is where your issue is, identifying these constructs as "hardcoded". It is just referencing a Meaningfull PK literally.
Now from the perspective of any code segment only, if you use the same value a few times, you can improve the code by capturing the literal string in a variable, and then using the variable in the rest of the code block. Certainly not a function. But that is an efficiency and good practice issue. Even that does not change the effect IF CountryCode = #cc_aus
I really should use constants and no hard coded literals.
You can say they won't be changed, but you may never know. And it is best to make it a habit. To use symbolic constants.
In my experience, this kind of issue is masking a deeper problem: failure to do actual OOP and to follow the DRY principle.
In a nutshell, capture the decision at startup time by an appropriate definition for each action inside the if statements, and then throw away both the config_options and the run-time tests.
Details below.
The sample usage was:
if (config_options.value('FOO_ENABLED') == 'Y') ...
which raises the obvious question, "What's going on in the ellipsis?", especially given the following statement:
(Of course, this same option may need to be checked in many places in the system code.)
Let's assume that each of these config_option values really does correspond to a single problem domain (or implementation strategy) concept.
Instead of doing this (repeatedly, in various places throughout the code):
Take a string (tag),
Find its corresponding other string (value),
Test that value as a boolean-equivalent,
Based on that test, decide whether to perform some action.
I suggest encapsulating the concept of a "configurable action".
Let's take as an example (obviously just as hypthetical as FOO_ENABLED ... ;-) that your code has to work in either English units or metric units. If METRIC_ENABLED is "true", convert user-entered data from metric to English for internal computation, and convert back prior to displaying results.
Define an interface:
public interface MetricConverter {
double toInches(double length);
double toCentimeters(double length);
double toPounds(double weight);
double toKilograms(double weight);
}
which identifies in one place all the behavior associated with the concept of METRIC_ENABLED.
Then write concrete implementations of all the ways those behaviors are to be carried out:
public class NullConv implements MetricConverter {
double toInches(double length) {return length;}
double toCentimeters(double length) {return length;}
double toPounds(double weight) {return weight;}
double toKilograms(double weight) {return weight;}
}
and
// lame implementation, just for illustration!!!!
public class MetricConv implements MetricConverter {
public static final double LBS_PER_KG = 2.2D;
public static final double CM_PER_IN = 2.54D
double toInches(double length) {return length * CM_PER_IN;}
double toCentimeters(double length) {return length / CM_PER_IN;}
double toPounds(double weight) {return weight * LBS_PER_KG;}
double toKilograms(double weight) {return weight / LBS_PER_KG;}
}
At startup time, instead of loading a bunch of config_options values, initialize a set of configurable actions, as in:
MetricConverter converter = (metricOption()) ? new MetricConv() : new NullConv();
(where the expression metricOption() above is a stand-in for whatever one-time-only check you need to make, including looking at the value of METRIC_ENABLED ;-)
Then, wherever the code would have said:
double length = getLengthFromGui();
if (config_options.value('METRIC_ENABLED') == 'Y') {
length = length / 2.54D;
}
// do some computation to produce result
// ...
if (config_options.value('METRIC_ENABLED') == 'Y') {
result = result * 2.54D;
}
displayResultingLengthOnGui(result);
rewrite it as:
double length = converter.toInches(getLengthFromGui());
// do some computation to produce result
// ...
displayResultingLengthOnGui(converter.toCentimeters(result));
Because all of the implementation details related to that one concept are now packaged cleanly, all future maintenance related to METRIC_ENABLED can be done in one place. In addition, the run-time trade-off is a win; the "overhead" of invoking a method is trivial compared with the overhead of fetching a String value from a Map and performing String#equals.
I believe that the two reasons you have mentioned, Possible misspelling in string, that cannot be detected until run time and the possibility (although slim) of a name change would justify your idea.
On top of that you can get typed functions, now it seems you only store booleans, what if you need to store an int, a string etc. I would rather use get_foo() with a type, than get_string("FOO") or get_int("FOO").
I think there are two different issues here:
In the current project, the convention of using hard-coded strings is already well established, so all the developers working on the project are familiar with it. It might be a sub-optimal convention for all the reasons that have been listed, but everybody familiar with the code can look at it and instinctively knows what the code is supposed to do. Changing the code so that in certain parts, it uses the "new" functionality will make the code slightly harder to read (because people will have to think and remember what the new convention does) and thus a little harder to maintain. But I would guess that changing over the whole project to the new convention would potentially be prohibitively expensive unless you can quickly script the conversion.
On a new project, symbolic constants are the way IMO, for all the reasons listed. Especially because anything that makes the compiler catch errors at compile time that would otherwise be caught by a human at run time is a very useful convention to establish.
Another thing to consider is intent. If you are on a project that requires localization hard coded strings can be ambiguous. Consider the following:
const string HELLO_WORLD = "Hello world!";
print(HELLO_WORLD);
The programmer's intent is clear. Using a constant implies that this string does not need to be localized. Now look at this example:
print("Hello world!");
Here we aren't so sure. Did the programmer really not want this string to be localized or did the programmer forget about localization while he was writing this code?
I too prefer a strongly-typed configuration class if it is used through-out the code. With properly named methods you don't lose any readability. If you need to do conversions from strings to another data type (decimal/float/int), you don't need to repeat the code that does the conversion in multiple places and can cache the result so the conversion only takes place once. You've already got the basis of this in place already so I don't think it would take much to get used to the new way of doing things.