Author Topic: FORMAT implementation (question regarding ANY)  (Read 3334 times)

0 Members and 1 Guest are viewing this topic.

Brian Alvarez

  • Guest
FORMAT implementation (question regarding ANY)
« 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:

Code: [Select]
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. :)

 

Charles Pegge

  • Guest
Re: FORMAT implementation (question regarding ANY)
« Reply #1 on: October 04, 2018, 03:17:54 PM »
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)

Code: [Select]
function format(double d, string f="") as string
return str(d)
end function

short b=-1
print format b

Brian Alvarez

  • Guest
Re: FORMAT implementation (question regarding ANY)
« Reply #2 on: October 04, 2018, 03:48:15 PM »
 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.

Brian Alvarez

  • Guest
Re: FORMAT implementation (question regarding ANY)
« Reply #3 on: October 04, 2018, 04:14:20 PM »

With the method you suggest works but gives wrong result. passing a single variable containing 1.1 displays an integer: 1

Brian Alvarez

  • Guest
Re: FORMAT implementation (question regarding ANY)
« Reply #4 on: October 04, 2018, 04:21:09 PM »
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.

Brian Alvarez

  • Guest
Re: FORMAT implementation (question regarding ANY)
« Reply #5 on: October 04, 2018, 04:29:12 PM »

 Hmm in fact, it is str the one rounding the values.

Code: [Select]
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.

Brian Alvarez

  • Guest
Re: FORMAT implementation (question regarding ANY)
« Reply #6 on: October 04, 2018, 04:31:22 PM »
Tried...

Code: [Select]
somestring = str(123.5, 5)
now somestring contains "124"

 I think i got a bad o2 build. Updated today i think.

Charles Pegge

  • Guest
Re: FORMAT implementation (question regarding ANY)
« Reply #7 on: October 04, 2018, 11:39:53 PM »
It looks like you have an intermediate integer somewhere. This is normal rounding up.

Brian Alvarez

  • Guest
Re: FORMAT implementation (question regarding ANY)
« Reply #8 on: October 05, 2018, 09:18:04 AM »
this last one looks like a direct conversion, where can the integer be?

Brian Alvarez

  • Guest
Re: FORMAT implementation (question regarding ANY)
« Reply #9 on: October 05, 2018, 09:42:23 PM »
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.

Charles Pegge

  • Guest
Re: FORMAT implementation (question regarding ANY)
« Reply #10 on: October 06, 2018, 12:17:10 AM »
Brian,

I've tested these:

The autoconversion does what it is meant to do

Code: [Select]
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)
« Last Edit: October 06, 2018, 02:49:19 AM by Charles Pegge »

Brian Alvarez

  • Guest
Re: FORMAT implementation (question regarding ANY)
« Reply #11 on: October 06, 2018, 10:21:37 AM »
can you test with the latest oxygen? I will update again today.

Brian Alvarez

  • Guest
Re: FORMAT implementation (question regarding ANY)
« Reply #12 on: October 06, 2018, 10:29:08 AM »
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:

Code: [Select]
'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

Charles Pegge

  • Guest
Re: FORMAT implementation (question regarding ANY)
« Reply #13 on: October 06, 2018, 12:30:23 PM »
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.

jack

  • Guest
Re: FORMAT implementation (question regarding ANY)
« Reply #14 on: October 06, 2018, 05:37:54 PM »
could the FPU rounding mode be responsible?
perhaps some other code set the rounding mode to cause the unexpected result