Re: Generic collections - C# Discussion Boards

PozzaVecia22-Jul-13 1:14

22-Jul-13 1:14

thanks very useful

harold aptroot22-Jul-13 1:05

22-Jul-13 1:05

That doesn't work. Or rather, it may work - accidentally.
But see http://msdn.microsoft.com/en-us/library/yt2fy5zk.aspx[^]:

The order of the keys in the Dictionary<tkey, tvalue="">.KeyCollection is unspecified

It is not (necessarily) in the order that you added the items.

It often works. But it isn't guaranteed to.

edit: it turns out that, in the current implementation (which may change!) it will indeed work as long as you never delete anything. That's just an implementation detail, it would be foolish to rely on it. It could change in any update.

Also, of course, you're doing a linear search through a list. That is not ideal.

modified 22-Jul-13 7:17am.

PozzaVecia22-Jul-13 3:31

22-Jul-13 3:31

oky thank

BillWoodruff23-Jul-13 2:41

23-Jul-13 2:41

harold aptroot wrote:
you're doing a linear search through a list.

Hi Harold,

I am curious: do you know for a fact that using Linq 'ElementAt, or using the (not Linq) 'IndexOf on an Array, or List, internally performs a linear search ?

In the case of 'ElementAt on a Dictionary, I am assuming there's some cost of some kind of internal conversion since Dictionary doesn't inherently support "sequential" indexing by integer.

thanks, Bill

~
“This isn't right; this isn't even wrong." Wolfgang Pauli, commenting on a physics paper submitted for a journal

harold aptroot23-Jul-13 3:11

23-Jul-13 3:11

The IndexOf of a List uses the IndexOf of Array, and that ones's a linear search (I checked it just be sure, but really there's no other choice anyway).
What ElementAt does depends on the thing you're applying it to, it will use IList<T>'s indexer if that interface is implemented (Dictionary does not implement it, so ElementAt would scan through the enumerator).

So in conclusion, that code was pretty inefficient.

BillWoodruff23-Jul-13 4:09

23-Jul-13 4:09

Thanks for your reply, Harold, that is very interesting to know.

It makes me wonder: if you were dealing with a really big generic List, or a huge Dictionary, if you could implement a much more efficient solution than the current operators, and, if so, why MS has not done that.

I would have thought that Linq operators, particularly, were highly optimized with the latest algorithms: reminds me I should never assume anything about software tools.

yours, Bill

~
“This isn't right; this isn't even wrong." Wolfgang Pauli, commenting on a physics paper submitted for a journal

harold aptroot23-Jul-13 5:32

23-Jul-13 5:32

There aren't many options there.. (there are some, discussed below) I mean, say you have an array and you want to know the index of some value and you have an algorithm that does not potentially look at all elements, how can it know the thing it's trying to find isn't in the part that it hasn't looked at?

Clearly it can't, so in the worst case you're always looking at all elements anyway. Leaving the "standard complexity model" behind for a moment, you can do a lot better than O(n): divide the array in m parts, search each part in parallel, then do a Min-Reduction phase on all the results. That's O(log m) in PRAM (where the assumption m = n is allowed), but PRAM is not a realistic model for present-day CPU computing.
In the CPU world that same algorithm is still O(n) (because it's really O(n/m + log m) and m is a constant now), which doesn't necessarily have to be a bad thing, not all O(n)'s are created equally after all. But this isn't a particularly awesome algorithm:
1) it spends a lot of time just fetching things from memory, and doesn't do a whole lot with them. (of course the normal algorithm does that too, that it will be a worse bottleneck when multiple threads are doing it)
2) even if you abort the threads working on the higher ranges (or if you want any index, not just the lowest: all other threads) when you find the item, you will have wasted work, so even when it's faster it takes more resources.
3) it has a lot of overhead from all the thread business.
In a quick test, this algorithms start pulling ahead on average for an array of a million integers, and then only when the item is not actually in the array (the worst case for the simple linear search).
It almost reaches a speedup of 4x on my machine (which isn't that bad considering it's a quad core + hyperthreading) but each time an item actually is in the array, the multithreaded algorithm loses or almost loses, no matter how big I make the array (tested up to an array of 2²⁸ ints).

So it's not really suitable as a default algorithm for libraries: it's terrible in the common case that the item is actually in the array.

modified 23-Jul-13 11:42am.

BillWoodruff23-Jul-13 18:11

23-Jul-13 18:11

Once again, thanks, for that very illuminating reply !

I'd say if you tested up to 2²⁸, that would cover most non-astronomical level scenarios !

Of more interest, and something I actually intend to explore, is what happens when have compound structures with KeyValue pairs, and both Key and Value Types are complex classes, not just ValueTypes.

... edit ... on second thought: if K and V are complex classes, I think it's just a case of comparing pointers in any IndexOf, or ElementAt, type operation, so: no difference than if K and V were .NET ReferenceTypes (?) ...

Please come to northern Thailand (in late-October~early-January is best), and let me take you, and your family, elephant riding in the jungle Smile | :)

yours, Bill

~
“This isn't right; this isn't even wrong." Wolfgang Pauli, commenting on a physics paper submitted for a journal

modified 24-Jul-13 0:42am.

harold aptroot23-Jul-13 22:42

23-Jul-13 22:42

BillWoodruff wrote:
Of more interest, and something I actually intend to explore, is what happens when have compound structures with KeyValue pairs, and both Key and Value Types are complex classes, not just ValueTypes.

It depends, it calls Equals(T other) when IEquatable<T> is implemented (in that type or a base class), regular Equals otherwise which might default to Object.Equals, in that case it uses Reference Equality for reference types and Bitwise Equality for value types (that's how the official documentation puts it), which could be restated as "always bitwise equality, so if you give it a reference it's bitwise equality on the reference itself" (that might help a person who thinks in pointers, it would probably confuse someone who thinks in objects).
The code where it tests to see which case it's in and then makes an EqualityComparer uses a lot of reflection, by the way.

Thanks for inviting me by the way, but I've found that jungles aren't my thing, so I don't think I'll do anything with that..

harold aptroot21-Jul-13 1:18

21-Jul-13 1:18

Often when you have a problem that looks like "I need a data structure that has the properties of A and of B" where A and B are some data structure, there's an obvious way to just combine A and B and wrap them a little thing that keeps them synchronized.
Such as here, it looks like a List and like a Dictionary.. what can you do? Well you can make a List<Tvalue> and a Dictionary<Tkey, int> and let the dictionary map keys to indexes in the list.
If you also want removal, you can use a linked list instead of a list, and let the dictionary map keys to nodes in the linked list.

PozzaVecia21-Jul-13 22:56

21-Jul-13 22:56

I did the same as a workaround solution... thanks a lot

BillWoodruff21-Jul-13 23:40

21-Jul-13 23:40

Hi Harold,

Upvoted, as usual: why is it that when I read your comments, I often feel like I am listening to Yoda trying to tell me something through metaphor that's just beyond my ability to grasp ? Smile | :)

yours, Bill

~
“This isn't right; this isn't even wrong." Wolfgang Pauli, commenting on a physics paper submitted for a journal

PozzaVecia22-Jul-13 1:18

22-Jul-13 1:18

Disable Windows Navigation

M.Kamran Asim21-Jul-13 21:19

M.Kamran Asim

21-Jul-13 21:19

use Dictionary<string,double>

aymen Tn18-Jul-13 5:11

aymen Tn

18-Jul-13 5:11

Hi

I'm developing a wpf application using visual studio 2010 in c#.
for security reason, the navigation in the operating system is not allowed while running the application.
That means once it is launched, all Windows menu, icons, toolbars ... must be hidden, and only the application must appear.
(it's a kind of that the PC becomes only dedicated to it).

Any suggestion or Idea ?

Thanks in advance

GuyThiebaut18-Jul-13 5:26

GuyThiebaut

18-Jul-13 5:26

I don't have any code but what I think you might want to look into is running the application in what is known as 'kiosk' mode.

“That which can be asserted without evidence, can be dismissed without evidence.”

― Christopher Hitchens

Emmanuel Medina18-Jul-13 5:27

Emmanuel Medina

18-Jul-13 5:27

Sounds like what you want is a "kiosk" mode kinda thing.

If so, you should add WindowStyle="None" and WindowState="Maximized" to the XAML of your main window. Further, you can even disable resizing and make it be the windows at the top from the start, adding ResizeMode="NoResize" and Topmost="True". Code would look like this:

XML

<Window x:Class="WpfApplicationTest1.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="350" Width="525"
        WindowStyle="None"
        WindowState="Maximized"
        ResizeMode="NoResize"
        Topmost="True">

Note that Windows keyboard shortcuts still work (Alt+Tab, Windows Key, Alt+F4). If you want to "disable" those, you will have to capture them, although opening applications in this manner (for example Windows+E for Windows Explorer) won't display the newly opened application since yours is Topmost as set in the property.

[EDIT]
The same can be achieved modifying those properties in the constructor, like so:

namespace WpfApplicationTest1
{
  public partial class MainWindow : Window
  {
    public MainWindow()
    {
      InitializeComponent();
      WindowStyle = WindowStyle.None;
      WindowState = WindowState.Maximized;
      ResizeMode = ResizeMode.NoResize;
      Topmost = true;
    }
  }
}

If you think you can do a thing or think you can't do a thing, you're right - Henry Ford

Emmanuel Medina Lopez

modified 18-Jul-13 13:48pm.

aymen Tn18-Jul-13 22:44

aymen Tn

18-Jul-13 22:44

Hello

Thanks for your reply.
but with this solution the windows expolorer still work, for example when I push the keybord start button it still works,
What I want to do is to diable all windows fonctionnality (like Windows +E ....)

Thanks

Freak3018-Jul-13 23:46

Freak30

18-Jul-13 23:46

I don't think, you can do this. And even if you did, the user could still press Ctrl + Alt + Del (which can't be intercepted as far as I know), open Task Manager and kill your application.

I would suggest another appoach. Give the user only minimal rights (just to his user directory). Start your application under a different user who has access to the necessary directories. Require a password to close your application. Under this setup the Task Manager is of no use because the user can't kill other users' processes.

The good thing about pessimism is, that you are always either right or pleasently surprised.

modified 19-Jul-13 6:17am.