I too don't have a strong preference for NegatedArguments vs before_call. I figured it could be something of general use, but if it's really only used here then it may be overkill. Your call, really.

If we keep the 'negate' flag, then we have to patch ATen as well otherwise it will be ignored, the options will be flipped. There is already an if_true: and if_false: in cwrap, can we use or modify those?

@zdevito The issue with if_true is that it turns the generated variable (arg_unbiased) into a const char*.

Can cwrap be modified to not transform if_true/if_false, the few places where it is used modified to quote the strings, and then use if_true: false, if_false: true instead of negate? This would be easier to support in the ATen wrapper rather than another flag that modifies arguments.

I'll look into it.

@zdevito I extended BoolOption to avoid changing type to const char* unless if_true is a string and removed negated.

Build now fails because ATen interprets 0 and 1 emitted by cwrap as strings in BoolOptions.
@zdevito would you please look into the ATen side of it? Thx!

I squashed my commits and rebased onto master.
I can now replicate the ATen issues (tests were passing on my branch).

First fix for if_true/if_false for ATen:

--- a/torch/lib/ATen/function_wrapper.py
+++ b/torch/lib/ATen/function_wrapper.py
@@ -1,6 +1,12 @@
 import re
 from code_template import CodeTemplate
 
+import sys
+if sys.version_info[0] == 3:
+    string_type = str
+else:
+    string_type = basestring
+
@@ -276,8 +282,12 @@ def create_derived(backend_type_env, declarations):
         if requires_checked_cast(argument):
             return CHECKED_USE.get(argument['type'], '{}_').format(argument['name'])
         elif argument['type'] == 'bool' and 'if_true' in argument:
-            return '({}) ? "{}" : "{}"'.format(argument['name'],
-                                               argument['if_true'], argument['if_false'])
+            if isinstance(argument['if_true'], string_type):
+                tpl = '({}) ? "{}" : "{}"'
+            else:
+                tpl = '({}) ? {} : {}'
+            return tpl.format(argument['name'],
+                       argument['if_true'], argument['if_false'])

@zdevito please let me know how should I go about this (I can open a PR in ATen or maybe you want to just go ahead).

The second error is related to ambiguous code generation given the signature in cwrap. In pytorch/torch/lib/build/ATen/ATen/Type.h, at lines 392 and 394 we get:

virtual Tensor & var_out(const Tensor & self, int64_t dim, bool unbiased, Tensor & destination) ;
virtual Tensor & var_out(const Tensor & self, int64_t dim, bool keepdim, Tensor & destination) ;

which is ambiguous. This is a case where we have two keyword arguments of the same time in Python and either of them can be specified. It looks to me like a corner case in need of a general fix.
What do you think?

@lantiga I think the ATen workflow we are going for is for PRs that are motivated by PyTorch changes is to do the same as for TH/THC etc. - make the changes in PyTorch and we will review them here, and then someone will forward to the ATen repo.

We have had tried to work around having the type signature ambiguity in ATen - I can't remember exactly what we decided upon.

@lantiga I fixed the bug that causes the ambiguous overload in ATen. It should filter them correctly now.

I updated to the latest ATen on pytorch master, so has Zach's fixes.

Thanks @killeent, @zdevito and @soumith! I've pushed my fix to ATen, tests pass now.

this is now merged into master. thanks Luca!

Great @soumith, thanks!