Raul, briefly inline, I will not extend this thread, I am not looking for a
solution to our engine, it is already architected extremely efficiently.
> On 22 Nov 2019, at 4:53 am, Raul Miller wrote:
>>
>
> This is the kind of information I was looking for.
>
> That said, I am having trouble r
Hi Jimmy (sorry, been away for 3 days), good question and we have investigated
FPGAs, but abandoned for these reasons:
We prefer “vanilla” code in the engine (less dependencies, don’t tweak the
Linux kernel, minimal external packages and libraries etc)
We also code-generate from a very general ER
On Thu, Nov 21, 2019 at 7:44 AM 'Rob Hodgkinson' via Programming
wrote:
> Raul, I fear you have strayed off path again so as you inferred, I provide a
> very brief background to this.
I did not know, and I felt I had to convey the ideas you were
suggesting to me, to find out what you were talkin
@Rob Have you considered using FPGA boards to boost your throughput ?
On Thu, Nov 21, 2019 at 8:44 AM Vijay Lulla wrote:
> Rob,
> Can you please send me the paper too? I would like to read it.
> Thanks in advance,
> Vijay.
>
>
>
--
Rob,
Can you please send me the paper too? I would like to read it.
Thanks in advance,
Vijay.
On Tue, Nov 19, 2019 at 8:02 PM 'Rob Hodgkinson' via Programming <
programm...@jsoftware.com> wrote:
> Devon, my previous reply also brought to mind a very good example you
> request below …
>
> In kdb+
Raul, I fear you have strayed off path again so as you inferred, I provide a
very brief background to this.
I am speaking from direct experience as I have specialised in the matching
engine space since 1992 when I co-wrote the first commercial in memory matching
engine (called X-Stream).
This i
On Tue, Nov 19, 2019 at 8:00 PM 'Rob Hodgkinson' via Programming
wrote:
> The overhead associated with the multi key indexing you describe
> below is impractical for low latency matching, and avoided by
> managing a free space list for bucket re-use.
Why do you say that? (How big of a dataset doe
Devon, my previous reply also brought to mind a very good example you request
below …
In kdb+ the “table” datatype is built atop the “dictionary” data type… a table
may be perceived as a list of dictionaries (Key value pairs) that are
Columns/Values. I’ll send you a paper offline that shows th
OK thanks Raul.
Fast append is no issue, appends can be very fast as you suggest. The issue is
to maintain an ordering attribute that is fast/custom for each use case (in my
case an incoming order).
Linked Lists work very effectively, although having said that I would not try
to write a fast
Fast append can be implemented on an array language without linked
lists -- the mechanism involves leaving some empty memory at the end
of arrays and using that for append when there's only one reference to
the array and that reference is being updated.
For multi-key indexing, what you would do i
I disagree on this point Devon, linked lists are a very powerful data structure
and can be “overlaid” atop dynamic arrays to maintain a desired index order.
Without such a structure the only practical way is to append and (re)sort to
maintain an array in a suitable form.
An example of this is t
Yes, for J, you'd probably do something like (#/.~ trigrams), for a
batch of extracted trigrams. (Or something a bit more complicated, if
you allowed wildcard placeholders in your trigrams.)
And, if you had multiple batches, for example, from :
labels1=: ~.trigrams1
sums1=: #/.~trigrams1
labels2=
I used dictionary objects in Visual Basic (Access) to report similarity in text
strings based on trigram usage. The keys were the distinct 3-letter
combinations; the values were the incremented hit counts. It was both efficient
and effective. But I think there is a better array approach in J.
A simple use case which resembles the German-English dictionary is to implement
variable-value bindings in a small interpreter. I've run into this many times
in what I've been doing lately.
Cheers,
Louis
> On 18 Nov 2019, at 19:38, Raul Miller wrote:
>
> Dictionaries might provide a useful op
Dictionaries might provide a useful optimization for compression algorithms
For example: https://rosettacode.org/wiki/LZW_compression#J
See also:
https://en.wikipedia.org/wiki/DEFLATE
https://en.wikipedia.org/wiki/LZ77_and_LZ78
https://en.wikipedia.org/wiki/Prediction_by_partial_matching
https://
The example of translation from one language to another is not good enough?
Sure, it is possible to implement using it arrays only, but one can say so
about any turing-complete language including obscure ones.
Dictionaries are convenient - they require almost no mental effort to store
something
п
I would like to see examples of where a dictionary would be the preferred
way of dealing with some data. Does anyone know of any, not necessarily in
J, that are short and to the point?
On Mon, Nov 18, 2019 at 1:02 PM Danil Osipchuk
wrote:
> I quickly put together a minimal implementation along
I quickly put together a minimal implementation along those lines, to have
a subject for a discussion regarding performance and general usage
An object 'Map has a hash list mapping hash value to other 2 lists -- boxed
lists of boxed keys (per hash value) and boxed lists of boxed values.
It is not
s: works with strings. I would want key and value to be any nouns.
And as Raul observed, we're talking about an optimization here, so I
wouldn't want to have to convert each noun to a linear representation.
Henry Rich
On 11/18/2019 11:50 AM, Gilles Kirouac wrote:
Why can't such a class be i
https://www.jsoftware.com/help/dictionary/dsco.htm
"Incorrect global symbols data may cause misinterpretation of symbol
arrays, or data corruption, or a system crash, or the end of
civilization as we know it."
Thanks,
--
Raul
On Mon, Nov 18, 2019 at 11:50 AM Gilles Kirouac wrote:
>
> Why can'
This is really too soon. We haven't even found and fixed all existing
uses of those words.
That said, what would they be used to do?
As Henry mentioned in another message, locales already supply the
"get/fetch" semantics.
What he didn't mention is that you can use i. in conjunction with {
and }
Why can't such a class be implemented using s: Symbols?
It does calculate hashes and seems appropriate for dictionaries.
What is deficient in the implementation of s: ?
Why a new hash function?
~ Gilles
Le 2019-11-18 à 08:09, Henry Rich a écrit :
> Right now I am thinking that the need for dictio
Right now I am thinking that the need for dictionaries could be met by a
class whose instances are associative memories. Key, values,
hashtables, chains if needed would be stored inside the instance. The
interface would be simply x Put y and Get y. I reckon this would be
fast enough without
The performance of dyad i. is quite good. If size of dictionary is small,
eg thousands of items only. Then a simplistic implementation of 2 arrays, 1
for keys and 1 for values should be good enough.
On Mon, Nov 18, 2019, 7:10 PM Danil Osipchuk
wrote:
> symbols are essentially names optimized for
symbols are essentially names optimized for lookup and comparison, as such
they are useful to implement locales efficiently, if one to build an map
using those as keys, indeed one gets something resembling K dictionaries
http://www.math.bas.bg/bantchev/place/k.html :
"Another distinguishing featur
It's a long time since I played with s: - do J symbols have any
relevance to dictionaries/directories?
APL/J cousin, K, appears to have the dictionary as pretty central to its
data organisation, but maybe
that's more akin to J's locales.
Neither topic helpful probably relevant here, but mig
Dictionaries are powerful (if I may, this is the thing I miss most in J).
I recall reading somewhere, that a dictionary is a generalization of a
mapping {X}->{Y}, if Xs are (0..N) then we get an array.
Thus, using array facilities in J when a task calls for a dictionary will
always add a layer of i
Lua (https://www.lua.org) comes to mind:
A little (~150kB for the windows dll) language which as only composite
datatype has the table, to be used both as a dictionary, as well as indexed
array, as well as container for any OOP objects. It appears very mature and
stable, being used in plenty of big
Since d. /D. are being retired (for derivative usage), why not use them for an
inbuilt dictionary type?
I think J would be better with some kind of hashmap / dictionary (O(1) lookup
time), and d./D. already match
the first letter of "dictionary", so it's the perfect fit.
On Monday, November
key/value dictionary can be done in addon, but I think better
implemented in C for efficieny because it contains loops.
Sun, 17 Nov 2019, Henry Rich написал(а):
> In J I find myself coming back to simple arrays for most data structures.
>
> Trees can be represented as boxes containing subtrees.
Yes, but I want something lean and fast, not dealing with file-size
chunks. Example: a German-English dictionary. I give it a German word,
it gives me back the English. It can be continually updated.
Henry Rich
On 11/17/2019 10:02 PM, 'Jim Russell' via Programming wrote:
AFAIR, wasn't that
AFAIR, wasn't that a feature built into the (lib 1) component files addon? I
don't recall using a separate dictionary function.
> On Nov 17, 2019, at 9:49 PM, Henry Rich wrote:
>
> The datatype I really want is a directory object that acts as an efficient
> and easy-to-use associative memory.
Thanks for all the answers so far.
What prompted my questioning is the Advent of Code problem mentioned by
R.E.Boss in september :
http://www.jsoftware.com/pipermail/programming/2019-September/053995.html
I tried a simple approach splitting huge arrays in two to insert data and
it took forever to
In J I find myself coming back to simple arrays for most data structures.
Trees can be represented as boxes containing subtrees. That works, but
is usually more trouble than simply managing an array.
Linked lists are used only for efficiency, and in the cases where that
matters you can easil
I failed to communicate the links before, but here they are. Ordinal fractions
are somewhat like infinite-dimensional arrays.
https://www.academia.edu/10031088/ORDINAL_FRACTIONS_-_the_algebra_of_data
http://www.statemaster.com/encyclopedia/Ordinal-fraction
Bo.
Den søndag den 17. november 2
Trees are simple to implement in J -
https://code.jsoftware.com/wiki/User:Devon_McCormick/Trees - as are graphs
-
https://code.jsoftware.com/wiki/NYCJUG/2009-11-10/BreadthFirstGraphTraversal
.
A stack is simple to implement too but I'm not sure why you would want to
as it's simply a vector with ve
ORDINAL FRACTIONS - the algebra of data
|
|
|
| | |
|
|
|
| |
ORDINAL FRACTIONS - the algebra of data
This paper was submitted to the 10th World Computer Congress, IFIP 1986
conference, but rejected by the referee
|
|
|
Den søndag den 17. november 2019 07.12.02 CE
Arrays are roughly analogous to computer memory.
Put different: I think you are asking the wrong question.
(Partially: it's worth thinking about why you pick whichever data
structures...)
((It can also sometimes be useful to look on rosettacode for examples of
various daya structure handling mec
Of course, use array for everything.
* if all you have is a hammer, everything looks like a nail
eg. https://code.jsoftware.com/wiki/Essays/Tree_Sum
Sat, 16 Nov 2019, Jimmy Gauvin написал(а):
> Hi,
>
> when dealing with data structures other than arrays such as trees, graphs,
> stacks, linked l
Hi,
when dealing with data structures other than arrays such as trees, graphs,
stacks, linked lists what other programming language do you resort to ?
Or do stick with J for all endeavours?
Jimmy
--
For information about J foru
40 matches
Mail list logo
