| Anonymous | Login | Signup for a new account | 2020-01-21 03:18 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 | OS | OS 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 |  llFloor-precision-problem.patch [^] (1,129 bytes) 2012-08-15 04:08 [Show Content]
| |||||||||
 Relationships |
|
 Relationships |
|
Notes |
|
|
(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. |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2012-08-18 04:32 | DMX04 | New Issue | |
| 2012-08-18 04:32 | DMX04 | Issue generated from: 0006160 | |
|
Issue History |
| Copyright © 2000 - 2012 MantisBT Group |
 |