Oxygen Basic
Programming => Problems & Solutions => Topic started by: Brian Alvarez on October 04, 2018, 01:54:20 PM
-
I am trying to implement the FORMAT function, and i obviously need to pass as a parameter a numeric value of either long, or single (or any other integer or floating point type) variable or numeric expression. As a rudimentary test function i have the following:
FUNCTION FORMAT(any d, string f = "") AS STRING
FUNCTION = str(d)
END FUNCTION
Passing d as a numeric literal 1 works, but passing 1.1 doesnt display anything. So, the question is, how can i access floating point values of a variable like this? I am guessing pointers, but how do i recognize that it contains a floating point value and not another thing?
Same goes for f variable, i would like to pass either an integer (representing the number of decimals) or a string containing the formatting string.
Thanks for any help. :)
-
Hi Brian,
You can pass the value as double. o2 will then autoconvert any parameter expression to this type before calling.
(problems with byte and sbyte to be fixed)
function format(double d, string f="") as string
return str(d)
end function
short b=-1
print format b
-
There is an error (or several) somewhere.
When compiling it to 32bit exe using a literal 1, gives me a 4-button error message box (im trying to avoid those!) + wrong result.
When compiling it in 64 bit mode it gives me a wrong result. Attaching images of it.
When compiling it using a SINGLE variable containing 1.1, no error s are displayed, but wrong formated number (1066192077) is displayed.
-
With the method you suggest works but gives wrong result. passing a single variable containing 1.1 displays an integer: 1
-
Passing a 1.6 rounds it to 2.
By the way, the error message box i am guessing its because of different MessageBoxA declarations. I will check those later.
-
Hmm in fact, it is str the one rounding the values.
str(-1.6) displays -2
str(1.6) displays 2
storing the value to string first gives the same result, so, im sure the value is not being passed through any other filters or conversions.
-
Tried...
somestring = str(123.5, 5)
now somestring contains "124"
I think i got a bad o2 build. Updated today i think.
-
It looks like you have an intermediate integer somewhere. This is normal rounding up.
-
this last one looks like a direct conversion, where can the integer be?
-
I refreshed this thread like a hundred times today. I need to be
able to monitor the values of many functions to start converting
them to Oxygen. Please let me know when a fix is ready, or an
example of how to do it correctly.
-
Brian,
I've tested these:
The autoconversion does what it is meant to do
function format(double d, string f="") as string
return str(d)
end function
print format(1.4+1.1) '2.5
short b=-1
print format(b)
string b=130.5
print format(b)
-
can you test with the latest oxygen? I will update again today.
-
I made a copy-paste of your code, just changed the name of "format" to "formt" to avoid internal collisions,
i get 3 messageboxes, first displays 2, second displays -1 and the third one displays 130.
The following is the exact code being compiled:
'Generated with PluriBASIC 6.0.74371.0
$ filename "hello_world.exe"
uses rtl64
' STARTS STR$.BIN
' Enter the stock code and functions here.
' END OF STR$.BIN
' STARTS PLURIBASIC_INIT.BIN
' Enter the stock code and functions here.
' END OF PLURIBASIC_INIT.BIN
' STARTS CALLBACKDATA.BIN
' CALLBACK data
' END OF CALLBACKDATA.BIN
' STARTS ENTRY_POINT.BIN
' Enttry point code
' END OF ENTRY_POINT.BIN
' Initializes various things in the script.
FUNCTION PluriBASIC_Initialize() AS LONG
END FUNCTION
function formt(double d, string f="") as string
return str(d)
end function
FUNCTION PBMAIN() AS LONG
DOUBLE d
STRING s
d = 1.6
s = STR(d)
print formt(1.4+1.1)
short b= -1
print formt(b)
string b=130.5
print formt(b)
END FUNCTION
PBMAIN() ' invoke entry point
-
Hi Brian,
Your program works correctly here with several different versions of oxygen.dll (earliest march 2018). I am mystified as to why your results are rounded.
-
could the FPU rounding mode be responsible?
perhaps some other code set the rounding mode to cause the unexpected result
-
Yes, that is a possibility.
Brian, you can test this by adding finit to the start of o2 programs.
Asm instruction finit sets the FPU to its default settings.
-
sure.
Same results. I will try to get a different DLL. maybe mine is faulty.