Squeak-dev August 2000

squeak-dev@lists.squeakfoundation.org

130 participants
418 discussions

Re: SWIKI DOWN?
by Doug Way 03 Aug '00

03 Aug '00

"Andrew C. Greenberg" wrote: > > The Swiki appears to be down at the moment. I sent an e-mail to > Mark, but got a vacation message in reply. Don't forget that "Swiki Down" emails should be sent to swiki-bugs(a)cc.gatech.edu. (Presumably someone other than just Mark checks that address.) The Swiki was still down when I checked just now. Any kind soul out there interested in setting up their computer as a server to be a simple read-only mirror of the Squeak Swiki? (using Comanche or whatever works best?) You'll earn the undying affection of the Squeak community. :-) - Doug Way dway(a)mat.net, @riskmetrics.com RiskMetrics Group, Ann Arbor, MI http://www.riskmetrics.com

3 2

Re: Large integers
by Bob Arning 03 Aug '00

03 Aug '00

On Thu, 3 Aug 2000 12:53:26 -0400 (EDT) Jesse Welton <jwelton(a)pacific.mps.ohio-state.edu> wrote: >Er, actually, I see what you mean. That doesn't change the results >much for really large integers. I see a significant increase in speed >by changing \\ to \\\. What cases doesn't \\\ handle, that \\ does? #\\\ will take you directly to the LargeInteger plugin which is optimized for this kind of stuff. Sending #\\ to a LargeInteger will often fail the primitive: Take the receiver modulo the argument. The result is the remainder rounded towards negative infinity, of the receiver divided by the argument. Fail if the argument is 0. Fail if either the argument or the result is not a SmallInteger or a LargePositiveInteger less than 2-to-the-30th (1073741824). and take you to the super method: ^self - (self // aNumber * aNumber) which will be slower. Note that #\\\ is only suitable for positive numbers which. I think, is all one cares about in DSA, RSA, etc. Cheers, Bob

1 0

sinful bug
by Luciano Notarfrancesco 03 Aug '00

03 Aug '00

x sin = x for all x >= 16r7FFFFFFFFFFFFDFC Why? Luciano.- __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/

1 0

Re: Large integers
by Bob Arning 03 Aug '00

03 Aug '00

Helge, On Thu, 03 Aug 2000 18:28:14 +0200 Helge Horch <Helge.Horch(a)munich.netsurf.de> wrote: >Great, three ways to skin the cat. Now for the real, large integers: > [snip] > >This is not what I expected. I'd have to examine the algorithms more >closely, but maybe RAA or JM know what's going on. (I thought that, given >the LI plugin, we might drop the special-case LI arithmetic in DSA, but the >simple replacement does not seem desirable.) What the LI plugin _did_ allow us to do was to drop the DSA-specific plugin. If you are puzzled by why the third example in: >[100 timesRepeat: [(855 raisedTo: 2753) \\ 3233]] timeToRun --> 9944 >[100 timesRepeat: [855 raisedTo: 2753 modulo: 3233]] timeToRun --> 20 >[100 timesRepeat: [DigitalSignatureAlgorithm new raise: 855 to: 2753 mod: >3233]] timeToRun --> 90 took longer, it is that by promoting #\\\ to Integer rather than implementing the Integer version as ^self \\ anInteger you will use #digitDiv:neg: in all cases, but it is a primitive only for Large ints. Cheers, Bob

1 0

Re: Large integers
by Jesse Welton 03 Aug '00

03 Aug '00

Wouter Gazendam wrote: > > Hi All, > > I'm trying to build a RSA implementation in Squeak, and I came across the > following problem: > RSA works with incredibly large numbers (sometimes up to 10^1000), > PrintIt-ing the next line takes about 8 secs to run: > > (855 raisedTo: 2753) \\ 3233 > > Any ideas how to speed this up? Sure. I believe even with the LargeIntegers plugin, you can greatly improve the speed of such calculations by using a specialized exponentiation routine that performs all calculations within the given modulus. I just whipped this up, and I think it's correct, but be warned that it may have faults. Method Integer>>raisedTo:modulo: raisedTo: exponent modulo: modulus | e e2 er product products | exponent isInteger ifFalse: [self error: 'exponent must be an integer']. exponent strictlyPositive ifFalse: [self error: 'exponent must be strictly positive']. product := self. products := OrderedCollection new. e := 1. [ e2 := e*2. e2 <= exponent ] whileTrue: [ products addLast: product. product := product*product \\ modulus. e := e2. ]. er := exponent - e. [ er > 0 ] whileTrue: [ e := e/2. (e <= er) ifTrue: [ er := er - e. product := product*(products removeLast) \\ modulus. ] ifFalse: [ products removeLast ]. ]. ^product On my 2.8beta system, I get these times: [100 timesRepeat: [(855 raisedTo: 2753) \\ 3233]] timeToRun --> 5995 [100 timesRepeat: [855 raisedTo: 2753 modulo: 3233]] timeToRun --> 12 -Jesse

2 1

Re: Large integers
by Bijan Parsia 03 Aug '00

03 Aug '00

On Thu, 3 Aug 2000, Peter Novak wrote: > Hi Wouter, > Hmmm... I just tried to execute your line and I have the result immediately. > I am running on Squeak 2.9a. Two things can make a huge difference: 1) Whether you're running with the large integer plugin (the latest VMs (i.e., >=2.8) have this built in) or not. Don't even think about it without the plugin (the pure Smalltalk code is, itself, not very speed optimized). 2) Whether you hit a gc. When I popped the example into a long running image it did a full gc first (this sometimes happens, I find, if I try an example after letting an image "sit" for a long time). So, here's a micro-micro-benchmark: Smalltalk garbageCollect. Time millisecondsToRun:[(855 raisedTo: 2753) \\ 3233] On the same machine (300mhz pentium type): 2.7ish VM: 26352 2.8ish VM: 184 Clearly this says nothing about runs of calculations in a specific app, but should give a feel for how things roll. I recommend looking at IntegerArray style classes as well. Cheers, Bijan Parsia. P.S. Peter, sorry for sending it to you twice!

1 0

RE: [UNIX][ALPHA][NET] When to tap the r/w sems?
by Lex Spoon 03 Aug '00

03 Aug '00

"Peter Crowther" <peter(a)crowther.demon.co.uk> wrote: > > From: Lex Spoon [mailto:lex@cc.gatech.edu] > > select() tells you whether a socket is read-able or not, but > > it doesn't tell you when it *becomes* readable. > > True, but at least two platforms have ways of telling you. SIGIO in many > UNIXes is a good prompt to run a select() to see what's changed, and with > WinSock you can ask for socket events on your event queue. I'm not enough > of a Mac coder to know whether, or how, similar things could be handled > there. > Ian used SIGIO for a while, but it's not the same on all platforms. So he dropped back to using select(). select() is fairly well defined and quite reliable. Calling it twice in a row isn't going to be *tooo* expensive, and anyway, as I/O becomes really heavy, there tend to be more "hits" per select and so the overhead becomes less significant. -Lex

1 0

Re: Compiler, was Re: Block closures
by Lex Spoon 03 Aug '00

03 Aug '00

"Roel Wuyts" <rwuyts(a)vub.ac.be> wrote: > Indeed, the 'comment-handling' is currently really bad. I would like to > easily rewrite a parsetree (say, optimize it, refactor it, do Java-like > before/after stuff), keeping the comments. It is currently possible, but not > clean at all. Why not have a 'CommentNode', that keeps the position of the > comment in the source. That way we can 'pull up' the comments from where > they are living now. Also note that, depending on the builder you use when > parsing, comments could be enabled or not. > > "position in source code" isn't semantically meaningful, and so it shouldn't be needed in the parse tree. Much better would be "this comment comments on this variable", or "this comment is a method comment". -Lex

1 0

Re: [BUG] Symbol>>hash
by Lex Spoon 03 Aug '00

03 Aug '00

Stephan Rudlof <sr(a)evolgo.de> wrote: > > > biggerHash > > > > > > self size <= 2 ifTrue: [^self hash]. > > > ^self inject: self size into: [ :sum :each | (sum + sum + each asciiValue) bitAnd: 16rFFFFFF] > > > > I think this was what the current hash was meant to avoid. Perhaps we > > could change it into something not so expensive, but simply better... > > something that gives you 24 bits of hash. > Someone mentioned a great strings implementation they had done in another language. One of the tricks it use was to cache the hash value: after all, most strings don't change very often. And for some kinds of hashes, you could even incrementally update it whenever someone does at:put:.... -Lex

1 0

Re: sinful bug
by Lex Spoon 03 Aug '00

03 Aug '00

Stephan Rudlof <sr(a)evolgo.de> wrote: > E.g. computing > 1.0e20 sin > works not in ST, but it works directly from a C program. > > I bet the C code gives a useless answer! If not for 1.0e20, then it surely does for 1.0e200. -Lex

1 0

← Newer
1
...
35
36
37
38
39
40
41
42
Older →

Jump to page: