(archive)MISFIT

[flashjh]

So, why <option value="9"> and not <option value="5">?

[chalsall]

Originally Posted by flashjh

So, why <option value="9"> and not <option value="5">?

#5 was already in use on the DCTF form for "No P-1 done".

And since HTML options don't have to be linear and I wanted the same number to mean the same thing for both LLTF and DCTF, I figured #9 allowed me room for future expansion.

[swl551]

Originally Posted by chalsall

#5 was already in use on the DCTF form for "No P-1 done".

And since HTML options don't have to be linear and I wanted the same number to mean the same thing for both LLTF and DCTF, I figured #9 allowed me room for future expansion.

I already wrote code to deal with the non-linear mapping so changing it now would be a $750.00 rework fee.

[swl551]

Just gotta get out of Boston before the next freaking snow storm ****tomorrow**** and get back to my development PC.

[flashjh]

Originally Posted by chalsall

#5 was already in use on the DCTF form for "No P-1 done".

And since HTML options don't have to be linear and I wanted the same number to mean the same thing for both LLTF and DCTF, I figured #9 allowed me room for future expansion.

I was mostly poking fun, but that certianly makes sense

[swl551]

Originally Posted by chalsall

#5 was already in use on the DCTF form for "No P-1 done".

And since HTML options don't have to be linear and I wanted the same number to mean the same thing for both LLTF and DCTF, I figured #9 allowed me room for future expansion.

How do I confirm my test fetch actually executed a #9 fetch? (beyond seeing the outbound POST data)

[chalsall]

Originally Posted by swl551

How do I confirm my test fetch actually executed a #9 fetch? (beyond seeing the outbound POST data)

+---------------------+-------------------------------------------------------------------------------------------------------------+
| Noted               | Note                                                                                                        |
+---------------------+-------------------------------------------------------------------------------------------------------------+
| 2013-02-23 21:02:55 | LF(9) -- N:    5 G:   25 P: 74 L:      5000 H:    888888 -- n:  100 p: 73 l:  57000000 h:  65000000 -- A: 2 | 
| 2013-02-23 21:27:32 | LF(9) -- N:    5 G:    5 P: 68 L:         0 H: 100000000 -- n:  100 p: 71 l:         0 h: 100000000 -- A: 2 | 
| 2013-02-23 21:35:53 | LF(9) -- N:    5 G:    0 P: 73 L:         0 H: 100000000 -- n:    5 p: 73 l:  57000000 h:  65000000 -- A: 5 | 
| 2013-02-23 21:27:51 | LF(9) -- N:    5 G:    0 P: 68 L:         0 H: 100000000 -- n:    5 p: 71 l:         0 h: 100000000 -- A: 5 | 
+---------------------+-------------------------------------------------------------------------------------------------------------+

Values submitted by the client with the POST request: LF (LLTF), (Option), N: Number, G: GHzDays, P: Pledge, L: Low, H: High.
Values passed into the SQL (after possible alternation): n: Number, l: Low, h: High.
Results: A: Number of candidates actually assigned.

Please note that (as you can see from the data) I have implemented option #9 to not increase the Pledge past what is passed, with the exception that any pledge below 71 is always increased to 71. Also, the "Noted" field is in UTC.

[swl551]

Originally Posted by chalsall

+---------------------+-------------------------------------------------------------------------------------------------------------+
| Noted               | Note                                                                                                        |
+---------------------+-------------------------------------------------------------------------------------------------------------+
| 2013-02-23 21:02:55 | LF(9) -- N:    5 G:   25 P: 74 L:      5000 H:    888888 -- n:  100 p: 73 l:  57000000 h:  65000000 -- A: 2 | 
| 2013-02-23 21:27:32 | LF(9) -- N:    5 G:    5 P: 68 L:         0 H: 100000000 -- n:  100 p: 71 l:         0 h: 100000000 -- A: 2 | 
| 2013-02-23 21:35:53 | LF(9) -- N:    5 G:    0 P: 73 L:         0 H: 100000000 -- n:    5 p: 73 l:  57000000 h:  65000000 -- A: 5 | 
| 2013-02-23 21:27:51 | LF(9) -- N:    5 G:    0 P: 68 L:         0 H: 100000000 -- n:    5 p: 71 l:         0 h: 100000000 -- A: 5 | 
+---------------------+-------------------------------------------------------------------------------------------------------------+

Values submitted by the client with the POST request: LF (LLTF), (Option), N: Number, G: GHzDays, P: Pledge, L: Low, H: High.
Values passed into the SQL (after possible alternation): n: Number, l: Low, h: High.
Results: A: Number of candidates actually assigned.

Please note that (as you can see from the data) I have implemented option #9 to not increase the Pledge past what is passed, with the exception that any pledge below 71 is always increased to 71. Also, the "Noted" field is in UTC.

[per my interpretation] I had ghosted pledge when #9 option is selected. I just now un-ghosted that form value (based on statement above) and submitted a #9 option with pledge 74 and got back

Factor=2013-2-23,62029573,72,73

[per my interpretation] #9 was supposed to dole out what is needed most and not pay attention to pledge, low and high (reason they are ghosted on the MISFIT form). Only count or GhzDays were to be honored ensuring enough assignments were send back.

I really do want GPU72 to decide what is needed most this current implementation is somewhere in the middle and not what I expected.

Scott

[chalsall]

Originally Posted by swl551

I really do want GPU72 to decide what is needed most this current implementation is somewhere in the middle and not what I expected.

Please see my post #513, paragraph #4 above.

The pledge field is honored in so far as GPU72 will decide what it wants to do up to that pledge level, but no further. This is to allow MISFIT users to say they're willing to go to 74, but if only 73 is sustainable at the moment (as it is currently), that's what will be assigned.

Conversely, if a MISFIT user is only willing to go to 73 (or 72, or 71) when (if) 74 is WMS, they will only be assigned work to 73 (or 72, or 71).

[Dubslow]

Originally Posted by chalsall

The pledge field is honored in so far as GPU72 will decide what it wants to do up to that pledge level, but no further. This is to allow MISFIT users to say they're willing to go to 74, but if only 73 is sustainable at the moment (as it is currently), that's what will be assigned.

Conversely, if a MISFIT user is only willing to go to 73 (or 72, or 71) when (if) 74 is WMS, they will only be assigned work to 73 (or 72, or 71).

Shouldn't that be what WMS does? #9 I thought was going to be GPU272 decides everything. Edit: Or, if a user has any restrictions at all, then they shouldn't be using "Let GPU272 decide".

[chalsall]

Originally Posted by Dubslow

Shouldn't that be what WMS does? #9 I thought was going to be GPU272 decides everything. Edit: Or, if a user has any restrictions at all, then they shouldn't be using "Let GPU272 decide".

A reasonable argument.

I'm happy to implement whatever is decided by consensus.