On 6/8/2011 1:10, Invisible wrote:
> On 07/06/2011 07:34 PM, Darren New wrote:
>> On 6/7/2011 10:44, Orchid XP v8 wrote:
>>> And that's why when somebody says "one time I did <insert very unlikely
>>> thing here>", people tend not to believe it.
>>
>> So, you're saying I'm lying?
>
> I'm saying that if you casually claim to have solved a problem which has
> stumped AI researchers for decades, I'm going to be /slightly sceptical/
> about it. Which seems quite rational to me...

Recognising a tune has stumped researches for decades?

I didn't solve it. The guys who invented MP3 solved it. I just used it to 
build a bigger system, then watched it work.

What's unlikely about a computer figuring out the primary pitches of a 
recorded piece of music, comparing it to the primary pitches of other music, 
and deciding they're the same?  Is that more amazing than tineye?

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> On 07/06/2011 07:49 PM, Aydan wrote:
>
> > As for precision, try the following experiment:
> > 1. Sit in front of your computer and put your finger on a key.
> > 2. Close your eyes
> > 3. wave aroud wildly with your arms
> > 4. put the finger back on the key from step one.
> > 5. open your eyes
> > Did you hit the same key? I doubt it.
>
> News flash: Robots can't do this either.

They absolutely can. Have a look at industrial robots

> For example, a hard drive has a "servo track" recorded on one platter,
> so that the read/write heads can sense where they are, since the voice
> coils that steer the heads can't reliably return to the same location
> with the necessary precision.

That's not a robot

> This, even though those voice coils are controlled by a normal computer,
> which is capable of doing perfectly "precise" calculations.
>
> This has nothing to do with the precision of the calculations that the
> controller performs, be it a computer or a brain. It's just an inherent
> result of mechanical devices being imprecise.

You should not conclude the precision of all possible drive mechanisms from the
precision if a single one.
HDD head positioning is done gearless. This is inherently imprecise.
They did it like that to be fast, reliable (no worn gears), and they knew they
can get the feedbak they need for accuracy.
Industrial robots for example have geared drives and you can have them move from
one positio to another and back to the exact same position without needing
external calibration. This is because they use stepper motors and geared drives
with very little play for exact reproducability of positions.
You can have one of those move for hours and it won't drift.
And it doesn't get feedback if it's still on track either.

> > If you can do that than that's what I'd call precice.
> > Moving your finger a few centimeters without watching and hitting a key that is
> > more than a finger wide is not precise.
>
> You don't play a musical instrument, do you?

No, but in this case it doesn't matter.

> Let me tell you, the black keys are *narrower* than a human finger. And
> if you're not careful, your fingers slip off the side. Doesn't sound
> very nice...

That may be, but does it really matter if you are a  millimeter off?
And let's say you move your hand about 10 cm and can hit a key within a
millimeter. Sounds realistic? That's still only 1% accuracy.
Your printer head for example can do much better. It can position to a fraction
of a millimeter over 20cm. Multiple times. Without recalibrating.
CNC machines can position to less than a tenth of a millimeter over several
meters. They don't get feedback either. They calibrate onec before starting a
process and run through the process without the need to recalibrate.

> Anyway, if that fails to convince you, try throwing a ball through a
> hoop. By the time you get any feedback about whether you hit or not,
> it's far too late to do anything about it; you've already let go of the
> ball! And yet, many people manage to throw precisely enough to do this
> reliably.

Precisely enough? Right.

Even the absolute pros won't be able to hit the hoop all the time exactly in the
center without touching the rim.
Sinking the ball has a much higher probability, because , up to a point it
doesn't matter if you hit the rim, it will still go in.
A basketball has a diameter of about 24cm the hoop has a diameter of about 45cm.
That makes 10 cm of error margin right there.
Let's say you need to hit the hoop within a radius of 15cm from a distance of
say 5 meters.
That's a whopping 3% of accuracy.
Even if you go out to 15m distance youl only be at 1% accuracy.
Not what I'd call accurate in robot terms.
Program a robot to throw the ball and you'll get better precision once you have
it calibrated properly.
That's the big difference: A human can quite confidently throw a ballinto a hoop
from a multitude of positions without much "setup" time.
But once a robot is calibrated to it's position it can hit the target forever.
The human usually can't.

> Similar story for anyone who plays darts, snooker, tennis, ...

OK, next time you are in a Pub with a darts board, have a look at the
"professionals" and how often they actually hit the triple 20 if they want to.

Post a reply to this message

Le 08/06/2011 20:29, Aydan nous fit lire :
>> > News flash: Robots can't do this either.
> They absolutely can. Have a look at industrial robots
> 

Well, in fact, industrial robots have sequences of fixed positions on
end of run for each axis (be it a translation or rotation) to regularly
reassign the reading of their sensors. Usually perform at start-up and
during the production cycle.

(kind of: push motor to maximum right (against physical stop), store
sensor value. push motor to maximum left... store value. Update sensor's
dataset (for interpolating curve of sensor))
For advanced systems, the physical stop can be replaced by video capture
with pattern matching.

Even the coding wheels (alternative binary on strips with different
frequencies) can only be assumed to have an accurate relative value.

And if you know a bit about using a graduated wheel connected to a
screw, you know that you must always measure by moving from the same
direction, as the screw does not fit the bold exactly in both directions.

Post a reply to this message

On 07/06/2011 04:57 PM, Aydan wrote:

> You're not matching the waveform but the spectrum.

