[Sc-devel] Re: CheckBadValues

[Scott Wilson]

Fine by me.

S.

On 23 Jul 2007, at 17:42, James Harkins wrote:

> On 7/23/07, Scott Wilson <sdwilson at wesleyan.edu> wrote:
>> I'm still think that finer grained is most intuitive, least likely to
>> confuse, and generally useful, that lots of messages in the post
>> window is not a problem when debugging, and that as some people might
>> expect it now it wouldn't hurt in any case to keep the current
>> behaviour as the default.
>
> Hi Scott,
>
> What if I change the logic so that there are only three post modes?
>
> 0 = no post
> 1 = post a line for every bad value
> 2 = post a line whenever the fp classification changes
>
> Then, with post == 2, the only piece of information that is not
> available (but which is available with post == 1) is the number of
> consecutive values with a given classification. And it would be
> trivial to count the values and include that in the posted message.
>
> That way (with the count), post == 2 would be no less fine-grained
> than post == 1, only without the redundancy. And the interface is
> simpler for the user than yesterday's proposal.
>
> For instance, with post == 1 you might get something like this:
>
> Infinite number found in Synth 1000, ID: 0
> Infinite number found in Synth 1000, ID: 0
> Infinite number found in Synth 1000, ID: 0
> Infinite number found in Synth 1000, ID: 0
> Infinite number found in Synth 1000, ID: 0
> Infinite number found in Synth 1000, ID: 0
> Infinite number found in Synth 1000, ID: 0
> Infinite number found in Synth 1000, ID: 0
> Infinite number found in Synth 1000, ID: 0
> NaN found in Synth 1000, ID: 0
> NaN found in Synth 1000, ID: 0
> NaN found in Synth 1000, ID: 0
> NaN found in Synth 1000, ID: 0
>
> ... but with post == 2, you would get:
>
> Infinite number found in Synth 1000, ID: 0 (44100 previous samples  
> were normal)
> NaN found in Synth 1000, ID: 0 (9 previous samples were infinite)
> Normal number found in Synth 1000, ID: 0 (4 previous samples were NaN)
>
> I would argue that the latter contains more useful troubleshooting
> data per unit of output in the current behavior (and, there is nothing
> you can determine from the former output option that you can't
> determine from the latter). So, if anyone can come up with a scenario
> where the current output is better than what I'm proposing, I'm open
> to being convinced.
>
> Thanks for your comments, Scott. You helped refine my proposal into
> something that is a better balance between ease of use and clarity of
> output.
>
> hjh
>
> -- 
> James Harkins /// dewdrop world
> jamshark70 at dewdrop-world.net
> http://www.dewdrop-world.net
>
> "Come said the Muse,
> Sing me a song no poet has yet chanted,
> Sing me the universal."  -- Whitman
> _______________________________________________
> Sc-devel mailing list
> Sc-devel at create.ucsb.edu
> http://www.create.ucsb.edu/mailman/listinfo/sc-devel
>