Skip to Main Content

Data Science & Machine Learning

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Oracle 21c XGBoost "feature not supported"

user8005280Oct 15 2021

XGBoost is a popular and award winning data mining algorithm.
Oracle has implemented it on Oracle 21c by way of an external module. (I think there is an R module behind the scenes). Oracle has re-used and integrated the open source code.
As such, XGBoost is perhaps somewhat different under-the-hood, than other Oracle data mining algorithms.
I have been running data mining algorithms in Oracle 19c (primarily using SVM and random forests) and have just upgraded to 21c and wanted to give XGBoost a try.
I am getting a strange error when running the CREATE_MODEL procedure.
ERROR at line 1:
ORA-40216: feature not supported
ORA-06512: at "SYS.DBMS_DATA_MINING", line 355
ORA-06512: at "SYS.DBMS_DATA_MINING", line 605
ORA-06512: at "SYS.DBMS_DATA_MINING", line 564
"Feature not supported" is quite vague and there is not much information on it.
It could be anything ranging from formatting and exporting the data to the R procedure, to some internal bug in the R procedure, to a whole host of other things.
I do know that the error occurs right away, within one second of calling CREATE_MODEL.
I am using quite a number of DM_NESTED_BINARY_DOUBLES objects in my data table. I don't know if that could be the issue.
If I had access to the Oracle source code, then I could probably find the error myself just by inspecting the code. Some programmer at Oracle has an "if statement" there somewhere and raises that error when a certain condition is not met. The problem would be so easy to solve if I had access to that source code. Probably take me 20 minutes to figure it out. But I do not. It is just this big black box.
Anyway, rather than porting my existing code, that works fine for Random Forests, I am going to have to create an extremely simple stand alone test case -- probably use a data table with 10 columns and 100 rows, and see if there error persists. Probably not. Then incrementally build up the complexity until I can reverse engineer the error. This is not the most efficient way to do things. What could have been 20 minutes is instead 3 or 4 hours. And that is only to find out what the bug is. Then to fix it, who knows.
Sorry for the rant. A generic error such as "feature not supported" simply gives me no information. Whoever programmed that should have done a better job with that error message.
Thank you,

Comments

Frank Kulash
Hi, Rahul,

Starting in Oracle 11.2, you can use a recursive WITH clause (instead of CONNCT BY) to do that easily.

For earlier versions, see this thread:
4092659

n! is a very special case; it can be done without CONNECT BY, XML functions or PL/SQL, like this:
SELECT	ROUND (EXP (SUM (LN (LEVEL))))	AS f
FROM	dual
CONNECT BY	LEVEL <= 10	-- or any positive integer
;
Edited by: Frank Kulash on Apr 18, 2011 11:53 AM

Edited by: Frank Kulash on Apr 18, 2011 11:54 AM
Solomon posted the same ROUND(EXP (SUM( LN ... solution independently, whicle I was posting mine.
Solomon Yakobson
select  round(exp(sum(ln(level)))) factorial
  from  dual
  connect by level <= 10
/

 FACTORIAL
----------
   3628800

SQL> 
SY.
Ganesh Srivatsav
Answer
Try this,
SQL> WITH T
  2       AS (SELECT LEVEL num
  3             FROM DUAL
  4           CONNECT BY LEVEL < = 10)
  5  SELECT num, EXP (SUM (LN (lvl))) factorial
  6    FROM (SELECT LEVEL lvl
  7            FROM (SELECT MAX (num) mx FROM T)
  8          CONNECT BY LEVEL <= mx),
  9         T
 10   WHERE lvl<=num
 11   GROUP BY num;

       NUM  FACTORIAL
---------- ----------
         1          1
         2          2
         3          6
         4         24
         5        120
         6        720
         7       5040
         8      40320
         9     362880
        10    3628800

10 rows selected.

SQL> 
G.
Marked as Answer by Mac_Freak_Rahul · Sep 27 2020
Mac_Freak_Rahul
Thanks Ganesh , SY ,Frank for providing me the answer

Regards
Rahul
pollywog
here is another way
/* Formatted on 10/22/2010 8:28:21 AM (QP5 v5.149.1003.31008) */
SELECT id num, running_total
  FROM DUAL
MODEL RETURN UPDATED ROWS
   DIMENSION BY (0 d)
   MEASURES (CAST (NULL AS NUMBER) id, 1 running_total)
   RULES
      ITERATE (10)
      (id [ITERATION_NUMBER] = ITERATION_NUMBER + 1,
       running_total[ITERATION_NUMBER] =  case  when iteration_number > 1 then id[cv()] * running_total[cv() - 1]else iteration_number+1 end )
NUM	RUNNING_TOTAL
1	1
2	2
3	6
4	24
5	120
6	720
7	5040
8	40320
9	362880
10	3628800
Frank Kulash
Hi, Rahul,

Here's an Oracle 11.2 solution, using a recursive WITH clause:
WITH	f (n, n_factorial)	AS
(
	SELECT	1	AS n
	,	1	AS n_factorial
	FROM	dual
		--
    UNION ALL
		--
	SELECT  n + 1			AS n
	,	n_factorial * (n + 1)	AS n_factorial
	FROM	f
	WHERE	n	< 10
)
SELECT	*
FROM	f
;
Output:
`        N N_FACTORIAL
---------- -----------
         1           1
         2           2
         3           6
         4          24
         5         120
         6         720
         7        5040
         8       40320
         9      362880
        10     3628800
To summarize what (I believe) everyone is saying:

Multiplying a list of numbers (including consecutive integers, generated by CONNECT BY) can be done by the SUM function, together with EXP and LN.
This has been known since the time of the deluge. When Noah brought all the animals out of the ark, and told them to "be fruitful and multiply" (see Genesis 8.17), some of the snakes objected, saying that they were only adders, and couldn't multiply. Noah showed them how to cut tree limbs into pieces, stick four of the peices upright in the ground, and build a horizontal platform on top with the other pieces; then they were all set, because even adders can multiply if they have a log table.

However, multiplying is a special case. When you have a recursive relationship, where the value on one level is based on the value at a previous level, then you can use a recursive WITH clause (starting in Oracle 11.2) or XMLQUERY (in Oracle 10, and up), or write a user-defined function that will take a string such as '1*2*3*4' and return the result of that computation.
MODEL is another option that nobody has mentioned yet. It's probably more work in most cases. (Pollywog did mention it, while I was posting this.)

If the data is not really coming from a table (as is the case here), a user-defined funciton in PL/SQL might be appropriate.
Starting in in Oracle 9, you can write user-defined aggregate/analytic functions.

Edited by: Frank Kulash on Apr 18, 2011 12:32 PM
pollywog
hey I gave a shout out to the model :)
Solomon Yakobson
pollywog wrote:
hey I gave a shout out to the model :)
No need to iterate and no need for CASE:
SELECT  num,
        factorial
  FROM  DUAL
    MODEL
      DIMENSION BY (1 num)
      MEASURES (1 factorial)
      RULES (
             factorial[for num from 2 to 10 increment 1] =  cv(num) * factorial[cv() - 1]
            )
/

       NUM  FACTORIAL
---------- ----------
         1          1
         2          2
         3          6
         4         24
         5        120
         6        720
         7       5040
         8      40320
         9     362880
        10    3628800

10 rows selected.

SQL> 
SY.
MichaelS
One more for the record:
SQL> select rownum - 1 n, to_number(column_value) factorial
  from xmltable('declare function local:fac ($i) {
                          if ($i = 0) then
                           1
                          else
                           $i * local:fac($i - 1)
                        }; (::)
                        for $i in 0 to 10 return local:fac($i)')
/
         N  FACTORIAL
---------- ----------
         0          1
         1          1
         2          2
         3          6
         4         24
         5        120
         6        720
         7       5040
         8      40320
         9     362880
        10    3628800

11 rows selected.
1 - 9

Post Details

Added on Oct 15 2021
3 comments
486 views