Anonymous | Login | Signup for a new account | 2021-01-28 03:50 PST | ![]() |
Main | My View | View Issues | Change Log | Roadmap | Summary | My Account |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | |||||
0006180 | opensim | [REGION] Script Functions | public | 2012-08-15 04:08 | 2012-08-18 04:32 | |||||
Reporter | SignpostMarv | |||||||||
Assigned To | ||||||||||
Priority | normal | Severity | major | Reproducibility | always | |||||
Status | patch included | Resolution | open | |||||||
Platform | Operating System | Operating System Version | ||||||||
Product Version | master (dev code) | |||||||||
Target Version | Fixed in Version | |||||||||
Summary | 0006180: llFloor operates on doubles rather than floats, producing differences in expected results | |||||||||
Description | The repro script indicates 27 for all values in Second Life, whereas OpenSim indicates 27 for the value of a and 26 for the llFloor() results. The attached patch changes the behaviour of llFloor() in OpenSim to match the behaviour of llFloor() in Second Life | |||||||||
Steps To Reproduce | default { touch_start(integer t) { float a = 26.9999995; llSay(0, llList2CSV([ a, llFloor(a), llFloor(26.9999995) ])); } } | |||||||||
Tags | No tags attached. | |||||||||
Git Revision or version number | dc82ad0 | |||||||||
Run Mode | Standalone (1 Region) , Grid (1 Region per Sim) | |||||||||
Physics Engine | BasicPhysics | |||||||||
Script Engine | ||||||||||
Environment | .NET / Windows32, .NET / Windows64 | |||||||||
Mono Version | None | |||||||||
Viewer | ||||||||||
Attached Files | ![]() | |||||||||
![]() |
|
(0022136) justincc (administrator) 2012-08-15 14:26 |
It seems to me that this points to a more fundamental issue. If llFloor() is cast internally from double to float then llCeil(), llRound(), etc. should be as well. But then one could ask why LSL_Float was modelled internally using a double rather than a float and save all this and future casting. |
(0022137) SignpostMarv (reporter) 2012-08-15 14:32 |
26.9999995 should ceil to 27 is 26.9999995 or float-cast to 27. I can only think llRound would have issues if it was fed a double greater than 0.5 that typecast to float would be less than 0.5 |
(0022138) justincc (administrator) 2012-08-17 15:55 |
No, there are other cases. For instance, in SL default { touch_start(integer t) { float a = 27.0000002; llSay(0, llList2CSV([ a, llCeil(a), llCeil(27.0000002) ])); } } Object: 27.000000, 27, 27 but will return Primitive: 27.000000, 28, 28 because SL casts the literals to floats with less precision than doubles. It wouldn't surprise me if there were lots of examples of this though I admit I haven't looked further. |
(0022139) justincc (administrator) 2012-08-17 15:56 |
Which is why I think it would be much better to cast these straight off to floats rather than doubles if one really wants to be LSL compliant. Whether this is a good idea or not is another question. |
![]() |
|||
Date Modified | Username | Field | Change |
2012-08-18 04:32 | DMX04 | New Issue | |
2012-08-18 04:32 | DMX04 | Issue generated from: 0006160 |
Copyright © 2000 - 2012 MantisBT Group |