[Info-vax] New VSI Roadmap (yipee!)

[Stephen Hoffman]

On 2015-03-01 20:52:57 +0000, John Reagan said:

> On Sunday, March 1, 2015 at 10:07:48 AM UTC-5, Stephen Hoffman wrote:
>> On 2015-03-01 04:33:55 +0000, John Reagan said:
> 
>>> Rounding floating point to certain number of decimal places?  That> > 
>>> doesn't make sense.  Floating numbers are exact.  1.23 isn't really> > 
>>> 1.23 but something close to it.  I don't know what a float-to-float> > 
>>> rounding does?
>> 
>> Z = 1.2345678
>> Z = FRound( Z, 2%)
>> Z = 1.23
>> Z = 1.2378
>> Z = FRound( Z, 2%)
>> Z = 1.24
> 
> I know.  You want to throw away fractions of a penny or pick up 
> fractions of a penny.

I ended up overhauling the code involved with my own most recent 
encounter with floating point used for cash storage.  Switching to 
integer made the totals match to the penny which made the accountants 
understandably giddy, and sped up the code.  Coincidentally, that 
package was written in BASIC.

> If you want to "create" money, go mine for Bitcoin.

More like throwing away money buying and powering the mining rigs, but 
I digress.

> The reality is that the routine overhead is small compared to the 
> floating/integer operations involved.  There is no simple instruction 
> sequence to do that (since it isn't something people do with normal 
> floating point data), it will always be slow.  I would think that GEM 
> would inline that routine if it was defined in the same module.

It'd be interesting to get some details on GEM optimizations someday — 
there was specific behavior in C around functions not declared static 
not being inlined, IIRC.  What BASIC does here, I'd not want to hazard 
even a guess.  Fodder for your boot camp presentations.  :-)

It'd also be interesting to instrument and figure out why the code was 
so slow, and if there was a way to optimize it.   David: tried checking 
for alignment faults (if Itanium) or other nasties?


-- 
Pure Personal Opinion | HoffmanLabs LLC