Re: [linux-audio-dev] Knobs / widget design + some OT stuff
At Sun, 27 Jun 2004 23:03:15 -0400, Pete Bessman wrote: > > That's a straw man. The original point was something to the effect > of "a volume knob which can only be operated after studying a manual > is an indication that the UI designer is a failure," although my > rendition is probably more caustic than the original. So it seems it wasn't clear that the above was a humorous jab, not meant to be taken seriously. My bad. My sense of humor must be "special." This *was* a debate about the performance requirements of Thorsten's fan sliders. I personally think that machines which can't deal with the sliders would be better off running trackers; high-end audio already comes with a high-end performance tag (relatively speaking), and if you can afford a 1Ghz/512MB system, you can afford a GPU. Really, you can: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&category=40160&item=5103986172&rd=1 The argument got "ugly" when Fons took a point of Thorsten's out of context (if you define "ugly" as the point at which I got pissed and started flinging argumentum ad hominem). "Requiring the user to read documentation to learn about functionality he would not even expect is not an option," is clearly wrong on a general level. Therefore, Fons is technically right; the only way such a requirement could exist is if the human desire for knowledge has dropped to a pathologically low level, either from lack of education (*snort*) or other causes. However, the point is clearly right as it applies to the fan sliders. A user with an IQ >= 100 shouldn't need to consult a manual to spin a knob or flip a switch, and if you think otherwise you should bar yourself from participating in UI discussions. Skewering a point on a literal and pedantic level is a sure-fire way to get labeled an elitist. Moral of the story: make a snide and barely on topic remark, get a face full of flame. -- Pete www.gazuga.net
Re: [linux-audio-dev] Traps in floating point code
On Mon, Jun 28, 2004 at 12:23:37 +0200, Maarten de Boer wrote:
> Hi Erik,
>
> Depending on the ranges of your increment, and the accuracy you
> want to obtain, you might consider doing this with integers only.
Yes, for this kind of accumulator thing I often use a hacked up
fixedpoint representation:
typedef union {
int32_t all;
struct {
uint16_t fr;
int16_t in;
} part;
} fixp16;
as you're only ever adding to them, you dont gain much by using floats,
getting the interger part out is really cheap and easy (foo.part.in) and
the fractional part is foo.part.fr / 2^16. Accumulation is done with
accum.all += delta.all. The 32.32 form should be obvious.
I think the struct components need to be the other way round for bigendian
machines though. I really must do something about making that work...
- Steve
Re: [linux-audio-dev] Traps in floating point code
Hi Erik,
Depending on the ranges of your increment, and the accuracy you
want to obtain, you might consider doing this with integers only.
Maarten
> The fix in this case was this:
>
> for (;;)
> {
> /* Bunch of other code. */
>
> fractional += increment ;
> rem = fmod (fractional, 1.0); /* floating point modulus */
> integer += lrint (round (fractional - rem));
> fractional = rem;
> }
[linux-audio-dev] Traps in floating point code
Hi all,
People who play around with floating point code (especially on x86)
quickly learn about the evils of comparing the equality of one floating
point value with another.
There are other related evils with floating point one of which I was
bitten by just recently and I thought I'd share it with y'all. If it
helps just one person from spending 20 odd hours chasing an elusive
bug like I did, I will have acheived something.
The evil I speak of is the difference between 32 and 64 bit floating
point representations (types float and double) and the x86 CPU's
internal 80 bit representation.
The most common trap is something like:
if (x == y)
do_something ();
where x and y are say double flotaing point numbers. Also lets just say
that the value of x is already in the CPU's FPU register as a result of
a previous operation and the other y, is not. What happens is that the
result of the previous operation can have a full 80 bits (part mantissa,
part exponent and a sign bit) of precision while y, loaded from memory
does not have this extra precision. The comparison therefore fails, even
though when printed out (or when compiler optimisation is switched off)
the two values are equal. This is the reason why the above if statement
is better written as:
if (fabs (x - y) < 1e-20)
do_something ();
The reason I am writing this email is that I was recently bitten by a
similar problem. I was keeping a running index into a table, and keeping
the integer part separate from the fractional part which was kept in a
double floating point:
double fractional = 0.0, increment = 0.1;
int integer = 0;
for (;;)
{
/* Bunch of other code. */
fractional += increment ;
integer += lrint (floor (fractional));
fractional -= floor (fractional);
}
The above code can produce very odd results for certain values of
increment. The problem in this case manifested itself in the
integer/fractional losing counts when compiled with gcc-3.4 while
the same code had worked perfectly with previous versions of the
compiler. The problem seems to be caused by the fact that the other
code in the loop was pushing at least some of the relevant values
out of the FPU stack into double floating point variables and that
when they were reloaded they had lost precision.
The fix in this case was this:
for (;;)
{
/* Bunch of other code. */
fractional += increment ;
rem = fmod (fractional, 1.0); /* floating point modulus */
integer += lrint (round (fractional - rem));
fractional = rem;
}
which is far more robust.
HTH,
Erik
--
+---+
Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid)
+---+
"The X-files is too optimistic. The truth is not out there."
-- Anthony Ord
Re: [linux-audio-dev] Knobs / widget design + some OT stuff
On Sun, Jun 27, 2004 at 11:03:15PM -0400, Pete Bessman wrote: > That's a straw man. The original point was something to the effect of > "a volume knob which can only be operated after studying a manual is > an indication that the UI designer is a failure," although my > rendition is probably more caustic than the original. That was *not* the original point. It was: 'requiring a user to read a manual to discover functionality he does not even suspect is not an option'. You introduced the volume knob, followed by some caustic language. -- FA
Re: [linux-audio-dev] Knobs / widget design + some OT stuff
On Mon, Jun 28, 2004 at 08:47:48AM +0200, Jens M Andreasen wrote: > Actually, in my house we speak latin only when we feel the urge to make > fun of people in badly need of a good argument. Out of house, of course, > we speak latin to make people feel stupid and stop argueing with us. I don't live in your house. -- FA
