Re: NSExpression is incorrect?
Thanks for this suggestion, Ben. I ultimately went with a combination of this suggestion (dynamically determining associativity) and Ronald's suggestion (allowing the user to choose). My parser will start with the associativity used by NSExpression, but provides a property to change it. Thanks! Dave On Nov 21, 2010, at 3:33 AM, Ben Haller wrote: Another option would be to make your code mimic whatever NSExpression is doing on that machine, by evaluating 2 ** 3 ** 2 (once, and caching the result) and seeing whether it comes out as 64 or 512. That way if/when Apple fixes their bug, your code will seamlessly follow suit. Which of these alternatives is best depends upon how your code is going to be used, of course. Roland's suggestion of a compatibility switch seems good; the behavior I suggest could be a third option for that switch. Then the user of the class can decide what they want to get. Probably the best default would be to use the correct (right associative) parsing, though, as it seems unlikely that a whole lot of code specifically depends upon this bug in NSExpression, so for most clients there is probably no need to propagate the buggy behavior... Ben Haller McGill University ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSExpression is incorrect?
Another option would be to make your code mimic whatever NSExpression is doing on that machine, by evaluating 2 ** 3 ** 2 (once, and caching the result) and seeing whether it comes out as 64 or 512. That way if/when Apple fixes their bug, your code will seamlessly follow suit. Which of these alternatives is best depends upon how your code is going to be used, of course. Roland's suggestion of a compatibility switch seems good; the behavior I suggest could be a third option for that switch. Then the user of the class can decide what they want to get. Probably the best default would be to use the correct (right associative) parsing, though, as it seems unlikely that a whole lot of code specifically depends upon this bug in NSExpression, so for most clients there is probably no need to propagate the buggy behavior... Ben Haller McGill University On 2010-11-21, at 1:07 AM, Roland King wrote: I agree with you that exponentiation is usually defined as right-associative. How about a compatibility switch in your code which you can flip to make it work either way. On 21-Nov-2010, at 11:25 AM, Dave DeLong wrote: Hi everyone, Let's say I have the string @2 ** 3 ** 2. I can run this through NSPredicate to parse it into an NSExpression tree for me, like so: NSExpression * e = [(NSComparisonPredicate *)[NSPredicate predicateWithFormat:@2 ** 3 ** 2 == 0] leftExpression]; When I log/evaluate this predicate, it gives me (2 ** 3) ** 2, which evaluates to 64. In other words, NSExpression (or NSPredicate or whomever) has assumed that the power operator is a left-associative operator. According to Wikipedia (the source of all truth and knowledge), when no parentheses are present in the expression, the order is usually understood to be top-down, not bottom-up. [1] In other words, a ** b ** c is understood to be a ** (b ** c), not (a ** b) ** c. Put more formally, the power operator is supposed to be right associative. (rdar://problem/8692313) I'm currently working on some code that mimics much of the behavior of NSExpression. However, I'm now faced with a choice: do I make my code technically correct by making the power operator right associative, or do I maintain parity with NSExpression and make it left associative? Any suggestions you have would be welcome. Thanks, Dave DeLong [1]: http://en.wikipedia.org/wiki/Exponentiation#Identities_and_properties ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org This email sent to r...@rols.org ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/bhcocoadev%40sticksoftware.com This email sent to bhcocoa...@sticksoftware.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSExpression is incorrect?
I agree with you that exponentiation is usually defined as right-associative. How about a compatibility switch in your code which you can flip to make it work either way. On 21-Nov-2010, at 11:25 AM, Dave DeLong wrote: Hi everyone, Let's say I have the string @2 ** 3 ** 2. I can run this through NSPredicate to parse it into an NSExpression tree for me, like so: NSExpression * e = [(NSComparisonPredicate *)[NSPredicate predicateWithFormat:@2 ** 3 ** 2 == 0] leftExpression]; When I log/evaluate this predicate, it gives me (2 ** 3) ** 2, which evaluates to 64. In other words, NSExpression (or NSPredicate or whomever) has assumed that the power operator is a left-associative operator. According to Wikipedia (the source of all truth and knowledge), when no parentheses are present in the expression, the order is usually understood to be top-down, not bottom-up. [1] In other words, a ** b ** c is understood to be a ** (b ** c), not (a ** b) ** c. Put more formally, the power operator is supposed to be right associative. (rdar://problem/8692313) I'm currently working on some code that mimics much of the behavior of NSExpression. However, I'm now faced with a choice: do I make my code technically correct by making the power operator right associative, or do I maintain parity with NSExpression and make it left associative? Any suggestions you have would be welcome. Thanks, Dave DeLong [1]: http://en.wikipedia.org/wiki/Exponentiation#Identities_and_properties ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org This email sent to r...@rols.org ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
re: NSExpression with constant NSData value crashes Core Data
On 2009 May 17, at 15:10, Ben Trumbull wrote: Core Data supports == and != searches against binary data. You should be able to just use a predicate like: [NSPredicate predicateWithFormat:@myTransformableAttribute = %@, myGuidObject] and have it just work. Read the above carefully! myGuidObject is an NSData, right? So when you make that predicate with %@, it becomes a string description, complete with angle brackets and a whitespace separating each group the four bytes. Core Data is actually comparing the ^descriptions^ of NSData objects. Yuck!! Uhm, No. %@ is the vararg specifier for an NSObject. - stringWithFormat: turns that into a string. Because - stringWithFormat: turns everything into a string. Kinda the point. -predicateWithFormat: does NOT call -description randomly. Predicates are trees of first class objects, like an AST for a query. It does not turn objects into their textual representation before comparison. Result: It worked fine with the XML store (Why??). But when I switch to the SQLite store, it crashes when Core Data sends a -UTF8String message to the data object -- because it's expecting a damned description string. Took me several hours before I finally read Ben's post very carefully and figured out why it was doing that. This bug was fixed in 10.5.7 - Ben ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSExpression with constant NSData value crashes Core Data
On 2009 May 22, at 13:54, Ben Trumbull wrote: Uhm, No. %@ is the vararg specifier for an NSObject. - stringWithFormat: turns that into a string. Because - stringWithFormat: turns everything into a string. Kinda the point. -predicateWithFormat: does NOT call -description randomly. Predicates are trees of first class objects, like an AST for a query. It does not turn objects into their textual representation before comparison. Ah, I'd forgotten that and incorrectly jumped to that conclusion when I saw that my data was being sent -UTF8String. Result: It worked fine with the XML store (Why??). But when I switch to the SQLite store, it crashes when Core Data sends a -UTF8String message to the data object -- because it's expecting a damned description string. Took me several hours before I finally read Ben's post very carefully and figured out why it was doing that. This bug was fixed in 10.5.7 Indeed, I was using 10.5.6 and coincidentally just updated this afternoon. THANKS for the info -- that would have REALLY confused me had I seen that it had suddenly fixed itself. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSExpression
On Jun 28, 2008, at 10:35 PM, Chris wrote: NSExpression * ex = [NSExpression expressionForFunction: [NSExpression expressionForConstantValue:@BAR] selectorName:@length arguments:nil]; NSPredicate * predicate = [NSCompoundPredicate andPredicateWithSubpredicates:[NSArray arrayWithObject: ex]]; [predicate evaluateWithObject:@FOO substitutionVariables:nil]; What are you trying to achieve? ex is not a predicate, so you're only supplying one -- incorrect -- argument to create an AND predicate. It's not clear what role FOO plays in the third line. mmalc ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: NSExpression
On Jun 28, 2008, at 11:35 PM, Chris wrote: If anyone has a clue how to use it, I'd be grateful. This was my unsuccessful attempt: NSExpression * ex = [NSExpression expressionForFunction: [NSExpression expressionForConstantValue:@BAR] selectorName:@length arguments:nil]; NSPredicate * predicate = [NSCompoundPredicate andPredicateWithSubpredicates:[NSArray arrayWithObject: ex]]; [predicate evaluateWithObject:@FOO substitutionVariables:nil]; [NSFunctionExpression evaluateWithObject:substitutionVariables:]: unrecognized selector sent to instance 0x68b8af0 1) If you want to evaluate the NSExpression then use expressionValueWithObject:context. NSExpression * ex = [NSExpression expressionForFunction:[NSExpression expressionForConstantValue:@BAR] selectorName:@length arguments:nil]; int result = (int)[ex expressionValueWithObject:nil context:nil]; but this is probably not what you were trying to do (you didn't say what you were trying to do so I'm guessing). This is also a rather long way to get the length of a string. 2) andPredicateWithSubpredicates: wants an array of NSPredicates not NSExpressions. When you evaluated the NSPredicate the NSExpression object you put in the subpredicate array does not implement evaluateWithObject:substitutionVariables: and you get that warning. (Note: NSFunctionExpression is a subclass of NSExpression created for expressions of type NSFunctionExpressionType) I'm going to guess that you want to use a predicate to check the length of one string to the length of several others? One way using a NSPredicate could be: NSString *bar = [NSString stringWithString:@BAR]; NSString *foo = [NSString stringWithString:@FOO]; NSString *foobar = [NSString stringWithString:@FOOBAR]; NSPredicate *predicate = [NSPredicate predicateWithFormat:@length == %d, [bar length]]; BOOL result1 = [predicate evaluateWithObject:foo]; NSLog(@%@ = %@, foo, result1 ? @YES : @NO); BOOL result2 = [predicate evaluateWithObject:foobar]; NSLog(@%@ = %@, foobar, result2 ? @YES : @NO); output: 2008-06-29 02:23:23.475 testStrings[68040:10b] FOO = YES 2008-06-29 02:23:23.485 testStrings[68040:10b] FOOBAR = NO There are easier ways to compare the lengths (just use the length method in an if statement). If this does not cover what you are trying to do then you need to give more info. --Nathan ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: NSExpression
On Jun 28, 2008, at 12:13 AM, Chris [EMAIL PROTECTED] wrote: NSExpression defines this method: + (NSExpression *)expressionForFunction:(NSString *)name arguments: (NSArray *)parameters and the doco provides this example: [NSExpression expressionForFunction:(@selector(random)) arguments:nil]; Isn't that wrong? Can you really pass a selector to a NSString argument? The compiler is complaining, and the program crashes when I attempt. Yeah it is wrong. I believe you just pass a string with the same contents as what you would put in @selector. -shawn ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: NSExpression
If anyone has a clue how to use it, I'd be grateful. This was my unsuccessful attempt: NSExpression * ex = [NSExpression expressionForFunction:[NSExpression expressionForConstantValue:@BAR] selectorName:@length arguments:nil]; NSPredicate * predicate = [NSCompoundPredicate andPredicateWithSubpredicates:[NSArray arrayWithObject: ex]]; [predicate evaluateWithObject:@FOO substitutionVariables:nil]; [NSFunctionExpression evaluateWithObject:substitutionVariables:]: unrecognized selector sent to instance 0x68b8af0 On 29/06/2008, at 12:43 AM, Shawn Erickson wrote: On Jun 28, 2008, at 12:13 AM, Chris [EMAIL PROTECTED] wrote: NSExpression defines this method: + (NSExpression *)expressionForFunction:(NSString *)name arguments: (NSArray *)parameters and the doco provides this example: [NSExpression expressionForFunction:(@selector(random)) arguments:nil]; Isn't that wrong? Can you really pass a selector to a NSString argument? The compiler is complaining, and the program crashes when I attempt. Yeah it is wrong. I believe you just pass a string with the same contents as what you would put in @selector. -shawn ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
