תחומים - פורום חרדי מקצועי

המיון + האיחוד הוא לכאורה בזבוז, כי המיון הוא לא רק סורק, אלא גם ממקם, ובמקרה שלך היה עדיף שכבר יאחד בנקודת זמן זו.
השאלה איך לממש איחוד מהיר ללא מיון, הרי איחוד מחפש ובשביל חיפוש בינארי צריך מיון. התשובה היא שצריך רשימה חדשה למאוחדים (וזו רשימה הרבה יותר קצרה, ממילא המיון שלה זול יותר) שהיא תהיה ברת חיפוש מהיר כמו רשימה ממויינת.
אבל, אף שאינני מבין איך, Dictionary מוצא מהר יותר מחיפוש בינארי. וממילא עדיף Dictionary.

לפי מה שנראה לי, Dictionary מהתחלה יעשה את העבודה מהר יותר.

אם תמשיך בקו שלך, אז יש לי שיפור:
הפירוש שבמשל הוא המערך השלמים שבנמשל. כמה פירושים = כמה מערכים. במקור יש רק פירוש לכל מילה, אז עדיף שתעבוד עם אובייקט שונה שמכיל במקום ליסט משתנה שלם פשוט (זה חיסכון גם בזיכרון וגם במעבד). ובאובייקט היעד (המאוחד) יהיה מערך ולא ליסט (חיסכון בזיכרון).

פורסם במקור בפורום CODE613 ב07/04/2014 19:24 (+03:00)

@רחמים

כעת סיימתי את הנסיון, תחילה הכנסתי את כל המילים לרשימה אחת ארוכה, אח''כ מיינתי ואח''כ הסרתי כפולים במקום 20 דקות זה הסתיים ב 40 שניות עבור המיון ועוד 7 שניות עבור הסרת איחוד הכפולים !!!

שתי שאלות:
כמה איברים יש?
איך הסרת כפולים?

פורסם במקור בפורום CODE613 ב07/04/2014 16:57 (+03:00)

אם הנמשל ממש זהה למשל, אני חושש שהדרך הנכונה והמעצבנת (כי זה מוריד את כל האתגר) זה הוא מסד נתונים.
זה לא באמת פיתרון, כי למסד יש אותו בעיה אבל מבחינה מעשית זה פשוט להיפטר מהמטלה...
הכי מהיר אני חושב זה טבלה ארוכה ואח"כ Distinct לטבלה אחרת.

פורסם במקור בפורום CODE613 ב07/04/2014 16:34 (+03:00)

בתמונה דלעיל, מושך את העין מייד המספר הגדול 50,000 שמופיע כמה פעמים בשורת הListDictionary.
למה זה כ"כ נורא? כי זה ממומש ע"י רשימה מקושרת...
כפי שנראה אין לה שום מעלה בפעולות קולקשנים רגילים.

פורסם במקור בפורום CODE613 ב07/04/2014 16:08 (+03:00)

להרחבת הידיעות אודות סוגי הקולקשיינס:
http://geekswithblogs.net/BlackRabbitCoder/archive/2011/06/16/c.net-fundamentals-choosing-the-right-collection-class.aspx
והנה עוד מMSDN

בקשר לסוגי המילונים - מפתח-ערך, הנה תמונה מתוך ספר C# in nutshell שנותנת אינדיקציה לשם מה עשוייה כל אחת:

לצפייה טובה לחצו קליק ימני על התמונה > פתח בכרטיסייה חדשה.
המספרים הם אלפיות שניה, לביצוע 50,000 פעולות, במחשב הבדיקה (1.5 Ghz).

ורחמים, אם אתה רוצה באמת עצות טובות, פרוש את התמונה במלואה, חסר הרבה פרטים שבירורם היה יכול לעזור לתשועה ברוב יועץ.

פורסם במקור בפורום CODE613 ב07/04/2014 15:58 (+03:00)

אני אכן לא קראתי מספיק בעיון את הקוד שלך (לתשומת לבך, קוד זה לא צורה להבהיר מה אתה רוצה לעשות).

אז אכן הDictionary ייתן לך לכאורה ביצועים משופרים למציאת הערך (פי שתיים).
חוץ מזה הקוד שלך באמת לוקה ביעילות בזה: במידה והמפתח קיים הוא מאתר פעמיים (אינדקס, ואח"כ לפי KEY).
היית צריך לעשות ככה:

Sub mySub(ByVal list As List(Of myType))
    For Each myType As myType In list
        ' בודק אם המפתח כבר קיים
        Dim key As List(Of Integer)
        If dic.TryGetValue(myType.A, key) = False Then
            key = New List(Of Integer)
            dic.Add(myType.A, key)
        End If
        dic(myType.A).Add(myType.B)
    Next
End Sub

(בטעות בקוד לשי הטיפוס הוא int במקום מערך של int, אבל העיקרון זהה).

אם אתה מקבל את כל הנתונים בבת אחת אני גם חושב שעדיף לרכז לבסוף.
תוכל להיעזר בשאילתת לינק לקיבוץ משהו כזה:

Sub mySub(ByVal list As List(Of myType))
    Dim q = From el In list
            Group el By el.A Into grp = Group
            Select New With {.Key = A, .Ints = grp.SelectMany(Function(x) x.B)}
    ...
End Sub

פורסם במקור בפורום CODE613 ב07/04/2014 15:53 (+03:00)

@רחמים

מה לא מובן?
תפתח ברפלקטור ותראה איך בנוי ליסט
מאחורי הקלעים יש מערך רגיל שעושים לו REDIM כל פעם מחדש

התום לב שלך שובה את ליבי.
אתה כתבת "לזה עדיף מערך רגיל כדי שיהיה אפשר לעשות חיפוש בינארי" אז הערתי שגם בליסט אפשר.
אז אתה מתחיל להסביר לי שמאחורי הקלעים זה מבוסס על מערך (כאילו שאלמלא כן לא היה אפשר).
אתה אפי' מצרף קוד...
מה זה נוגע לנידון היפה שאנו דנים בו? מה משנה איך זה ממומש?!?

פורסם במקור בפורום CODE613 ב07/04/2014 14:48 (+03:00)

בקשר לקוד שלך, הוא לא עונה על השאלות שלי. א"א לנחש דרכו את השאלות הפשוטות שאותם שאלתי.
חוץ מזה טרחתי והבאתי לך קישור, עשית בו שימוש?

בשביל לבדוק אם איבר קיים ולפי זה להכניס SortedList הוא ודאי לא האידאלי. למה החלטת שאתה צריך אותו? (בשביל לקבל בסוף מיון, תמיין בסוף. הSortedList עשוי להחזקת רשימה ממויינת שתישאר ככה גם כשמוסיפים לה טיפונת איברים פה ושם).
Dictionary ייתן לך ביצועים משופרים (בדרך שבחרת בקוד שלך), וHashSet יחסוך לך את הקוד שכתבת לבדיקת המצאות איבר (קראת את ההודעה שלי הקודמת? שם כבתי גם שהוא עושה זאת יעיל).

פורסם במקור בפורום CODE613 ב07/04/2014 14:43 (+03:00)

@רחמים

@דוד ל.ט.
למה החלטת שבליסט א"א לעשות חיפוש בינארי?

בליסט אפשר, אבל זה רק בגלל שהליסט מבוסס על מערך רגיל, בקוד הבא השורה השניה מתקבלת אבל השלישית לא:

Dim list As New List(Of String)
        Dim num = list.BinarySearch("A")
        Array.BinarySearch(list, "A")

:x :lol: <!-- s8-) --><img src="{SMILIES_PATH}/icon_cool.gif" alt="8-)" title="מגניב" /><!-- s8-) --> :oops:

אפשר להבין מה אתה רוצה?

פורסם במקור בפורום CODE613 ב07/04/2014 14:31 (+03:00)

@רחמים

מצד אחד הליסט צריך להיות מסוגל להכיל הרבה מאוד ערכים, בסביבות חצי מליון עד מליון ולזה עדיף לכאורא רשימה מקושרת כיון שעבור כל איבר חדש היא מקצה שטח קטן חדש שאינו צריך להיות רצוף לשטח הזכרון של איברים אחרים, אלא הוא נמצא אי שם ומדברים איתו דרך מצביע,

למה רצוף זה לא טוב? אדרבא זה טוב. אם אתה דואג איפה יהיה שטח רצוף זה לא נראה לי עניינך :).

