What kind of performance gain is there to what you did compared to using a TypeConverter on both objects, then a final comparison of the result? Curious if you have looked at that before.
That is creating an expression for each row and compiling it for each row, right? I'm guessing the main factor here is performance so if it was that big of a concern I wonder if you wouldn't want to make a dictionary of them for the unique types encountered, especially since most rows are going to have the same columns. I think I'm going to work up an example app with a few of these methods on lots of rows, to try some of these out and see the difference. I'll post it here within a few days. On Mar 4, 6:23 am, Simone Busoli <[email protected]> wrote: > It's the .NET fx, and it's LCG, lightweight code generation. > > > > On Wed, Mar 4, 2009 at 10:19, webpaul <[email protected]> wrote: > > > Is there a framework you are using that supports this or is that > > something you guys came up with? I see a .compile in there when it is > > generating that final .Equal statement. > > > On Mar 4, 2:31 am, Simone Busoli <[email protected]> wrote: > > > I'm creating on the fly a method which performs a comparison of the two > > > values by coercing them to the same type. > > > Say you have: > > > > object a = (int)1; > > > object b = (byte)1; > > > > You'd get a.Equals(b) to be false, which is somewhat unexpected. > > > > What I'm doing is this: > > > > ((int)a).Equals((int)(byte)b), which returns true, as expected. > > > > There might be other ways, however. > > > > On Wed, Mar 4, 2009 at 03:40, webpaul <[email protected]> wrote: > > > > > Do you have a link to something that explains the general concept of > > > > what is going on there? I haven't ever seen anything like that before. > > > > > On Mar 3, 8:06 pm, Simone Busoli <[email protected]> wrote: > > > > > committed in rev. 2086 > > > > > > On Sun, Feb 22, 2009 at 20:03, Simone Busoli < > > [email protected] > > > > >wrote: > > > > > > > Right :) I'm not sure I can take the time in the next few days, > > > > though, > > > > > > but it's on my todo list. > > > > > > > On Sun, Feb 22, 2009 at 20:01, Ayende Rahien <[email protected]> > > > > wrote: > > > > > > >> Go for it :-)That would actually keep us consistent with the > > > > appropriate > > > > > >> C# behavior, which is the expected one. > > > > > > >> On Sun, Feb 22, 2009 at 1:56 PM, Simone Busoli < > > > > [email protected]>wrote: > > > > > > >>> What about LCG with expressions? They know how to compare each > > other, > > > > > >>> when they know who they are :) > > > > > > >>> On Sun, Feb 22, 2009 at 19:52, Ayende Rahien <[email protected]> > > > > wrote: > > > > > > >>>> Custom Comparators for the join.We can detect them not being of > > the > > > > > >>>> same type and coerce them to the bigger type > > > > > > >>>> On Sun, Feb 22, 2009 at 1:49 PM, webpaul <[email protected]> > > > > wrote: > > > > > > >>>>> How are you thinking of doing it? Casting up should always be > > safe, > > > > so > > > > > >>>>> you could always cast any numeric type to double or something > > like > > > > > >>>>> that in order to compare. That way you could compare 1 with > > 1.00 > > > > also. > > > > > >>>>> Not sure if that is a perf problem or not though. > > > > > > >>>>> On Feb 22, 11:33 am, Ayende Rahien <[email protected]> wrote: > > > > > >>>>> > +1 > > > > > > >>>>> > On Sun, Feb 22, 2009 at 11:36 AM, Simone Busoli < > > > > > >>>>> [email protected]>wrote: > > > > > > >>>>> > > Actually, when you're doing a join it would be a very cool > > > > feature > > > > > >>>>> to have. > > > > > >>>>> > > I spent quite some time wondering why the rows didn't join > > > > > >>>>> correctly, and it > > > > > >>>>> > > was because the field on which it was performing the join > > was > > > > an > > > > > >>>>> integer on > > > > > >>>>> > > one side and a byte on the other. So far, the solution has > > been > > > > to > > > > > >>>>> write > > > > > >>>>> > > tests which ensure that the two sides of the join have the > > same > > > > > >>>>> field types, > > > > > >>>>> > > but I would like to solve it at the RhinoETL level. > > > > > > >>>>> > > On Sun, Feb 22, 2009 at 03:54, webpaul <[email protected] > > > > > wrote: > > > > > > >>>>> > >> Ok, mission accomplished then - Makes sense once you think > > > > about > > > > > >>>>> it. I > > > > > >>>>> > >> certainly don't have any burning need for it to work and > > the > > > > easy > > > > > >>>>> work > > > > > >>>>> > >> around is to cast one of the items as they are read in if > > it > > > > > >>>>> becomes > > > > > >>>>> > >> an issue so I think it's fine. Just wanted to check if > > that > > > > was a > > > > > >>>>> > >> desired thing or not. > > > > > > >>>>> > >> On Feb 21, 10:43 am, Simone Busoli < > > [email protected]> > > > > > >>>>> wrote: > > > > > >>>>> > >> > That was to point out the subtlety in the .net fx. I > > already > > > > > >>>>> discussed > > > > > >>>>> > >> it, > > > > > >>>>> > >> > please lookup "row equality" on the mailing list. I > > think > > > > this > > > > > >>>>> can be > > > > > >>>>> > >> > addressed in several ways, but didn't take the time to > > do it > > > > > >>>>> yet. > > > > > > >>>>> > >> > On Sat, Feb 21, 2009 at 17:13, webpaul < > > [email protected]> > > > > > >>>>> wrote: > > > > > > >>>>> > >> > > I looked at some recent changes and one of them was > > for > > > > > >>>>> checking row > > > > > >>>>> > >> > > equality. I noticed there was a specific test for an > > > > (int)1 > > > > > >>>>> not being > > > > > >>>>> > >> > > equal to a (byte)1 - is that the desired behavior or > > was > > > > the > > > > > >>>>> test put > > > > > >>>>> > >> > > in there just to demonstrate that subtlety? I did a > > little > > > > > >>>>> test and > > > > > >>>>> > >> > > was surprised to find the below .NET framework > > behavior, I > > > > > >>>>> would have > > > > > >>>>> > >> > > thought they would be equal: > > > > > > >>>>> > >> > > object a = (int)1; > > > > > >>>>> > >> > > object b = (byte)1; > > > > > > >>>>> > >> > > Assert.IsFalse(a.Equals(b)); > > > > > > >>>>> > >> > > I'm guessing the framework just returns false if the > > types > > > > are > > > > > >>>>> > >> > > different in the Equals implementation. > > > > > > >>>>> > >> > > So I understand why the test behaves how it does, just > > > > curious > > > > > >>>>> if that > > > > > >>>>> > >> > > is the desired effect or just due to the above and you > > > > wanted > > > > > >>>>> it to be > > > > > >>>>> > >> > > clear.- Hide quoted text - > > > > > > >>>>> > >> > - Show quoted text -- Hide quoted text - > > > > > > >>>>> > - Show quoted text -- Hide quoted text - > > > > > > - Show quoted text -- Hide quoted text - > > > > - Show quoted text -- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en -~----------~----~----~----~------~----~------~--~---
