r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Core] Discuss core issues

Gregg
19-Aug-2010
[17960]
Cool. Yeah, there are times we need to use advanced algorithms, and 
times we don't.
Brock
19-Aug-2010
[17961]
Carl has a character by character search in Rebodex.  Not sure if 
that is any better than what you have done.
Tomc
20-Aug-2010
[17962]
G raham a suffix tree may be what tou want for trem compleation
Graham
20-Aug-2010
[17963]
suffix tree?
Tomc
20-Aug-2010
[17964x2]
a forest of trees where the words are on the path from root to leaf 
so at any interior node the possible compleations are the subtree 
the node you are on is the root of
if not clear blame it on post op drugs... I'm recovering from bad 
 cellulitus
Sunanda
20-Aug-2010
[17966]
It's a type of denormalised trie:
   http://marknelson.us/1996/08/01/suffix-trees/
Graham
20-Aug-2010
[17967x3]
It clearly has affected your typing!
I guess you didn't get the necrotizing fasciitis version!
So, all I need is to write a function that takes my data and builds 
the tree ...
Tomc
20-Aug-2010
[17970]
it has affected my typing in that I have time to spend here
Graham
20-Aug-2010
[17971]
Since my data is also invariant ... I could save the data structure 
and send it to my users :)
Tomc
20-Aug-2010
[17972x2]
if your controlled vocab chantes much it will be expensive
this is why controlled vocabularies are good
Graham
20-Aug-2010
[17974x2]
There aren't that many new drugs added to the pharmacopaiea on a 
monthly basis
The FDA makes sure of that!
Tomc
20-Aug-2010
[17976]
sounds ideal
Graham
20-Aug-2010
[17977x2]
so how are the nodes represented?  blocks?  objects?
http://www.mail-archive.com/[list-:-rebol-:-com]/msg07839.html
Tomc
20-Aug-2010
[17979]
if you can get away with blocks it should be cheaper , since you 
only decend,  parent is not needed just child blocks and value may 
work
Graham
20-Aug-2010
[17980]
Maybe Carl can add this as a native for find/deep :)
Tomc
20-Aug-2010
[17981]
also look at prefix trees, may be a simpiler  variant for word compleation
Chris
21-Aug-2010
[17982]
Is there a case to be made for use/only ?

>> use [a][a: 1]
== 1
>> use/only [a][a: 1]
== [a: 1]

Replaces having to 'double bag' -
>> use [a][[a: 1]]

Am I missing an obvious equivalent?
Ladislav
21-Aug-2010
[17983]
I would say, that your equivalent is fine. Since it is not that hard 
to use the "double bag", I doubt it justifies the refinement, since 
the refinement expression isn't shorter than the expression it is 
supposed to replace.
Chris
21-Aug-2010
[17984x2]
You get longer line lengths in the standard style:

use [a][
    [
	a: 1
    ]
]

; picture a: 1 being slightly more code
vs.

use/only [a][
    a: 1
]


Partly it's aesthetics - but this is a language, aesthetics can be 
important.
Ladislav
22-Aug-2010
[17986x2]
It still is possible to introduce just a special "double bag style", 
which is aesthetically acceptable, IMO (I have seen it somewhere, 
so it is not my invention):

use [a] [[
    a: 1
]]
>> f: func [] [[
[        a: 1
[        b: 2
[        ]]
>> f
== [
    a: 1
    b: 2
]
>> source f
f: func [][[
        a: 1
        b: 2
    ]]
Graham
22-Aug-2010
[17988]
I've got diplopia!
Gabriele
22-Aug-2010
[17989]
The disadvantage of [[ is that it can be difficult to notice sometimes, 
but otherwise it seems acceptable in cases like this.
Izkata
22-Aug-2010
[17990]
If I'm using that, I usually double-indent the surrounded code, to 
help make it easier to notice
Chris
22-Aug-2010
[17991x2]
Gab: right, it's more difficult to visually parse, and it's ugly 
(two different issues, I'd say).  Perhaps I need to use a 'double-bag 
function.
It's also mentally uncomfortable - it feels like there should be 
a way to do use/only [a][a: 1]

parse "this" use/only [mk][opt "t" mk: to end (probe mk)]
Izkata
22-Aug-2010
[17993]
Any reason not just pull the 'use outwards?

use [mk][
   parse "this" [opt "t" mk: to end (probe mk)]
]
Chris
22-Aug-2010
[17994]
In that case, no.
Gabriele
23-Aug-2010
[17995x2]
alternatively... one could think of extending WITH (not sure if we 
ever decided if we wanted that built-in)
(hmm, no, same problem, WITH still evaluates)
Anton
23-Aug-2010
[17997]
The current USE does:
1. Create context of specified words.
2. Bind body.
3. Evaluate.
Chris wants to be able to remove the evaluation.

In a perfect world with no legacy issues to worry about, I would 
prefer USE to do only steps 1 & 2, and USE/DO to do all three steps.

Or, a new function could be introduced (which I might name ENCLOSE 
or COOP) which does only steps 1 & 2.


Alternatively, if there was a function which returned a context created 
from a block of words, eg:


 CONTEXTUALIZE: func [words [block!]] [ ... ]  ; Returns a new context 
 containing words without evaluation.


then you could imagine using an idiom to get steps 1 & 2, or all 
three steps. eg:

	bind body contextualize words  ; Steps 1 & 2.
	do bind body contextualize words   ; All three steps.

So Chris' example would be:


 parse "this" bind [opt "t" mk: to end (probe mk)] contextualize [mk]

(<sigh> If only BIND had its argument order reversed...)
Maxim
24-Aug-2010
[17998x3]
I'm working on a high-performance windows counter for R2.   on my 
system, the resolution is 1 / 3500000  !!!


just calling the function twice, back to back returns more than 6700 
counts in difference.. which is pretty fast.
AFAICT, it uses something like the CPU frequency counters directly.
wow, this is so precise, I can time a single call to a native!  :-)
Pekr
24-Aug-2010
[18001]
why R2? You have got sources to R3. Improve timers in there :-)
Maxim
24-Aug-2010
[18002x2]
not timers, counters....   ;-)
its probably the same high-precision counters that R3 uses.
Pekr
24-Aug-2010
[18004]
why are you working on counters, instead of releasing Glass, which 
was supposed to be out 3 months ago? :-) Is that somehow related?
Maxim
24-Aug-2010
[18005]
I am on vacation, I having fun working on my animation/game/math 
package.  this will allow more precise animation timing... cause 
as it stands, in R2 I can't manage much more than 32 OR 66 frames 
per second, since all time values are stuck in 0.016 increments.
Pekr
24-Aug-2010
[18006]
good enough :-) So we finally can make a Scala killer later :-)
Maxim
24-Aug-2010
[18007]
did you try my little view test app?
Pekr
24-Aug-2010
[18008x2]
While REBOL can animate fast, the movement of elements is still jerky. 
Double buffering does not help here either.
Yes, I did. And I was really impressed - cool performance - it is 
... realtime :-)