I have got a data-management problem. I have a database where "EDSS.1","EDSS.2",... represent a numeric variable, scaled from 0 to 10 (0.5 scale), where higher number stand for higher disability. For each EDSS variable, I have a "VISITDATE.1", "VISITDATE.2",...
EDSS
VISITDATE
Now I am interested in assessing the CONFIRMED DISABILITY PROGRESSION (CDP), which is an increased i 1 poin on the EDSS. To make things more difficult, this increment need to be confirmed in the subsequent visit (e.g. EDSS.3) which has to be >= 6 months (which is, VISITDATE.3 - VISITDATE.2 > 6 months.
To do so, I am creating a nested ifelse statement, as showed below.
prova <- prova %>% mutate(
CDP = ifelse(EDSS.2 > EDSS.1 & EDSS.3>=EDSS.2 & difftime(VISITDATE.3,VISITDATE.2,
units = "weeks") > 48,
print(ymd(VISITDATE.2)),0))
However, I am facing the following main problems:
How can I print the VISIT.DATE of my interest instead of 1 or 0?
How can I shift my code to the EDSS.2,EDSS.3, and so on? I am interested in finding all the confirmed disability progressions (CDPs).
Many thanks to everyone who find the time to answer me.
Is it possible to solve this problem with a solution which has time complexity better than linear?
N light bulbs are connected by a wire. Each bulb has a switch associated with it, however due to faulty wiring, a switch also changes the state of all the bulbs to the right of current bulb. Given an initial state of all bulbs, find the minimum number of switches you have to press to turn on all the bulbs. You can press the same switch multiple times.
Note : 0 represents the bulb is off and 1 represents the bulb is on.
Input : [0 1 0 1]
Steps:
press switch 0 : [1 0 1 0]
press switch 1 : [1 1 0 1]
press switch 2 : [1 1 1 0]
press switch 3 : [1 1 1 1]
Return : 4
This is called a "Lights Out" riddle:
http://mathworld.wolfram.com/LightsOutPuzzle.html
One speed improvement I could think off would be to paralellise the setting of all the bulbs to the right. In particular a GPU might be able to do that effectively (I am not sure as you need to change wich elements are effected with each loop).
Maybe making it a proper boolean Array and bitwise XOR-ing a pattern onto the array?
Unless the real process is a lot more complex then XOR-ing boolean values, memory speed will be the bottleneck here - not CPU time.
Unless this is for purely academic purposes, the performance rant propably applies:
http://ericlippert.com/2012/12/17/performance-rant/
I'm working on an android application and at some point, I retrieve a value contained between -100 and 100 which follow a normal law (I don't have the parameters of this law).
I would like to create a function which returns me a mark on 20 but to avoid to have all marks between 8 and 12, I would like to "stretch" values around 0.
For example, a variation of 1 around the 0 will give me a 0.5 point of difference in the mark, and a 1 point variation around the 100 will give me a 0.01 point of difference in the mark.
Is there any algorithm/function/trick that will gave me this possibility ? Which could be the conditions or requirement ? Is there any library available that will give me this possibility ? (I search but didn't found...)
Thank you !
Continuing with some experimentation here I was interested is seeing how to continuing training a VW model.
I first ran this and saved the model.
vw -d housing.vm --loss_function squared -f housing2.mod --invert_hash readable.housing2.mod
Examining the readable model:
Version 7.7.0
Min label:0.000000
Max label:50.000000
bits:18
0 pairs:
0 triples:
rank:0
lda:0
0 ngram:
0 skip:
options:
:0
^AGE:104042:0.020412
^B:158346:0.007608
^CHAS:102153:1.014402
^CRIM:141890:0.016158
^DIS:182658:0.278865
^INDUS:125597:0.062041
^LSTAT:170288:0.028373
^NOX:165794:2.872270
^PTRATIO:223085:0.108966
^RAD:232476:0.074916
^RM:2580:0.330865
^TAX:108300:0.002732
^ZN:54950:0.020350
Constant:116060:2.728616
If I then continue to train the model using two more examples (in housing_2.vm), which note, has zero values for ZN and CHAS:
27.50 | CRIM:0.14866 ZN:0.00 INDUS:8.560 CHAS:0 NOX:0.5200 RM:6.7270 AGE:79.90 DIS:2.7778 RAD:5 TAX:384.0 PTRATIO:20.90 B:394.76 LSTAT:9.42
26.50 | CRIM:0.11432 ZN:0.00 INDUS:8.560 CHAS:0 NOX:0.5200 RM:6.7810 AGE:71.30 DIS:2.8561 RAD:5 TAX:384.0 PTRATIO:20.90 B:395.58 LSTAT:7.67
If the model saved is loaded and training continues, the coefficients appear to be lost from these zero valued features. Am I doing something wrong or is this a bug?
vw -d housing_2.vm --loss_function squared -i housing2.mod --invert_hash readable.housing3.mod
output from readable.housing3.mod:
Version 7.7.0
Min label:0.000000
Max label:50.000000
bits:18
0 pairs:
0 triples:
rank:0
lda:0
0 ngram:
0 skip:
options:
:0
^AGE:104042:0.023086
^B:158346:0.008148
^CRIM:141890:1.400201
^DIS:182658:0.348675
^INDUS:125597:0.087712
^LSTAT:170288:0.050539
^NOX:165794:3.294814
^PTRATIO:223085:0.119479
^RAD:232476:0.118868
^RM:2580:0.360698
^TAX:108300:0.003304
Constant:116060:2.948345
If you want to continue learning from saved state in a smooth fashion you must use the --save_resume option.
There are 3 fundamentally different types of "state" that can be saved into a vw "model" file:
The weight vector (regressor) obviously. That's the model itself.
invariant parameters like the version of vw (to ensure binary compatibility which is not always preserved between versions), number of bits in the vector (-b), and type of model
state which dynamically changes during learning. This subset includes parameters like learning and decay rates which gradually change during learning with each example, the example numbers themselves, etc.
Only --save_resume saves the last group.
--save_resume is not the default because it has an overhead and in most use-cases it isn't needed. e.g. if you save a model once in order to do many predictions and no learning (-t), there's no need in saving the 3rd subset of state.
So, I believe in your particular case, you want to use --save_resume.
The possibility of a bug always exists, especially since vw supports so many options (about 100 at last count) which are often interdependent. Some option combinations make sense, other don't. Doing a sanity check for roughly 2^100 possible option combinations is a bit unrealistic. If you find a bug, please open an issue on github. In this case, please make sure to use a complete example (full data & command line) so your problem can be reproduced.
Update 2014-09-20 (after an issue was opened on github, thanks!):
The reason for 0 valued features "disappearing" (not really from the model, but only from the --invert_hash output) is that 1) --invert_hash was never designed for multiple passes, because keeping the original feature names in a hash-table, incurs a large performance overhead 2) The missing features are those with a zero value, which are discarded. The model itself should still have any feature with any prior pass non-zero weight in it. Fixing this inconsistency is too complex and costly for implementation reasons, and would go against the overriding motivation of making vw fast, especially for the most useful/common use-cases. Anyway, thanks for the report, I too learned something new from it.
I'm using ControllerMate with a Nostromo (Belkin) n52 (NOT the te version) Speedpad on an iMac running Snow Leopard.
The official SpeedPad configuration software doesn't run beyond Tiger, or at least, it doesn't run on Snow Leopard due to the kext failing to load properly, hence the attempt at using ControllerMate.
The official SpeedPad configuration software has the capability to load 1 unique set of keys per "page", where there are 4 pages. This ultimately led me to be able to do things like basic key mapping on the first page, key combinations on the second, macro'ing on the third, and I set up some global shortcuts for my music player, and bound those same shortcuts on the last page of the Speedpad.
Pages were represented by the currently lit LED on the unit;
No LEDs On / Red LED On / Green LED On / Blue LED On
I'm attempting to use the Logic functions of ControllerMate in order to recreate this same behavior. Clicking a button bound to this routine will cause the LEDs to start cycling in the order listed above, ultimately circling around and restarting at no LEDs on.
I'm going to explain this as best I can so that the basic principles of programming/logic here could feasibly be answered by any individual here, but I might fail, and you might need to familiarize yourself with ControllerMate first :P.
ControllerMate presents you with a grid, where you simply drag objects in. It's a visual programming canvas. For example, my Canvas has 4 blocks on it currently;
Nostromo SpeedPad 2
Keypad LeftAlt
This is the key that corresponds to the large Orange button above the DPad. It's on the Canvas so I can dump other elements into it, and get elements out of it.
It's a basic Input/Output system with snapping elements.
Num Lock
Caps Lock
Scroll Lock
These represent the LEDs. When these blocks turn "on", the related LED on the SpeedPad lights up.
For example, if I connect one Lock block, or all of them, directly to the LeftAlt block, pressing the "LeftAlt" button on the SpeedPad turns on one/all of the LED light(s) for the duration that it's held.
ControllerMate actually has a wonderful guide of explaining the "Blocks" and showing what they look like at http://www.orderedbytes.com/controllermate/help/?show=blocks
The Logic blocks I have to work with are as follows:
AND
NOT
OR
XOR
ON/OFF Gate
ON/OFF Latch
1:2 Selector
Toggle
Most of these are self explanatory already, but just in case they aren't, please consult the above link to get the specific Block Reference (My Rep. currently prevents me from linking each of the above elements).
I'm thinking that I'm going to have success with using a series of Toggles and Gates, but I haven't quite been able to interconnect them properly to consistently behave in a perfect loop of invocation.
Bonus Points if you're really feeling up to it (you'll get an accepted answer for satisfying only the primary question, promise!):
Not only a linear On/Off per LED, but a complete permutation of all On/Off combinations;
All Off
Red On Blue Off Green Off
Red On Blue On Green Off
Red On Blue Off Green On
Red On Blue On Green On
Red Off Blue On Green Off
etc.
[edit]
If anyone with suitable rep could create/add the "ControllerMate" tag to this question I'd sure appreciate it.
I figured it all out, it was quite a long time coming. Let's break it into a few different topics;
(1) Keybinding / Key Representation
(2) Blocks Used
(3) Logic
First, I set up a simple key remap, but that example failed because pressing the Speedpad 02 key, would input it's original mapping (q) and the re-map I defined (w). I started crawling over the ControllerMate Forums, and I stumbled on a
great couple of posts, which would make better starting points than the .cmate definition files that are easy to find, but I digress…
After ripping my hair out looking for a setting I had missed, program preferences, or what have you, I looked on the forums and came across a great thread. After reading it, I took the 30 second and disabled all the buttons for the "keyboard" palette portion and the "mouse" palette portion that didn't actually exist.
This means disabling all but the 15 numbered keys, plus the orange key, plus the dpad for the keyboard portion, and disabling all the mouse keys for the mouse portion. I'm going to send this new map file to Ken (the ControllerMate developer).
After doing this, and naming the keys something sane so they're properly represented as the key they're labeled, the remaps work as expected. Speedpad 02 only enter my remaped key of w, and nothing else!
This first step finally was finished.
Second and third, I sat down and figured out a creative solution to the LED task;
I'm using exactly zero of the logic blocks above. I use meta blocks (Key blocks, group blocks) and math.
When pressing the Orange thumb button, a "accumulator" block runs, from 0 to 3, stepping by 1 each push.
That accumulator has 3 outlets, each going to a subtraction block. The first subtraction block subtracts 1, the second subtracts 2, the third subtracts 3.
All of those subtractor blocks connect directly to a "Value Selector". If the value is zero, that particular selector turns on.
Thus, when I've pushed the orange button once, the accumulator provides a value of 1, which goes to all of the subtractors, but more specifically the one controlling the Red LED subtracts 1, and totals 0, so it's Value Selector enables, which enables the "Num Lock" (Red
LED) light.
The LED Outlets connect to a constant number value block (again, the -1 subtraction stack connection ultimately provides a constant value of 1, the -2 subtraction stack ends up at a constant value of 2, -3 goes to 3.
All three of these constant value blocks goes to a series of 4 Addition blocks, Red LED/Constant 1 has four outputs, to all four Addition blocks. Blue LED/Constant 2 has four outputs that go to all four Addition blocks, and Green LED/Constant 3 [...].
Then, a configuration page can be placed on the canvas, in which case I moved the "remap" page onto the canvas, and attached it to an addition->expect 0 value selector block, meaning that if the addition equals zero, that particular value selector is on. When all LEDs are
off, the top half constant value blocks are disabled, and don't provide their particular value.
Now, I just need to figure out what to bind to the other three modes I was so desperately working on.
Picture of the ControllerMate Canvas;
http://vxjasonxv.com/images/ControllerMateSC2.png