And computing the "spectrum" of a time-varying signal is still an open 
research problem.

Post a reply to this message

>> News flash: Robots can't do this either.
>
> They absolutely can. Have a look at industrial robots

We have several robots in our lab. Every single one of them has sensors 
to detect where the various moving parts are. Every single one runs a 
calibration routine of varying degrees of slowness when you turn it on 
and/or reset it.

>> For example, a hard drive has
>
> That's not a robot

Yes it is. So is a washing machine, or a printer, or any other 
electromechanical device of similar complexity.

> You should not conclude the precision of all possible drive mechanisms from the
> precision if a single one.

My point still stands: The fact that a given mechanism isn't very 
precise doesn't mean that the thing controlling it is inherently imprecise.

Post a reply to this message

> What's unlikely about a computer figuring out the primary pitches of a
> recorded piece of music, comparing it to the primary pitches of other
> music, and deciding they're the same?

Here's one for you: Given a recording of a single pure tone, can you 
determine what pitch that is?

Unfortunately, nobody has yet found a way to do this reliably. I've yet 
to find a guitar tuner that can perform this apparently trivial task.

Now, you're telling me that you have something that can take a 
/non-stationary/ wave containing an arbitrarily complex mixture of tones 
that vary over time and actually deduce something meaningful from it?

Further, you're telling me that it can actually do this with such 
reliability that it can even recognise completely different renditions 
of the same piece of music, without false-positives or false-negatives?

That would be a pretty insane result if it were true.

> Is that more amazing than tineye?

I don't know. Does tineye actually /work/?

More to the point, if I draw a rendition of The Wet Bird in pencil, 
would tineye recognise it as the same image? /That/ would be a problem 
of comparable difficulty. I don't doubt that you can probably determine 
whether two slightly different versions of the same image match, or 
whether two slightly different versions of the same sound recording 
match. But completely different versions? That would require some insane AI.

Post a reply to this message

On 6/9/2011 1:12, Invisible wrote:
> On 07/06/2011 04:57 PM, Aydan wrote:
>
>> You're not matching the waveform but the spectrum.
>
> And computing the "spectrum" of a time-varying signal is still an open
> research problem.

Apparently not.

http://en.wikipedia.org/wiki/Spectrogram

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 6/9/2011 1:34, Invisible wrote:
> Now, you're telling me that you have something that can take a
> /non-stationary/ wave containing an arbitrarily complex mixture of tones
> that vary over time and actually deduce something meaningful from it?

You mean, like Verizon VCast Song ID?
Music Brainz Picard?
Shazam (http://www.shazam.com/)

> Further, you're telling me that it can actually do this with such
> reliability that it can even recognise completely different renditions of
> the same piece of music, without false-positives or false-negatives?

No, I didn't say that.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 08/06/2011 20:29, Aydan nous fit lire :
> >> > News flash: Robots can't do this either.
> > They absolutely can. Have a look at industrial robots
> >
>
> Well, in fact, industrial robots have sequences of fixed positions on
> end of run for each axis (be it a translation or rotation) to regularly
> reassign the reading of their sensors. Usually perform at start-up and
> during the production cycle.
>
> (kind of: push motor to maximum right (against physical stop), store
> sensor value. push motor to maximum left... store value. Update sensor's
> dataset (for interpolating curve of sensor))
> For advanced systems, the physical stop can be replaced by video capture
> with pattern matching.
>
> Even the coding wheels (alternative binary on strips with different
> frequencies) can only be assumed to have an accurate relative value.
>
> And if you know a bit about using a graduated wheel connected to a
> screw, you know that you must always measure by moving from the same
> direction, as the screw does not fit the bold exactly in both directions.

AKAIK industrial robots use stepper motors and not positional sensors or coding
wheels. The step size of the motor is known as is the play on the gearing. Which
by the way can be mechanically minimized by having a springloaded secondary gear
which presses the primary gear against the driving gear to minimize play.
So you know the positioning accuracy from that.
As long as the motor doesn't miss a step, which is ensured by using acceleration
curves and such so you limit the momentum of the motor, you can move without
recalibration for a long time.
CNC mills for example can take several hours to machine a piece and AFAIK they
don't recalibrate inbetwen.
Recalibration is usually only done when the robot/CNC machine starts working or
if an error occured, because it takes time and time is money. Recalibration is
also not done by moving against a mechanical stop. It's done by moving to a
reference position with a special sensor, usually a light barrier.

Post a reply to this message

On 6/6/2011 12:40 PM, Orchid XP v8 wrote:
>
> It's quite clear that the design motivation behind this was not chip
> space but OS support. Compared to the space taken up by huge caches, a
> piffling 7 registers is nothing...
>

Actually, this is exactly why the aliased the floating point registers 
in MMX. Otherwise, without the OS supporting the new registers, all hell 
would break loose when the OS handled an ISR, because it was not aware 
of the new registers and didn't properly preserve their values. 
(Remember, interrupts only store the flags and the instruction pointer 
before being serviced. It's the job of the ISR to preserve any other 
registers.)

But how could that be? If the OS isn't aware, then it wouldn't alter 
them, so they'll be fine. Except the OS does things like dispatch to a 
game's input handler when a keypress comes in, and causes the screen to 
redraw, which uses SIMD instructions to repaint the screen. Corrupting 
the very same registers another program was using to perform some sort 
of signal analysis in the background. Oops.

-- 
~Mike

Post a reply to this message