Integer#printPaddedWith:to:base: and the associated convenience method Integer#printPaddedWith:to: are not currently implemented; these methods aren't in the ANSI standard, but are in VW and Squeak.

More importantly, Integer#printPaddedWith:to:base: is used in the HTTP class of the packaged version of Swazoo; hence, I'm submitting this issue as a bug rather than a feature request.

Hi,

I cann add a Float >> NaN in a dictionary by the way multiple times (

st> p at: (FloatQ allInstances at: 3) put: 123
st> p at: (FloatQ allInstances at: 3) put: 123
st> p at: (FloatQ allInstances at: 3) put: 123
st> p
Dictionary (

       NaN->123
       NaN->123
       NaN->123

)

)

But when I try to acces to it, it failed :

Object: Dictionary new: 32 "<0x2b1783097a40>" error: Invalid argument Inf: key not found
SystemExceptions.NotFound(Exception)>>signal
SystemExceptions.NotFound(Exception)>>signal:
SystemExceptions.NotFound class>>signalOn:what:

Hi Paolo here the the stack trace when I've tried to send displayString a Float (I am not sur if it was NaN)

Object: -inf error: Infinity can only be a Float
ArithmeticError(Exception)>>signal (AnsiExcept.st:216)
ArithmeticError(Exception)>>signal: (AnsiExcept.st:226)
FloatD(Number)>>arithmeticError: (AnsiExcept.st:1526)
FloatD(Float)>>checkCoercion (Float.st:470)
FloatD(Float)>>floor (Float.st:633)
FloatQ(Float)>>floorLog: (Float.st:360)
FloatQ(Float)>>printOn:special: (Float.st:502)
FloatQ(Float)>>printOn: (Float.st:430)
FloatQ(Object)>>displayOn: (Object.st:505)

The pi example gave me a clue.

st>3.1415926535897932384626433832795028841971693993751058209749445923078164062862q sin exponent
-61
st>-1.0q arcCos sin exponent
-64

What, I lost three bits?
Hmm fairly sure about my 256bits approximation of pi though...

st>-1.0q arcCos
3.1415926535897932385
st>3.1415926535897932385q
3.1415926535897932383
st> 3.1415926535897932385q sin exponent
-63

Yes, there might be a problem for reading these extended precision.

I get a surprising result:

st> FloatD pi sin abs < FloatQ pi sin abs.
true

Let pi be an exact representation.
I expect (pi - FloatD pi) abs > (pi - FloatQ pi) abs
And thus same relation-ship between sin...

I suspect FloatQ pi is not the nearest to pi:
st> (FloatQ class>>#pi) methodSourceString
'pi [

       "Returns the value of pi. Hope is that it is precise enough"

       
       ^3.1415926535897930885169542232694q
   ]'

In contrast, the first decimals I compute are: