World: r4wp

then do things like 
1. select the top 50%
2. calculate interquartile ranges etc.

Why do the brackets not match...

apologies again - extracted this fragment from a gzillion mb file 
- there should be     
  ]]]]
at the end

aha, skipping does work, but the comparison happens on the strings 
instead of the objects.

yes...
>> sort/skip/compare/all comps 2 func [a b][a > b ]
..sorts in reverse order

i cant seem to reference the object!

is MCAPZ the same as ATTRIBS?

yes

if i do:

>> sort/skip/compare/all comps 2 func [a b][length? a/mcapz > length? 
b/mcapz ]
i get an invalid path error

and what i need to do is more complex than that :(

you can do a REVERSE H before and after the sorting. That allows 
SORT to grab the objects.

let me try...

>> reverse comps sort/skip/compare/all comps 2 func [a b][length? 
a/mcapz  > length? b/mcapz ]
** Script Error: Invalid path value: mcapz
** Near: length? a/mcapz > length? b/mcapz

Try:


func [a b][probe type? a probe type? b length? a/mcapz  > length? 
b/mcapz ]

when you use /all,   you get two BLOCKS.  one for each record of 
length /skip

so your function is called like so: 

sort-func [   "2009-2010"  #[object! [  ... ]]  ]      [ "2011-2012" 
 #[object! [ ... ]]   ]

aha, that means you don't need the REVERSE. You just need to reference 
the values differently.

reverse comps sort/skip/compare/all comps 2  func [a b][probe type? 
a probe type? b length? a/mcapz  > length? b/mcapz ]

block!
block!
** Script Error: Invalid path value: mcapz
** Near: length? a/mcapz > length? b/mcapz

Maxim's SORT-FUNC block shows you how to reference the values properly.

my last example above with ?? added shows this clearly:


>>  sort/skip/compare/all [1 [2  "a"] 0 [4 "z"] 5 [4 "m"]] 2 func 
[a b][ ?? a  ?? b   a/2/2 < b/2/2 ]
a: [0 [4 "z"]]
b: [5 [4 "m"]]
a: [1 [2 "a"]]
b: [0 [4 "z"]]
a: [5 [4 "m"]]
b: [1 [2 "a"]]
== [1 [2 "a"] 5 [4 "m"] 0 [4 "z"]]


what is part of the record is completely irrelevant to sort, it transfers 
all control to your function.

the only really problem with a compare func is that you must be sure 
that your data can be compared (which is not true for all types.

ex:  true/false  is not defined for all comparison ops:
>>   true > false
** Script Error: Cannot use greater? on logic! value
** Near: true > false

am getting somewhere (i think)
>> sort/skip/compare/all comps 2 func [a b][o: a/2/mcapz probe o]
=== make hash! ["2003-2004" make object! [
        yyyymmdd: 30-Sep-2003
        rebal-year: 2003
        ...]]
etc

so it is a referencing problem

yep... its the /2/ which is important here  <:-)

just discovered another problem though...not all inner hashes have 
the same years - so one objects inner hash may have key "1991-1992" 
while another may not

looks like i will have to collect the objects/inner-hash-objects 
into a separate collection, then apply the sorting on the new collection

c: copy[] foreach [k v] comps [if select v/mcapz "1991-1992" [append 
c v]] or some such

then use maxim's sort-func on c instead

is that generally the right direction? i would have ideally liked 
to have avoided creating new blocks to conserve memory...

you can simply say that when an entry doesn't have a year, it is 
always larger,  so you have them at the end of the list.  you could 
then sort those without a date according to their name.


if you want just the list for "1991-1992" yes, that is a good approach... 


however usually, the fastest way to filter-out lists, is to copy 
the block (not deep, so its quick) and then use remove-each on the 
new block... like-so:

filtered-data: copy data

remove-each [hash mcapz] filtered-data [ not select mcapz "1991-1992"]

will try with both approaches.

thanks for the filtered-data tip maxim - will definitely move to 
that!

anyone know which one of these would be the correct one to use?

1. percentile: func[s p /local n][n: round/floor (p * (length? s) 
+ 0.5) return s/(n - 1)]

2. percentile: func[s p /local n][n: round/floor (p * (length? s) 
+ 0.5) return s/(n)]

s is a sorted series, p is a decimal from 0.0 to 1.0

Those radio buttons are a real pain in the ... . Somebody please 
rewrite those and make a radiogroup that makes sense?

view layout [
    radio-line of 'a "Check this out"
    radio-line of 'a "or this"
    pad 8
    radio-line of 'b "Or Check this out"
    radio-line of 'b "or this"
    radio-line of 'b "or that"
]

What' exactly is your problem with radio buttons, Arnold?

Well it was quite a problem to get the selected value. I ended up 
first initialising all /data fields to their respective values beforehand 
to true for the one on and false for the two unselected ones. After 
that the fields behaved like you would expect, being true in case 
the selection was on this button and false if not selected.
Radio-line is new to me.

Something like this cost me only a couple of hours trial and err 
(mostly err) for there was no proper example to copy and it didn't 
work out of the box without the initialisations. 
main: layout [
a: radio on 'things lbl-a: "A"
b: radio of 'things lbl-b: "B"
etc]
a/data: true
b/data: false
view main

by default all radio buttons in the same pane switch together, you 
can just wrap your radio buttons in a panel.

ex:

view layout [
	panel [across radio radio radio on]
	panel [across radio on radio radio]
]

Stil that was not the problem. I wanted to know what selection was 
made :)

In my previous example b/data had a value none in stead of false 
and I could have two radioselections selected at the same time.

yeah, well, all I can say is that whenever view or more specifically 
VID is frustrating, you should just mold the face which is aggravating 
you, save the code to a file and read it in your favorite syntax 
highlighted editor.


you will learn A LOT about how VID.view works and learn quite a few 
Reboling techniques too.

very few people use functions as extensively and as precisely as 
Carl.   many functions have supported types I never even realized... 
like 'PICK which supports   true/false

(Carl wrote VID, so its a good example of his Rebol coding)

(its coarse and dense though, so don't despair if you don't undersand 
it all, just go through it line by line ... and learn)

here is a simple way to get the code for a face within the layout 
function ( I found it the easiest to remember):

view layout [
	across
	text "1"
	my-radio: radio on 
	do [probe my-radio]
	text "2"
	radio
]


the advantage of this system is that you get the actual face with 
any facets setup as they really are in your gui.  this is often the 
easiest way to identify just where and how a specific facet affects 
a face... probe it without your change, and then run it again, with 
your change... comparing both probes in a diff or merge tool.

the other way is to use get-style.   the advantage here is that is 
preserves the init block, instead of clearing it after VID has done 
its work


a good look at the 'init block is often useful to understand why 
changing some of the face values is ineffective (like changing face/color 
is often useles... since that face is setup to use face/colors). 
 

this block is run after all the facets have been applied. 

note that you can set or append to this block in your own styles.

HTH  :-)

get-radio-buttons: does [
    reduce [
        get-face option-1
        get-face option-2
        get-face option-3
    ]
]

reset-radio-buttons: does [
    clear-face option-1
    clear-face option-2
    clear-face option-3
]

view layout [

    option-1: radio-line "Option 1" of 'options [probe get-radio-buttons]

    option-2: radio-line "Option 2" of 'options [probe get-radio-buttons]

    option-3: radio-line "Option 3" of 'options [probe get-radio-buttons]

    btn "reset radios" [reset-radio-buttons]
]

Best to use the getter-/setter-methods wherever they are implemented.