@רחמים

ולזה עדיף מערך רגיל כדי שיהיה אפשר לעשות חיפוש בינארי לפני שמכניסים איבר חדש ולא לעבור מהתחלה עד הסוף כל פעם.

למה החלטת שבליסט א"א לעשות חיפוש בינארי?

מה שחשוב לדעת זה בכמה פעמים אתה מכניס את הערכים (בבת אחת, כמה פעמים, הרבה הרבה פעמים), לפי מה אתה שולף אותם (סדרתי או גם אקראי - לפי key וכדו') ומה המחלקה/מבנה שמשמשים לקבוע את ייחדויותו של הערך ואת השוואתו, והאם נלווים לערך נתונים נוספים מלבדו.

בשביל להכניס לרשימה ערכים ייחודיים, יש מחלקה HashSet (גם גנרית), היא עושה את העבודה בשקט (אל תדאג, היא עושה זאת ביעילות) - אפשר להוסיף ערכים והיא מדלגת על קיים (היא מחזירה ערך בוליאני אם הערך הוכנס או לא).
אבל יש עוד הרבה וריאציוות של אוספים, ראה כאן.

פורסם במקור בפורום CODE613 ב07/04/2014 13:22 (+03:00)

דבר ראשון הכותרת לא מספיק מבטאת את שאלתך.
שנית, מנין לך שרשימה מקושרת טובה מלבנות כל פעם מערך חדש?

ובכן, ליסט זה כמו מערך. ומערך, זה הכי מהיר שיש, וגם הכי חסכוני.
הבעיה שלך עם הגדילה של הליסט, זה בעיה שאם תתחבט בה תעשה כמו שמפתחי דוט נט עשו. המתכנת מצידו צריך להשתדל שהגידול יהיה צפוי כפי האפשר, ולהיערך בצורה מאוזנת בין נפח הזיכרון שיש לתפוס ובין תדירות הגידול וכמותו.
הליסט מקבל באחד מבנאיו ערך מספרי שקובע את הצפי הראשוני - זה פשוט בונה מערך בגודל זה.

על כל פנים הלינק שנתת מביא את עיקרון הרשימה מקושרת, שמשמשת להרבה דברים בעקרונות תוכנה.
יש את הדבר הזה בדוט נט בשם LinkedList תוכל לנסות לראות אם הוא מהיר יותר או להיפך.
הנה כמה שבדקו זאת: http://stackoverflow.com/q/169973/1271037, וכאן הסברים לתופעות http://stackoverflow.com/q/5983059/1271037 ועוד http://www.codeproject.com/Articles/340797/Number-crunching-Why-you-should-never-ever-EVER-us.

וכללית, השכל מחייב את ההנחה שכל דבר בדוט בנוי בצורה טובה מאוד, רק שצריך לדעת מה מיועד למה, ומה יש יותר טוב לכל סיטואציה.

פורסם במקור בפורום CODE613 ב06/04/2014 21:33 (+03:00)

@שמואל

בסוף עשיתי טאב קונטרולים לבד ובסופו של דבר בגלל שישנה ביינדינגים לelementName שהוא בעצם שוה גם בכרטיסיות אחרות ממיילא כל התוכנה מסונכרנת יחד ונהיים שיבושים מטורפים
למישהוא יש פיתרון דחוף? (מדובר בתוכנה שכבר בנוייה כך שקשה לחשוב על דרך חזור)
מקוה שהסברתי ברור
תודה!

לכאורה יש כאן ניתוח לא נכון של תופעה.
element Name מוגבל לסקופ השורש הויזואלי של המופע שאותו הוא מייצג.
לדוגמה בחלון, ברמת החלון, ביוזר קונטרול ברמת היוזר קונטרול ואותו דבר סטייל וטמפלט.

הבעיה כנראה שונה, אולי סנכרון בין הCurrentItem של מקור נתונים משותף.

פורסם במקור בפורום CODE613 ב26/05/2014 11:35 (+03:00)

@רחמים

הפקד שהזכרת באמת מרשים אבל אני אישית אוהב את הטאב קונטרול בסגנון של VS שהטאב איטמס לא משתנים ברוחב שלהם וכשלחלקם אין מקום המעבר אליהם מתבצע ע''י חץ קטן מצד ימין שפותח רשימה של כולם.
דבר נוסף שחסר בפקד הזה ביחס לכרום הוא גיררת טאב איטם החוצה ושיהפך לחלון חדש.
ועוד דבר אין שם איקון בראש כל טאב איטם כמו בכרום.

זה השוואה ממש לא נכונה. הרי בכרום לא היית רוצה את השיפורים הללו, כך שאתם מדברים על שתי צרכים.
מה שאתה אוהב זה חלונות עם עגינה יש כמה פרוייקטים חינמיים כאלו בWPF, אני זוכר avalonDock.

פורסם במקור בפורום CODE613 ב08/04/2014 11:22 (+03:00)

בעיקרון לסגור זה להסיר טאב קונטרול.
חייבים לכתוב לזה קוד מסויים.

פורסם במקור בפורום CODE613 ב07/04/2014 16:33 (+03:00)

אפשר לעשות טאב קוטרול, ובמקום חלונות להשתמש בטאב אייטמס.
אם רוצים לארח חלונות ממש, זה סיפור רציני שמצריך מציאת מחלקה מתאימה.

פורסם במקור בפורום CODE613 ב07/04/2014 13:27 (+03:00)

לא כ"כ מבין מה התכווננת עם אקסל, ואקסס אינני מכיר כ"כ.
אתה מתכוון לניהול לוגי או חזותי? אתה רוצה שהחלונות יתארחו בתוך החלון הראשי כמו כרטיסיות של דפדפן? או סרגל ניווט שמציג את כולם ופןץח בחלון נפרד?

פורסם במקור בפורום CODE613 ב06/04/2014 18:50 (+03:00)

לפני הכל אציין שאני לא מבין למה לא עבד לך.

הקוד שהבאת מטפל במקרה כמו של דטה גריד, שיש גם שורות חדשות וגם ישנות שנערכו (לא בהכרח, וודאי שלא בהכרח כולם, כך שהוא לא לגמרי יעיל הקוד הזה, אבל הוא מביא את התוצאות הרצויות).

אופן הבדיקה שלו מתבסס על השדה המפתח שהוא AutoIncerment מה שאומר שהוא 0 באנטיטי שעוד לא היה מעולם במסד, ולאחמ"כ יש לו מספור אוטומטי.
במידה ויש מספר, ממילא המסקנה היא שמדובר בשורה קיימת, ורק צריך להגיד לDbContext שייקח אותה בחשבון (כי הDbContext שמור רק מה שהוא עצמו הביא ושינה, ואילו השורה כאן שונתה לפני שהDbContex נוצר. לכן צריך לקשר אותה לקונטקסט. גם אחרי הקישור, יש לציין לקונקסט שהיא עברה שינוי, כי לפי זה הוא מחליט אם לעדכן.

אגב, לפי מה שקראתי, ההשמה למאפיין State עושה גם קישור בעקיפין כך שהשורה של הקישור מיותרת.

פורסם במקור בפורום CODE613 ב06/04/2014 18:46 (+03:00)

מוצאים את השורה המתאימה משנים ושומרים ככה:

DbContext.SaveChanges().

אם לקחו את האנטיטי מDbContext והDbContext לא קיים כבר בסקופ הנוכחי, אז כשיוצרים חדש צריך "לקשר" בחזרה את האובייקט לקונקסט, זה נראה לי, אדרבה תבדוק ותדווח.

בשביל לקשר כותבים:

DbContext.Attach(Entity)

פורסם במקור בפורום CODE613 ב06/04/2014 17:28 (+03:00)

לא הבנתי. שמירה רגילה?

פורסם במקור בפורום CODE613 ב06/04/2014 16:33 (+03:00)

@רחמים

את התכנון אני משפר בכל עת בלא קשר לנושא הנידון

זהו, שיש תכנון מצד העניין, ויש תכנון בגלל אילוצי השפה - "עם קשר" במקרה זה. ייתכן שהתכנון שלך טוב, ובכל אופן עליך "לשבש" אותו בשביל להפיק את המירב מדוט נט.

פורסם במקור בפורום CODE613 ב06/04/2014 14:15 (+03:00)