471,310 Members | 1,375 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,310 software developers and data experts.

Multiplication using Linq

Hello,

Is it possible to multiply all Prices in a List<Productby 1.1 using
Linq?

Product has a property named Price.

Thanks,
Miguel
Sep 4 '08 #1
7 11115
On Thu, 04 Sep 2008 15:06:52 -0700, shapper <md*****@gmail.comwrote:
Is it possible to multiply all Prices in a List<Productby 1.1 using
Linq?

Product has a property named Price.
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
Sep 4 '08 #2
shapper wrote:
Is it possible to multiply all Prices in a List<Productby 1.1 using
Linq?

Product has a property named Price.
I would use:

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

Arne
Sep 5 '08 #3
On Sep 4, 11:18*pm, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
wrote:
On Thu, 04 Sep 2008 15:06:52 -0700, shapper <mdmo...@gmail.comwrote:
Is it possible to multiply all Prices in a List<Productby 1.1 using
Linq?
Product has a property named Price.

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
Sep 5 '08 #4
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
Sep 5 '08 #5
On Sep 5, 6:32*am, Marc Gravell <marc.grav...@gmail.comwrote:
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
Sep 5 '08 #6
"shapper" <md*****@gmail.comwrote in message
news:0a**********************************@e53g2000 hsa.googlegroups.com...
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.
Sep 5 '08 #7
Peter Duniho wrote:
On Thu, 04 Sep 2008 15:06:52 -0700, shapper <md*****@gmail.comwrote:
>Is it possible to multiply all Prices in a List<Productby 1.1 using
Linq?

Product has a property named Price.

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#)
------------------------------------------------------------------------
Sep 5 '08 #8

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

54 posts views Thread by Andy | last post: by
9 posts views Thread by Ralf Hildebrandt | last post: by
87 posts views Thread by Vijay Kumar R Zanvar | last post: by
17 posts views Thread by Christopher Dyken | last post: by
18 posts views Thread by martin | last post: by
1 post views Thread by Sozos | last post: by
2 posts views Thread by Neil Chambers | last post: by
5 posts views Thread by CSharper | last post: by
reply views Thread by rosydwin | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.