How slow is converting between floating-point representation and integer 
representation?

I'm seeing a very large performance hit when I do this, and I'm trying 
to figure out whether this is just one of the performance 
characteristics of a typical CPU, or a software bug.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> How slow is converting between floating-point representation and integer
> representation?
> 
> I'm seeing a very large performance hit when I do this, and I'm trying
> to figure out whether this is just one of the performance
> characteristics of a typical CPU, or a software bug.


Which language? Any example of the code that shows what you are actually
doing?


-- 
Severi Salminen
http://www.iki.fi/severi

Post a reply to this message

Severi Salminen wrote:

> Which language? Any example of the code that shows what you are actually
> doing?

If I add up a few thousand 32-bit signed integers, it takes 20 seconds.

If I use double-precision floating-point, it takes 43 seconds.

If I use double-precision, and then convert each number to an integer, 
and then add it to the total, it takes 6 minutes.

I'm wondering whether the hardware is actually that slow, or whether 
this is a performance bug in Haskell's number libraries.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> If I add up a few thousand 32-bit signed integers, it takes 20 seconds.

  What are you using? A 8086? In fact, I think even a 8086 could sum
a lot more than a few thousands of integers in 20 seconds.

  Out of curiosity, I tried a small test program in my computer which
creates an array of integers, then goes through it and calculates the
sum of all the integers. I had to use an array of 100 million integers
before I got even some measurable delay, and that was 0.7 seconds.

  I bet most of the time was caused by cache misses because of the
humongous array (taking 400 megabytes of memory) rather than the summing
process.

> If I use double-precision, and then convert each number to an integer, 
> and then add it to the total, it takes 6 minutes.

> I'm wondering whether the hardware is actually that slow, or whether 
> this is a performance bug in Haskell's number libraries.

  I think there's something else fundamentally wrong with the system you
are using than summing integers or converting between floats and ints.

-- 
                                                          - Warp

Post a reply to this message

Orchid XP v8 wrote:
> Severi Salminen wrote:
> 
>> Which language? Any example of the code that shows what you are actually
>> doing?
> 
> If I add up a few thousand 32-bit signed integers, it takes 20 seconds.
> 
> If I use double-precision floating-point, it takes 43 seconds.
> 
> If I use double-precision, and then convert each number to an integer,
> and then add it to the total, it takes 6 minutes.
> 
> I'm wondering whether the hardware is actually that slow, or whether
> this is a performance bug in Haskell's number libraries.

I tried adding up 1e10 (10 billion, using Finnish  meaning of "billion"
:) floats to a float variable (in 2 nested for loops). It took around
10s. Adding up 1e10 floats to an int variable took 30s. So the
conversion took some time. I tried with C++ with no optimizations at all.

But I agree with Warp. Adding up few thousand integers should definitely
not take 20s.

-- 
Severi Salminen
http://www.iki.fi/severi

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:49987420@news.povray.org...
> Orchid XP v8 <voi### [at] devnull> wrote:

> > I'm wondering whether the hardware is actually that slow, or whether
> > this is a performance bug in Haskell's number libraries.

>   I think there's something else fundamentally wrong with the system you
> are using

Fundamentally wrong? Of course. He already mentioned Haskell, didn't he?

Post a reply to this message

>> If I add up a few thousand 32-bit signed integers, it takes 20 seconds.
> 
>   What are you using? A 8086? In fact, I think even a 8086 could sum
> a lot more than a few thousands of integers in 20 seconds.

You understand that when I said "a few thousand", I just meant "a lot", 
right? I wasn't being rigorous about the number.

Actually the number I'm using is 10^8, which is... er, let me see... 100 
million?

>   Out of curiosity, I tried a small test program in my computer which
> creates an array of integers, then goes through it and calculates the
> sum of all the integers. I had to use an array of 100 million integers
> before I got even some measurable delay, and that was 0.7 seconds.
> 
>   I bet most of the time was caused by cache misses because of the
> humongous array (taking 400 megabytes of memory) rather than the summing
> process.

Uhuh. And are you by any chance running this on an AMD Mobile AlthonXP 
1400+?

>> If I use double-precision, and then convert each number to an integer, 
>> and then add it to the total, it takes 6 minutes.
> 
>> I'm wondering whether the hardware is actually that slow, or whether 
>> this is a performance bug in Haskell's number libraries.
> 
>   I think there's something else fundamentally wrong with the system you
> are using than summing integers or converting between floats and ints.

I hacked into the numeric library and called the low-level C primop 
directly, and runtime dropped to 68 seconds, rather than 6 minutes. I 
believe this clearly demonstrates that there is something Very Wrong 
with the default numeric implementation...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> >> If I add up a few thousand 32-bit signed integers, it takes 20 seconds.
> > 
> >   What are you using? A 8086? In fact, I think even a 8086 could sum
> > a lot more than a few thousands of integers in 20 seconds.

> You understand that when I said "a few thousand", I just meant "a lot", 
> right? I wasn't being rigorous about the number.

> Actually the number I'm using is 10^8, which is... er, let me see... 100 
> million?

  20 seconds to add up 100 million integers is still quite a lot.

  I find it ironic that you constantly comment on the "unfounded" prejudices
relating to the speed of Haskell in the other group, yet time after time you
demonstrate in practice how Haskell is orders of magnitude slower than a
simple C++ program. This isn't the first time that I remember.

> >   Out of curiosity, I tried a small test program in my computer which
> > creates an array of integers, then goes through it and calculates the
> > sum of all the integers. I had to use an array of 100 million integers
> > before I got even some measurable delay, and that was 0.7 seconds.
> > 
> >   I bet most of the time was caused by cache misses because of the
> > humongous array (taking 400 megabytes of memory) rather than the summing
> > process.

> Uhuh. And are you by any chance running this on an AMD Mobile AlthonXP 
> 1400+?

  I have hard time believing my computer is 30 times faster than that.
Twice or three times as fast I could still maybe swallow, but not 30 times.
(Athlons are rather notorious for being much faster than the Pentium4 line
with the same clockrates.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   I find it ironic that you constantly comment on the "unfounded" prejudices
> relating to the speed of Haskell in the other group, yet time after time you
> demonstrate in practice how Haskell is orders of magnitude slower than a
> simple C++ program. This isn't the first time that I remember.

Well, you look at Haskell and how it's used, and it "looks" like it 
should be insanely slow. (E.g., recursion is used everywhere.) It's easy 
to think it has no performance at all.

And yet, when you look at things like the Great Language Shootout, 
Haskell beats several supposedly "superior" languages. Last time I 
checked, it's near the very top of the main scoreboard.

>   I have hard time believing my computer is 30 times faster than that.
> Twice or three times as fast I could still maybe swallow, but not 30 times.
> (Athlons are rather notorious for being much faster than the Pentium4 line
> with the same clockrates.)

OK, well I just wrote a small C program to do the same thing... and it 
segfaulted at me.

So then I looked up the printf() manpage to find out what the correct 
magic code is, and tried again... 0.8 seconds to do the integer sum.

Based in this information, I conceed defeat. I have no idea what's gone 
wrong here.



PS. I just changed the Haskell program. It now takes 0.5 seconds - which 
is even faster than C. But I still have no idea why the first version 
wasn't this fast, so that's not much comfort.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:

> PS. I just changed the Haskell program. It now takes 0.5 seconds - which 
> is even faster than C. But I still have no idea why the first version 
> wasn't this fast, so that's not much comfort.

So maybe it's because I'm using this version of the compiler that I 
built myself, and it's broken in some way?

Er, no. Just tried it with the release version. The numbers are a 
fraction of a second slower still. Either way, two equivilent 
formulations of the program have wildly different runtimes.

Interestingly, on my much more powerful desktop PC [with yet another 
version of the compiler], the "slow" version only takes 2 seconds. But 
the "fast" version is too quick to time, so something is still wrong.

Ah, the bitter taste of utter defeat.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> OK, well I just wrote a small C program to do the same thing... and it 
> segfaulted at me.

  I give up. For some reason trying to teach you something seems
completely pointless.

-- 
                                                          - Warp

Post a reply to this message

Orchid XP v8 wrote:
> Based in this information, I conceed defeat. I have no idea what's gone 
> wrong here.

I was going to suggest earlier "maybe he's evaluating the stuff lazily and 
doesn't realize it", but then I deleted it half-written thinking "surely I'm 
not going to guess better than Andrew what his Haskell code is doing." :-)

-- 
   Darren New, San Diego CA, USA (PST)
   "Ouch ouch ouch!"
   "What's wrong? Noodles too hot?"
   "No, I have Chopstick Tunnel Syndrome."

Post a reply to this message

Warp wrote:
>   I give up. For some reason trying to teach you something seems
> completely pointless.

Now now. He *did* say he got it working. :-)  And you must admit, printf() 
isn't the most intuitive way of printing something.

-- 
   Darren New, San Diego CA, USA (PST)
   "Ouch ouch ouch!"
   "What's wrong? Noodles too hot?"
   "No, I have Chopstick Tunnel Syndrome."

Post a reply to this message

> Er, no. Just tried it with the release version. The numbers are a fraction 
> of a second slower still. Either way, two equivilent formulations of the 
> program have wildly different runtimes.

What's the difference between them?

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

>>   I give up. For some reason trying to teach you something seems
>> completely pointless.
> 
> Now now. He *did* say he got it working. :-)  And you must admit, 
> printf() isn't the most intuitive way of printing something.

No, it seems Warp is right.

I have conclusively demonstrated that Haskell is many orders of 
magnitude slower than C even for a trivial program.

After all these years of using Haskell, I thought I understood how it 
worked. I read all the papers about all the sophisticated optimisations 
the compiler performs. And I felt sure I knew what I was doing. But, 
clearly, I don't.

I have wasted 4 years of my life on Haskell. It is so beautiful and 
eligant, I wanted it to be the answer, and I blindly believed that it 
would be. Clearly it isn't.

The irony, the sheer irony of it, is that the whole reason I was timing 
this stuff in the first place was that I was just about to reach into 
the source code of the compiler to try to tweak its performance. It is 
obvious to me now that I shouldn't be let anywhere near an actual 
compiler. Better to leave that to the real experts.

It seems I've been deluding myself. All these years, I thought I was 
some kind of master programmer. What, just because I've been writing 
programs for 20 years, that makes me an expert? Just because I wrote 
some trivial raytracer and it kinda worked, that means I'm good at 
programming? Who the hell am I kidding?

I am now the laughing stock of this forum. Nobody is ever doing to take 
anything I say about Haskell seriously ever again. Even better, when I 
asked about this in the Haskell forum, I got yelled at for being a 
troll. (Again.)

So, not only do I fail at programming, I fail at human interaction. It 
seems everywhere I do, people yell at me for being immature and 
outspoken. Maybe I should just take myself away somewhere and figure out 
WTF is *wrong* with me. I fail at life.

I'm sorry.

Post a reply to this message

On 2/16/2009 1:54 AM, Invisible wrote:
>>>  I give up. For some reason trying to teach you something seems
>>> completely pointless.
>>
>> Now now. He *did* say he got it working. :-) And you must admit,
>> printf() isn't the most intuitive way of printing something.
>
> No, it seems Warp is right.

Nah, he's just fed up.  That happens with people, but we love him[1] anyway!

> I have conclusively demonstrated that Haskell is many orders of
> magnitude slower than C even for a trivial program.

No, you haven't.  What you *have* demonstrated is that your particular 
program runs slower than an alternative implementation in a completely 
different environment.

I can't say what the slowdown is, or why it's occurring, unless I saw 
your actual Haskell code.  Most likely there's a very good reason for 
the performance hit.

> I have wasted 4 years of my life on Haskell. It is so beautiful and
> eligant, I wanted it to be the answer, and I blindly believed that it
> would be. Clearly it isn't.

"When you're a hammer, the whole world looks like a nail."

The fact is that Haskell, like every other language out there, is a tool 
- a tool that helps you get things done.  It doesn't do the same things 
C does, or do things the same way, because it *isn't* C.  It's good at 
(and for) different things[2].

