Thanks, Ian,
turns out that implementation, for the matching part,
isn’t too far from what I did.
Funnily, I thought about rewording what you called match as
('0' e. ".@-,,)/ in the left part of “aligned” – sorry for
my bad names, it’s been written down quickly
And then I found that the way I did it is pretty much exactly
your matchY even though I coded from the paper given where
you tried to translate literally.
And the differences to my J implementation can teach ways
to approach a problem to some degree. You did a good job
explaining the background of how the original you translated
from might have come to be. This, too, was insightful.
And I do like your CN and CS idea, where I gave in too early
and muttered about wanting to “avoid parsing”.
But there’s another issue I ran into looking at the way you
approached it. What did I do? Obviously not thinking the J way.
I read database and thought data. My different approaches in
the D, J, and lua implementations were driven by different
data layout that had to be supported by fitting algorithms.
But this is a functional language and we could as well think
about functions, about algorithms first, and only afterwards
juggle the data to fit them.
I guess this was in part due to the thread starting with
spreadsheets that are inherently data- and data-layout-driven,
and in part as well due to this very example starting out with
a set of data that was just given where the algorithms had to
be crafted.
But that’s not to say there’s not a fair contribution to my
failure on my part. I should have seen my stubborn approach
of focussing on the data only.
So this was another inspiration and shows me what I still
need to learn and get used to.
thankfully,
Hauke
Am 08.01.21 um 13:36 schrieb Ian Clark:
> Hauke,
>
> Might this help towards what you're aiming to do?
>
> https://code.jsoftware.com/wiki/User:Ian_Clark/credo
>
> Ian
>
> On Fri, 8 Jan 2021 at 11:50, Hauke Rehr <hauke.r...@uni-jena.de> wrote:
>
>> re-implementing in another language is often helpful
>> I thought lua’s tables should lend themselves to the
>> structure we have here, so I tried another approach –
>> and found another quirk:
>> your solution depends on the order of entry
>>
>> I had to add lines 50, 106–109 incl., and change
>> lines 61 and 277 in order to get the correct results.
>>
>>
>> Am 08.01.21 um 07:56 schrieb Hauke Rehr:
>>> … and here’s a J implementation (and output)
>>> but I stumbled upon another aspect that didn’t
>>> match the specification as I understood it:
>>>
>>> consider the first example 13510:
>>> your solution contains SIMUL which is 13509
>>> so I implemented that whenever either of them
>>> has a 0, they match. I think that’s wrong.
>>> The query may be more general but not more
>>> specific than the things we want it to match.
>>>
>>> In my D implementation, it’s in the function
>>> match in lines 105 through 117, (I already
>>> wondered if it’s wrong but didn’t check again
>>> after I found I got your ‘correct’ results);
>>> in the J script, it’s where the comment says
>>> what’s superfluous.
>>>
>>> … and I edited the 0 : 0 content (added an LF)
>>> in order to not have to do too much parsing
>>>
>>> cheers,
>>> Hauke
>>>
>>>
>>> Am 08.01.21 um 04:41 schrieb Hauke Rehr:
>>>> I jotted down a q&d-implementation in D.
>>>> When I found out that your example doesn’t
>>>> fit the hierarcical layout (multiple instances
>>>> for 11, for example, so 11 isn’t a category
>>>> even though there are things like 111),
>>>> I ripped out the code depending on the hierarchy.
>>>>
>>>> The results agree with your results so I think
>>>> this should be a correct re-implementation.
>>>>
>>>> Am 08.01.21 um 00:30 schrieb Hauke Rehr:
>>>>> That post was written too soon.
>>>>> Now that I’ve taken a look at what ordinal fractions
>>>>> are meant to be, it looks to me more like what I think
>>>>> I first came to know when learning some prolog.
>>>>> I try to write down my new understanding of ordinal fractions,
>>>>> in a more old-fashioned lingo of enums (concepts)
>>>>> with their elements, and tagging data with them:
>>>>>
>>>>> there is an a priori given set of hierarchical enums
>>>>> where subordinate ones’ range and meaning may depend
>>>>> on superordinate ones
>>>>> you tag any data by at most one element of each enum
>>>>> where the elements themselves are part of the data
>>>>> (and are tagged by themselves only)
>>>>> any data with an incomplete set of tags is a category
>>>>> all “leaf data” if thought of the hierarchy as a tree
>>>>> is given a full set of tags.
>>>>> then you just do some matching where everything matches unless
>>>>> there is an enum the things to be matched both have an entry of
>>>>> and where the entries don’t agree
>>>>>
>>>>> @bo: Is this “translation” of the concept of ordinal fractions
>> adequate?
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>>
>>
>> --
>> ----------------------
>> mail written using NEO
>> neo-layout.org
>> ----------------------------------------------------------------------
>> For information about J forums see http://www.jsoftware.com/forums.htm
>>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
----------------------
mail written using NEO
neo-layout.org
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
