[jira] Issue Comment Edited: (MAHOUT-226) Velocity-based code generation support to support more primitive type collections

["Benson Margulies (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MAHOUT-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12792880#action_12792880 ] 

Benson Margulies edited comment on MAHOUT-226 at 12/19/09 6:35 PM:
-------------------------------------------------------------------

OK, time to turn up the persuasion device.

The goal here is to extend the code from Colt, not to leave it as-is and build next to it.  If you really want to preserve the original colt code unscathed, you should ask me to go back and rework my first commit, since I added several new functions to the IntIntHashMap to provide functionality comparable to Trove.

Note that, ignoring my mistake of last evening, this patch doesn't change any 'functions'. So far, it's all interfaces. I don't really see any value in preserving an older copy of the very same interface (as examined at the .class level) under another package name.

The first really interesting commit in this project would, according to my idea, remove the checked-in AbstractIntIntMap and OpenIntIntHashMap and replace them with templates, and thus get the complete set.

That's why I started with unit tests for that stack of code, so that I could prove to everyone, including myself, that I don't bust the IntInt map when adding all the others via the template trick.

SInce I can't imagine any way to unit test an interface, let alone an interface consisting of a single function that takes two parameters and returns a boolean, I didn't write specific a specific unit test for IntIntProcedure. But there are uses of that interface and implementations of it in the unit tests I wrote for the int-int map. So, I think I could claim with some justification that there are now tests that would catch bad things on these items. Not so for the 'Function' thing that I mistakenly put in the initial patch, and which I have no intention of touching at all, ever, as part of the hash table extensions.

The pattern I'm proposing here is:

1) create adequate unit tests
2) enhance
3) rinse, lather, repeat

I'm claiming that I've got tests for the IntInt hash map, and so I can tackle it.

Next will come the Object-* case, which will need tests before I change anything, and then the *-Object case.





      was (Author: bmargulies):
    OK, time to turn up the persuasion device.

The goal here is to extend the code from Colt, not to leave it as-is and build next to it.  If you really want to preserve the original colt code unscathed, you should ask me to go back and rework my first commit, since I added several new functions to the IntIntHashMap to provide functionality comparable to Trove.

Note that, ignoring my mistake of last evening, this patch any 'functions'. So far, its all interfaces. I don't really see any value in preserving an older copy of the very same interface (if examined at the .class level) under another package name.

The first really interesting commit in this project would, according to my idea, remove the checked-in AbstractIntIntMap and OpenIntIntHashMap and replace them with templates, and thus get the complete set.

That's why I started with unit tests for that stack of code, so that I could prove to everyone, including myself, that I don't bust the IntInt map when adding all the others via the template trick.

SInce I can't imagine any way to unit test an interface, let alone an interface consisting of a single function that takes two parameters and returns a boolean, I didn't write specific a specific unit test for IntIntProcedure. But there are uses of that interface and implementations of it in the unit tests I wrote for the int-int map. So, I think I could claim with some justification that there are now tests that would catch bad things on these items. Not so for the 'Function' thing that I mistakenly put in the initial patch, and which I have no intention of touching at all, ever, as part of the hash table extensions.

The pattern I'm proposing here is:

1) create adequate unit tests
2) enhance
3) rinse, lather, repeat

I'm claiming that I've got tests for the IntInt hash map, and so I can tackle it.

Next will come the Object-* case, which will need tests before I change anything, and then the *-Object case.




  
> Velocity-based code generation support to support more primitive type collections
> ---------------------------------------------------------------------------------
>
>                 Key: MAHOUT-226
>                 URL: https://issues.apache.org/jira/browse/MAHOUT-226
>             Project: Mahout
>          Issue Type: Task
>          Components: Matrix
>            Reporter: Benson Margulies
>         Attachments: codegen.patch, compileroptions.patch
>
>
> We want the complete set of hash maps on the primitive types. The code can be generated. So here's a code generator to do it, and, to show it off, the TypeTypeFunction.java family set up to be generated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.