i'm using Scispacy (which is awesome!) but when I type 'tau' into the app found here https://scispacy.apps.allenai.org/
the UMLS entity gives me the canonical name of 'MAPT gene' which is what I want.
But when I do the exact same thing in my python code based on the app code (see here https://gist.github.com/DeNeutoy/b20860b40b9fa9d33675893c56afde42)
the first canonical name on the list is 'uridine triacetate' (the second is 'MAPT gene')
in the app code there is the call 'if show_only_top:break' so I assume somehow their app implementation orders the linked entities differently.
if someone can explain the difference in ordering and how to fix that would be great thanks!!
This question was also asked on github (https://github.com/allenai/scispacy/issues/344), and answered there, but I am including the answer below in case anyone ends up here.
The demo app is not currently running the latest version of scispacy, and the inconsistent ordering of the entities was an issue that was fixed in scispacy version 0.4.0.
I'm using tf.io.decode_proto to parse some custom protobufs in a way that can be used inside #tf.functions. This seems to work fine when accessing message fields, but it raises an unknown field error when trying to access something declared as a oneof (not the fields inside it).
Is there any way to get something similar to proto.WhichOneof(oneof_field) using tf.io.decode_proto? If possible I'd rather avoid getting all possible fields inside the oneof and iterating them to see which one (if any) has non-empty data.
I don't know of any workarounds, but a good way to resolve this is to fix the op itself; the error probably comes from here. It's worth filing an issue to see if anyone might be able to help.
I'm making the transition from VB6 to VB.Net (VS 2010) and have a basic rather than expansive understanding of the latter. I obviously have quite a bit of code to... I hesitate to use the word "upgrade" when "port" would be more apt given that the upgrade wizard in past versions of VS may as well have just commented out the code and said "Hey, why don't you re-start from scratch?"
In one procedure which I'm bringing across the Len() function was used to determine the length of a string variable. That still works in VB.Net (though I imagine that it's actually a call to the Strings.Len Method), but the other alternative is to just query the .Length property of the variable.
The question is which to use and why. I've looked through the relevant MSDN pages and all they seem to tell me is that the method/property exists. Nothing is said about performance issues, particularly when loops of large numbers of calls might be involved.
My question, then, is whether anyone is aware of any tested and confirmed benefit of using one approach over the other, or whether it's merely a question of personal preference. Any pointers on similar situations that I might encounter as I make the progression would also be appreciated though given the Stack Overflow guidelines it's just this one issue that I'm interested in seeing whether there's a specific answer to.
Because you're using VB.NET, your Strings can be Nothing and unless you explicitly check for that, most VB methods, including Len, will treat it the same as String.Empty i.e. "".
With Reflector you can see Len is implemented as a null check, returning 0 for Nothing and otherwise returning .Length, and the JITter will likely in-line the call.
So, if you're using other VB methods, I'd suggest using Len too, unless you know the String is not Nothing or check for Nothing everywhere.
So according to this:
Len, another classic BASIC function, returns the length of a string. System.String has the Length property that provides the same information. Is one better than the other?
Performance-wise, these two functions show little difference over 1000’s of iterations. There doesn’t appear to be any reason to prefer one over the other in this case plus there is no functional difference. I’m kind of partial to using the property value rather than the VB function since it encourages thinking of .NET strings as objects. However, at the core, it’s really only a personal preference thing.
If you trust their word, then there's your answer. Otherwise, coding up a test and iterating should give you the final answer.
I'm not sure about the specifics of the Len() method (my language of choice is C#), but I would say definitely go with the Length property. Length is a member of the System.String class, whereas Len() isn't.
My guess is that Len() is just a VB shim on top of the Length property. Someone could probably make the argument that using Len() is more idiomatic, from a VB point of view. I think I'd prefer to use the property built in to the class, rather than just use a different mechanism just because it's provided by the language.
The Len method is provided for backwards compatibility with old VB6 (and earlier) non-.NET code. There's nothing technically wrong with using it. It will work, and just as well, at that. But, it's better to use the new .NET way of doing things whenever possible. Outside of getting you more into the ".NET mindset", though, the only real tangible benefit of using String.Length is that it makes it easier to port the code to other .NET languages in the future.
In addition to #Andrew's post, the Len() is string function from Visual Basic run-time library where as Length is a property of System.String class of .net framework API.
Recently I faced problem with my old VB.Net code that was using Len() function. I upgraded my project to Core which was referencing the old VB.net dll file and it was using Len() function. I got run time compatibility error - Method not found: 'Int32 Microsoft.VisualBasic.Strings.Len(System.String)'
I have to change all such old function that Core has deprecated. So I stand by using String.Length over Len() as suggested by Steven Doggart.
I am calling the OTA API from HP Quality Centre and one of the calls requires sending a NULL.
This is the actual line of code:
stepF.AddItem(NULL)
This works perfectly in VBA and VB6 but VB.NET doesn't accept Nulls. Anyone know how to fix such an issue?
You need to use Nothing, which is mostly equivalent to null.
Nothing is the Null value for most reference types in VB.Net, I would recommend taking a look at Nullable(Of T) on either MSDN or some good information about it in this SO post, if the API you are using is a .Net web service you may be able to partial class the WSDL and fix although it sounds as though you are not.
The correct value to use is System.DBNull.Value.
Even if the documentation tells us that this is generally used for database null values, it represent the absence of value, otherwise NULL.
You should use DBNull
We've got Localsolr (2.9.1 lucene-spatial library) running on Solr 1.4 with Tomcat 1.6. Everything's looking good, except for a couple little issues.
If we specify fl=id (or fl= anything) and wt=json it seems that the fl parameter is ignored (thus we get a lot more detail in our results than we'd like).
If we specify fl=id and leave out wt=json (which defaults to returning xml results), we get the expected fields back. We'd really prefer to use wt=json because the results are easier for us to deal with (also, the same issue also arises with wt=python and wt=ruby).
Ideas? Known issue? Workarounds?