![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Tue 04/12/12 19:09, Orchid Win7 v1 wrote:
>>> Not exactly taxing, eh?
>>
>> Of course there are many ways to approach this in C# and most other
>> languages. Using LINQ and and working in decimal datatype without error
>> handling:
>>
>> private List<decimal> ParseAndSortValuesFromString1(string text)
>> {
>> return text.Split(' ').Select(s => Decimal.Parse(s)).OrderBy(s =>
>> s).ToList();
>> }
>
> According to one of the guys I work with, "LINQ is great and everything,
> but it makes the code extremely slow". Does anybody have any actual
> /facts/ with which to confirm or refute this? I would have expected
> there to be a fairly minimal speed difference...
LINQ has a certain amount of overhead, as to whether that significantly
impacts the speed of your code obviously depends on the exact code and
data you're dealing with. Even in your example I suspect the speed
differential is highly dependent on the size of the list.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Orchid Win7 v1 <voi### [at] dev null> wrote:
> public List<Int> foobar(String s)
Btw, why return a list?
I know that memory allocation in C# is probably faster than it is
in C++, but it still feels odd to use a list instead of something more
memory-efficient (which C# most certainly ought to support) and faster
to access. What possible advantage could there be in using a list of
ints?
Are you transferring your customs of using lists from Haskell to C#?
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> Orchid Win7 v1 <voi### [at] dev null> wrote:
>>> Think Netflix or Lovefilm for music.
>
>> Ah yes - two other services that I don't yet understand...
>
> You don't understand why people would pay a moderate sum of money in
> order to be able to watch movies or listen to music? (And *legally* at
> that...)
>
No, he doesn't understand how a service can offer near-HD resolution
over the Internet. Despite the fact that tv providers have had no
problem doing 60 channels of the same thing over the same wires for the
last 30 years (10 years in the case of HD).
He also complains of not knowing what "cable tv" is, despite the fact
that he admitted his parents used to have it.
You, know, regular Andy stuff.
;)
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 05/12/2012 02:22 PM, Warp wrote:
> Orchid Win7 v1<voi### [at] dev null> wrote:
>> public List<Int> foobar(String s)
>
> Btw, why return a list?
>
> I know that memory allocation in C# is probably faster than it is
> in C++, but it still feels odd to use a list instead of something more
> memory-efficient (which C# most certainly ought to support) and faster
> to access. What possible advantage could there be in using a list of
> ints?
>
> Are you transferring your customs of using lists from Haskell to C#?
The C# "List" class actually represents a growable array. So it has O(1)
index and O(1) append until the underlying array needs to be enlarged
(which is obviously O(n) time).
The "LinkedList" class represents a (double-linked) list, with the usual
performance characteristics you would expect for that container.
As best as I can tell, List is pretty much the default container to use
unless you need something more specific.
You could also use a normal array. But that isn't resizable (which
doesn't matter in this particular case).
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> You don't understand why people would pay a moderate sum of money in
>> order to be able to watch movies or listen to music?
>>
> No, he doesn't understand how a service can offer near-HD resolution
> over the Internet.
Providing data over the Internet isn't hard. But providing HD video *in
realtime* would seem difficult given that people don't have
megabit-speed Internet access yet.
> Despite the fact that tv providers have had no
> problem doing 60 channels of the same thing over the same wires for the
> last 30 years (10 years in the case of HD).
Digital TV isn't 30 years old. :-P
Besides, it's no secret that a simplex broadcast channel is much easier
to set up than a full-duplex communications channel.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 03/12/2012 02:46 PM, Warp wrote:
> I have had the great fortune of never having to work with someone who
> isn't a competent programmer.
I've only met people who are very bad with computers. When I went to
university, I seemed to know more than most of the lectures I was paying
to teach me, which is always a little bit worrying.
Bafflingly, all the people in my class appeared to hate computers, which
begs the question "why the hell are you here??"
This job is my first experience of working with people who have a clue.
And even they think I'm a bit strange for having all this CS knowledge...
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> According to one of the guys I work with, "LINQ is great and everything,
>> but it makes the code extremely slow". Does anybody have any actual
>> /facts/ with which to confirm or refute this? I would have expected
>> there to be a fairly minimal speed difference...
>
> LINQ has a certain amount of overhead, as to whether that significantly
> impacts the speed of your code obviously depends on the exact code and
> data you're dealing with. Even in your example I suspect the speed
> differential is highly dependent on the size of the list.
I would expect that for this example question, you would be very
hard-pressed to construct a program inefficient enough to be considered
"too slow". ;-)
You could perhaps write the program in the Iota calculus, running in an
Iota interpreter written in Bash script. That might perhaps be slow
enough...
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 03/12/2012 08:50 AM, scott wrote:
>> Of course, The Real WTF is hiring. With unemployment at historic record
>> levels, we literally cannot find *anybody* with the skill-set we need.
>> Personally I find this baffling. The market must be /flooded/ with
>> experienced programmers, and yet we keep interviewing people who can't
>> program their way out of a paper bag.
>
> Hehe welcome to the real world. We have exactly the same problems with
> hiring Engineers. Can you describe what this circuit does? No, ok what
> about this one? No, ok what does this *component* do ... ermmm not
> exactly, have you every used an oscilloscope? No, ok we'll be in touch,
> thanks bye.
This is what baffles me.
Consider the following conversation...
Mr Fail: Hi. I've got 20 years' experience as a brick layer. Are you hiring?
Boss: Oh really? Well, can you just quickly tell me, is that wall over
there stretcher-bond of Flemish-bond?
Mr Fail: Uh... well, I really specialised in /internal/ walls.
Boss: Great! So tell me, at what height should the internal
damp-proofing course be run?
Mr Fail: Well, I, er, mostly worked in tropical countries where damp
isn't a problem.
Boss: Cool. So how many runs of bricks between tie-in wraps?
Mr Fail: Tie-in wraps?
Boss: Goodbye.
The thing is, *nobody* thinks they can just walk in and pretend to know
how to be a brick layer. Because it's ****ing obvious that it'll take
the people interviewing you about 11 seconds to figure out that you know
nothing about anything.
So *why* the hell does this constantly happen in computing?!? >_<
>> It's /almost/ as if the guy was desperately
>> Googling the code while he was on the phone.
>
> Or typing it into the IDE then copying & pasting over, that's what I
> would probably do, as I pretty much rely on the auto-complete stuff to
> get code right first time (or even remember the method names correctly).
Yeah, but I'm fairly sure even VS doesn't write entire blocks of code
for you. Google searching does. ;-)
> From what was discussed here before (sorry don't remember who with) it
> seems recruitment agencies for software are very poor compared to ones
> for engineering for some reason. Seems like there is a market for a
> decent software recruitment agency that actually employs people who know
> a tiny bit how to program so can weed out people like you describe.
I'm currently unsure as to whether we're just not paying the agents
enough money, or whether there's nobody out there to recruit.
(As a small company, we have very little money to spend. And the owners
are the type of people who see job agents as a totally unnecessary
expense and want to spend the absolute minimum possible on them.)
With such high unemployment, you would THINK there's loads of people out
there... but we're beginning to suspect that maybe all the /competent/
people get snapped up faster than we can find them...
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 05/12/2012 9:23 PM, Orchid Win7 v1 wrote:
> Providing data over the Internet isn't hard. But providing HD video *in
> realtime* would seem difficult given that people don't have
> megabit-speed Internet access yet.
WTF!
--
Regards
Stephen
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Wed, 05 Dec 2012 21:23:24 +0000, Orchid Win7 v1 wrote:
>>> You don't understand why people would pay a moderate sum of money in
>>> order to be able to watch movies or listen to music?
>>>
>> No, he doesn't understand how a service can offer near-HD resolution
>> over the Internet.
>
> Providing data over the Internet isn't hard. But providing HD video *in
> realtime* would seem difficult given that people don't have
> megabit-speed Internet access yet.
m-/
That is where you're wrong, Andy. Even my pokey internet connection is 3
Mbps. More than enough to handle sufficient data to do a medium quality
HD picture on a 10' screen.
>> Despite the fact that tv providers have had no problem doing 60
>> channels of the same thing over the same wires for the last 30 years
>> (10 years in the case of HD).
>
> Digital TV isn't 30 years old. :-P
No, but cable TV is close to that. We had cable when I was a teenager,
and easily had 120 channels at that time (that would be in the 80's).
That's not really classified information, either.
Jim
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |