Does appear to be a "quality of implementation" issue. Hadn't ever used it w/ the negative optional argument but looks like does have some artifacts, not clear quite where this one would come from. Since it's builtin function can't see implementation but that's what it looks like happens...altho for this input the "deadahead"
>> fix(100000/1E5)*1E5
ans =
100000
>>
works so not sure what must be going on internally.
Looks to me to be worth a bug report.
A workaround I'm sure you've already thought of is to wrap the call in another round...
>> round(round(100000,-5))
ans =
100000
>>
Best Answer