Copy Page

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account. You can also Sign Up for a new account.

<h2>Problem</h2>

<p>Bit operations don't have the same semantics that the rest of Clojure's numeric functions do. Primitive semantics should be the default, there should be no conditionals, and bit ops should map directly to primitive ops.</p>

<h2>Steps</h2>

<ol>
	<li>Bit ops have primitive semantics by default (<a href="http://dev.clojure.org/jira/browse/CLJ-772">CLJ-772 bit ops to have primitive semantics by default, no conditionals, direct mapping to JVM primitive ops</a>)
	<ul>
		<li>No conditionals in default ops, like in <a href="https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Numbers.java#L455">Numbers.java</a></li>
	</ul>
	</li>
	<li>Bit ops with boxed semantics are in another ns (<a href="http://dev.clojure.org/jira/browse/CLJ-767">CLJ-767 Remove support for non-primitive bit-shift operations</a>)</li>
	<li>n-ary bit ops are inlined (<a href="http://dev.clojure.org/jira/browse/CLJ-184">CLJ-184 n-ary bit functions, also inlining of n-ary bit and math operations</a>)</li>
</ol>

<h2>Questions</h2>

<ol>
	<li>Does &quot;boxed semantics&quot; mean negative shift distance flips the direction?  Does it mean anything else, e.g., returning BigInt on overflow?  Can this just be left to the API on BigInteger? <span style="color: rgb(0,0,255);">SDH: negative shifts should be eliminated everywhere. There is (should be?) no such thing as overflow in bit ops, and there should be no promotion to BigInt.</span></li>
	<li>Changing bit ops <code>Numbers</code> methods to map directly to primitive ops means a breaking change with respect to negative bit-shift distances.  Is this intended/acceptable? <span style="color: rgb(0,0,255);">SDH: No negative shifts. Patch that simply removes the negative shift stuff would be welcome.</span></li>
	<li>Assuming no overflow support, is there any reason bit ops should not all return long, as opposed to sometimes Object? <span style="color: rgb(0,0,255);">SDH: Always long is good</span>.
	<ol>
		<li>If no, do we still need the BitOps interface? <span style="color: rgb(0,0,255);">SDH: Good point, BitOps no longer needed.</span></li>
		<li>Can the bit ops fns be written using prim interfaces? <span style="color: rgb(0,0,255);">SDH: Should be able to work with no interfaces, merely four overloads: long/long, long/Object, Object/long, and Object/Object</span>.</li>
	</ol>
	</li>
	<li>Support of n-ary ops via reduce causes a multiple orders of magnitude performance hit. Is unbounded expansion an acceptable solution for inline n-ary support?  Is there work underway for better support for reduce when working with primitive-taking/returning fns? <span style="color: rgb(0,0,255);">SDH: Macro expansion is good, won't be unbounded unless your code is infinite. There is a</span> <span style="color: rgb(0,0,255);"><a href="http://dev.clojure.org/jira/browse/CLJ-184">patch</a></span> <span style="color: rgb(0,0,255);">that needs review/refreshing.</span></li>
</ol>

<h2>Related Tickets</h2>

<ul>
	<li><a href="http://dev.clojure.org/jira/browse/CLJ-767">CLJ-767 Remove support for non-primitive bit-shift operations</a></li>
	<li><a href="http://dev.clojure.org/jira/browse/CLJ-441">CLJ-441 Add unchecked coercions</a></li>
	<li><a href="http://dev.clojure.org/jira/browse/CLJ-771">CLJ-771 Move unchecked-prim casts to clojure.unchecked</a></li>
	<li><a href="http://dev.clojure.org/jira/browse/CLJ-772">CLJ-772 bit ops to have primitive semantics by default, no conditionals, direct mapping to JVM primitive ops</a></li>
	<li><a href="http://dev.clojure.org/jira/browse/CLJ-184">CLJ-184 n-ary bit functions, also inlining of n-ary bit and math operations</a></li>
	<li><a href="http://dev.clojure.org/jira/browse/CLJ-666">CLJ-666 Add support for Big* numeric types to Reflector</a></li>
</ul>