From ... From: Erik Naggum Subject: Re: Problems with EQUALP hash tables and Arrays Date: 1999/05/29 Message-ID: <3136956702725490@naggum.no>#1/1 X-Deja-AN: 483408604 References: <374AF040.F0978582@mindspring.com> <1WU23.43$KM3.15733@burlma1-snr2> <3136843901742945@naggum.no> mail-copies-to: never Organization: Naggum Software; +47 8800 8879; http://www.naggum.no Newsgroups: comp.lang.lisp * Lieven Marchand | I think it would make more sense for the standard to demand of | implementors to document the expected performance of their implementation. * Erik Naggum | this would mean that no implementation would ever be conforming to the | standard, and reasonable people would shrug off that requirement, because | it is actually an unreasonable thing to request people to do. * Lieven Marchand | Why? It seems more reasonable than demanding a certain performance | requirement. I have tried, but I do not understand what you are trying to say. are people "demanding a certain performance requirement" (whatever this means) today? or is it an example of something much less reasonable than your already unreasonable request that you are kindly offering us because you actually have the much more unreasonable request in mind? in case you missed my point entirely, language standards are not the place to require performance statistics from implementations. it doesn't matter how much you think you need it or how useful you think it might be. it's incredibly stupid to put such requirements in a standard. | Personally, I have nothing against commercial vendors but this issue | seems orthogonal to the discussion. Besides, it would make sense for the | vendors to document things like that when it gets asked frequently. That | is why a lot of vendors put (a sanitized version of) their support | knowledge base online. and what? are you unhappy with the current support offerings? it looks like you don't have anything actually constructive in mind. | I think I do understand. you wrote: ||... but since the implementation is not required to support objects or ||arrays above a certain size any vendor can claim O(1) performance of ||everything by choosing a suitably large constant. and this indicates that you have very little understanding of what the big-O notation is supposed to express and use it in a very sloppy fashion that I would expect from newspaper hacks. I certainly do not expect any vendor to be equally devoid of understanding or willing to compromise his credibility with users who actually knows what you suggest they say means. | That's why I don't think such requirements are useful in a standard. so the standard should not include them, but you think it's smart to demand such data of every conforming implementations, even though you think that by jacking up the constant, you can get away with grossly misleading numbers? but never mind -- programmers who can't write stuff they need on their own should be doing something else entirely. #:Erik -- @1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century