Is there any way to check if 2 linked lists have the same elements regardless of order.
edit question:
I have fixed the code and given some more details:
this is the method that compares 2 lists
compare: object2
^ ((mylist asBag) = ((objetc2 getList) asBag)).
the method belongs to the class myClass that has a field : myLList. myList is a linkedList of type element.
I have compiled it in the workspace:
a: = element new id:1.
b:= element new id:2.
c:=element new id:3.
d: = element new id:1.
e:= element new id:2.
f:=element new id:3.
elements1 := myClass new.
elements addFirst:a.
elements addFirst:b.
elements addFirst:c.
elements2 := myClass new.
elements addFirst:d.
elements addFirst:e.
elements addFirst:f.
Transcript show: (elements1 compare:elements2).
so I am getting false.. seems like it checks for equality by reference rather than equality by value..
So I think the correct question to ask would be: how can I compare 2 Bags by value? I have tried the '=='..but it also returned false.
EDIT:
The question changed too much - I think it deserves a new question for itself.
The whole problem here is that (element new id: 1) = (element new id: 1) is giving you false. Unless it's particular class (or superclasses) redefine it, the = message is resolved comparing by identity (==) by default. That's why your code only works with a collection being compared with itself.
Test it with, for example, lists of numbers (which have the = method redefined to reflect what humans understand by numeric equality), and it will work.
You should redefine your element's class' = (and hashCode) methods for this to work.
Smalltalk handles everything by reference: all there exist is an object, which know (reference) other objects.
It would be wrong to say that two lists are equivalent if they are in different order, as the order is part of what a list means. A list without an order is what we call a bag.
The asBag message (as all of the other as<anotherCollectionType> messages) return a new collection of the named type with all the elements of the receiver. So, #(1 2 3 2) is an Array of four elements, and #(1 2 3 2) asBag is a bag containing those four elements. As it's a Bag, it doesn't have any particular order.
When you do bagA := Bag new. you are creating a new Bag instance, and reference it with bagA variable. But then you do bagA := myList asBag, so you lose the reference to the previous bag - the first assignment doesn't do anything useful in your code, as you don't use that bag.
Saying aBool ifTrue: [^true] ifFalse: [^false] has exactly the same meaning as saying ^aBool - so we prefer just to say that. And, as you only create those two new bags to compare them, you could simplify your whole method like this:
compareTo: anotherList
^ myList asBag = anotherList asBag
Read it out loud: this object (whatever it is) compares to another list if it's list without considering order is the same than the other list without order.
The name compareTo: is kind of weird for returning a boolean (containsSameElements: would be more descriptive), but you get the point much faster with this code.
Just to be precise about your questions:
1) It doesn't work because you're comparing bag1 and bag2, but just defined bagA and bagB.
2) It's not efficient to create those two extra bags just because, and to send the senseless ifTrue: message, but other way it's OK. You may implement a better way to compare the lists, but it's way better to rely on the implementation of asBag and the Bag's = message being performant.
3) I think you could see the asBag source code, but, yes, you can assume it to be something like:
Collection>>asBag
|instance|
instance := Bag new.
instance addAll: self.
^instance
And, of course, the addAll: method could be:
Collection>>addAll: anotherCollection
anotherCollection do: [ :element | self add: element ]
So, yes - it creates a new Bag with all the receiver's elements.
mgarciaisaia's answer was good... maybe too good! This may sound harsh, but I want you to succeed if you're serious about learning, so I reiterate my suggestion from another question that you pick up a good Smalltalk fundamentals textbook immediately. Depending on indulgent do-gooders to rework your nonsensical snippets into workable code is a very inefficient way to learn to program ;)
EDIT: The question has changed dramatically. The following spoke to the original three-part question, so I paraphrased the original questions inline.
Q: What is the problem? A: The problem is lack of fundamental Smalltalk understanding.
Q: Is converting to bags an efficient way to make the comparison? A: Although it's probably not efficient, don't worry about that now. In general, and especially at the beginning when you don't have a good intuition about it, avoid premature optimization - "make it work", and then only "make it fast" if justified by real-world profiling.
Q: How does #asBag work? A: The implementation of #asBag is available in the same living world as your own code. The best way to learn is to view the implementation directly (perhaps by "browsing implementors" if you aren't sure where it's defined") and answer your own question!! If you can't understand that implementation, see #1.
I want to make a scientific calculator in which the user enters something like 3+4*(3-5)/23 and then the calculator can return the value.
Now I'm trying to find a way to parse a string of mathematical expression. I know that there are some built parsers and algorithms but I want to know whether it's possible by using #define method.
Basically, I want to use the #define to literally remove the # and " " in a string and make it look like an expression that can be evaluated. At this stage, I won't use unknown variables like x or 3*k or a*b/c. All will be numbers and operators like 3+4 and 32 that can be directly evaluated by the compiler. Here is what I want to write in #define:
#define eval#"(x)" x
In the above code, eval is just a signal of parsing and the #"x" is the actual string that need to parse and x is a mathematical expression. After the translation, only x will remain. For example, if I write
double result = eval#"(3+4)";
the compiler will read
double result = 3+4;
(according to my understanding of #define). However, the code does not work. I suspect that the quotation marks confuse the compiler and cause the code to break. So my question is: can anyone come up with a solution using #define?
This is not possible with the preprocessor, no string manipulation besides concatenation supported.
Why would you need the #"x" syntax anyways? You can just put the expression right there in the code.
People are right, you cannot do it in direct way, however if you very want macro:
#define eval(x) [[[NSExpression expressionWithFormat:x] expressionValueWithObject:nil context:nil] doubleValue]
double result = eval(#"3+4");
#define is an invocation of the C preprocessor, which is not capable of this kind of manipulation. It almost sounds like you're trying to define an Objective-C macro that would do the same kind of thing as a LISP macro, but that's not possible. Why don't you tell us what the original problem is that you're trying to solve... I think we can probably come up with an easier way to do what you're trying to do.
Task:
I am planning to parse a formula string in NSPredicate and to replace variables in the string by their numeric values. The variables are names for properties of existing object instances in my data model, for instance I have a class "company" with an instance "Apple Corp."
Set-up:
My formula would like look like this: "Profitability_2011_in% = [Profit 2011] / [Revenue 2011]"
The instance "Apple Corp" would have the following properties:
Revenue 2009 = 10, Revenue 2010 = 20, Revenue 2011 = 30,
Profit 2009 = 5, Profit 2010 = 10, Profit 2011 = 20.
Hence, the formula would yield 20 / 30 = 67%.
Variables are usually two-dimensional, for instance defined by "profit" as the financial statement item and "year" (for instance 2011).
The variables are enclosed in [ ] and the dimensions are separated by " " (whitespace).
How I would do it
My implementation would begin with NSRegularExpression's matchesInString:options:range: to get an array of all variables in the formula (Profit 2011, Revenue 2011) and then construct an NSDictionary (key = variable name) out of this array by querying my data model.
What do you think?
Is there a better way to do it in your view?
In the formula, how would you replace the variables by their values?
How would you parse the formula?
Thank you!!
Yes, you can do this. This falls under the category of "Using NSPredicate for things for which it was not intended", but will work just fine.
You'll need to replace your variables with a single word that start with a $, since that's how NSPredicate denotes variables:
NSPredicate *p = [NSPredicate predicateWithFormat:#"foo = $bar"];
However you want to do that, great. NSRegularExpression is a fine way to do that.
Once you do that, you'll have something like this:
#"$profitability2011 = $profit2011 / $revenue2011"
You can then pop this through +predicateWithFormat:. You'll get back an NSComparisonPredicate. The -leftExpression will be of type NSVariableExpressionType, and the -rightExpression will be of type NSFunctionExpressionType.
This is where things start to get hairy. If you were to -evaluteWithObject:substitutionVariables:, you'd simply get back a YES or NO value, since a predicate is simply a statement that evaluates to true or false. I haven't explored how you could just evaluate one side (in this case, the -rightExpression), but it's possible that -[NSExpression expressionValueWithObject:context:] might help you. I don't know, because I'm not sure what that "context" parameter is for. It doesn't seem like it's a substitution dictionary, but I could be wrong.
So if that doesn't work (and I have no idea if it will or not), you could use my parser: DDMathParser. It has a parser, similar to NSPredicate's parser, but is specifically tuned for parsing and evaluating mathematical expressions. In your case, you'd do:
#import "DDMathParser.h"
NSString *s = #"$profit2011 / $revenue2011";
NSDictionary *values = ...; // the values of the variables
NSNumber *profitability = [s numberByEvaluatingStringWithSubstitutions:values];
The documentation for DDMathParser is quite extensive, and it can do quite a bit.
edit Dynamic variable resolution
I just pushed a change that allows DDMathParser to resolve functions dynamically. It's important to understand that a function is different from a variable. A function is evaluated, whereas a variable is simply substituted. However, the change only does dynamic resolution for functions, not variables. That's ok, because DDMathParser has this neat thing called argumentless functions.
An argumentless function is a function name that's not followed by an opening parenthesis. For convenience, it's inserted for you. This means that #"pi" is correctly parsed as #"pi()" (since the constant for π is implemented as a function).
In your case, you can do this:
Instead of regexing your string to make variables, simply use the names of the terms:
#"profit_2011 / revenue_2011";
This will be parsed as if you had entered:
#"divide(profit_2011(), revenue_2011())"
You can the set up your DDMathEvaluator object with a function resolver. There are two examples of this in the DDMathParser repository:
This example shows how to use the resolver function to look up the "missing" function in a substitution dictionary (this would be most like what you want)
This example shows you to interpret any missing function as if it evaluated to 42.
Once you implement a resolver function, you can forego having to package all your variables up into a dictionary.
Is there a better way to do it in your view?
Yes - using Flex & Bison.
Possibly you could achieve what you want with a regex - but for many expression grammars, a regex isn't powerful enough to parse the grammar. Also, regex things like this get large, unreadable, and unyieldy.
You can use Flex (a lexer) and Bison (a parser) to create a grammar definition for your expressions, and generate C code (which, as I'm sure you know, works perfectly with Objective-C since Objective-C is C) which you can use to parse your expressions.
In the formula, how would you replace the variables by their values?
As you parse through it with Bison you should have a hash table with variable names and their current values. When you generate the syntax tree, add references to the variables to your syntax tree nodes.
How would you parse the formula?
Again - Flex & Bison are specifically meant to do this kind of thing - and they excel at it.
I'm doing something really dumb, and I don't see it.
I've got an object doc with a method:
-(float) currentOrient
{
return 50.5;
}
In another object, I call:
-(void) showPage
{
float rot2=0;
rot2 = [doc currentOrient] ;
NSLog(#"SP rotation is %.2f", rot2);
}
However, the output is :
SP rotation is 1112145920.000000
No, one question is "Why is the %2f not formatting correctly?" But the more confusing question is "Where is that number coming from?" Yes, I've walked through it with a debugger, the value of rot DOES change from the garbage it starts with. and that number DOES appear to be consistent.
Clearly something really dumb is going on...
It sounds like the showPage method doesn't know right return type for currentOrient, so it's interpreting the value returned as an int and casting that nonsensical int to a float. Are you getting any warnings? Are you sure you're importing the header for currentOrient correctly? Is the currentOrient method declared correctly?
I can answer the first question:
Why is the %2f not formatting correctly?
Because it ought to be %1.2f to round to two decimal places (which I believe is what you're trying to achieve?)
And guess at the second:
Do you have a property named rot in the code? Other than that... shrug... I don't know - I'm assuming you've simplified the example to post on SO, have you taken out other code that may be relevant? Based on the information you've provided everything should be ducky.
On a side note: When I hit bugs like this I go do something physical. Usually when I come back my head is clear and I find the problem immediately. You might want to give that a try too! :D
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
This question is to seek out good examples of Hungarian Notation, so we can bring together a collection of these.
Edit: I agree that Hungarian for types isn't that necessary, I'm hoping for more specific examples where it increases readability and maintainability, like Joel gives in his article (as per my answer).
The problem with asking for good examples of Hungarian Notation is that everyone's going to have their own idea of what a good example looks like. My personal opinion is that the best Hungarian Notation is no Hungarian Notation. The notation was originally meant to denote the intended usage of a variable rather than its type but it's usually used for type information, particularly for Form controls (e.g., txtFirstName for a text box for someone's first name.). This makes the code less maintainable, in terms of readability (e.g., "prepIn nounTerms prepOf nounReadability") and refactoring for when the type needs to be changed (there are "lParams" in the Win32 API that have changed type).
You should probably consider not using it at all. Examples:
strFirstName - this can just be firstName since it's obvious what it's for, the type isn't that important and should be obvious in this case. If not obvious, the IDE can help you with that.
txtFirstName - this can change to FirstNameTextBox or FirstName_TextBox. It reads better and you know it's a control and not just the text.
CAccount - C was used for class names in MFC but you really don't need it. Account is good enough. The uppercase name is the standard convention for types (and they only appear in specific places so they won't get confused with properties or methods)
ixArray (index to array) - ix is a bit obscure. Try arrayIndex.
usState (unsafe string for State) - looks like "U.S. State". Better go with state_UnsafeString or something. Maybe even wrap it in an UnsafeString class to at least make it type-safe.
The now classic article, as mentioned in other Hungarian posts, is the one from Joel's site:
http://www.joelonsoftware.com/articles/Wrong.html
p
(for pointer). Its pretty much the only prefix I use. I think it adds a lot to a variable (eg that its a pointer) and so should be treated a little more respectfully.
Hungarian for datatypes is somewhat passe now IDEs can tell you what the type is (in only a few seconds hovering over the variable name), so its not so important. But treating a pointer as if its data is not good, so you want to make sure it's obvious to the user what it is even if he makes assumptions he shouldn't when coding.
t
Tainted data. Prefix all data incoming from an untrusted source to make that variable as tainted. All tainted data should be cleansed before any real work is done on it.
It's pointless to use Hungarian to indicate types because the compiler already does it for you.
Where Hungarian is useful is to distinguish between logically different sorts of variables that have the same raw type. For example, if you are using ints to represent coordinates, you could prefix x coordinates with x, y coordinates with y and distances with d. So you would have code that looks like
dxHighlight = xStart - xEnd
yHighlight = yLocation + 3
yEnd = yStart + dyHeight
dyCode = dyField * 2
and so on. It's useful because you can spot errors at a glance: If you add a dy to a y, you always get a y. If you subtract two x's you always get a dx. If you multiply a dy by a scalar, you always get a dy. And so on. If you see a line like
yTop = dyText + xButton
you know at a glance that it is wrong because adding a dy and a x does not make sense. The compiler could not catch this for you because as far as it can tell, you are adding an int to an int which is fine.
Do not use language specific prefixes.
We use:
n: Number
p: Percentage 1=100% (for interest rates etc)
c: Currency
s: String
d: date
e: enumeration
o: object (Customer oCustomer=new Customer();)
...
We use the same system for all languages:
SQL
C
C#
Javascript
VB6
VB.net
...
It is a life saver.
Devil's Advocate: The best example of Hungarian notation is not to use it. :D
We do not gain any advantage to using Hungarian notation with modern IDEs because they know the type. It adds work when refactoring a type for a variable since the name would also have to be changed (and most of the time when you are dealing with a variable you know what type it is anyway).
You can also get into ordering issues with the notation. If you use p for pointer and a for address do you call your variable apStreet or paStreet? Readability is diminished when you don't have consistency, and you have to use up valuable mind space when you have to remember the order that you have to write the notation in.
I find hungarian notation can sometimes be useful in dynamic languages. I'm specifically thinking of Server Side Actionscript (essentially just javascript), but it could apply elsewhere. Since there's no real type information at all, hungarian notation can sometimes help make things a bit easier to understand.
Hungarian notation (camel casing, as I learned it) is invaluable when you're inheriting a software project.
Yes, you can 'hover' over a variable with your IDE and find out what class it is, but if you're paging through several thousand lines of code you don't want to have to stop for those few seconds - every.... single.... time....
Remember - you're not writing code for you or your team alone. You're also writing it for the person who has to pick up this code 2-5 years down the road and enhance it.
I was strongly against Hungarian notation until I really started reading about it and trying to understand it's original intent.
After reading Joels post "Wrong" and the article "Rediscovering Hungarian Notation" I really changed my mind. Done correct I belive it must be extremly powerful.
Wrong by Joel Spolsky
http://www.joelonsoftware.com/articles/Wrong.html
Rediscovering Hungarian Notation
http://codingthriller.blogspot.com/2007/11/rediscovering-hungarian-notation.html
I belive that most Naysayers have never tried it for real and do not truly understand it.
I would love to try it out in a real project.
I think the key thing to take away from Joel's article, linked above, and Hungarian Notation in general, is to use it when there's something non-obvious about the variable.
One example, from the article, is encoded vs non encoded strings, it's not that you should use hungarian 'us' for unsafe strings and 's' for safe strings, it's that you should have some identifier to indicate that a string is either safe or not. If it becomes standard, it becomes easy to see when the standard is being broken.
The only Hungarian that's really useful anymore is m_ for member variables. (I also use sm_ for static members, because that's the "other" scope that still exists.) With widescreen monitors and compilers that take eight-billion-character-long variable names, abbreviating type names just isn't worth it.
m
When using an ORM (such as hibernate) you tend to deal managed and unmanaged objects. Changing an managed object will be reflected in the database without calling an explicit save, while dealing with a managaged object requires an explicit save call. How you deal with the object will be different depending on which it is.
I find that the only helpful point is when declaring interface controls, txtUsername, txtPassword, ddlBirthMonth. It isn't perfect, but it helps on large forms/projects.
I don't use it for variables or other items, just controls.
In addition to using 'p' for pointer, I like the idea of using 'cb' and 'cch' to indicate whether a buffer size parameter (or variable) is a count of bytes or a character count (I've also seen - rarely - 'ce' used to indicate a count of elements). So instead of conveying type, the prefix conveys use or intent.
I admit, I don't use the prefix as consistently as I probably should, but I like the idea.
A very old question, but here's a couple of "Hungarian" prefixes I use regularly:
my
for local variables, to distinguish locality where the name might make sense in a global context. If you see myFoo, it's only used in this function, regardless of anything else we do with Foos anywhere else.
myStart = GetTime();
doComplicatedOperations();
print (GetTime() - myStart);
and
tmp
for temporary copies of values in loops or multi-step operations. If you see two tmpFoo variables more than a couple of lines from each other, they're almost certainly unrelated.
tmpX = X;
tmpY = Y;
X = someCalc(tmpX, tmpY);
Y = otherCalc(tmpX, tmpY);
and sometimes old and new in for similar reasons to tmp, usually in longer loops or functions.
Well, I use it only with window control variables. I use btn_, txt_, lbl_ etc to spot them. I also find it helpful to look up the control's name by typing its type (btn_ etc).
I only ever use p for a pointer, and that's it. And that's only if I'm in C++. In C# I don't use any hungarian notation.
e.g.
MyClass myClass;
MyClass* pMyClass;
That's all :)
Edit: Oh, I just realised that's a lie. I use "m_" for member variables too. e.g.
class
{
private:
bool m_myVar;
}
I agree that Hungarian notation is no longer particularly useful. I thought that its original intention was to indicate not datatype, but rather entity type. In a code section involving the names of customers, employees and the user, for example, you could name local string variables cusName, empName and usrName. That would help distinguish among similar-sounding variable names. The same prefixes for the entities would be used throughout the application. However, when OO is used, and you're dealing with objects, those prefixes are redundant in Customer.Name, Employee.Name and User.Name.
The name of the variable should describe what it is. Good variable naming makes Hungarian notation useless.
However, sometimes you'd use Hungarian notation in addition to good variable naming. m_numObjects has two "prefixes:" m_ and num. m_ indicates the scope: it's a data member tied to this. num indicates what the value is.
I don't feel hindered at all when I read "good" code, even if it does contain some "Hungarian." Right: I read code, I don't click it. (In fact, I hardly use my mouse ever when coding, or any voodoo programming-specific lookup features.)
I am slowed when I read things like m_ubScale (yes, I'm looking at you, Liran!), as I have to look at its usage (no comments!) to find out what it scales (if at all?) and it's datatype (which happens to be a fixed-point char). A better name would be m_scaleFactor or m_zoomFactor, with a comment as a fixed-point number, or even a typedef. (In fact, a typedef would be useful, as there are several other members of several classes which use the same fixed-point format. However, some don't, but are still labeled m_ubWhatever! Confusing, to say the least.)
I think Hungarian was meant to be an additive to the variable name, not a replacement for information. Also, many times Hungarian notation adds nothing at all to the variable's readability, wasting bytes and read time.
Just my 2¢.
There's no such thing as a good example of hungarian notation. Just don't use it. Not even if you are using a weakly typed language. You'll live happier.
But if you really need some reason not to use it, this is my favourite one, extracted from this great link:
One followon trick in the Hungarian notation is "change the type of a variable but leave the variable name unchanged". This is almost invariably done in windows apps with the migration from Win16 :- WndProc(HWND hW, WORD wMsg, WORD wParam, LONG lParam) to Win32 WndProc(HWND hW, UINT wMsg, WPARAM wParam, LPARAM lParam) where the w values hint that they are words, but they really refer to longs. The real value of this approach comes clear with the Win64 migration, when the parameters will be 64 bits wide, but the old "w" and "l" prefixes will remain forever.
I find myself using 'w' meaning 'working', as a prefix instead of 'temp' or 'tmp', for local variables that are just there to jockey data around, like:
Public Function ArrayFromDJRange(rangename As Range, slots As Integer) As Variant
' this function copies a Disjoint Range of specified size into a Variant Array 7/8/09 ljr
Dim j As Integer
Dim wArray As Variant
Dim rCell As Range
wArray = rangename.Value ' to initialize the working Array
ReDim wArray(0, slots - 1) ' set to size of range
j = 0
For Each rCell In rangename
wArray(0, j) = rCell.Value
j = j + 1
Next rCell
ArrayFromDJRange = wArray
End Function