Leap year problem
ಅಧಿಕ ವರ್ಷದ ಸಮಸ್ಯೆಯು (ಅಧಿಕ ವರ್ಷದ ದೋಷ ಅಥವಾ ಅಧಿಕ ದಿನದ ದೋಷ ಎಂದೂ ಕರೆಯಲ್ಪಡುತ್ತದೆ) ಡಿಜಿಟಲ್ (ಕಂಪ್ಯೂಟರ್-ಸಂಬಂಧಿತ) ಮತ್ತು ಡಿಜಿಟಲ್ ಅಲ್ಲದ ದಾಖಲಾತಿ ಮತ್ತು ದತ್ತಾಂಶ ಸಂಗ್ರಹಣಾ ಪರಿಸ್ಥಿತಿಗಳೆರಡಕ್ಕೂ ಒಂದು ಸಮಸ್ಯೆಯಾಗಿದ್ದು, ಇದು ಯಾವ ವರ್ಷಗಳು ಅಧಿಕ ವರ್ಷಗಳು ಎಂಬುದರ ಲೆಕ್ಕಾಚಾರದಲ್ಲಿನ ದೋಷಗಳಿಂದ ಅಥವಾ ಅಧಿಕ ವರ್ಷಗಳು ಮತ್ತು ಸಾಮಾನ್ಯ ವರ್ಷಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ಪರಿಗಣಿಸದೆ ದಿನಾಂಕಗಳನ್ನು ಕುಶಲತೆಯಿಂದ ನಿರ್ವಹಿಸುವುದರಿಂದ ಉಂಟಾಗುತ್ತದೆ. ಲೀಪ್ ಇಯರ್ ದೋಷಗಳು ಸಾಮಾನ್ಯವಾಗಿ ನೈಜ-ಪ್ರಪಂಚದ ಬಳಕೆಯಲ್ಲಿ ಅವು ಬೀರಬಹುದಾದ ಪ್ರಭಾವದ ಪ್ರಮಾಣವನ್ನು ಆಧರಿಸಿ ಎರಡು ವರ್ಗಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆಃ ವಿನಾಯಿತಿಗಳು, ದೋಷ ರಿಟರ್ನ್ ಕೋಡ್ಗಳು, ಪ್ರಾರಂಭಿಸದ ಅಸ್ಥಿರಗಳು ಅಥವಾ ಅಂತ್ಯವಿಲ್ಲದ ಲೂಪ್ಗಳಂತಹ ದೋಷ ಪರಿಸ್ಥಿತಿಗಳಿಗೆ ಕಾರಣವಾಗುವಂತಹವು, ಅವು ತಪ್ಪಾದ ದತ್ತಾಂಶಕ್ಕೆ ಕಾರಣವಾಗುತ್ತವೆ, ಉದಾಹರಣೆಗೆ ಶ್ರೇಣಿಯ ಪ್ರಶ್ನೆಗಳು ಅಥವಾ ಒಟ್ಟುಗೂಡಿಸುವಿಕೆಯಲ್ಲಿನ ಆಫ್-ಬೈ-ಒನ್ ಸಮಸ್ಯೆಗಳು ಉದಾಹರಣೆಗೆ ಪೈಥಾನ್ ಈ ಕೆಳಗಿನ ಪೈಥಾನ್ ಕೋಡ್ 1ನೇ ವರ್ಗದ ಲೀಪ್ ಇಯರ್ ದೋಷಕ್ಕೆ ಒಂದು ಉದಾಹರಣೆಯಾಗಿದೆ. ಇದು ಇಂದು ಫೆಬ್ರವರಿ 29 ರವರೆಗೆ ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ನಂತರ, ಅದು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಸಾಮಾನ್ಯ ವರ್ಷದ ಫೆಬ್ರವರಿ 29 ಅನ್ನು ರಚಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಡೇಟ್ ಕನ್ಸ್ಟ್ರಕ್ಟರ್ "ದಿನವು ತಿಂಗಳ ವ್ಯಾಪ್ತಿಯಿಂದ ಹೊರಗಿದೆ" ಎಂಬ ಸಂದೇಶದೊಂದಿಗೆ ವ್ಯಾಲ್ಯೂ ಎರರ್ ಅನ್ನು ಎತ್ತುತ್ತದೆ. ದಿನಾಂಕದ ಆಮದು ದಿನಾಂಕದಿಂದ ಇಂದು = date.today () ನಂತರ = today.replace (ವರ್ಷ = today.year + 1) ವಿಂಡೋಸ್ ಸಿ + + ಈ ಕೆಳಗಿನ ವಿಂಡೋಸ್ ಸಿ + + ಕೋಡ್ 1ನೇ ವರ್ಗದ ಅಧಿಕ ವರ್ಷದ ದೋಷಕ್ಕೆ ಒಂದು ಉದಾಹರಣೆಯಾಗಿದೆ. ಪ್ರಸ್ತುತ ದಿನಾಂಕವು ಅಧಿಕ ವರ್ಷದ ಫೆಬ್ರವರಿ 29 ಆಗುವವರೆಗೆ ಇದು ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ನಂತರ, ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರದ ದಿನಾಂಕವಾದ ಸಾಮಾನ್ಯ ವರ್ಷದ ಫೆಬ್ರವರಿ 29 ಅನ್ನು ಪ್ರತಿನಿಧಿಸಲು ಕ್ರಮವನ್ನು ಮಾರ್ಪಡಿಸುತ್ತದೆ. ಸಿಸ್ಟೆಮ್ಟೈಮ್ ರಚನೆಯನ್ನು ನಿಯತಾಂಕವಾಗಿ ಸ್ವೀಕರಿಸುವ ಯಾವುದೇ ಕಾರ್ಯಕ್ಕೆ ST ಅನ್ನು ರವಾನಿಸುವುದು ವಿಫಲವಾಗಬಹುದು. ಉದಾಹರಣೆಗೆ, ಇಲ್ಲಿ ತೋರಿಸಲಾಗಿರುವ ಸಿಸ್ಟಮ್ ಟೈಮ್ ಟು ಫೈಲ್ ಟೈಮ್ ಕರೆಯು ದೋಷ ಸಂಕೇತವನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ. ಆ ರಿಟರ್ನ್ ಮೌಲ್ಯವನ್ನು ಪರಿಶೀಲಿಸದ ಕಾರಣ (ಇದು ಅತ್ಯಂತ ಸಾಮಾನ್ಯವಾಗಿದೆ), ಇದು ಎಫ್ ಟಿ ಅನ್ನು ಪ್ರಾರಂಭಿಸದೆ ಬಿಡಲು ಕಾರಣವಾಗುತ್ತದೆ. ಸಿಸ್ಟಮ್ ಸ್ಟಂಟ್; ಫೈಲ್ ಟೈಮ್ ಅಡಿ; ಗೆಟ್ಸಿಸ್ಟಮ್ ಟೈಮ್ (& ಸ್ಟ); st.wYear + +; ಸಿಸ್ಟಮ್ ಟೈಮ್ ಟು ಫೈಲ್ ಟೈಮ್ (& ಸ್ಟ, & ಫು); ಮೈಕ್ರೋಸಾಫ್ಟ್ ಸಿ #ಈ ಕೆಳಗಿನ. ನೆಟ್ ಸಿ #ಕೋಡ್ ಲೀಪ್ ಇಯರ್ 1ನೇ ವರ್ಗದ ದೋಷಕ್ಕೆ ಒಂದು ಉದಾಹರಣೆಯಾಗಿದೆ. ಇದು ಫೆಬ್ರವರಿ 29 ರವರೆಗೆ ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ನಂತರ, ಅದು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಸಾಮಾನ್ಯ ವರ್ಷದ ಫೆಬ್ರವರಿ 29 ಅನ್ನು ರಚಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಡೇಟ್ ಟೈಮ್ ಕನ್ಸ್ಟ್ರಕ್ಟರ್ ಆರ್ಗ್ಯುಮೆಂಟ್ ಔಟ್ ಆಫ್ ರೇಂಜ್ ಎಕ್ಸೆಪ್ಶನ್ ಅನ್ನು ಎಸೆಯುತ್ತದೆ. ಡೇಟ್ ಟೈಮ್ ಡಿಟಿ = DateTime.Now; ಡೇಟ್ ಟೈಮ್ ಫಲಿತಾಂಶ = ಹೊಸ ಡೇಟ್ ಟೈಮ್ (dt.Year + 1, dt.Month, dt.Day); ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಈ ಕೆಳಗಿನ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಕೋಡ್ ವರ್ಗ 2 ಅಧಿಕ ವರ್ಷದ ದೋಷಕ್ಕೆ ಒಂದು ಉದಾಹರಣೆಯಾಗಿದೆ. ಇದು ಫೆಬ್ರವರಿ 29 ರವರೆಗೆ ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ 2020-02-29 ನಲ್ಲಿ. ನಂತರ ಅದು ವರ್ಷವನ್ನು 2021ಕ್ಕೆ ನಿಗದಿಪಡಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. 2021-02-29 ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಕಾರಣ, ಡೇಟ್ ಆಬ್ಜೆಕ್ಟ್ ಮುಂದಿನ ಮಾನ್ಯ ದಿನಾಂಕಕ್ಕೆ ಮುಂದುವರಿಯುತ್ತದೆ, ಅದು 2021-03-01. ವರ್ dt = ಹೊಸ ದಿನಾಂಕ (); dt.setFullYear (dt.getFullYear () + 1); ಬ್ಯಾಡ್ ಲೀಪ್ ಇಯರ್ ಅಲ್ಗಾರಿದಮ್ (ಅನೇಕ ಭಾಷೆಗಳು) ಈ ಕೆಳಗಿನ ಕೋಡ್ ಅನೇಕ ಭಾಷೆಗಳಲ್ಲಿ ಕಂಡುಬರುವ ಅಧಿಕ ವರ್ಷದ ದೋಷಕ್ಕೆ ಒಂದು ಉದಾಹರಣೆಯಾಗಿದೆ. ಫಲಿತಾಂಶವನ್ನು ಯಾವುದಕ್ಕೆ ಬಳಸಲಾಗುತ್ತದೆ ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ ಇದು ವರ್ಗ 1 ಅಥವಾ ವರ್ಗ 2ರ ಪರಿಣಾಮವನ್ನು ಉಂಟುಮಾಡಬಹುದು. ಒಂದು ಅಧಿಕ ವರ್ಷವು ನಿಖರವಾಗಿ ಪ್ರತಿ ನಾಲ್ಕು ವರ್ಷಗಳಿಗೊಮ್ಮೆ ಬರುತ್ತದೆ ಎಂದು ಅದು ತಪ್ಪಾಗಿ ಊಹಿಸುತ್ತದೆ. ಬೂಲ್ ಲೀಪ್ ಇಯರ್ = ವರ್ಷ% 4 = = 0 ಆಗಿದೆ; ಲೀಪ್ ಇಯರ್ ಅಲ್ಗಾರಿದಮ್ನಲ್ಲಿ ಸರಿಯಾದ ಲೀಪ್ ಇಯರ್ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ವಿವರಿಸಲಾಗಿದೆ. ಮೈಕ್ರೋಸಾಫ್ಟ್ ಎಕ್ಸೆಲ್ ತನ್ನ ಆರಂಭಿಕ ಆವೃತ್ತಿಗಳಿಂದ, 1900 ಅನ್ನು ಅಧಿಕ ವರ್ಷವೆಂದು ತಪ್ಪಾಗಿ ಪರಿಗಣಿಸಿದೆ ಮತ್ತು ಆದ್ದರಿಂದ ಫೆಬ್ರವರಿ 29 ಆ ವರ್ಷದ ಫೆಬ್ರವರಿ 28 ಮತ್ತು ಮಾರ್ಚ್ 1 ರ ನಡುವೆ ಬರುತ್ತದೆ. ದೋಷವು ಲೋಟಸ್ 1-2-3 ನಿಂದ ಹುಟ್ಟಿಕೊಂಡಿತು, ಮತ್ತು ಹಿಂದುಳಿದ ಹೊಂದಾಣಿಕೆಯ ಉದ್ದೇಶಕ್ಕಾಗಿ ಎಕ್ಸೆಲ್ನಲ್ಲಿ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಯಿತು. 1900 ಅನ್ನು ಅಧಿಕ ವರ್ಷವೆಂದು ಪರಿಗಣಿಸಲು ಕಾರಣಗಳನ್ನು ವಿವರಿಸುತ್ತಾ ಮೈಕ್ರೋಸಾಫ್ಟ್ ಈ ದೋಷದ ಬಗ್ಗೆ ಒಂದು ಲೇಖನವನ್ನು ಬರೆದಿದೆ. ಈ ದೋಷವನ್ನು ಇ. ಸಿ. ಎಂ. ಎ. ಆಫೀಸ್ ಓಪನ್ ಎಕ್ಸ್. ಎಂ. ಎಲ್. (ಓ. ಓ. ಎಕ್ಸ್. ಎಂ. ಎಲ್.) ವಿವರಣೆಯಲ್ಲಿ ಅವಶ್ಯಕತೆಯಾಗಿ ಪ್ರಚಾರ ಮಾಡಲಾಗಿದೆ. 1996ರಲ್ಲಿ, ಡಿಸೆಂಬರ್ 31ರಂದು, ನ್ಯೂಜಿಲೆಂಡ್ನ ತಿವಾಯಿ ಪಾಯಿಂಟ್ ಮತ್ತು ಆಸ್ಟ್ರೇಲಿಯಾದ ಟ್ಯಾಸ್ಮೆನಿಯಾದ ಬೆಲ್ ಕೊಲ್ಲಿಯಲ್ಲಿರುವ ಎರಡು ಅಲ್ಯೂಮಿನಿಯಂ ಕರಗಿಸುವ ಘಟಕಗಳಲ್ಲಿ, ಕರಗಿಸುವ ಪಾಟ್ಲೈನ್ಗಳನ್ನು ನಿಯಂತ್ರಿಸುವ 660 ಕಂಪ್ಯೂಟರ್ಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಮಧ್ಯರಾತ್ರಿಯಲ್ಲಿ ಸ್ಥಗಿತಗೊಂಡವು, ಏಕೆಂದರೆ ವರ್ಷದ 366ನೇ ದಿನವನ್ನು ನಿರ್ವಹಿಸಲು ಕಂಪ್ಯೂಟರ್ಗಳನ್ನು ಪ್ರೋಗ್ರಾಮ್ ಮಾಡಲಾಗಿಲ್ಲ. ದುರಸ್ತಿ ವೆಚ್ಚವು ಅದಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿದೆ ಎಂದು ಅಂದಾಜಿಸಲಾಗಿದೆ. 2000 ರಲ್ಲಿ, ಡಿಸೆಂಬರ್ 31 ರಂದು, ನಾರ್ವೆಯಲ್ಲಿ ರಾಷ್ಟ್ರೀಯ ರೈಲ್ರೋಡ್ ಕಂಪನಿ ವೈ ತನ್ನ ಎಲ್ಲಾ 29 ಹೊಸ ಸಿಗ್ನಾಟುರ್ ರೈಲುಗಳು ಓಡಲು ವಿಫಲವಾಗಿವೆ ಎಂದು ಕಂಡುಹಿಡಿದಿದೆ ಏಕೆಂದರೆ ಅವರ ಆನ್ಬೋರ್ಡ್ ಕಂಪ್ಯೂಟರ್ಗಳು ದಿನಾಂಕವನ್ನು ವರ್ಷದ 366 ನೇ ದಿನವೆಂದು ಗುರುತಿಸಲಿಲ್ಲ. ಮಧ್ಯಂತರ ಕ್ರಮವಾಗಿ, ಎಂಜಿನಿಯರ್ಗಳು ತಮ್ಮ ಗಡಿಯಾರಗಳನ್ನು ಒಂದು ತಿಂಗಳ ಹಿಂದಕ್ಕೆ ಮರುಹೊಂದಿಸುವ ಮೂಲಕ ರೈಲುಗಳನ್ನು ಪುನರಾರಂಭಿಸಿದರು. ಡಿಸೆಂಬರ್ 31,2008ರ ಮಧ್ಯರಾತ್ರಿಯ ವೇಳೆಗೆ, ಅನೇಕ ಮೊದಲ ತಲೆಮಾರಿನ ಝೂನ್ 30 ಮಾದರಿಗಳು ಸ್ಥಗಿತಗೊಂಡವು. ಫ್ರೀಸ್ಕೇಲ್ ಬರೆದ ಆಂತರಿಕ ಗಡಿಯಾರ ಚಾಲಕ ಮತ್ತು ಸಾಧನವು ಅಧಿಕ ವರ್ಷವನ್ನು ನಿರ್ವಹಿಸುವ ವಿಧಾನದಿಂದ ಈ ಸಮಸ್ಯೆ ಉಂಟಾಗಿದೆ ಎಂದು ಮೈಕ್ರೋಸಾಫ್ಟ್ ಹೇಳಿದೆ. ಇದು 24 ಗಂಟೆಗಳ ನಂತರ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ತನ್ನನ್ನು ತಾನೇ ಸರಿಪಡಿಸಿಕೊಂಡಿತು, ಆದರೆ ಕಾಯಲು ಬಯಸದವರಿಗೆ ಮಧ್ಯಂತರ "ಪರಿಹಾರ" ಎಂದರೆ ಸಾಧನದ ಬ್ಯಾಟರಿಯನ್ನು ಹರಿಸುವುದು ಮತ್ತು ನಂತರ ಜನವರಿ 1,2009 ರಂದು ಮಧ್ಯಾಹ್ನ ಯುಟಿಸಿ ನಂತರ ರೀಚಾರ್ಜ್ ಮಾಡುವುದು. ಸೋನಿಯ ಪ್ಲೇಸ್ಟೇಷನ್ 3 ತಪ್ಪಾಗಿ 2010 ಅನ್ನು ಅಧಿಕ ವರ್ಷವೆಂದು ಪರಿಗಣಿಸಿದೆ, ಆದ್ದರಿಂದ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಫೆಬ್ರವರಿ 29,2010 ಅನ್ನು ಮಾರ್ಚ್ 1,2010 ರಂದು ತೋರಿಸಲಾಯಿತು ಮತ್ತು ಪ್ರೋಗ್ರಾಂ ದೋಷವನ್ನು ಉಂಟುಮಾಡಿತು. 2012 ರಲ್ಲಿ, ಮಾರ್ಚ್ 31 ರಂದು ಮೊದಲ ಬಾರಿಗೆ ಹೊರಹೊಮ್ಮಿದ ಅಧಿಕ ವರ್ಷದ ದೋಷದಿಂದಾಗಿ ಟಾಮ್ಟಾಮ್ ಉಪಗ್ರಹ ನ್ಯಾವಿಗೇಷನ್ ಸಾಧನಗಳು ಅಸಮರ್ಪಕವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದವು. 2012 ರಲ್ಲಿ, ಜಿಮೇಲ್ನ ಚಾಟ್ ಇತಿಹಾಸವು ಫೆಬ್ರವರಿ 29 ರಂದು ಉಳಿಸಲಾದ ಎಲ್ಲಾ ಚಾಟ್ಗಳಿಗೆ ಡಿಸೆಂಬರ್ 31,1969 ರ ದಿನಾಂಕವನ್ನು ತೋರಿಸಿತು. 2012 ರಲ್ಲಿ, ಮೈಕ್ರೋಸಾಫ್ಟ್ ಅಜುರೆಯನ್ನು ಫೆಬ್ರವರಿ 28 ರಂದು ಅಧಿಕ ವರ್ಷದ ದೋಷದಿಂದ ಆಫ್ಲೈನ್ನಲ್ಲಿ ತೆಗೆದುಕೊಳ್ಳಲಾಯಿತು. ಸಂಜೆ 5.45 ಕ್ಕೆ ಪಿ. ಎಸ್. ಟಿ. ಯಲ್ಲಿ ವಿಂಡೋಸ್ ಅಜೂರ್ ತಂಡವು ಒಂದು ಸಮಸ್ಯೆಯ ಬಗ್ಗೆ ತಿಳಿದುಕೊಂಡಿತು, ಇದು ಅಧಿಕ ವರ್ಷಕ್ಕೆ ತಪ್ಪಾದ ಸಮಯದ ಲೆಕ್ಕಾಚಾರದಿಂದಾಗಿ. 2016ರಲ್ಲಿ, ಕೋಡ್ ಆಫ್ ಮ್ಯಾಟ್ ಜಾಲತಾಣದ 2016ರ ಲೀಪ್ ಡೇ ಬಗ್ಗಳ ಪಟ್ಟಿಯಲ್ಲಿ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಲೀಪ್ ವರ್ಷದ ದೋಷಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಲಾಗಿದೆ. 2016 ರಲ್ಲಿ, ಫೆಬ್ರವರಿ 29 ರಂದು ಡಸೆಲ್ಡಾರ್ಫ್ ವಿಮಾನ ನಿಲ್ದಾಣದಲ್ಲಿ ಲಗೇಜ್ ಕನ್ವೇಯರ್ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಅಧಿಕ ವರ್ಷದ ದೋಷವು 1,200 ಕ್ಕೂ ಹೆಚ್ಚು ಸಾಮಾನುಗಳನ್ನು ತಮ್ಮ ವಿಮಾನಗಳನ್ನು ತಪ್ಪಿಸಲು ಕಾರಣವಾಯಿತು. 2020ರಲ್ಲಿ ಕೋಡ್ ಆಫ್ ಮ್ಯಾಟ್ ಜಾಲತಾಣದ 2020ರ ಲೀಪ್ ಡೇ ಬಗ್ಗಳ ಪಟ್ಟಿಯಲ್ಲಿ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಲೀಪ್ ವರ್ಷದ ದೋಷಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಲಾಗಿದೆ. ಟೈಮ್ ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ಮತ್ತು ಶೇಖರಣಾ ದೋಷಗಳು ವರ್ಷ 2100 ಸಮಸ್ಯೆಯ ಉಲ್ಲೇಖಗಳು ಟೈಮ್ ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ಮತ್ತು ಶೇಖರಣಾ ದೋಷಗಳು ಕ್ಯಾಲೆಂಡರ್ ಸಾಫ್ಟ್ವೇರ್ ದೋಷಗಳು ತಂತ್ರಜ್ಞಾನದ ಅಪಾಯಗಳನ್ನು ಸಹ ನೋಡಿ.