Date and Timestamp comparison
Locked
1234
1234
Date and Timestamp comparison
 
|
Hmm,
june23ts := Timestamp fromSeconds: 3328473600. june26dt := june23ts asDate addDays: 3. june26dt < june23ts "false" june26dt > june23ts "false" Shouldn't this either blow up or actually do the right thing? It does neither at the moment, which manifests in very subtle bugs on occasion. Joerg tells me there's even an AR for this somewhere from a while back. Cheers! -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. |
smime.p7s (4K)
RE: Date and Timestamp comparison
|
|
IMO, it should do the "right thing". Given that june26dt is three days
ahead of june23ts... "june26dt < june23ts" should return false for the same reason that "4 < 4.0" returns false. "june26dt > june23ts" should return true for the same reason that "4 > 4.0" returns false. "june26dt = june23ts" should return false for the same reason that "4 = 4.0" returns true. The date should be coerced to a Timestamp for comparison. #coerce: is currently defined for ArithmaticValue. #coerce: isn't well suited for most other subclasses of Magnitude so I propose adding the class Chronometric as a subclass of Magnitude. Chronometric would support coersion and be the superclass of all Date/Time classes. A generic description of a Chronometric is 'a number of standard and deterministic increments of a given precision from an epoch'. Coersion would be toward the highest precision and coersion would adjust for epoch differences. "Standard increments" means increments adjusted to GMT/UTC (when relevant to a chronometic being compared). "Deterministic increments" means leap durations do not cause duplication (when relevant to a chronometic being compared). If standard/deterministic increments are expected of one chronometic but are not known by another then the later would convert using the current timezone and ignoring leap durations. Standard chronometric conversion methods would make it easy to create and compare new subclasses with little hassle. The workaround is to do explicit coersion like this: june26dt asTimestamp < june23ts asTimestamp. "false" june26dt asTimestamp > june23ts asTimestamp. "true" june26dt asTimestamp = june23ts asTimestamp. "false" Paul Baumann -----Original Message----- From: Boris Popov [mailto:[hidden email]] Sent: Thursday, July 27, 2006 11:05 AM To: [hidden email] Subject: Date and Timestamp comparison Hmm, june23ts := Timestamp fromSeconds: 3328473600. june26dt := june23ts asDate addDays: 3. june26dt < june23ts "false" june26dt > june23ts "false" Shouldn't this either blow up or actually do the right thing? It does neither at the moment, which manifests in very subtle bugs on occasion. Joerg tells me there's even an AR for this somewhere from a while back. Cheers! -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. -------------------------------------------------------- This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. |
RE: Date and Timestamp comparison
|
|
I agree, it should just coerce them automagically. Also, as far as your
suggestion to do the coercion by hand, clearly that's the way to do it, unfortunately often you come across code which you would not suspect as being of disperate types, and therefore subtle bugs are introduced. self documents reject: [:ea | ea received > self deadline] where #received could be a timestamp and #deadline could be a date. Cheers! -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. -----Original Message----- From: Paul Baumann [mailto:[hidden email]] Sent: Thursday, July 27, 2006 11:31 AM To: Boris Popov; [hidden email] Subject: RE: Date and Timestamp comparison IMO, it should do the "right thing". Given that june26dt is three days ahead of june23ts... "june26dt < june23ts" should return false for the same reason that "4 < 4.0" returns false. "june26dt > june23ts" should return true for the same reason that "4 > 4.0" returns false. "june26dt = june23ts" should return false for the same reason that "4 = 4.0" returns true. The date should be coerced to a Timestamp for comparison. #coerce: is currently defined for ArithmaticValue. #coerce: isn't well suited for most other subclasses of Magnitude so I propose adding the class Chronometric as a subclass of Magnitude. Chronometric would support coersion and be the superclass of all Date/Time classes. A generic description of a Chronometric is 'a number of standard and deterministic increments of a given precision from an epoch'. Coersion would be toward the highest precision and coersion would adjust for epoch differences. "Standard increments" means increments adjusted to GMT/UTC (when relevant to a chronometic being compared). "Deterministic increments" means leap durations do not cause duplication (when relevant to a chronometic being compared). If standard/deterministic increments are expected of one chronometic but are not known by another then the later would convert using the current timezone and ignoring leap durations. Standard chronometric conversion methods would make it easy to create and compare new subclasses with little hassle. The workaround is to do explicit coersion like this: june26dt asTimestamp < june23ts asTimestamp. "false" june26dt asTimestamp > june23ts asTimestamp. "true" june26dt asTimestamp = june23ts asTimestamp. "false" Paul Baumann -----Original Message----- From: Boris Popov [mailto:[hidden email]] Sent: Thursday, July 27, 2006 11:05 AM To: [hidden email] Subject: Date and Timestamp comparison Hmm, june23ts := Timestamp fromSeconds: 3328473600. june26dt := june23ts asDate addDays: 3. june26dt < june23ts "false" june26dt > june23ts "false" Shouldn't this either blow up or actually do the right thing? It does neither at the moment, which manifests in very subtle bugs on occasion. Joerg tells me there's even an AR for this somewhere from a while back. Cheers! -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. -------------------------------------------------------- This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. |
RE: Date and Timestamp comparison
|
|
There could however be differences in comparison of mixed date and timestamp with > and <.
Should the timestamp (in ISO format for i18n) 2006-01-01-12-00-00 be greater than 2006-01-01 or equal? If you want date presision, it would be equal. If you want timestamp precision, the date should be coerced to the date with time zero and then is less than 12:00. Depends on what your intention for the tests are. And which side of the comparison should drive the coercion, left or right, timestamp or date? Coercing towards highest precision of the two fails for date comparisons on a date and a timestamp that should return equality for the date part. You would also introduce floor and ceiling to timestamps, or - as we did - floor/ceilingTo: aPrecision (means, floor to 5 minutes interval, ceiling to next full hour, ...), since for some tests a second difference doesn't matter. So I have doubts that you can implement a general solution and won't need explicit coercion to be safe. Just my 2c Thomas > -----Original Message----- > From: Boris Popov [mailto:[hidden email]] > Sent: Friday, July 28, 2006 2:16 AM > To: Paul Baumann; [hidden email] > Subject: RE: Date and Timestamp comparison > > I agree, it should just coerce them automagically. Also, as > far as your > suggestion to do the coercion by hand, clearly that's the way > to do it, > unfortunately often you come across code which you would not > suspect as > being of disperate types, and therefore subtle bugs are introduced. > > self documents reject: [:ea | ea received > self deadline] > > where #received could be a timestamp and #deadline could be a date. > > Cheers! > > -Boris > > -- > +1.604.689.0322 > DeepCove Labs Ltd. > 4th floor 595 Howe Street > Vancouver, Canada V6C 2T5 > > [hidden email] > > CONFIDENTIALITY NOTICE > > This email is intended only for the persons named in the message > header. Unless otherwise indicated, it contains information that is > private and confidential. If you have received it in error, please > notify the sender and delete the entire message including any > attachments. > > Thank you. > > -----Original Message----- > From: Paul Baumann [mailto:[hidden email]] > Sent: Thursday, July 27, 2006 11:31 AM > To: Boris Popov; [hidden email] > Subject: RE: Date and Timestamp comparison > > IMO, it should do the "right thing". Given that june26dt is three days > ahead of june23ts... > > "june26dt < june23ts" should return false for the same > reason that "4 < > 4.0" returns false. > "june26dt > june23ts" should return true for the same reason > that "4 > > 4.0" returns false. > "june26dt = june23ts" should return false for the same > reason that "4 = > 4.0" returns true. > > The date should be coerced to a Timestamp for comparison. #coerce: is > currently defined for ArithmaticValue. #coerce: isn't well suited for > most other subclasses of Magnitude so I propose adding the class > Chronometric as a subclass of Magnitude. Chronometric would support > coersion and be the superclass of all Date/Time classes. A generic > description of a Chronometric is 'a number of standard and > deterministic > increments of a given precision from an epoch'. Coersion > would be toward > the highest precision and coersion would adjust for epoch differences. > "Standard increments" means increments adjusted to GMT/UTC (when > relevant to a chronometic being compared). "Deterministic increments" > means leap durations do not cause duplication (when relevant to a > chronometic being compared). If standard/deterministic increments are > expected of one chronometic but are not known by another then > the later > would convert using the current timezone and ignoring leap durations. > Standard chronometric conversion methods would make it easy to create > and compare new subclasses with little hassle. > > The workaround is to do explicit coersion like this: > june26dt asTimestamp < june23ts asTimestamp. "false" > june26dt asTimestamp > june23ts asTimestamp. "true" > june26dt asTimestamp = june23ts asTimestamp. "false" > > Paul Baumann > > -----Original Message----- > From: Boris Popov [mailto:[hidden email]] > Sent: Thursday, July 27, 2006 11:05 AM > To: [hidden email] > Subject: Date and Timestamp comparison > > Hmm, > > june23ts := Timestamp fromSeconds: 3328473600. > june26dt := june23ts asDate addDays: 3. > june26dt < june23ts "false" > june26dt > june23ts "false" > > Shouldn't this either blow up or actually do the right thing? It does > neither at the moment, which manifests in very subtle bugs on > occasion. > Joerg tells me there's even an AR for this somewhere from a > while back. > > Cheers! > > -Boris > > -- > +1.604.689.0322 > DeepCove Labs Ltd. > 4th floor 595 Howe Street > Vancouver, Canada V6C 2T5 > > [hidden email] > > CONFIDENTIALITY NOTICE > > This email is intended only for the persons named in the > message header. > Unless otherwise indicated, it contains information that is > private and > confidential. If you have received it in error, please notify > the sender > and delete the entire message including any attachments. > > Thank you. > > > > -------------------------------------------------------- > This message may contain confidential information and is intended for > specific recipients unless explicitly noted otherwise. If you > have reason to > believe you are not an intended recipient of this message, > please delete it > and notify the sender. This message may not represent the opinion of > IntercontinentalExchange, Inc. (ICE), its subsidiaries or > affiliates, and > does not constitute a contract or guarantee. Unencrypted > electronic mail is > not secure and the recipient of this message is expected to provide > safeguards from viruses and pursue alternate means of > communication where > privacy or a binding message is desired. > > |
RE: Date and Timestamp comparison
|
|
As Boris mentioned in the original post this has been reported
previously. See http://www.parcplace.net/list/vwnc-archive/0305/threads.html#00032 . As I recall an AR was created and the initial feeling was that this should be trivial to fix. However the problem resisted a general solution and there it was left. Perhaps it is time to fall back to plan "B" and throw an exception when comparing Date's and Timestamps. Joerg > -----Original Message----- > From: Thomas Brodt [mailto:[hidden email]] > Sent: July 28, 2006 12:16 AM > To: [hidden email] > Subject: RE: Date and Timestamp comparison > > There could however be differences in comparison of mixed date and > timestamp with > and <. > > Should the timestamp (in ISO format for i18n) 2006-01-01-12-00-00 be > greater than 2006-01-01 or equal? If you want date presision, > it would be equal. If you want timestamp precision, the date should be > coerced to the date with time zero and then is less than > 12:00. Depends on what your intention for the tests are. And which > the comparison should drive the coercion, left or right, > timestamp or date? Coercing towards highest precision of the two fails for > date comparisons on a date and a timestamp that should > return equality for the date part. > You would also introduce floor and ceiling to timestamps, or - as we did - > floor/ceilingTo: aPrecision (means, floor to 5 minutes > interval, ceiling to next full hour, ...), since for some tests a second > difference doesn't matter. > > So I have doubts that you can implement a general solution and won't need > explicit coercion to be safe. > > Just my 2c > > Thomas > > > > -----Original Message----- > > From: Boris Popov [mailto:[hidden email]] > > Sent: Friday, July 28, 2006 2:16 AM > > To: Paul Baumann; [hidden email] > > Subject: RE: Date and Timestamp comparison > > > > I agree, it should just coerce them automagically. Also, as > > far as your > > suggestion to do the coercion by hand, clearly that's the way > > to do it, > > unfortunately often you come across code which you would not > > suspect as > > being of disperate types, and therefore subtle bugs are introduced. > > > > self documents reject: [:ea | ea received > self deadline] > > > > where #received could be a timestamp and #deadline could be a date. > > > > Cheers! > > > > -Boris > > > > -- > > +1.604.689.0322 > > DeepCove Labs Ltd. > > 4th floor 595 Howe Street > > Vancouver, Canada V6C 2T5 > > > > [hidden email] > > > > CONFIDENTIALITY NOTICE > > > > This email is intended only for the persons named in the message > > header. Unless otherwise indicated, it contains information that is > > private and confidential. If you have received it in error, please > > notify the sender and delete the entire message including any > > attachments. > > > > Thank you. > > > > -----Original Message----- > > From: Paul Baumann [mailto:[hidden email]] > > Sent: Thursday, July 27, 2006 11:31 AM > > To: Boris Popov; [hidden email] > > Subject: RE: Date and Timestamp comparison > > > > IMO, it should do the "right thing". Given that june26dt is three > > ahead of june23ts... > > > > "june26dt < june23ts" should return false for the same > > reason that "4 < > > 4.0" returns false. > > "june26dt > june23ts" should return true for the same reason > > that "4 > > > 4.0" returns false. > > "june26dt = june23ts" should return false for the same > > reason that "4 = > > 4.0" returns true. > > > > The date should be coerced to a Timestamp for comparison. #coerce: > > currently defined for ArithmaticValue. #coerce: isn't well suited for > > most other subclasses of Magnitude so I propose adding the class > > Chronometric as a subclass of Magnitude. Chronometric would support > > coersion and be the superclass of all Date/Time classes. A generic > > description of a Chronometric is 'a number of standard and > > deterministic > > increments of a given precision from an epoch'. Coersion > > would be toward > > the highest precision and coersion would adjust for epoch differences. > > "Standard increments" means increments adjusted to GMT/UTC (when > > relevant to a chronometic being compared). "Deterministic increments" > > means leap durations do not cause duplication (when relevant to a > > chronometic being compared). If standard/deterministic increments are > > expected of one chronometic but are not known by another then > > the later > > would convert using the current timezone and ignoring leap durations. > > Standard chronometric conversion methods would make it easy to create > > and compare new subclasses with little hassle. > > > > The workaround is to do explicit coersion like this: > > june26dt asTimestamp < june23ts asTimestamp. "false" > > june26dt asTimestamp > june23ts asTimestamp. "true" > > june26dt asTimestamp = june23ts asTimestamp. "false" > > > > Paul Baumann > > > > -----Original Message----- > > From: Boris Popov [mailto:[hidden email]] > > Sent: Thursday, July 27, 2006 11:05 AM > > To: [hidden email] > > Subject: Date and Timestamp comparison > > > > Hmm, > > > > june23ts := Timestamp fromSeconds: 3328473600. > > june26dt := june23ts asDate addDays: 3. > > june26dt < june23ts "false" > > june26dt > june23ts "false" > > > > Shouldn't this either blow up or actually do the right thing? It > > neither at the moment, which manifests in very subtle bugs on > > occasion. > > Joerg tells me there's even an AR for this somewhere from a > > while back. > > > > Cheers! > > > > -Boris > > > > -- > > +1.604.689.0322 > > DeepCove Labs Ltd. > > 4th floor 595 Howe Street > > Vancouver, Canada V6C 2T5 > > > > [hidden email] > > > > CONFIDENTIALITY NOTICE > > > > This email is intended only for the persons named in the > > message header. > > Unless otherwise indicated, it contains information that is > > private and > > confidential. If you have received it in error, please notify > > the sender > > and delete the entire message including any attachments. > > > > Thank you. > > > > > > > > -------------------------------------------------------- > > This message may contain confidential information and is intended > > specific recipients unless explicitly noted otherwise. If you > > have reason to > > believe you are not an intended recipient of this message, > > please delete it > > and notify the sender. This message may not represent the opinion of > > IntercontinentalExchange, Inc. (ICE), its subsidiaries or > > affiliates, and > > does not constitute a contract or guarantee. Unencrypted > > electronic mail is > > not secure and the recipient of this message is expected to provide > > safeguards from viruses and pursue alternate means of > > communication where > > privacy or a binding message is desired. > > > > |
RE: Date and Timestamp comparison
|
|
In reply to this post by Boris Popov, DeepCove Labs (SNN)
Thomas,
You raise a valid number theory argument for which there is already an established solution that is consistent with my proposal. I recognize the validity of your argument but counter that all programming languages default to intuitive and easily practiced standards. Understand that the issue you raise exists with arithmatic values too... It is standard behavior for coercion to be toward the greater generality. Timestamp is a higher precision and generality than Date just as Float is a higher generality than Integer. The standard is required to give predictable and intuitive results. Consider how strange things would be if ArithmaticValue assumed fuzzy variances by default (the #asInteger or #asFloat sends below would be implied): 4 asInteger < 4.5 asInteger. "false -- bad answer" 4 asInteger > 4.5 asInteger. "false -- bad answer" 4 asInteger = 4.5 asInteger. "true -- imprecise answer" 4 asFloat < 4.5 asFloat. "true" 4 asFloat > 4.5 asFloat. "false" 4 asFloat = 4.5 asFloat. "false" People expect "4 < 4.5" to return true; likewise: 2006-01-01 < 2006-01-01-12-00-00 should return true. 2006-01-01 > 2006-01-01-12-00-00 should return false. 2006-01-01 = 2006-01-01-12-00-00 should return false. It is up to the application programmer to do fuzzy comparisons as necessary. It could be standard that division by zero return a fuzzy number range/limit instead of an exception, but everyone has already been taught that division by zero has no valid result. Smalltalk can handle fuzzy numbers and unpredictable return types, but imagine all the confused people would be if that were the default. With a Chronometric superclass defined and standard conversion/coercion methods, there is nothing to prevent an application developer from creating a FuzzyDate or FuzzyTimestamp that is a higher generality than Timestamp and that would behave more in line with the number theory. Consider that these answers would now be correct and predictable with the explicit introduction of FuzzyInteger: 4 asFuzzyInteger < 4.5. "false" 4 asFuzzyInteger > 4.5. "false" 4 asFuzzyInteger = 4.5. "true" In truth, all measurements are fuzzy numbers. IMO, Science recognizes the imprecision of those numbers in less than ideal ways due to historical reasons, but the end results are within a margin of error that is usually acceptable. I could go on to propose a Measurement class hierarchy be added as a standard way to introduce fuzzy numbers to Smalltalk, but I'll stop now. A general solution can certainly be implemented without explicit coercion. I consider fuzzy date comparisons to be a specialized solution requiring explicit coercion--just as with other ArithmaticValue comparisons. Paul Baumann -----Original Message----- From: Thomas Brodt [mailto:[hidden email]] Sent: Friday, July 28, 2006 3:16 AM To: [hidden email] Subject: RE: Date and Timestamp comparison There could however be differences in comparison of mixed date and timestamp with > and <. Should the timestamp (in ISO format for i18n) 2006-01-01-12-00-00 be greater than 2006-01-01 or equal? If you want date presision, it would be equal. If you want timestamp precision, the date should be coerced to the date with time zero and then is less than 12:00. Depends on what your intention for the tests are. And which side of the comparison should drive the coercion, left or right, timestamp or date? Coercing towards highest precision of the two fails for date comparisons on a date and a timestamp that should return equality for the date part. You would also introduce floor and ceiling to timestamps, or - as we did - floor/ceilingTo: aPrecision (means, floor to 5 minutes interval, ceiling to next full hour, ...), since for some tests a second difference doesn't matter. So I have doubts that you can implement a general solution and won't need explicit coercion to be safe. Just my 2c Thomas > -----Original Message----- > From: Boris Popov [mailto:[hidden email]] > Sent: Friday, July 28, 2006 2:16 AM > To: Paul Baumann; [hidden email] > Subject: RE: Date and Timestamp comparison > > I agree, it should just coerce them automagically. Also, as far as > your suggestion to do the coercion by hand, clearly that's the way to > do it, unfortunately often you come across code which you would not > suspect as being of disperate types, and therefore subtle bugs are > introduced. > > self documents reject: [:ea | ea received > self deadline] > > where #received could be a timestamp and #deadline could be a date. > > Cheers! > > -Boris > > -- > +1.604.689.0322 > DeepCove Labs Ltd. > 4th floor 595 Howe Street > Vancouver, Canada V6C 2T5 > > [hidden email] > > CONFIDENTIALITY NOTICE > > This email is intended only for the persons named in the message > header. Unless otherwise indicated, it contains information that is > private and confidential. If you have received it in error, please > notify the sender and delete the entire message including any > attachments. > > Thank you. > > -----Original Message----- > From: Paul Baumann [mailto:[hidden email]] > Sent: Thursday, July 27, 2006 11:31 AM > To: Boris Popov; [hidden email] > Subject: RE: Date and Timestamp comparison > > IMO, it should do the "right thing". Given that june26dt is three days > ahead of june23ts... > > "june26dt < june23ts" should return false for the same reason that "4 > < 4.0" returns false. > "june26dt > june23ts" should return true for the same reason that "4 > > 4.0" returns false. > "june26dt = june23ts" should return false for the same reason that "4 > = 4.0" returns true. > > The date should be coerced to a Timestamp for comparison. #coerce: is > currently defined for ArithmaticValue. #coerce: isn't well suited for > most other subclasses of Magnitude so I propose adding the class > Chronometric as a subclass of Magnitude. Chronometric would support > coersion and be the superclass of all Date/Time classes. A generic > description of a Chronometric is 'a number of standard and > deterministic increments of a given precision from an epoch'. Coersion > would be toward the highest precision and coersion would adjust for > epoch differences. > "Standard increments" means increments adjusted to GMT/UTC (when > relevant to a chronometic being compared). "Deterministic increments" > means leap durations do not cause duplication (when relevant to a > chronometic being compared). If standard/deterministic increments are > expected of one chronometic but are not known by another then the > later would convert using the current timezone and ignoring leap > durations. > Standard chronometric conversion methods would make it easy to create > and compare new subclasses with little hassle. > > The workaround is to do explicit coersion like this: > june26dt asTimestamp < june23ts asTimestamp. "false" > june26dt asTimestamp > june23ts asTimestamp. "true" > june26dt asTimestamp = june23ts asTimestamp. "false" > > Paul Baumann > > -----Original Message----- > From: Boris Popov [mailto:[hidden email]] > Sent: Thursday, July 27, 2006 11:05 AM > To: [hidden email] > Subject: Date and Timestamp comparison > > Hmm, > > june23ts := Timestamp fromSeconds: 3328473600. > june26dt := june23ts asDate addDays: 3. > june26dt < june23ts "false" > june26dt > june23ts "false" > > Shouldn't this either blow up or actually do the right thing? It does > neither at the moment, which manifests in very subtle bugs on > occasion. > Joerg tells me there's even an AR for this somewhere from a while > back. > > Cheers! > > -Boris > > -- > +1.604.689.0322 > DeepCove Labs Ltd. > 4th floor 595 Howe Street > Vancouver, Canada V6C 2T5 > > [hidden email] > > CONFIDENTIALITY NOTICE > > This email is intended only for the persons named in the message > header. > Unless otherwise indicated, it contains information that is private > and confidential. If you have received it in error, please notify the > sender and delete the entire message including any attachments. > > Thank you. > > > > -------------------------------------------------------- > This message may contain confidential information and is intended for > specific recipients unless explicitly noted otherwise. If you have > reason to believe you are not an intended recipient of this message, > please delete it and notify the sender. This message may not represent > the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries > or affiliates, and does not constitute a contract or guarantee. > Unencrypted electronic mail is not secure and the recipient of this > message is expected to provide safeguards from viruses and pursue > alternate means of communication where privacy or a binding message is > desired. > > -------------------------------------------------------- This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. |
Re: Date and Timestamp comparison
|
|
In reply to this post by Joerg Beekmann, DeepCove Labs (YVR)
some thoughts...
I think that the question here should really be whether it makes sense to compare a Date and a Timestamp. I am not convinced that it does, nor am I convinced that it doesn't.... I don't see why an exception could not be raised, as Joerg recommended. On the first time the code is run, the developer would notice and fix the problem accordingly to his system's business logic, i.e: self documents reject: [:ea | ea received > self deadline] would raise an exception and the developer would trace it and fix it to something like: self documents reject: [:ea | ea received date > self deadline] or: self documents reject: [:ea | ea received > (Timestamp fromDate: self deadline andTime: '16:00' asTime)] OBS: '16:00' asTime works in ObjectStudio... I dont have VW installed here to check if it works in it as well, but you got the idea Implementing a default behaviour in base classes seems to an unneeded constraint, IMHO. Regards, Ricardo On 7/28/06, Joerg Beekmann <[hidden email]> wrote:
As Boris mentioned in the original post this has been reported |
Re: Date and Timestamp comparison
|
|
In reply to this post by Joerg Beekmann, DeepCove Labs (YVR)
A long time ago, we gave up on Date/Time etc for our business objects,
and created our own. We do lots of comparisons -- and we have four (I think) date types (date, hrebrewDate, dateTime, timeStamp (date/time/user/application)). We spent lots of time on comparisons since they are important and tend to be used quite a bit. Its quite normal for someone to change a date into a dateTime or vice-versa, or into a stamp. We expect the code to continue working. There can be issues with timezone which we support for all our date types. I would think that these comparisons would be considered important, and such things as reported here considered bugs -- should be fixed! Joerg Beekmann wrote: As Boris mentioned in the original post this has been reported previously. See http://www.parcplace.net/list/vwnc-archive/0305/threads.html#00032 . As I recall an AR was created and the initial feeling was that this should be trivial to fix. However the problem resisted a general solution and there it was left. Perhaps it is time to fall back to plan "B" and throw an exception when comparing Date's and Timestamps. Joerg-----Original Message----- From: Thomas Brodt [[hidden email]] Sent: July 28, 2006 12:16 AM To: [hidden email] Subject: RE: Date and Timestamp comparison There could however be differences in comparison of mixed date and timestamp with > and <. Should the timestamp (in ISO format for i18n) 2006-01-01-12-00-00 be greater than 2006-01-01 or equal? If you want date presision, it would be equal. If you want timestamp precision, the date should be coerced to the date with time zero and then is less than 12:00. Depends on what your intention for the tests are. And whichside of -- Dennis Smith [hidden email] Cherniak Software Development Corporation +1 905.771.7011 400-10 Commerce Valley Dr E Fax: +1 905.771.6288 Thornhill, ON Canada L3T 7N7 http://www.CherniakSoftware.com |
Re: Date and Timestamp comparison
|
|
In reply to this post by Joerg Beekmann, DeepCove Labs (YVR)
Joerg Beekmann wrote:
> Perhaps it is time to fall back to plan "B" and throw an exception when > comparing Date's and Timestamps. IMHO, that's the best solution in this case. Dates and timestamps are not related in the same way as real numbers and integers are. Mathematically, the set of integers is a subset of the set or real numbers. But the "set of dates" is not a subset of any "set of timestamps". This makes it impossible to define a "natural" ordering relationship on the union of both sets, which is what the attempt to implement polymorphic comparison methods amounts to. You can think of the timeline as a continuous scale, and dates or timestamps (or more generally, points in time of a certain granularity) as "names" for time periods of a certain length (the granularity). In this model, a date is not the same thing as a timestamp denoting the first second (or microsecond, or whatever granularity is used for timestamps) of the day denoted by the date. You could ask if a timestamp preceeds a date, is included in the day denoted by a date, or is later than a date, overlaps a timestamp of a different granularity, etc. Another model is to think of dates and timestamps as instances on discrete time scales of different granularity. This makes dates and timestamps of different granularities incomparable. In SQL-92 e.g., values are converted to a common base granularity before comparing them. "aDate asTimestamp" is not really a conversion, as it has the meaning "compute a Timestamp denoting the first second/millisecond/microsecond (?) of the day denoted by aDate". The result does not represent the same point on the same scale, as converting 4 to 4.0 would (this conversion converts between two representations / notations of the same thing, 4 and 4.0 are the same number from a mathematical perspective). A lot of information on time models is available at the University of Aalborg's TimeCenter http://www.cs.aau.dk/TimeCenter/pub.htm and the "Consensus Glossary of Temporal Database Concepts" http://www.cs.aau.dk/~csj/Glossary/index.html I had to dig into some of those papers some years ago when we had to implement a full bitemporal model for a statistics application - not exactly what I would call an easy reading... ;-) Joachim |
Re: Date and Timestamp comparison
|
|
In reply to this post by Ricardo Birmann
On Jul 28, 2006, at 8:36, Ricardo Birmann wrote: some thoughts... Or even why they would have the opportunity in the first place. This is probably overtly naive on my part, but I can't for the life of me figure out why Date or Time exist in the image with the presence of Timestamp. Just use a Timestamp to express your date. -- Travis Griggs Objologist "I choose. Therefore, I Am" DISCLAIMER: This email is bound by the terms and conditions described at http://www.key.net/disclaimer.htm |
Re: Date and Timestamp comparison
|
|
In reply to this post by Joachim Geidel
On 7/28/06, Joachim Geidel <[hidden email]> wrote: Joerg Beekmann wrote: exactly! you can't think of a Date as a Timestamp with time 00:00, 12:00, or anything else for that matter... it is simply undefined You can think of the timeline as a continuous scale, and dates or |
RE: Date and Timestamp comparison
|
|
In reply to this post by Boris Popov, DeepCove Labs (SNN)
It is reasonable to fix the bug by throwing an exception. How about
something like this (implemented as an ANSI exception of course): < aDate aDate class == self class ifFalse: [ ^self error: 'Date/Time comparison deficiency. Sorry this could have been avoided if you''d purchased better tools. Fix with explicit conversion or implement your own damn tools like everyone else.'. ]. ... Some kidding aside, if the problem isn't to be fixed then it may be better to throw an exception instead of allowing invalid code assumptions to go unnoticed. Sometimes a little pain is required to get people in order. Sometimes Smalltalk coding just isn't painful enough. That whole polymorphism thing is overrated anyway. Real code declares data types. Smalltalk should expect certain data types and just crash occasionally after deployment when code or data is wrong. ;) On second thought, fall back to plan "C" and forget the problem exists. I'd rather get paid to write yet another DateTime implementation anyway. Paul Baumann P.S. This response is trying to be funny of course, not meant to offend. I've expressed my opinion and proposed a solution that mimics common practice. It is also common practice for application code to explicitly compare with least common precision, but a general comparison should use greatest common precision to yield consistent and predictable results. It should be clear how a Chronometric abstract superclass would facilitate conversions as well as both types of comparisions. I'll leave the topic alone now. Cheers! -----Original Message----- From: Joerg Beekmann [mailto:[hidden email]] Sent: Friday, July 28, 2006 11:13 AM To: Thomas Brodt; [hidden email] Subject: RE: Date and Timestamp comparison As Boris mentioned in the original post this has been reported previously. See http://www.parcplace.net/list/vwnc-archive/0305/threads.html#00032 . As I recall an AR was created and the initial feeling was that this should be trivial to fix. However the problem resisted a general solution and there it was left. Perhaps it is time to fall back to plan "B" and throw an exception when comparing Date's and Timestamps. Joerg -------------------------------------------------------- This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. |
RE: Date and Timestamp comparison
|
|
In reply to this post by Boris Popov, DeepCove Labs (SNN)
From: Ricardo Birmann
[mailto:[hidden email]] real numbers and integers are.
exactly! you can't think of a Date as a Timestamp with time 00:00, 12:00, or anything else for that matter... it is simply undefined
I'd like to put a different point of view on this. I agree that mathematically, 4 and 4.0 are generally regarded as being equal. But that's only one definition of equality; even in mathematics there are times when they are most definitely not the same thing. For instance 4 is also regarded as being equal to the complex number 4 + 0i, which in turn is regarded as equal to the point (4,0) in the complex plane. And under modular mathematics, modulo 3, 4 is equal to 1. I'm sure you wouldn't want all these "equals" to be the default behaviour in Smalltalk, and nor should they be.
In science and engineering, 4 and 4.0 are very different: the second is 10 times more accurate than the first.
In common experience (and also in linguistics) 4 is a measure used for countable things like apples (countable nouns), whereas 4.0 is a measure used for non-countable things like apple sauce (mass nouns). The two can't be compared directly (rather like apples and oranges), and whilst the former can exist without units, the latter needs a unit (4.0kg, 4 litres etc.). You can't apply one form of number to the other kind of thing: "we're so average, we have 2.4 kids", or "how much water is in that lake, Daddy?" "3!". Very different beasts.
There's thus no sound basis for making black and white statements about whether Integers and Reals, or Dates and Timestamps, are always comparable. We certainly can't use maths to tell us the answer about Dates and Timestamps – it doesn't even really give the final answer for its own domain.
The best basis for a decision in VW, IMHO, is what is most useful to most people who are not doing research in that particular area. In the cases above, clearly it is useful to most people to compare Integers and Reals transparently. There may be catches where we hit the limits of precision for either type, but in general things will work. Similarly for Timestamps and Dates: a Timestamp equates very well to a Real, and a Date to an Integer. If we consider a Date as having a zero Time part, just as we consider an Integer to have a zero part after the decimal point, we have a coherent system that produces intuitive results.
Dates and Timestamps are not numbers, but we can define a useful algebra on them, allowing operations mixing Dates and Timestamps. There's nothing in VW that says that a Date is any particular, well-defined semantic kind of date – it's just your everyday kind of date. As such everybody uses (and abuses) it in different ways. But you can be pretty sure the majority of ways would be compatible with an ordering that said 3pm on December 25th 2006 is greater than December 1st 2006. If you want to compare 3pm on December 25th 2006 with December 25th 2006, most people would say it is still greater; if you want to say they're the same, or something even more funky, you have to do a little more work (e.g. convert both to Dates first).
Just my tuppence… Steve |
Re: Date and Timestamp comparison
|
|
Steven Kelly wrote:
> The best basis for a decision in VW, IMHO, is what is most useful to > most people who are not doing research in that particular area. Point taken. What I wrote was quite over the top. :-( > Dates and Timestamps are not numbers, but we can define a useful algebra > on them, allowing operations mixing Dates and Timestamps. There's > nothing in VW that says that a Date is any particular, well-defined > semantic kind of date – it's just your everyday kind of date. As such > everybody uses (and abuses) it in different ways. But you can be pretty > sure the majority of ways would be compatible with an ordering that said > 3pm on December 25^th 2006 is greater than December 1^st 2006. If you > want to compare 3pm on December 25^th 2006 with December 25^th 2006, > most people would say it is still greater; if you want to say they're > the same, or something even more funky, you have to do a little more > work (e.g. convert both to Dates first). You are right, as long as it's clearly defined what the result is, this solution would be okay in most cases. Raising an exception when comparing Dates to Timestamps would make them harder to use, so I don't prefer this solution any more. Whether 3pm on December 25^th 2006 should be greater than December 25^th 2006 or not is not so important as long as the results are consistent. Joachim |
|
|
In reply to this post by Travis Griggs
<rant>
I've been putting off posting about this for a long time, but I need to speak up so that hopefully something will change. This policy of not supporting Pollock is counterproductive. The original timetable for Pollock would have had it in production release now, and at SIC 2005 Sam said in his presentation that Pollock was then ready to use and he encouraged us to use it. It looked like Pollock was exactly what I need, and based on Sam's presentation, I thought I had good reason to think that Pollock was actually in a state to be useful. I actually waited until Pollock had another release before I started my port from VisualSmalltalk. That was in winter of 2005. There have been all sorts of problems. Missing behavior, horribly slow performance, weird keyboard and mouse handling, drawing bugs, etc. None of this would be a big deal if the VW dev team would respond to these issues. The "official" stance is that Pollock is in beta and unsupported. Call it beta or anything else you like, but a useful Pollock is overdue. The promise of a really great UI framework is there, but it's frustrating that progress is terribly lacking. I spend a lot of time trying to bend Pollock to my will. I am not trying to do anything special really. My software has simple UI features. I don't even ask for help until I've put real time into trying to solve issues myself. When I finally ask for help with some problem the response is often what I perceive to be indifference. I get more Pollock help from people who don't work for Cincom. I don't have time for this. :-/ It baffles me that there isn't some energy given to support people who are trying to use Pollock. How is Pollock ever supposed to become production if the core quality isn't there? Most software development companies would fall over backwards to embrace early adopters. -Fix bugs before adding features -Only refactor the design once the core has good quality (quality meaning it can be used to build software) -Do something (anything) about the severe performance problems. I have spent time in the profiler, but I have not been able to grok why it is so slow, but why shouldn't Cincom's developers be able to get an order of magnitude performance improvement in half an afternoon? A tenfold performance boost would be tremendously helpful, although I'm sure it could be a hundred times faster in some places. Please ditch the "we'll optimize it later" position. It doesn't serve your customers well. I love VisualWorks. The VW development team is a great bunch of people, and most of the time I get pretty good support. Pollock needs the same treatment as the rest of the product. The current stance of non-support is wrong and it jeapardizes the future of VW Smalltalk, at least for my project. I am not using the non-commercial version of VisualWorks. I am a paying customer. I am not using this for some free hobby project. This is my livelihood. This is my own money, time, and sweat I'm pouring into this. If I seem distressed, this is why. </rant> -Carl Gundel, author of Liberty BASIC http://www.libertybasic.com |
Re: Date and Timestamp comparison
|
|
In reply to this post by Joachim Geidel
In the code below assume #received answers a Timestamp and #due answers
a Date. self received > self due ifTrue: [self processLatePayment] Using the coerce dates to midnight approach we end up assuming a payment received on the due date is late unless it happens to come at exactly midnight. Examples like this suggest that converting the Timestamp to a Date might be just as reasonable a default approach. Throwing an exception also seems reasonable. In any case I usually embed the type in the name of the variable or method to help ensure I'm always comparing like to like. So, I'd probably end up implementing both #receivedTimestamp and #receivedDate and just use the date one for the comparison: self receivedDate > self dueDate ifTrue: [self processLatePayment] - Keith --- Joachim Geidel <[hidden email]> wrote: > Steven Kelly wrote: > > The best basis for a decision in VW, IMHO, is what is most useful > to > > most people who are not doing research in that particular area. > > Point taken. What I wrote was quite over the top. :-( > > > Dates and Timestamps are not numbers, but we can define a useful > algebra > > on them, allowing operations mixing Dates and Timestamps. There's > > nothing in VW that says that a Date is any particular, well-defined > > semantic kind of date it's just your everyday kind of date. As > such > > everybody uses (and abuses) it in different ways. But you can be > pretty > > sure the majority of ways would be compatible with an ordering that > said > > 3pm on December 25^th 2006 is greater than December 1^st 2006. If > you > > want to compare 3pm on December 25^th 2006 with December 25^th > 2006, > > most people would say it is still greater; if you want to say > they're > > the same, or something even more funky, you have to do a little > more > > work (e.g. convert both to Dates first). > > You are right, as long as it's clearly defined what the result is, > this > solution would be okay in most cases. Raising an exception when > comparing Dates to Timestamps would make them harder to use, so I > don't > prefer this solution any more. Whether 3pm on December 25^th 2006 > should > be greater than December 25^th 2006 or not is not so important as > long > as the results are consistent. > > Joachim > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
|
In reply to this post by Carl Gundel
Well, this does put us in a difficult position. Pollock is still in
preview, so it doesn't get official support. At the same time, Sam has been pretty responsive to input. So far as optimization goes, I know that Sam has a schedule for that - I've spoken to him about it. At 12:56 PM 7/29/2006, you wrote: ><rant> >I've been putting off posting about this for a long time, but I need to >speak up so that hopefully something will change. > >This policy of not supporting Pollock is counterproductive. The original >timetable for Pollock would have had it in production release now, and at >SIC 2005 Sam said in his presentation that Pollock was then ready to use and >he encouraged us to use it. It looked like Pollock was exactly what I need, >and based on Sam's presentation, I thought I had good reason to think that >Pollock was actually in a state to be useful. I actually waited until >Pollock had another release before I started my port from VisualSmalltalk. >That was in winter of 2005. > >There have been all sorts of problems. Missing behavior, horribly slow >performance, weird keyboard and mouse handling, drawing bugs, etc. None of >this would be a big deal if the VW dev team would respond to these issues. >The "official" stance is that Pollock is in beta and unsupported. Call it >beta or anything else you like, but a useful Pollock is overdue. The >promise of a really great UI framework is there, but it's frustrating that >progress is terribly lacking. > >I spend a lot of time trying to bend Pollock to my will. I am not trying to >do anything special really. My software has simple UI features. I don't >even ask for help until I've put real time into trying to solve issues >myself. When I finally ask for help with some problem the response is often >what I perceive to be indifference. I get more Pollock help from people who >don't work for Cincom. I don't have time for this. :-/ > >It baffles me that there isn't some energy given to support people who are >trying to use Pollock. How is Pollock ever supposed to become production if >the core quality isn't there? Most software development companies would >fall over backwards to embrace early adopters. > >-Fix bugs before adding features >-Only refactor the design once the core has good quality (quality meaning it >can be used to build software) >-Do something (anything) about the severe performance problems. I have >spent time in the profiler, but I have not been able to grok why it is so >slow, but why shouldn't Cincom's developers be able to get an order of >magnitude performance improvement in half an afternoon? A tenfold >performance boost would be tremendously helpful, although I'm sure it could >be a hundred times faster in some places. Please ditch the "we'll optimize >it later" position. It doesn't serve your customers well. > >I love VisualWorks. The VW development team is a great bunch of people, and >most of the time I get pretty good support. Pollock needs the same >treatment as the rest of the product. The current stance of non-support is >wrong and it jeapardizes the future of VW Smalltalk, at least for my >project. I am not using the non-commercial version of VisualWorks. I am a >paying customer. I am not using this for some free hobby project. This is >my livelihood. This is my own money, time, and sweat I'm pouring into this. >If I seem distressed, this is why. ></rant> > >-Carl Gundel, author of Liberty BASIC >http://www.libertybasic.com <Talk Small and Carry a Big Class Library> James Robertson, Product Manager, Cincom Smalltalk http://www.cincomsmalltalk.com/blog/blogView |
|
|
In reply to this post by Carl Gundel
James Robertson wrote:
> Well, this does put us in a difficult position. Pollock is still in > preview, so it doesn't get official support. And since Wrapper is to be replaced, it hasn't received a normal level of support for over four years now. Part of the problem is that throughout those four years, Pollock has always been "going to be in production in 12-18 months". Here's Sames from July 2002: http://www.parcplace.net/list/vwnc-archive/0207/msg00091.html > So, if Pollock will go into a production release in 2 - 3 releases > (7.2 or 7.3) [as Sames said in his previous message], then that means > something on the order of 12 - 18 months before it goes into production. > After that, it will sit side by side with the current GUI framework for > a minimum of another 2 releases (about a year... maybe a year and a half > if it has to go to 3 releases). Finally, the old framework will be > removed from the base image. That is in 2 to 3 years from now. As Ralph Johnson put it, in the same thread: http://www.parcplace.net/list/vwnc-archive/0207/msg00076.html > Think how long Cincom has been working on OpenTalk. > I predict that Pollock will take longer than has been predicted. > Also, there is a greater than 0% chance that it will never be > finished. I predict that the time from when it is first available > for use to the time when you will be unhappy if you have not converted > will be at least three years. Finally, I predict that if you hire > John Brant to do the conversion for you, it will take much less time > than you thought possible. The best thing to come out of Pollock so far, from our industry's point of view, is Sames' superb documentation of its progress. There's a lovely research project for some student: go through the Pollock releases and Sames' blog and other postings, and dissect the evolution of a framework. I still have high hopes for Pollock: doing it is the right decision, and Sames is doing it according to good XP practice (although it remains to be seen how well his interpretation of some aspects like late optimization works in the end; certainly it's been bad news so far in that it's stopped much early adoption). The big question I see remaining is how long will it take Cincom to rewrite all existing VW tools in Pollock. That was stated as a prerequisite for removing Wrapper from the base image into the obsolete directory, where it will remain as a loadable parcel "probably almost forever". I predict the tool migration will also take "probably almost forever", so to calculate the time till Wrapper is removed you need to load AT MetaNumerics: Transcript cr; show: (2 * (Infinity positive - 1)) printString Steve :-) > At 12:56 PM 7/29/2006, you wrote: > ><rant> > >I've been putting off posting about this for a long time, but I need to > >speak up so that hopefully something will change. > > > >This policy of not supporting Pollock is counterproductive. The original > >timetable for Pollock would have had it in production release now, and at > >SIC 2005 Sam said in his presentation that Pollock was then ready to use > and > >he encouraged us to use it. It looked like Pollock was exactly what I > need, > >and based on Sam's presentation, I thought I had good reason to think > that > >Pollock was actually in a state to be useful. I actually waited until > >Pollock had another release before I started my port from VisualSmalltalk. > >That was in winter of 2005. > > > >There have been all sorts of problems. Missing behavior, horribly slow > >performance, weird keyboard and mouse handling, drawing bugs, etc. None > of > >this would be a big deal if the VW dev team would respond to these issues. > >The "official" stance is that Pollock is in beta and unsupported. Call > it > >beta or anything else you like, but a useful Pollock is overdue. The > >promise of a really great UI framework is there, but it's frustrating > that > >progress is terribly lacking. > > > >I spend a lot of time trying to bend Pollock to my will. I am not trying > to > >do anything special really. My software has simple UI features. I don't > >even ask for help until I've put real time into trying to solve issues > >myself. When I finally ask for help with some problem the response is > often > >what I perceive to be indifference. I get more Pollock help from people > who > >don't work for Cincom. I don't have time for this. :-/ > > > >It baffles me that there isn't some energy given to support people who > are > >trying to use Pollock. How is Pollock ever supposed to become production > if > >the core quality isn't there? Most software development companies would > >fall over backwards to embrace early adopters. > > > >-Fix bugs before adding features > >-Only refactor the design once the core has good quality (quality meaning > it > >can be used to build software) > >-Do something (anything) about the severe performance problems. I have > >spent time in the profiler, but I have not been able to grok why it is so > >slow, but why shouldn't Cincom's developers be able to get an order of > >magnitude performance improvement in half an afternoon? A tenfold > >performance boost would be tremendously helpful, although I'm sure it > could > >be a hundred times faster in some places. Please ditch the "we'll > optimize > >it later" position. It doesn't serve your customers well. > > > >I love VisualWorks. The VW development team is a great bunch of people, > and > >most of the time I get pretty good support. Pollock needs the same > >treatment as the rest of the product. The current stance of non-support > is > >wrong and it jeapardizes the future of VW Smalltalk, at least for my > >project. I am not using the non-commercial version of VisualWorks. I am > a > >paying customer. I am not using this for some free hobby project. This > is > >my livelihood. This is my own money, time, and sweat I'm pouring into > this. > >If I seem distressed, this is why. > ></rant> > > > >-Carl Gundel, author of Liberty BASIC > >http://www.libertybasic.com > > <Talk Small and Carry a Big Class Library> > James Robertson, Product Manager, Cincom Smalltalk > http://www.cincomsmalltalk.com/blog/blogView |
|
|
Steven Kelly wrote:
> I still have high hopes for Pollock: doing it is the right decision, and > Sames is doing it according to good XP practice (although it remains to > be seen how well his interpretation of some aspects like late > optimization works in the end; certainly it's been bad news so far in > that it's stopped much early adoption). IMO, there's two different kinds of performance "optimization". If there is a requirement that something executes in x milliseconds, then making the code run fast enough such that it meets this target is not optimization, but fixing a bug. Continuing to tune for speed when the requirements are already fulfilled is what I would think of as optimization. In the case of Pollock, the comments about its performance imply that Pollock currently does not meet an important non-functional requirement, which would be a bug and consequently should be addressed as soon as possible instead of being postponed. If the performance problems are resulting from a design problem, then postponing to address them will probably make them harder to solve. However, if the performance requirements are not defined in an explicit and testable way (e.g. "an open and completely visible window with 20 input fields must update in 0.1 seconds when the contents of all input fields changes"), it's hard to draw the borderline between bug fixing and optimization. Are Pollock's performance targets well-defined? Best regards, Joachim Geidel |
|
|
In reply to this post by Carl Gundel
Carl Gundel wrote:
> <rant> > I've been putting off posting about this for a long time, but I need to > speak up so that hopefully something will change. > > This policy of not supporting Pollock is counterproductive. The original > timetable for Pollock would have had it in production release now, and at > SIC 2005 Sam said in his presentation that Pollock was then ready to use and > he encouraged us to use it. It looked like Pollock was exactly what I need, > and based on Sam's presentation, I thought I had good reason to think that > Pollock was actually in a state to be useful. I actually waited until > Pollock had another release before I started my port from VisualSmalltalk. > That was in winter of 2005. > > There have been all sorts of problems. Missing behavior, horribly slow > performance, weird keyboard and mouse handling, drawing bugs, etc. None of > this would be a big deal if the VW dev team would respond to these issues. > The "official" stance is that Pollock is in beta and unsupported. Call it > beta or anything else you like, but a useful Pollock is overdue. The > promise of a really great UI framework is there, but it's frustrating that > progress is terribly lacking. > > I spend a lot of time trying to bend Pollock to my will. I am not trying to > do anything special really. My software has simple UI features. I don't > even ask for help until I've put real time into trying to solve issues > myself. When I finally ask for help with some problem the response is often > what I perceive to be indifference. I get more Pollock help from people who > don't work for Cincom. I don't have time for this. :-/ > > It baffles me that there isn't some energy given to support people who are > trying to use Pollock. How is Pollock ever supposed to become production if > the core quality isn't there? Most software development companies would > fall over backwards to embrace early adopters. > > -Fix bugs before adding features > -Only refactor the design once the core has good quality (quality meaning it > can be used to build software) > -Do something (anything) about the severe performance problems. I have > spent time in the profiler, but I have not been able to grok why it is so > slow, but why shouldn't Cincom's developers be able to get an order of > magnitude performance improvement in half an afternoon? A tenfold > performance boost would be tremendously helpful, although I'm sure it could > be a hundred times faster in some places. Please ditch the "we'll optimize > it later" position. It doesn't serve your customers well. I posted a problem with Pollock slowness some time ago (maybe a year ago). At the time I digged in and made some profiling that showed that the cause of the slowness is mainly in LayoutFrame hierarchy and form's (subcanvas) nesting. Especially RelationalFrame is real performance killer. This is basically because there is no caching of values. So, for example when you click on input field to start typying, absolute bounds have to be calculated and in case of fractional and relational frames, this takes really long, because the same thing is computed many times (as with loosely written Fibonacci sequence). We also tried to fix it but it turned out not be easy (for us). Therefore we canceled our effort to start new project with Pollock. But these findings are dated basically a year back so I am not sure if this is still Pollock's current performance bottleneck. Ladislav Lenart |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |