Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours:
http://lists.squeakfoundation.org/pipermail/packages/2012-April/005306.html Name: Monticello-eem.505 Ancestors: Monticello-bf.504 Simple history search for the working copy browser. Open a Workspace containing all the history (version summaries) for the current package. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2012-April/005307.html Name: Kernel-nice.652 Ancestors: Kernel-laza.649 PURPOSE: Any Float now prints with the minimal number of digits that describes it unambiguously. This way, every two different Float will have a different printed representation. More over, every Float can be reconstructed from its printed representation with #readFrom:. self assert: ([:f | f isNaN or: [(Float readFrom: f printString) = f]] value: Float someInstance). Note that Float nan, Float infinity and Float infinity negated still print as 'NaN' 'Infinity' and '-Infinity' which are compatible with #readFrom:. RATIONALE: the old behaviour was obscuring our data like for example: 0.1 successor printString = 0.1 printString. 1.0e-100 printString = '9.99999999999999e-101'. The old behaviour was returning many digits without any guaranty of exactness which is useless. The old behaviour was faster (x4) but this is less relevant than exactness. Similar or better speed should be obtained by controlling number of printed digits if we can afford inexactness. IMPLEMENTATION: The essential change was to use #absPrintExactlyOn:base: in #printOn:base: Side note: this is really a bad name, because it prints the shortest base-representation, not the exact one. Anyway, we can only print the exact one in even bases. For example, the exact representation of 0.1 in base 10 is: 0.1 asFraction asScaledDecimal = 0.1000000000000000055511151231257827021181583404541015625s55. The second change was to marginally fast-up #absPrintExactlyOn:base: main loop by avoiding a #not send and piping decimal point test. Avoiding the #not makes the intention a tiny bit clearer. Also of few formatting has been performed in the last lines. REJECTED CHANGES: It is possible to move self > 0.0 before self isNaN to statistically reduce the number of tests performed. This works because Float nan > 0.0 = false. But this speed-up is quite marginal. Similarly (self = Infinity) could replace (self isInfinite) and save another send and also another test (because NegativeInfinity can't happen at this stage). This would be at the price of a class var reference leak. It could be more interesting to move this #isInfinite test in #printOn:base: in order to gather print rules for exceptional values. I didn't to avoid duplicating the test in the two branches > 0.0 and < 0.0. A far more efficient speed-up would be to optimize LargeInteger arithmetic. I think there is room, the VM is still using byte operations (thus at most 16 bits). ============================================= http://lists.squeakfoundation.org/pipermail/packages/2012-April/005308.html Name: Kernel-nice.683 Ancestors: Kernel-eem.682, Kernel-nice.652 Merge with nice.652 (Float unambiguous printing). ============================================= http://lists.squeakfoundation.org/pipermail/packages/2012-April/005309.html Name: Kernel-eem.684 Ancestors: Kernel-nice.683 Implement endPC numArgs and numTemps for closures and contexts (both block and method activations). Provide CompiledMethod>abstractBytecodeMessagesDo: et al. Implement BlockClosure>isClean to identify self-contained blocks. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2012-April/005310.html Name: Tests-eem.151 Ancestors: Tests-ul.150 Add tests for BlockClosure>isClean ============================================= |
Free forum by Nabble | Edit this page |