[kepler-dev] Question about OrderedRecordToken

[ben leinfelder]

I'm going to vote for allowing the non-commutative operations since  
the alternative strikes me as overly-restrictive.
The main reason I needed the ordered record was to mimic a table  
structure in which you could preserve the "column" order and refer to  
the labels by both name and index.
I can see this feature remaining extremely useful as long as a user of  
OrderedRecordToken knew which operand was going to determine the order  
of the result.
-ben

On Dec 6, 2009, at 4:51 PM, Edward A. Lee wrote:

>
> I agree that having a non-commutative add could be a problem...
> I'm not sure how serious.  Multiplication is not commutative if
> the arguments are matrices, and this doesn't seem to create serious
> problems.
>
> I'm really not sure what the right answer is...
>
> I guess since you are the designer, you get to decide!
>
> :-)
>
> Edward
>
>
> ben leinfelder wrote:
>> Edward -
>> After some gumshoeing, I've found that, for me, the add operation  
>> does naturally order the labels in the result rather than  
>> preserving the given order of the ordered record tokens involved.
>> Then after some tinkering, I now have it locally so that:
>> 'a.add(b)' returns a result in the order of 'a'
>> and
>> 'b.add(a)' return a result in the order of 'b'
>> But that seems wrong because then the addition is not commutative.  
>> Perhaps we do need to enforce that the tokens have the same  
>> ordering (but I agree that also seems wrong).
>> -ben
>> On Dec 5, 2009, at 8:24 AM, Edward A. Lee wrote:
>>>
>>> One possibility would be to not perform the addition if
>>> the ordering is not the same.  This would be consistent
>>> with the fact that
>>>
>>> [x = 1, y = 2] != [y = 2, x = 1]
>>>
>>> and that their types are different.
>>>
>>> I'm not sure about this though...
>>>
>>> Edward
>>>
>>>
>>> ben leinfelder wrote:
>>>> Edward,
>>>> I'm not sure what determines the order of the result when you add  
>>>> ordered record tokens - what do you suppose the order should be?  
>>>> With the example you have, I don't see a pattern. It's not even  
>>>> defaulting to the RecordToken ordering (alpha).
>>>> Does it make sense to have the result use the same ordering as  
>>>> the initial operand? Or should the operation fail when the tokens  
>>>> are not in the same order (seems severe)?
>>>> I'd expect
>>>> a.getType()
>>>> to return
>>>> object([x=int, y=int])
>>>> It seems to be deferring to the superclass for  
>>>> getType...something I should look into/fix.
>>>> Thanks for pointing these out.
>>>> -ben
>>>> On Dec 4, 2009, at 6:51 AM, Edward A. Lee wrote:
>>>>>
>>>>> Ben,
>>>>>
>>>>> I have a question about ordered record tokens.
>>>>> In the expression evaluator, I can do:
>>>>>
>>>>> >> a = [x = 1, y = 2]
>>>>> [x = 1, y = 2]
>>>>>
>>>>> >> c = [y = 2, x = 3]
>>>>> [y = 2, x = 3]
>>>>>
>>>>> >> a + c
>>>>> [y = 4, x = 4]
>>>>>
>>>>> >> c + a
>>>>> [y = 4, x = 4]
>>>>>
>>>>>
>>>>> What determines the order in the result?
>>>>>
>>>>> Also, if I do:
>>>>>
>>>>> >> a.getType()
>>>>> object({x = int, y = int})
>>>>>
>>>>> This description of the type seems exactly the same as
>>>>> the description I get from an (unordered) record token.
>>>>> Is this a problem? (I don't really know...)
>>>>>
>>>>> Thanks!
>>>>> Edward
>>>>> <eal.vcf>
>>> <eal.vcf>
> <eal.vcf>