Sometimes, you need C.  Sometimes you need Haskell.  Spending your time 
learning it and using it doesn't mean you've wasted your time.

Stephen R Donaldson is fond of quoting, "When you become a master of one 
thing, you become a master of all things."  This isn't to say that by 
learning Haskell you're a master programmer in any language; but the act 
of mastering something so complex teaches you how to master anything you 
set yourself to.

Never count the mastery of a skill as a waste, even if it's a skill you 
never end up using.

> The irony, the sheer irony of it, is that the whole reason I was timing
> this stuff in the first place was that I was just about to reach into
> the source code of the compiler to try to tweak its performance. It is

Actually, that's a great idea.  There's no better way to learn than by 
doing.

> obvious to me now that I shouldn't be let anywhere near an actual
> compiler. Better to leave that to the real experts.

Do you know what an "expert" really is?  An "ex" is a has-been, and a 
"spert" is a drip under pressure!

Anyway, how do you think the "experts" got to be that way?  By doing 
exactly what you're doing right now!

> It seems I've been deluding myself. All these years, I thought I was
> some kind of master programmer.

Well, you might have been deluding yourself in that, yes.  But there's 
nothing wrong with aspirations :)

> I am now the laughing stock of this forum.

No, you're not.  You're our friend and, yes, sometimes we laugh at you - 
but we laugh at pretty much everyone.  As Scott Adams says, "Everyone is 
an idiot at something."  That means that everyone gets to be laughed at 
:)  Take it in stride, and join in the laughter yourself - you might 
find it cathartic.

> seems everywhere I do, people yell at me for being immature and

They yell at you for being immature?  Doesn't that make them... immature?

> I fail at life.

Not yet, you haven't.  Everyone has minor stumbling blocks, but they 
really are minor.

Besides, if you're talking about failing at something you love, then 
you're in good company.  Do you know why Henry Ford's first automobile 
company was dissolved?  It was because the car they made was lower 
quality and higher price than he liked.  In other words, it was a 
question of optimization ;)

Anyway, it's late here, & I should get some sleep.

[1]See the thread titled "you & me right now, warp"

[2]If Haskell can be embedded, I'm thinking it would make a great patch 
for POV-Ray.  Something like this:

#declare h_func = haskell { "..." }

#declare val = h_func(1,2,3)

Anywhere POV takes functions, it could use a Haskell function.

-- 
...Chambers
www.pacificwebguy.com

Post a reply to this message

On Mon, 16 Feb 2009 09:54:56 +0000, Invisible <voi### [at] devnull> wrote:

>I have conclusively demonstrated that Haskell is many orders of 
>magnitude slower than C even for a trivial program.

But what about non trivial problems?

I'm sure that Haskell was not developed for adding lots of numbers. (Not
counting the fact that is what all computers do ;) ) What does it do well, why
not try checking it against C++ with something it is designed for?

As for wasting you time, if you enjoyed yourself the time was not wasted.
Remember the old saying. Don't get depressed, get even.
-- 

Regards
     Stephen

Post a reply to this message

Warp wrote:

>> Uhuh. And are you by any chance running this on an AMD Mobile AlthonXP 
>> 1400+?
> 
>   I have hard time believing my computer is 30 times faster than that.
> Twice or three times as fast I could still maybe swallow, but not 30 times.
> (Athlons are rather notorious for being much faster than the Pentium4 line
> with the same clockrates.)
> 

P4 Core2 Duo here,

1 billion iterations, C#

1000000000 Int Sum Time: 00:00:02.2499280
1000000000 Double Sum Time: 00:00:03.3905165
1000000000,1000000000 Double Convert Time: 00:00:03.7655045

^^ Interestingly the float to int conversion uses an MMX instruction. 
Apparently it is very costly to do it without MMX, the CLR JIT uses the 
MMX instruction regardless, so I have no comparison for the non-MMX 
instruction. But, the difference is negligible between floating point 
operations and integer.

-- 
~Mike

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> >>   I give up. For some reason trying to teach you something seems
> >> completely pointless.
> > 
> > Now now. He *did* say he got it working. :-)  And you must admit, 
> > printf() isn't the most intuitive way of printing something.

