adapting qunfold for the new interface of quapy #9
Conversation
…lection has disappeared from the fit method in favor of X, y
|
Cool, thanks for including qunfold into this update! Are you planning to push the changes into the QuaPy repository, soon? We should reflect this change also in the version numbers that are specified in the |
|
Sure, both solutions you suggest look good to me. Let me finish the tests with the new version of quapy, and merge the branch "nolabelledcollection" into quapy's "devel"; then we can synchronize the compatibility between qunfold and quapy and generate the corresponding releases. |
|
Hi Mirko, sorry for taking so long to get back to this issue... Would it be ok if I assume that version 0.1.5 of qunfold is the first one compatible with the new interface introduced in quapy? By the way, I was wondering — wouldn’t it make more sense to remove qunfold/quapy.py from the qunfold repo and move it into quapy instead, so that quapy can directly control how the wrapper is instantiated based on its own interface? As an example, imagine in the future I change the current order "X, y" with "y, X"; I could handle the wrapper function by myself without having to orchestrate releases. What do you think? As a final note: since I am breaking compatibility with the previous quapy version, for this new quapy release I will move from "0.1.9" -> "0.2.0". Take it into account if you plan to add some conditional code that depends on versioning. Regards! |
I tried to include the current logic of qunfold/quapy.py (i.e., the wrapping funcionality) into quapy, but I then discovered that the current wrapper assumes some inner changes in qunfold. Therefore, this looks like a chicken-and-egg problem, so lets simply keep the wrapper in qunfold and orchestrate releases. |
|
Hi Alex, let me check whether this assumption of inner changes can be circumvented. I would prefer to have the wrapper exclusively in QuaPy, as you suggested. I believe that your suggestion works but I'll have to check how precisely. When is your next release scheduled? Would be nice to include the improved integration of qunfold there. |
|
Nice, thanks.
I was planning to release 0.2.0 during August, but here is no rush.
I tried to include the wrapper code into quapy, but since my version of
qunfold was 0.1.4, there were some inconsistencies (having to do with
class hierarchies) which I could not fix within QuaPy.
El 2025-07-15 18:59, Mirko Bunse escribió:
… mirkobunse left a comment (mirkobunse/qunfold#9) [1]
Hi Alex, let me check whether this assumption of inner changes can be
circumvented. I would prefer to have the wrapper exclusively in QuaPy,
as you suggested. I believe that your suggestion works but I'll have
to check how precisely.
When is your next release scheduled? Would be nice to include the
improved integration of qunfold there.
--
Reply to this email directly, view it on GitHub [1], or unsubscribe
[2].
You are receiving this because you authored the thread.Message ID:
***@***.***>
Links:
------
[1]
#9 (comment)
[2]
https://github.com/notifications/unsubscribe-auth/AELURNCJ675VEUF3Y7K4WUT3IUXOJAVCNFSM6AAAAAB5DL2X76VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANZUGQZTKNRXGQ
--
Alejandro Moreo
Istituto di Scienza e Tecnologie dell'Informazione (ISTI)
Area della Ricerca CNR di Pisa - via G. Moruzzi 1, 56124 Pisa Italy
|
|
Closing this PR for being solved with the new integration between QuaPy v0.2.0 and qunfold v0.1.5; see HLT-ISTI/QuaPy#46 |
2 participants
Hi Mirko,
I'm working on a new version of QuaPy where I've (finally!) removed the cumbersome dependency between LabelledCollection and the quantification methods. The class still exists, but now all quantifiers are trained using:
I've also added a predict method (the old quantify method still works as an alias for the nostalgic).
This PR updates the QuaPy wrapper accordingly. I have not modified the version number of qunfold, assuming you'd prefer to handle versioning yourself.
Let me know if anything needs changing!
Best,
Alex