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

הרעיון של ספירת האפסים לכאורה נכון ומהיר יותר מהרעיונות האחרים.

מה שכתבת
@רחמים

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

זה לא בדיוק מה שהצעתי לעיל?

פורסם במקור בפורום CODE613 ב21/07/2013 13:58 (+03:00)

@רחמים

@magicode

עכשיו אני מקבל את זה בצורת מערך של 64 אברים שכל אבר מכיל ערך לדוגמא מ 0 עד 1. כל אבר מיצג בתמונה קו ואם הוא 100 הקו מופיע עד למעלה ואם הוא 0 הוא לא מופיע בכלל ואם הוא 0.5 הוא מופיע חצי וכן הלאה.

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

חשב את הממוצע של כל האברים במערך אם הממוצע מעל 50 בוודאי שזה מצולם ואם פחות מ 10 בוודאי שזה ציור.
וכמובן ממוצע זה חיבור של כל האיברים לחלק במספר האיברים.

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

פורסם במקור בפורום CODE613 ב21/07/2013 12:18 (+03:00)

@magicode

STDEV.P זה נוסחה שקיימת באקסל ?

2010..

בקודמים יש STDEVP.

פורסם במקור בפורום CODE613 ב18/07/2013 12:37 (+03:00)

איזה מאתגר הנושא

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

הנה דוגמא מאקסל, שתי טורים, הימיני כאילו ציור והשמאלי תמונה:
0.80 0.20
0.00 0.25
0.00 0.30
0.30 0.35
0.00 0.40
0.00 0.35
0.40 0.30
0.00 0.25
0.00 0.20
0.00 0.15

התוצאה של הנוסחה STDEV.P (סטיית התקן מלאה לא מדגמית)
0.257875939 לטור הימני.
0.075 לטור השמאלי.

פורסם במקור בפורום CODE613 ב18/07/2013 11:15 (+03:00)

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

רחמים, אין לך סיבה למהר, אבל אם יום אחד נמאס לך מWinForms,
אתה תקפוץ לWPF.

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

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

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

פורסם במקור בפורום CODE613 ב18/07/2013 10:48 (+03:00)

@ClickOne

בעיקרון LINQ מתחלק לכמה חלקים:
אם השאילתא פשוטה, כמו SELECT, הוא ממיר את השאילתא למחרוזת SQL, מריץ את זה בשרת, ומציף את הליסט בנתונים.
אם השאילתא יותר מורכבת, הוא "מנסה" להמיר אותה לפרוצדורה של SQL, מריץ אותה בשרת וכו'
ואם עשינו בשאילתא הפניות לפונקציות פנימיות אז:
[list:uzb1e9br][:uzb1e9br]אם הוא יכול להמיר גם את הפונקציה ההיא הוא ממיר אותה[/uzb1e9br]
[:uzb1e9br]אם הוא לא יכול, הוא קורה לכל הרשומות ומריץ את כל התהליך.[/uzb1e9br][/list:u:uzb1e9br]
איך אני יודע?
יש כלי מעקב על השרת שמראה את כל הבקשות שרצות.
בעז"ה אני ישתדל להראות כמה דוגמאות בקרוב.

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

שלום!
אתה מדבר על LinqToSql, אנחנו דיברנו על LINQ רגיל, ToObject.
אתה משתמש הרבה עם LinqToSql? שווה? אני מעולם לא ניסיתי.
מיקרוספט זנחו אותו לטובת Entity, ולEntity לא הצלחתי להתחבר, אז אני עובד עם ADO הרגיל.

פורסם במקור בפורום CODE613 ב30/12/2013 10:28 (+02:00)

הנה בדיקות כאלו בדיוק מהרשת:
לרעת לינק:
http://ox.no/posts/linq-vs-loop-a-performance-test
http://social.msdn.microsoft.com/Forums/en-US/facff412-118a-4a80-867a-66503463a638/measure-the-performance-of-a-linq-sort
http://martin.podval.eu/2010/10/c-sharp-linq-or-foreach-performance.html
http://www.alexyork.net/blog/2008/09/14/performance-of-foreach-loops-vs-linq/
http://www.codeproject.com/Articles/21934/LINQ-Performance-Test-My-First-Visual-Studio-2008http://www.dotnetscraps.com/dotnetscraps/post/linq-performance-part-1-linq-to-collection.aspx

בלוג שמדבר הרבה על זה:
http://msmvps.com/blogs/jon_skeet/default.aspx

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

אבל יש כללים הגיוניים.
לדוגמא לבדוק אם רשימה ריקה, עדיף לבדוק ע"י פונקציית Any שמחזירה לא במקרה ריק מאשר להשוות את Count לאפס.
זה ברור כשמש, בפרט כאשר התוצאה היא שיש איברים אבל אפי' במקרה שאין.
אולי נבנה רשימה של כאלה המלצות.

פורסם במקור בפורום CODE613 ב18/07/2013 18:23 (+03:00)

@ארכיטקט

אני לא יודע איך לבדוק זאת.

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

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

פורסם במקור בפורום CODE613 ב18/07/2013 16:56 (+03:00)

ביצועים בLinq זו שאלה כבדת משקל.
בעצם לכאורה אנו שוב זונחים את שקלולי הביצועים לטובת נוחות.
אז דבר ראשון, זו החלטה נבונה ברוב המקרים.
דבר שני, ברוב המקרים Linq יעיל בבירור.

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

לפעמים אפשר ממש לתהות ביכולתיו של הlinq.
לדוגמה יש לנו מערך מספרים שלמים, ואנו רוצים לקחת את כל הגדולים ממאה, ובצורה ממויינת.
איך היינו עושים ללא לינק?
[u:37lq31qk]הדרך הפשוטה:[/u:37lq31qk]
א. ממיינים ע"י Array.Sort.
ב. מתקדמים מהקצה התחתון בלולאה עד שמגיעים למאה, ומשמה מעתיקים את המערך.
[u:37lq31qk]או הרבה יותר טוב והרבה יותר נחות (מתאים לאנשי C++) [/u:37lq31qk]
למיין בעצמנו, ואז תוך כדי להשמיט איברים גדולים ממאה.

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

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

פורסם במקור בפורום CODE613 ב18/07/2013 11:38 (+03:00)

@שמואל

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

בא נשווה זאת לif בC#.

המבנה של if הוא כזה:
אם X = "כן" תעשה א
אם X = "לא" תעשה ב
אחרת (else) תעשה ג

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

ומה אם מקרה שאנו רוצים לדעת כן/לא על ביטוי לא שויוני; לדוגמה אם X גדול מ2?
אז א"א להשתמש עם טריגר.
בשביל זה עושים קונברטר, ואז "כורכים" (בינדינג) את העיצוב לX עם הקונברטר שיבדוק כל תנאי שבעולם ולפי זה יחזיר ערך מתאים לעיצוב.

פורסם במקור בפורום CODE613 ב18/07/2013 12:11 (+03:00)

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

מעניין איפה הבאג, אבל העיקר שעובד.

פורסם במקור בפורום CODE613 ב14/07/2013 22:28 (+03:00)

ניסיתי משהו דומה אצלי והכל עובד. מעניין מה קורה שמה.
(דוקא לי היו בעיות עם הביינדיגים).

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

פורסם במקור בפורום CODE613 ב11/07/2013 13:12 (+03:00)

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

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

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

פורסם במקור בפורום CODE613 ב04/02/2015 12:02 (+02:00)

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

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

בהצלחה רבה ומקוה לשמוע ממך פה יותר!

פורסם במקור בפורום CODE613 ב04/02/2015 11:14 (+02:00)

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

פורסם במקור בפורום CODE613 ב16/01/2014 13:30 (+02:00)

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

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

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

פורסם במקור בפורום CODE613 ב11/07/2013 11:31 (+03:00)

שכחתי להוסיף את הטולטיפ,
אז בשביל טולטיפ זהה לHeader, במקום השורה דלעיל שימי את זה:

<ContentPresenter Margin="10 0 0 0" VerticalAlignment="Center" Grid.Column="1" Content="{TemplateBinding HeaderedContentControl.Header}" ContentTemplate="{TemplateBinding HeaderedContentControl.HeaderTemplate}" ContentStringFormat="{TemplateBinding HeaderedContentControl.HeaderStringFormat}" ContentSource="Header">
    <ContentPresenter.ToolTip>
        <ContentControl Content="{TemplateBinding Header}" ContentTemplate="{TemplateBinding HeaderedContentControl.HeaderTemplate}" />
    </ContentPresenter.ToolTip>
</ContentPresenter>

פורסם במקור בפורום CODE613 ב11/07/2013 20:08 (+03:00)

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

<Label Margin="10 0 0 0" VerticalAlignment="Center" Content="{TemplateBinding Header}" 
Grid.Column="1" />

תחליפי בזו:

<ContentPresenter Margin="10 0 0 0" VerticalAlignment="Center"  Grid.Column="1"
 Content="{TemplateBinding HeaderedContentControl.Header}" ContentTemplate="{TemplateBinding HeaderedContentControl.HeaderTemplate}" ContentStringFormat="{TemplateBinding HeaderedContentControl.HeaderStringFormat}" ContentSource="Header" />

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

פורסם במקור בפורום CODE613 ב11/07/2013 19:52 (+03:00)

סתם בשביל הטסט,
מה קורה שאת מורידה לגמרי את השורה של הטקסטבוקס בטמפלט,
ומשאירה רק את האייקון?

פורסם במקור בפורום CODE613 ב10/07/2013 21:41 (+03:00)

מעניין.
אגב למה בהרצה? בזמן עיצוב לא מופיע כלום?

פורסם במקור בפורום CODE613 ב10/07/2013 16:15 (+03:00)