Multiplication using Linq

[shapper]

Hello,

Is it possible to multiply all Prices in a List<Product> by 1.1 using
Linq?

Product has a property named Price.

Thanks,
Miguel

 

[Arne Vajhøj]

Is it possible to multiply all Prices in a List<Product> by 1.1 using
Linq?

Product has a property named Price.

I would use:

list.ForEach((Product p) => p.Price *= 1.1m);

Arne

 

[shapper]

All due respect, not every problem is best solved using LINQ.  Sometimes,  
just a normal "foreach" enumeration is best.

If you are trying to query a set of data (collection, database, etc.) and 
manipulate the results of such a query, then LINQ can be very useful.  But  
if you're just trying to process individual elements in a set of data,  
using LINQ could be counter-productive.

No offense intended, but your posts seem to have this sort of "vibe" of  
someone who's found a shiny new hammer called "LINQ" and now thinks all of  
his problems are nails.  

At the very least, it might be helpful to those trying to answer if you  
could explain why all of your questions look like "Is it possible to do X 
using LINQ?"  Why is it that you want to implement all of these different  
things with LINQ?  What's wrong with just doing it "the old fashioned way"?

Pete

But does now Linq in some cases convert the code to a Loop itseld?

This was one idea I got from this forum ... So when using Lists Linq
can be useful in some operations ...

Thanks,
Miguel

 

[Marc Gravell]

This was one idea I got from this forum ... So when using Lists Linq

can be useful in some operations ...

Maybe - but in the /purest/ sense, LINQ is a [Q]uery language, not a
manipulation language. Note that there is no Enumerable.ForEach, for
example. Indeed the Expression side of LINQ is designed to be side-
effect free [at least, assuming that property getters are well-
behaved, etc].

There is nothing stopping you doing List<T>.ForEach([some lambda]),
but it doesn't usually gain you anything either - and will be (very
slightly) slower in the bargain (delegate invoke, capture indirection,
interface-vs-struct enumerator, etc).

Marc

 

[shapper]

This was one idea I got from this forum ... So when using Lists Linq
can be useful in some operations ...

Maybe - but in the /purest/ sense, LINQ is a [Q]uery language, not a
manipulation language. Note that there is no Enumerable.ForEach, for
example. Indeed the Expression side of LINQ is designed to be side-
effect free [at least, assuming that property getters are well-
behaved, etc].

There is nothing stopping you doing List<T>.ForEach([some lambda]),
but it doesn't usually gain you anything either - and will be (very
slightly) slower in the bargain (delegate invoke, capture indirection,
interface-vs-struct enumerator, etc).

Marc

Just as a try I have the following:
Products.Select(p => p.Price = p.Price * 1.2

This is not working ... what am I doing wrong?

Thanks,
Miguel

 

[Pavel Minaev]

Just as a try I have the following:
Products.Select(p => p.Price = p.Price * 1.2
This is not working ... what am I doing wrong?

This should work, if you've got all your types right. Are you sure that
Price is not an int or decimal (1.2 is double, and you can't multiply a
decimal and a double).

That said, it's still a bad idea. Mutating data in your queries is bad for a
multitude of reasons - one of them being that it will likely simply not work
with any IQueryable that maps the query to something (I mean, think about
it - LINQ to SQL tries to map Where()/Select() to SQL SELECT - how'd you map
the one you wrote above yourself?). It will also subtly break things if you
ever try to move to Parallel LINQ. LINQ is inherently functional, if you
need to transform data using it, you should create a new sequence, not
mutate the old one. If you want to mutate in-place, use imperative
constructs such as foreach.

I would highly recommend you to read the article "Functional vs. Procedural
Programming (LINQ to XML)":

http://msdn.microsoft.com/en-us/library/bb675169.aspx

While it deals with LINQ to XML, and its samples are XML-related the general
principles outlined within are equally applicable to all other LINQ flavors.

 

[Frans Bouma [C# MVP]]

All due respect, not every problem is best solved using LINQ.
Sometimes, just a normal "foreach" enumeration is best.

If you are trying to query a set of data (collection, database, etc.)
and manipulate the results of such a query, then LINQ can be very
useful. But if you're just trying to process individual elements in a
set of data, using LINQ could be counter-productive.

No offense intended, but your posts seem to have this sort of "vibe" of
someone who's found a shiny new hammer called "LINQ" and now thinks all
of his problems are nails.

At the very least, it might be helpful to those trying to answer if you
could explain why all of your questions look like "Is it possible to do
X using LINQ?" Why is it that you want to implement all of these
different things with LINQ? What's wrong with just doing it "the old
fashioned way"?

I was just thinking of posting the same!

@Shapper: take a step back, and first think how you would do it in
normal imperative (== C#) code, and then think how you might want to do
this in linq, but always consider: what you want to make is possible
without linq so using 'linq' is just another way of doing it, it's not
necessary to make things possible.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------