> No, it seems Warp is right.

> I have conclusively demonstrated that Haskell is many orders of 
> magnitude slower than C even for a trivial program.

  I was not talking about Haskell vs. the world in my comment quoted
above. I was talking about you trying to do it in *C* and having your
program crash, after all the trouble I have gone in the past to try to
teach you safe programming practices in C++, as a better alternative to C.

  I got exasperated because I thought that maybe, just maybe you had
learned something about the C/C++ family of languages, and perhaps learned
to make working programs in C++ with less effort (than in C, that is).
But no. When you want to try something with something else than Haskell,
you go once again back to C and have your program crash on you. It feels
like all my teaching efforts went completely to waste.

-- 
                                                          - Warp

Post a reply to this message

Slime wrote:
>> Er, no. Just tried it with the release version. The numbers are a fraction 
>> of a second slower still. Either way, two equivilent formulations of the 
>> program have wildly different runtimes.
> 
> What's the difference between them?

One relies on automatic list fusion, the other is hand-fused. It turns 
out GHC doesn't automatically fuse left folds. Since the entire program 
is a left fold, I guess that'll be the problem then...

If my assumption that all list operations do get fused had been correct, 
the two programs *would* be almost completely equivilent. (One with more 
overloading than the other, possibly contributing to a few percent 
overhead.)

This is what happens when you *assume* you know what you're talking 
about; you get caught out.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 15-2-2009 21:15, Orchid XP v8 wrote:
>>> If I add up a few thousand 32-bit signed integers, it takes 20 seconds.
>>
>>   What are you using? A 8086? In fact, I think even a 8086 could sum
>> a lot more than a few thousands of integers in 20 seconds.
> 
> You understand that when I said "a few thousand", I just meant "a lot", 
> right? I wasn't being rigorous about the number.
> 
> Actually the number I'm using is 10^8, which is... er, let me see... 100 
> million?

note to self: never lend money to that guy.

Post a reply to this message

Invisible wrote:
> I am now the laughing stock of this forum. Nobody is ever doing to take 
> anything I say about Haskell seriously ever again. Even better, when I 
> asked about this in the Haskell forum, I got yelled at for being a 
> troll. (Again.)

Last night, I wrote a carefully worded reply to the Haskell mailing 
list. As of now, the moderators still haven't released the message yet. 
So to everybody on the list, it looks like I posted a bunch of 
misinformation, got called on it, and just didn't bother to reply. Yay 
for me. :-(

Post a reply to this message

Chambers wrote:

> I can't say what the slowdown is, or why it's occurring, unless I saw 
> your actual Haskell code.  Most likely there's a very good reason for 
> the performance hit.

"GHC currently does not fuse left folds."

Since my entire program was a simple left fold, that'll be the problem. 
(This also explains why the hand-fused version runs much faster - 
although I'm still not sure how it manages to be *faster* than C...)

>> The irony, the sheer irony of it, is that the whole reason I was timing
>> this stuff in the first place was that I was just about to reach into
>> the source code of the compiler to try to tweak its performance. It is
> 
> Actually, that's a great idea.  There's no better way to learn than by 
> doing.

Sure. Like anybody is going to accept a compiler modification from a 
"troll". Like any of the compiler developers are going to be eager to 
help one out. Indeed, the person who yelled at me was the very guy I 
wanted to ask for help from; he's the one who reported the issue I was 
looking at fixing.

>> obvious to me now that I shouldn't be let anywhere near an actual
>> compiler. Better to leave that to the real experts.
> 
> Do you know what an "expert" really is?  An "ex" is a has-been, and a 
> "spert" is a drip under pressure!
> 
> Anyway, how do you think the "experts" got to be that way?  By doing 
> exactly what you're doing right now!

Well, we're talking about people such as the legendary Simon Peyton 
Jones, one of the original PhDs who *invented* Haskell. People who know 
what "denotional semantics" actually means, and what "the lambda cube" 
is. They didn't get to where they are by blindly poking around somebody 
else's source code. They did it by spending decades in research and 
development on programming language design, compiler architecturing, 
applied mathematics, and things I'd never understand in my wildest dreams.

>> It seems I've been deluding myself. All these years, I thought I was
>> some kind of master programmer.
> 
> Well, you might have been deluding yourself in that, yes.  But there's 
> nothing wrong with aspirations :)

There's nothing wrong with *wanting* to become a master. There's 
everything wrong with believing you *are* a master in the complete 
absence of any evidence for this.

>> I am now the laughing stock of this forum.
> 
> No, you're not.  You're our friend and, yes, sometimes we laugh at you - 
> but we laugh at pretty much everyone.  As Scott Adams says, "Everyone is 
> an idiot at something."  That means that everyone gets to be laughed at 
> :)  Take it in stride, and join in the laughter yourself - you might 
> find it cathartic.

Well, let me put it this way: Next time I say "Haskell is fast", nobody 
is going to believe me for even a split second. So basically what I've 
been saying all these years is nonesense.

>> seems everywhere I do, people yell at me for being immature and
> 
> They yell at you for being immature?  Doesn't that make them... immature?

Well, I say "yell" at me... Of course they put it more professionally 
than that. But the gist of it is that they think I'm a troll and they 
don't want me around.

> [2]If Haskell can be embedded, I'm thinking it would make a great patch 
> for POV-Ray.  Something like this:
> 
> #declare h_func = haskell { "..." }
> 
> #declare val = h_func(1,2,3)
> 
> Anywhere POV takes functions, it could use a Haskell function.

I'm not sure that would be such a hot idea.

   #declare angleR = angleD / 180 * pi;
   #declare angleR = haskell{"fromIntegral angleD / 180 * pi"};

   #declare center = <1, 2, 3>;
   #declare center = haskell{Vector3 1 2 3};

   #declare T1 = texture {pigment {red 1} finish {ambient 0}}
   #declare T1 = haskell{default_texture {pigment = PSolid {colour = 
ColourRGB 1 0 0}, finish = Finish {ambient = ColourRGB 0 0 0}}};

Not so great, eh?

What you *could* do - and what I attempted to do a while back - is 
design a domain-specific language for scene description/construction. It 
would be completely incompatible with POV-Ray's current SDL, but it 
might be quite nice.

OTOH, if you were going to do that, everybody would want an 
object-oritented language rather than a functional one.

Post a reply to this message

On 2/17/2009 1:25 AM, Invisible wrote:
> Invisible wrote:
>> I am now the laughing stock of this forum. Nobody is ever doing to
>> take anything I say about Haskell seriously ever again. Even better,
>> when I asked about this in the Haskell forum, I got yelled at for
>> being a troll. (Again.)
>
> Last night, I wrote a carefully worded reply to the Haskell mailing
> list. As of now, the moderators still haven't released the message yet.
> So to everybody on the list, it looks like I posted a bunch of
> misinformation, got called on it, and just didn't bother to reply. Yay
> for me. :-(

Ah, the joys of moderated groups :(

-- 
...Chambers
www.pacificwebguy.com

Post a reply to this message

>>> I am now the laughing stock of this forum. Nobody is ever doing to
>>> take anything I say about Haskell seriously ever again. Even better,
>>> when I asked about this in the Haskell forum, I got yelled at for
>>> being a troll. (Again.)
>>
>> Last night, I wrote a carefully worded reply to the Haskell mailing
>> list. As of now, the moderators still haven't released the message yet.
>> So to everybody on the list, it looks like I posted a bunch of
>> misinformation, got called on it, and just didn't bother to reply. Yay
>> for me. :-(
> 
> Ah, the joys of moderated groups :(

That's the fun thing. It's *not* a moderated group. (So... why are my 
posts being moderated??)

Post a reply to this message

>> Ah, the joys of moderated groups :(
> 
> That's the fun thing. It's *not* a moderated group. (So... why are my 
> posts being moderated??)

Well look at that... I sent an email to the list administrator, and 
*within minutes* several emails a sent a few days ago have suddenly 
appeared on the mailing list! How "interesting"... :-P

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message